3 ms·

over-engineering in hope that the language does everything for everybody is my biggest worry and why my excitement to consider it as something I want to work wi

over-engineering in hope that the language does everything for everybody is my biggest worry and why my excitement to consider it as something I want to work with drops with every year. Considering how quickly the language evolves (which ought to be a good thing considering it's still new) I'm being put off by all these features that only few need, while at the same time things like async are broken by design (not to mention the opinionated tooling of cargo, rustup, etc that follow the same flawed principles as npm, rvm and even cpan). Perhaps I'm being too conservative but I'd have more trust in the language if things were moving slower especially that rust positions itself as a systems programming language fit for production (today). Which is odd because what I want from something that ticks these 2 boxes is interface stability. I have more confidence in Zig or Nim for this reason. Give it another 5 years and it will be a similar mess as C++, or worse: Python (which ended up rolling out v3 which wasn't backward compatible with v2). Also the "safety/security" argument which is their big selling-point which goes out the window as soon as you pull 3rd party crates (as is the case in most of the projects).

roca 6y ago
Suggesting that Rust will follow Python by forking the language incompatibly is completely unfounded. No-one has shown any interest in that, and the edition system was designed specifically to avoid any need for that. > Also the "safety/security" argument which is their big selling-point which goes out the window as soon as you pull 3rd party crates Not at all. Rust's safety guarantees work in practice. In years working on our largish Rust project we practically never have had to deal with memory corruption or data races.
- herbstein 6y ago
  > Not at all. Rust's safety guarantees work in practice. They don't just work in practice. I spent 3 months last semester being taught in the separation logic "Iris", which is used to formally prove the safety guarantees of Rust as part of the RustBelt[0] project. That was under Lars Birkedal, for anyone curious. Rust is a language I love doing actual work in, but it's also one I really like from the perspective of the theoretical backing. [0] : https://plv.mpi-sws.org/rustbelt/
  - roca 6y ago
    Fun fact: Lars and I were in the same PhD intake at CMU. Tell him Robert O'Callahan says hi.
withoutboats2 6y ago
It doesn't really matter to me what you, an internet stranger, are "excited to consider as something you want to work with." Instead, what you should consider is how incredibly boorish it is to post that "async is broken by design" in reply to the person who designed async.
- deleted 6y ago
  [deleted]
- jkelleyrtp 6y ago
  I’m not sure why “rust async bad” has become a meme lately. I think people who don’t know much about rust need something to put it down and async is just an easy target. I’ve been using rust professionally for 3 years now and think async is great, and certainly has come a long way. I think there’s some work around closures that could be made better (explicit lifetimes, matching, etc) and some ecosystem fragmentation (Tokio, async-std) but I’m sure everything will settle out in due time. Thanks for contributing - don’t let internet people get you down.
ufmace 6y ago
> async are broken by design That's, uh, a rather bold assertion. Perhaps you could elaborate on why you feel it's "broken by design"? I've never heard anyone take that position at all, much less make an implied claim that it's a widely-accepted position.
- nindalf 6y ago
  You likely won't get an answer from someone making hyperbolic claims like that. But it's probably this discussion - https://internals.rust-lang.org/t/unsoundness-in-pin/11311/42 https://internals.rust-lang.org/t/unsoundness-in-pin/11311/4...
littlestymaar 6y ago
> I have more confidence in Zig or Nim for this reason Do you realize that at this point Rust is way more stable than those two languages? It's not a critique at all as they are much younger, but these are really bad examples to compare with.
- cb321 6y ago
  The first public release of Nim was June, 2008, but work began a few years earlier. So, Nim is at least a couple or more years older than Rust. Stability is often subjective (in terms of features people actually use).
IlliOnato 6y ago
> not to mention the opinionated tooling of cargo, rustup, etc that follow the same flawed principles as npm, rvm and even cpan Can you specify, what are these flawed principles? And what would be a better system? Thanks!

roca 6y ago

Suggesting that Rust will follow Python by forking the language incompatibly is completely unfounded. No-one has shown any interest in that, and the edition system was designed specifically to avoid any need for that. > Also the "safety/security" argument which is their big selling-point which goes out the window as soon as you pull 3rd party crates Not at all. Rust's safety guarantees work in practice. In years working on our largish Rust project we practically never have had to deal with memory corruption or data races.

herbstein 6y ago
> Not at all. Rust's safety guarantees work in practice. They don't just work in practice. I spent 3 months last semester being taught in the separation logic "Iris", which is used to formally prove the safety guarantees of Rust as part of the RustBelt[0] project. That was under Lars Birkedal, for anyone curious. Rust is a language I love doing actual work in, but it's also one I really like from the perspective of the theoretical backing. [0] : https://plv.mpi-sws.org/rustbelt/
- roca 6y ago
  Fun fact: Lars and I were in the same PhD intake at CMU. Tell him Robert O'Callahan says hi.

withoutboats2 6y ago

It doesn't really matter to me what you, an internet stranger, are "excited to consider as something you want to work with." Instead, what you should consider is how incredibly boorish it is to post that "async is broken by design" in reply to the person who designed async.

deleted 6y ago
[deleted]
jkelleyrtp 6y ago
I’m not sure why “rust async bad” has become a meme lately. I think people who don’t know much about rust need something to put it down and async is just an easy target. I’ve been using rust professionally for 3 years now and think async is great, and certainly has come a long way. I think there’s some work around closures that could be made better (explicit lifetimes, matching, etc) and some ecosystem fragmentation (Tokio, async-std) but I’m sure everything will settle out in due time. Thanks for contributing - don’t let internet people get you down.

ufmace 6y ago

> async are broken by design That's, uh, a rather bold assertion. Perhaps you could elaborate on why you feel it's "broken by design"? I've never heard anyone take that position at all, much less make an implied claim that it's a widely-accepted position.

nindalf 6y ago
You likely won't get an answer from someone making hyperbolic claims like that. But it's probably this discussion - https://internals.rust-lang.org/t/unsoundness-in-pin/11311/42 https://internals.rust-lang.org/t/unsoundness-in-pin/11311/4...

littlestymaar 6y ago

> I have more confidence in Zig or Nim for this reason Do you realize that at this point Rust is way more stable than those two languages? It's not a critique at all as they are much younger, but these are really bad examples to compare with.

cb321 6y ago
The first public release of Nim was June, 2008, but work began a few years earlier. So, Nim is at least a couple or more years older than Rust. Stability is often subjective (in terms of features people actually use).

IlliOnato 6y ago

> not to mention the opinionated tooling of cargo, rustup, etc that follow the same flawed principles as npm, rvm and even cpan Can you specify, what are these flawed principles? And what would be a better system? Thanks!