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

61–70 of 523 posts

Re: The Rust I wanted had no future

#61

Post by davedx »

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…

That being said... python had a BDFL and look how that turned out.

I think designing and evolving any living programming language is just one of the hardest problems out there.

Incredible blog post indeed, was awesome to read it.

Re: The Rust I wanted had no future

#62

Post by sanxiyn »

wuiheerfoj wrote: post #16
elcritch wrote: post #3

Earlier quoted context omitted.

One highlight from the article: > Traits. I generally don't like traits / typeclasses. To my eyes they're too type-directed, too global, too much like programming and debugging a distributed set of invisible inference rules, and produce too much coupling between libraries in terms of what is or isn't allowed to maintain coherence. Very much this! > I wanted (and got part way into building) a first class module system…

May I ask what you don’t like about traits (and perhaps insight on what the author meant)? Being a relative rust noob compared to other languages, I always felt traits were a super power when compared to eg interfaces in Java/C++ and flexible but with useful constraints compared to the structural typing nature of Typescript interfaces

In a trait-like system (including Java interface), there can be only one implementation of a trait for a type. That's why it is global, unlike ML module-like systems. Global is another word for anti-modular.

For example, in the real world, there are multiple ways to order strings (called collation), but since there can be only one implementation of (String, Ord) type-trait pair, one ordering is canonical. That may be bearable, but having canonical (String, Hash) implementation is not. What if you want to use (say) faster CityHash instead of canonical MurmurHash? So Rust resorts to things like BuildHasher, to get back multiple implementations.

Because it is global/anti-modular, it interferes with separate compilation, and it is one of reasons why Rust is slow to compile.

Then why would one use trait instead of module? Since there can be multiple implementations in module, you need to specify. So module is more verbose. In my (and Graydon's) opinion, a bit more verbosity is worth it for modularity, but many people disagreed.

This is another theme: Graydon is okay with verbosity, boilerplate, and being bureaucratic. In my (and Graydon's) opinion, programming is work that is secretarial, not artistic, so it is unimportant whether code is ugly or not. You may think current Rust is ugly, but no, it is the way it is because lots of people really cared about Rust code being pretty. If Graydon was a BDFL, Rust would be even more ugly, and in my opinion, as a result, would be a better programming language.

Re: The Rust I wanted had no future

#63

Post by masklinn »

ZephyrBlu wrote: post #56

This is an interesting read, because I read it as "I would have done all these things which would have kept the language more pure to my vision but less accessible". I also found this bit interesting: "It's easier to work with than C++, but that's fairly faint praise". I see this kind of thing in my own personal projects all the time. I'm thinking "oh it would be really cool if I built X" when in reality most of the…

Note that the quote is specifically about parsing Rust syntax, it’s not about the language in general (which is a lot easier and safer to work in than C++).

Re: The Rust I wanted had no future

#64

Post by giraffe_lady »

elcritch wrote: post #3
jstx1 wrote: post #2

A bunch of things you don't like about Rust? Turns out that the person who originally created the language doesn't like them either. I know that the main point is about governance and how having a BDFL would have led to a completely different language but I really would have preferred the Graydon-BDFL-Rust to what we have today. Very interesting article, worth a read.

One highlight from the article: > Traits. I generally don't like traits / typeclasses. To my eyes they're too type-directed, too global, too much like programming and debugging a distributed set of invisible inference rules, and produce too much coupling between libraries in terms of what is or isn't allowed to maintain coherence. Very much this! > I wanted (and got part way into building) a first class module system…

I loved reading that part! I've always found ocaml's (and now rescript's) first class modules flexible and powerful. They're definitely awkward but in that way where you're having to explicitly think about and declare relationships you'd happily ignore until they bite you.

Recently I've seen a lot of programmers I respect consider them a weaker or failed alternative to typeclasses, basically a dead-end. And I had been reluctantly coming to the conclusion that I must be wrong in some way I'm not able to fully perceive yet. Seeing such a notable PL designer come out on their side makes me feel less like a fool.

Re: The Rust I wanted had no future

#65

Post by ZephyrBlu »

masklinn wrote: post #63
ZephyrBlu wrote: post #56

This is an interesting read, because I read it as "I would have done all these things which would have kept the language more pure to my vision but less accessible". I also found this bit interesting: "It's easier to work with than C++, but that's fairly faint praise". I see this kind of thing in my own personal projects all the time. I'm thinking "oh it would be really cool if I built X" when in reality most of the…

Note that the quote is specifically about parsing Rust syntax, it’s not about the language in general (which is a lot easier and safer to work in than C++).

True, but I feel like the sentiment generalizes very well. I'm sure that C++ is perceived to have a similarly low bar in many areas.

Re: The Rust I wanted had no future

#67

Post by dathinab »

One thing I want to add wrt. "Cross-crate inlining and monomorphization. I wanted crates to allow inlining inside but present stable entrypoints to the outside." [..] is that it was in general well desired AFIK by most developers but so far out of scope that you probably would need to had the resources rust has today _before_ the 1.0 release to get it done right. At lest with the state CS research had been at during that time. By now due to various reasons (e.g. swift) there is much more research in that direction already done hence a new language has it much easier.

Re: The Rust I wanted had no future

#68

Post by inferiorhuman »

tick_tock_tick wrote: post #31
rob74 wrote: post #15

Earlier quoted context omitted.

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...

> 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.

Hard disagree. Rust brings a lot to the table for a web app. Compiled vs interpreted makes it easier to catch (syntax) errors beforehand. You can even go as far as compiled templates. Mapping JSON (or whatever) to strongly typed objects is great. Dependency management is best in class. I rather like diesel.rs (although it is very much an acquired taste) especially if you treat it like a safe query builder rather than an ORM.

The single biggest problem I've run into is that there's no real good story for a web app framework (especially since everyone's gone crazy over async). Rocket is perhaps a bit too magical for rust folks and it's been abandoned, but I rather liked it. I've warmed up to axum, but all this async stuff still rubs me the wrong way.

And, yes, compile times still suck.

Re: The Rust I wanted had no future

#69

Post by giraffe_lady »

lawn wrote: post #43
tejinderss wrote: post #14

Earlier quoted context omitted.

Or like ocaml with its module system and no explicit lifetimes / & type.

Which reminds me, I really need to try out ocaml.

A really unknown and underrated language for how good it is right now is rescript. It's ocaml's type & module systems and runtime semantics grafted onto JS. Ocaml's tooling, ecosystem, and standard lib situation are all ...fine... but quirky in ways that can be barriers when learning it.

Rescript lets you skip most of those, plus the (overblown but also real) weird syntax. I like ocaml and use it for projects still but if you just want to play around with what's unique and strong about it, rescript is what I would recommend right now.

Re: The Rust I wanted had no future

#70

Post by wongarsu »

Aissen wrote: post #12

On integer wrapping, I think explicit wrap is annoying at first, but eliminates a whole class of bug. I can only agree with: > (Swift at least traps in release by default -- I wish Rust had chosen to). I enable it in release on serious projects: [profile.release] overflow-checks = true

At least Rust has left the door open to allow panicking on overflow even in release builds in the future - presumably on platforms where hardware support makes this cheap enough.
Post reply on HN