Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The Rust I wanted had no future

graydon2.dreamwidth.org

Post reply on HN
Print view View original

251–260 of 523 posts

Re: The Rust I wanted had no future

#251

Post by [deleted] »

rob74 wrote: post #15
moonchrome wrote: post #8

As someone casually following Rust and haven't touched it or C++ in probably 5+ years (but keeping tabs in hope of coming back to that world), I feel like a lot of decisions he mentions are what made me optimistic about Rust adoption/positioning itself as a modern C++ replacement. So I kind of agree with his conclusion - his version of Rust would be much less interesting to me, and I think a lot of it's current users…

I think this quote also applies more generally: > It's easier to work with than C++, but that's fairly faint praise. So, while Rust positions itself as a C++ alternative with all the complexities that C++ developers love, it may become less attractive for other use cases. For instance, I find it highly questionable to develop a web app in Rust...

[deleted]

Re: The Rust I wanted had no future

#252

Post by svieira »

> Not 100% clear about actors -- I was weirdly focused on that model that in practice has many issues

Does anyone have any insights on the particular issues with actor-based concurrency vs. "direct parallelism like threads or locks" that he might be thinking about here?

Re: The Rust I wanted had no future

#253

Post by badrequest »

dataflow wrote: post #244
hardwaregeek wrote: post #222

A lot of Graydon's ideas feel like interesting extensions to ML-style languages. I bet if he had continued down that path, it would have been a lot more of an experimental language with a hodgepodge of different ideas. Which is totally valid (you need these languages to test new paradigms and features), but definitely would not have become mainstream. Basically, I view Grayson as a leader who set the tone for Rust be…

> Rust ending up as a replacement C++ helped it If anything, it's more a C replacement than a C++ replacement. It will take some market share from both of course (and other languages to a lesser extent too), but functionality-wise, it just isn't (currently, at least) practically able to replace some C++ use cases.

I'm interested in more on this. What can I do in C++ that I can't do in Rust?

Re: The Rust I wanted had no future

#254

Post by zanellato19 »

moth-fuzz wrote: post #239
pornel wrote: post #18

Earlier quoted context omitted.

Function coloring article conflated two things: one was legitimate limitation of JS unable to wait for async result from sync call, and the other was just author's opinion how the syntax should look like. Rust's async doesn't have the limitation author described – you can spawn and block both (Tokio has some limits there, but that's Tokyo's choice, not language limitation), making "color" largely irrelevant. The seco…

You can't evaluate a future in normal rust as there's no default executor, you need to pull in some library to even make blocking calls to async functions. IMO, this is even worse than function coloring.

You can also make your own executor. That's exactly how it was intended.

Re: The Rust I wanted had no future

#255

Post by duped »

fzeindl wrote: post #205
sph wrote: post #6

Very interesting insight from Graydon, in hindsight I too would have loved something more towards ML than C++. I never liked the kitchen sink approach that I see first C++, now Rust moving towards, but I respect what Rust has managed to solidify into. It's a good language. That said, I still hate async with a passion, it makes the language more complex and not very elegant (i.e. function coloring). And now that I kno…

I hate async as well. Developers should have learned about communicating sequential processes and blocking queues and none of that would have been necessary. It creates a weird divide in every language. Just learn about threading and do it. A nice talk about this: https://www.reddit.com/r/programming/comments/da141r/ron_pre...

Developers should learn the difference between concurrency and parallelism because async isn't equivalent to threading.

Re: The Rust I wanted had no future

#256

Post by dooglius »

Aissen wrote: post #172
jedisct1 wrote: post #133

Earlier quoted context omitted.

And then you may just have introduced side channels in crypto code.

> And then you may just have introduced side channels in crypto code. incorrect crypto code. If overflow is intentional, it should be annotated as such in operations, will generate similar assembly and won't panic. If it isn't intentional, then the code was bad to begin with.

If the branch can be mispredicted, and the misprediction happens depending on internal state you don't want to leak (cf. Spectre), then you have a side channel even if the branch is never actually taken.

Re: The Rust I wanted had no future

#257

Post by unrealhoang »

sph wrote: post #32
moonchrome wrote: post #8

As someone casually following Rust and haven't touched it or C++ in probably 5+ years (but keeping tabs in hope of coming back to that world), I feel like a lot of decisions he mentions are what made me optimistic about Rust adoption/positioning itself as a modern C++ replacement. So I kind of agree with his conclusion - his version of Rust would be much less interesting to me, and I think a lot of it's current users…

It makes me smile that my top-level comment says I would have preferred the ML-version of Rust, while you say you prefer the zero-cost-abstraction version of Rust that's more C++-like. Indeed in software engineering there is no silver bullet nor a perfect language for everybody :-)

There’s already a ML-version of Rust, it’s Ocaml

Re: The Rust I wanted had no future

#258

Post by mrkeen »

duped wrote: post #249
javajosh wrote: post #162

Too bad graydon didn't get his way with build times. I've come to believe that the most important feature of any development environment is to minimize the built-test-debug cycle. Of course, a real system has many different ones, ranging from "language level" to "I have to redeploy and perform a complex series of actions in an app or 3". But at the language level I've found that build performance is of paramount impo…

On top of this, there's this bogus mantra in the Rust community that "if it type checks then it works." I've spent of hours interactively debugging Rust code, crawling through tracing output etc, and hours waiting for Rust code to link with mold because I added an eprintln somewhere, so I'm not convinced. I love writing Rust and think it makes my life easier, but there's this stockholm syndrome about compile times. I…

> there's this stockholm syndrome about compile times. It sucks, and it's not the type system or borrowchecker's fault.

What do you mean?

Re: The Rust I wanted had no future

#259

Post by throwaway2037 »

FpUser wrote: post #224
tick_tock_tick wrote: post #31

Earlier quoted context omitted.

> it may become less attractive for other use cases. For instance, I find it highly questionable to develop a web app in Rust... I mean who'd want to and why bother trying to support that use case? Basically none of Rust's value proposition exists for a web app while nearly every single one of the downsides do.

>"I mean who'd want to and why bother trying to support that use case" I write my web apps in C++. They tend to be little bit more than just query database / update database. They're exposed as JSON based RPC and can be accessed by JS front end from browser or third party systems we interact with. The performance is stellar and the code size is not much different comparatively to using PHP / Ruby / Python / your_pet_…

Nice. Do you have some open source samples? I would like to see your style!

Re: The Rust I wanted had no future

#260

Post by pitaj »

weinzierl wrote: post #125

One thing I wished was on this list, but wasn't, is syntax. I love many syntax decisions Rust made, but I wish Rust hasn't borrowed so much syntax from C/C++. The syntax of these languages was designed under (for todays standards) weird keyboard and encoding constraints and many choices are just odd. To give you a few examples: - = instead of == for equality would have been the natural choice - := for assignment is s…

Assignment is more common than equality. Typing two identical sequential characters "==" is much easier than typing ":=" especially since on most keywords colon requires shift and equal does not. And having a two-character equality operator helps align things with "!=", ">=", "<=".
Post reply on HN