Rust has evolved from something safe and simple (once you grasp the different type of pointers) to something way less accessible.
Rust source code is now full of annotations, and very hard to read and maintain.
Traits have evolved from a nice feature to something overused everywhere.
Basic crates use so many generics, impl Trait and abstractions over abstractions over abstractions that it's really difficult to follow what concrete types you need to satisfy these.
When one of the oldest and still unanswered issue in the Hyper HTTP library is "how do I read the body?", there is a conceptual problem.
And things got even more complicated with Futures. async/await don't solve much, as besides textbook examples, these are unusable without deep knowledge of how everything works internally. Pin/Unpin makes things even more complicated.
I'm an early Rust adopter and advocate. However, I wouldn't consider it any longer for new projects.
My productivity in Rust has become very low compared to other languages such as Go or even C, that let me easily express what I want to do.
With Rust, 90% of my time is spent trying to understand how to express what I want to do. Such as what types I have, what 3rd party crates expect and how to convert them.
This is subjective, but there are at least a couple big counterexamples. Non-lexical lifetimes are a huge benefit for newcomers. I've gone through my old projects and just deleted all the nested blocks that I used to need to satisfy the borrow checker. Everything just works now. Also being able to match on `&T` or `&mut T` without putting the `ref` and `ref mut` keywords in each non-`Copy` binding, is another pretty big win. That's an entire keyword that we no longer need to teach to newcomers.
> Basic crates use so many generics, impl Trait and abstractions over abstractions over abstractions that it's really difficult to follow what concrete types you need to satisfy these.
Again this is subjective, but not following concrete types it the entire point of `impl Trait`. The type of `foo.iter().map(...).filter(...).step(...).take(...)` is a monster. Life is better when we don't have to type it. There are also new capabilities that come along with it: APIs don't have to commit to returning a certain kind of unboxed iterator, and unboxed closures can now be returned.
> async/await don't solve much, as besides textbook examples
None of what you're describing really tracks for me, having written many thousands of lines of rust and interfacing with my third party crates.
"async/await doesn't solve much" like your whole post confuses me.
I think right now a lot of rust libraries are "hyper generic" because they're intended to be lower level and to be built on top of. Like hyper, as an example. I've never found it particularly hard to work with generic libraries though.
I get the feeling that Rust is going to become, like C++ and Haskell, a language that you have to "live in". That is, if you take a break from the language for a few years, you won't understand the code that people are writing when you come back. Contrast that to, say, Go or Python, where you can come back to the language after five or ten years without any major difficulty.
Wow, hard disagree for me! I feel like Rust is the easiest language to maintain that I have ever used. I'm never afraid of changing things around since the compiler will always catch my mistakes and it is impossible (without unsafe) to introduce undefined behaviour. Whenever I'm using Rust my confidence levels are pretty much 100%. Having said that I don't know how the situation is for web dev since I'm a game dev, do you think that's the reason we have such different experiences?
This is precisely why I've lost interest in Rust. It feels limiting in the same way that fat frameworks do - it just becomes so much harder to express what I _really_ want to do sometimes, because I'm always working around the limits and requirements of the framework/abstractions which a lot of the time won't map very well to my solution.
> My productivity in Rust has become very low compared to other languages such as Go or even C, that let me easily express what I want to do.
As a C/C++ programmer who has being following Rust from a distance for sometime, with an intention to learn it later, this is somewhat concerning to hear. I've been meaning to start learning it for some time, however, my current workload doesn't provide enough spare time to start absorbing it.
In addition, it seems to be somewhat hard to find detailed information on how to do low-level things that would be very easy in C. Just as an example, one of our simulations relies on being able to craft raw UDP packets in order to "impersonate" remote basestations in our lab environment.
While this is trivial to do in C or C++, I haven't been able to find a good reference on how to do that with Rust. The lack of accessible documentation means that I'm unlikely to consider writing some of these more security sensitive parts of our system in Rust, even though there may be net benefits to doing so.
That's true. But you have to understand that Rust doesn't complicate things: Things are complicated. The difference between Rust and say, Python, is that Python hides lots of these complexities for you. This can have two sides effects: Performance and unintended consequences (bugs/hard to refactor/etc...)
Rust instead puts all of these complexities in front of you: Deal with it now.
So you have a choice: Deal with it now. Or deal with it later. And Rust has picked the former.
There definitely is a problem with some libraries using so many abstractions (traits) you have no idea how to use the thing.
I however do find writing rust to be quite enjoyable.
But I have so far entirely avoided the futures ecosystem and consider it a very good decision. One needs to have a very critical eye on what libraries to use
I can share similar experience. When I started to use Java, I happily digged into collections and stuff. It was quite easy to read and follow. Now with Java 8 I tried to read and follow their streams implementation. That was very hard. They implemented streams for semi-automatic parallelization which I never used and won't ever use and that made otherwise simple concepts just unreadable and unbearable. May be Rust developers tried to cover too big spectrum of the problems at once.
This is nonsense. Rust hasn't changed much since 1.0, but has matured a lot, and numerous small usability fixes add up, making it much nicer and productive than it was.
Rust is simpler to use, and simpler to learn than it ever was.
It has removed need for common pointless annotations (like ref in patterns, extern crate). Ambiguity of static vs dynamic dispatch in traits has been clarified with `dyn` and `impl` keywords.
The const generics feature is going to obsolete the worst-of-the-worst abuses of the type system trying to emulate that feature, and remove gotchas around arrays.
Async/await enables use of borrowed types in async code (freeing users from having to know about the `Pin`/`Unpin` implementation detail). Allows use of regular error handling, instead of requiring users to keep track of error types at each step in the chain of futures. It allows normal control flow instead of arcane wrangling with `Either` and boxing.
You listed a bunch of problems, and at the same complained that Rust has been solving them!
"Go is the result of C programmers designing a new programming language, and Rust is the result of C++ programmers designing a new programming language"
Genuine question: given a language which has a real notion of parallelism/concurrency and can run real threads on multiple cores, what is the appeal for async/await?
Interesting how much two of the big cloud providers are assisting the Rust project. Is GCP absent due to Chrome/Firefox?
> AWS has provided hosting for release artifacts (compilers, libraries, tools, and source code), serving those artifacts to users through CloudFront, preventing regressions with Crater on EC2, and managing other Rust-related infrastructure hosted on AWS.
> Microsoft Azure has sponsored builders for Rust’s CI infrastructure, notably the extremely resource intensive rust-lang/rust repository.
I really appreciate the clarity and communication style of these Rust release notes.
As an enthusiastic Rust user who is perhaps not as academic/intellectual as most of the Rust community, I often find Rust-related reading material quite daunting. But never these. They're simple and they're great.
The effect is very dependent on program structure and actual code running, but for a suitable application it's reasonable to expect anything from 5-15%, and sometimes much more (see e.g. Firefox reporting 18% here: https://glandium.org/blog/?p=3888 )
I just gave it a whirl on one of my own programs, which runs the distribution of votes for Australian senate elections. In my particular case I didn't see a speedup (but it's a relatively simple program: perhaps the branching was already predictable enough.)
Considering the Rust compiler performs much more useful checks than the Go compiler, has generics, etc. I don't see how that's really a fair comparison.
I almost got to make my first contribution to Rust, by correcting a small semantic error in the (pre)release notes, but alas, I wasn’t at a real computer at the time and someone else was faster :)
Well there is still time and lots to do. Let's help the project in any capacity we can.
I am a coder but I'm not well versed in Rust enough to be able to contribute code, but i'm gonna try to investigate and find other venues I might be helpful (writing documentation, translation to the languages i speak, etc).
I managed to get a small doc fix in a release a while ago and was pretty stoked about that. It was nice of them to put me in the contributor list for the release even though it was such a small change. (If I recall, removing superfluous `mut` parameters on `BufRead` or something)
Congrats! Like many I was looking forward to async/await in this release but I'm happy they've taken some extra time to work through any existing issues before releasing it.
[+] [-] jedisct1|6 years ago|reply
Rust source code is now full of annotations, and very hard to read and maintain.
Traits have evolved from a nice feature to something overused everywhere.
Basic crates use so many generics, impl Trait and abstractions over abstractions over abstractions that it's really difficult to follow what concrete types you need to satisfy these.
When one of the oldest and still unanswered issue in the Hyper HTTP library is "how do I read the body?", there is a conceptual problem.
And things got even more complicated with Futures. async/await don't solve much, as besides textbook examples, these are unusable without deep knowledge of how everything works internally. Pin/Unpin makes things even more complicated.
I'm an early Rust adopter and advocate. However, I wouldn't consider it any longer for new projects.
My productivity in Rust has become very low compared to other languages such as Go or even C, that let me easily express what I want to do.
With Rust, 90% of my time is spent trying to understand how to express what I want to do. Such as what types I have, what 3rd party crates expect and how to convert them.
[+] [-] oconnor663|6 years ago|reply
This is subjective, but there are at least a couple big counterexamples. Non-lexical lifetimes are a huge benefit for newcomers. I've gone through my old projects and just deleted all the nested blocks that I used to need to satisfy the borrow checker. Everything just works now. Also being able to match on `&T` or `&mut T` without putting the `ref` and `ref mut` keywords in each non-`Copy` binding, is another pretty big win. That's an entire keyword that we no longer need to teach to newcomers.
> Basic crates use so many generics, impl Trait and abstractions over abstractions over abstractions that it's really difficult to follow what concrete types you need to satisfy these.
Again this is subjective, but not following concrete types it the entire point of `impl Trait`. The type of `foo.iter().map(...).filter(...).step(...).take(...)` is a monster. Life is better when we don't have to type it. There are also new capabilities that come along with it: APIs don't have to commit to returning a certain kind of unboxed iterator, and unboxed closures can now be returned.
> async/await don't solve much, as besides textbook examples
See the real code examples here: https://docs.rs/dtolnay/0.0.3/dtolnay/macro._01__await_a_min...
[+] [-] staticassertion|6 years ago|reply
"async/await doesn't solve much" like your whole post confuses me.
I think right now a lot of rust libraries are "hyper generic" because they're intended to be lower level and to be built on top of. Like hyper, as an example. I've never found it particularly hard to work with generic libraries though.
[+] [-] foldr|6 years ago|reply
[+] [-] lukebitts|6 years ago|reply
[+] [-] mslm|6 years ago|reply
[+] [-] nineteen999|6 years ago|reply
As a C/C++ programmer who has being following Rust from a distance for sometime, with an intention to learn it later, this is somewhat concerning to hear. I've been meaning to start learning it for some time, however, my current workload doesn't provide enough spare time to start absorbing it.
In addition, it seems to be somewhat hard to find detailed information on how to do low-level things that would be very easy in C. Just as an example, one of our simulations relies on being able to craft raw UDP packets in order to "impersonate" remote basestations in our lab environment.
While this is trivial to do in C or C++, I haven't been able to find a good reference on how to do that with Rust. The lack of accessible documentation means that I'm unlikely to consider writing some of these more security sensitive parts of our system in Rust, even though there may be net benefits to doing so.
[+] [-] csomar|6 years ago|reply
Rust instead puts all of these complexities in front of you: Deal with it now.
So you have a choice: Deal with it now. Or deal with it later. And Rust has picked the former.
[+] [-] rapsey|6 years ago|reply
I however do find writing rust to be quite enjoyable.
But I have so far entirely avoided the futures ecosystem and consider it a very good decision. One needs to have a very critical eye on what libraries to use
[+] [-] vbezhenar|6 years ago|reply
[+] [-] pornel|6 years ago|reply
Rust is simpler to use, and simpler to learn than it ever was.
It has removed need for common pointless annotations (like ref in patterns, extern crate). Ambiguity of static vs dynamic dispatch in traits has been clarified with `dyn` and `impl` keywords.
The const generics feature is going to obsolete the worst-of-the-worst abuses of the type system trying to emulate that feature, and remove gotchas around arrays.
Async/await enables use of borrowed types in async code (freeing users from having to know about the `Pin`/`Unpin` implementation detail). Allows use of regular error handling, instead of requiring users to keep track of error types at each step in the chain of futures. It allows normal control flow instead of arcane wrangling with `Either` and boxing.
You listed a bunch of problems, and at the same complained that Rust has been solving them!
[+] [-] fetbaffe|6 years ago|reply
https://drewdevault.com/2019/03/25/Rust-is-not-a-good-C-repl...
[+] [-] Dowwie|6 years ago|reply
[+] [-] aleden|6 years ago|reply
Is https://github.com/hyperium/hyper/issues/1137 the issue you are referencing?
[+] [-] amedvednikov|6 years ago|reply
https://vlang.io
A relatively stable 0.2 release will be out this month.
[+] [-] eyeinthepyramid|6 years ago|reply
https://github.com/rust-lang/rust/issues/62149
[+] [-] pietroalbini|6 years ago|reply
[+] [-] umanwizard|6 years ago|reply
[+] [-] jjtheblunt|6 years ago|reply
[+] [-] sitkack|6 years ago|reply
> AWS has provided hosting for release artifacts (compilers, libraries, tools, and source code), serving those artifacts to users through CloudFront, preventing regressions with Crater on EC2, and managing other Rust-related infrastructure hosted on AWS.
> Microsoft Azure has sponsored builders for Rust’s CI infrastructure, notably the extremely resource intensive rust-lang/rust repository.
[+] [-] steveklabnik|6 years ago|reply
I don’t personally use cargo vendor but seeing it up streamed is also a big plus, IMHO.
[+] [-] stmw|6 years ago|reply
Small things like Option::xor() or default cargo run are signs more and more people are using it "for real".
[+] [-] Freak_NL|6 years ago|reply
Just curious; what is your practical use case for that method?
[+] [-] _zachs|6 years ago|reply
[+] [-] fnord77|6 years ago|reply
[+] [-] philbo|6 years ago|reply
As an enthusiastic Rust user who is perhaps not as academic/intellectual as most of the Rust community, I often find Rust-related reading material quite daunting. But never these. They're simple and they're great.
[+] [-] nicolashahn|6 years ago|reply
[+] [-] slovenlyrobot|6 years ago|reply
[+] [-] angrygoat|6 years ago|reply
It wasn't hard to try out, the docs are here (including using it via cargo): https://doc.rust-lang.org/rustc/profile-guided-optimization....
[+] [-] svnpenn|6 years ago|reply
https://github.com/rust-lang/rust/issues/61978
which puts it at over double the size of Go. Worse is seems to be no impetus to fix this. Also notable is Rust still doesnt have a Map literal:
https://github.com/rust-lang/rfcs/issues/542
[+] [-] mlindner|6 years ago|reply
[+] [-] the_mitsuhiko|6 years ago|reply
[+] [-] dralley|6 years ago|reply
[+] [-] lalaithion|6 years ago|reply
[+] [-] Sharlin|6 years ago|reply
[+] [-] fb03|6 years ago|reply
I am a coder but I'm not well versed in Rust enough to be able to contribute code, but i'm gonna try to investigate and find other venues I might be helpful (writing documentation, translation to the languages i speak, etc).
[+] [-] leshow|6 years ago|reply
[+] [-] tass|6 years ago|reply
What are some good open source projects built in rust which wouldn’t be too difficult to contribute to?
[+] [-] rvdca|6 years ago|reply
[+] [-] Freak_NL|6 years ago|reply
1: https://adventofcode.com
[+] [-] sleepysysadmin|6 years ago|reply
Why didn't Rust go with an easier to read syntax? Why did they stick to old C syntax?
Edit/ Sorry, didn't mean to offend anyone.
[+] [-] jcranmer|6 years ago|reply
* Ending statements with ;
* {} for braces, lowercase keywords for control flow
* [] and 0-based indexing for arrays
* Infix operator notation, with mathematical operator precedence
* &, |, ^, ~ for bitwise operators
* . is used for member access
But they didn't copy all of C's syntax:
* There's no ->, since dereference is usually automatic.
* No ?:, if/else can be used as expressions instead
* No ~, since ! on an integer variable does bitwise negation instead.
* Pointer, array, and function types don't have the weird syntax they do in C... you say [ * mut fn()->i32; 4] instead of int ( * ())[4]
* Types follow variables instead of precede them (x: i32 instead of int x)
* No C-style casts (x as i32 instead of (int)x)
[+] [-] steveklabnik|6 years ago|reply
We did diverge where we felt it was appropriate.
[+] [-] ausjke|6 years ago|reply
By all means I feel rust still compile too slowly, if it has faster build time I might spend some time playing with it.
[+] [-] leshow|6 years ago|reply
[+] [-] johnisgood|6 years ago|reply
[+] [-] unknown|6 years ago|reply
[deleted]
[+] [-] Siecje|6 years ago|reply
[+] [-] astrophysics|6 years ago|reply
[deleted]