I started learning Rust over the weekends and I think the second edition "The Rust Programming Language" is among the best introductory books on a programming language I have read (well half way so far).
As someone not only new to Rust but also systems programming in general I especially appreciate that the chapters include actual reasoning about why things are how they are in Rust and that they seem pretty open about drawbacks of the choices. As well as the use of precise language instead of trying to be too cute and overly beginner friendly.
An example for this is the lengthy page on Strings: https://doc.rust-lang.org/book/second-edition/ch08-02-string...
It really makes me feel you want me to understand what I'm doing from the start instead of getting a generic app out of the door as quick as possible and then tediously figure out the next basic steps from screencasts, scattered blog posts etc.
Also big plus for having the book and api doc available offline by default!
I'm going to try to come by #rustdoc and see if there something I could contribute.
I've been spending a good majority of my work hours with Rust and especially writing network services using Tokio. When things work there, it is very reliable, fast and has a tiny footprint with resources.
Now reading the promise to get a stable async/await and also having Tokio 0.2 in the pipeline, I'd say async Rust might be ready for prime time.
Don't get me wrong here, I enjoy using Tokio, but I'd say if you're not very experienced yet with Rust, and you try to mix an asynchronous database query and a web request together in the same event loop, or you wanted to use a reference to `self` in an inner future (which might suddenly want a static lifetime), you quite easily end up into trouble... Trouble like a couple of pages of errors, that are just not readable at all. And you get out maybe by knowing to use a `map_err` in that one future call after the second `then`, or by not referencing `self` in your futures...
Now when reading the announcement, and I've read and understood the RFC's, the next generation of async Rust will help here tremendously. And I will definitely be amongst the first ones adding the changes to my code, to finally make it cleaner and nicer for the next developer to jump in.
Heres just hoping that Mozilla is prepared to take responsibility for what they are trying to accomplish in the long haul.
A lot of companies have tried to make products that are both infinitely backwards compatible and always supported while still introducing breaking changes like this. It quickly becomes a giant internal mess of trying to figure out what the most common denominator of feature requirements to implement new things is. Developers will start making ergonomic decisions in their changes (well, it could support 2021, but I want a 2024 feature so I'm going to use it and peg this feature to 2024 minimum) and new changes need to be tested against every different language iteration.
This might seem like the best answer now, I just hope its not biting off more than anyone can chew in 2030. C++ had an era of malaise where conflicting implementations of the standard library across a dozen+ platforms led to the complete abandonment of it by the mid 2000s and it took Herb Sutter and friends to bring C++ back from the dead with one unified single truth of C++ with concrete compiler flags and tons of caution before adopting anything new to make sure all participants were capable of fielding it quickly enough to avoid the ecosystem fragmentation of the past.
Rust is advantaged today with only one major implementation, but if mrustc or other alternative Rust compilers become popular mixing those with epochs / eras / editions can spell disaster for language portability.
Its not an impossible task, but it is definitely a huge one. And its not the kind of work hobbyists will ever be willing to put up with in the long term, and its the kind of work that requires extraordinary familiarity with the whole of rustc, its design process, the RFCs, LLVM, etc. Its its opposite kind of work to what you put on the easy issues list for new contributors.
It is the primary reason why most software staggers its releases and depreciated support. Why Microsoft dropped Windows XP at all despite its wide adoption. Because even with billions of dollars of cash on hand trying to keep multiple parallel interconnected but distinct code paths functioning while both securing and improving them in isolation or together is in the highest echelons of software complexity and difficulty.
Lots of nice language improvements lined up for this year
I haven't played with Rust but I like the ecosystem and transparency.
Something that stands out is the Compatibility across editions section. Seems like they really thought this through:
> you can be on a different edition from your dependencies.
> Edition-related warnings...must be easily fixable via an automated migration tool (rustfix). Only a small minority of crates should require any manual work to opt in to a new edition
> the progression of new compiler versions is independent from editions; you can migrate at your leisure, and don’t have to worry about ecosystem compatibility; These are huge!
This really helps with ecosystem fragmentation. Other languages take note (please!)
Another thing that stood out was the embedded as first class citizen:
> Embedded devices. Rust has the potential to make programming resource-constrained devices much more productive—and fun! We want embedded programming to reach first-class status this year.
This seems like the only thing on the list that might not finish in time for the year or will be sub-par. I don't know how much more work they need to do but embedded programming requires fine-tune memory management and access to special registers on a per-hardware basis. A lot of times these things fly in the face of assumptions many programming languages (and compilers) make
I'm an average programmer, but I honestly don't get the goal of inclusiveness [edit: from the Rust 2017 Survey Results]
> Diversity and inclusiveness continue to be vital goals for the Rust project at all levels.
I mean.. lifetime checks won't stop working if you don't consider yourself heterosexual or anything o.O The two matters simply don't mix in my head
> Tooling improvements
For me that's the biggest issue currently with Rust. Type inference via "let" only makes it harder as I can't really know what type a certain variable or expression is without carefully tracking docs. I've tried two Rust plug-ins for VS Code and even though they installed required dependencies I still couldn't have proper list of members when pressing "dot" and without that I feel like programming in the 90's.
> Embedded devices
I'm excited about this. In my experience, embedded (and by extension, a large part of kernel/driver programming) is the last stronghold of C, because it's a place where you really need fine-grained control of your environment and C gives you that by default.
It's my day-to-day workhorse, and I often feel like I'm stuck in the dark ages still dealing with issues of tooling and expressiveness that CS has solved long ago. Free me!
I like that they are targeting CLI apps, it seems like a great fit for Rust and a nice onramp for the ecosystem for newcomers.
Okay, after two failed attempts (mainly due to lack of motivation, I hasten to admit), I think it's time for me to learn me some Rust.
I spent a long time working mostly with dynamically typed languages, but over the past few years, I have slowly drifted back into statically typed territories. At home, I have used Go a lot, at work, I have grown to like C#. Rust kind of looks like the next logical step along that trajectory, doesn't it?
And I get the impression that people who took the time to learn Rust enjoyed it very much. So here's my delayed new-year's resolution (I am the ____ing king of procrastination!): I am going to learn Rust and I am going to like it (I hope)!
You may have noticed a subtle change: what was previously called “epochs” is now “editions.”
Lots of great stuff coming this year! As always, happy to answer any questions.
As someone who does a lot of firmware I think I really need to explore more of what Rust brings to the table there. Interrupts are a major source of concurrency and I'd like to be fearless about those issues.
Here's my wishlist for embedded: first class hierarchical state machines, saturated arithmetic, fixed point types. In bare metal scenarios, these are much larger areas of potential errors than any ownership issues, since often, any dynamic allocation is restricted to a mailbox/queue primitive while everything else is statically allocated.
What I'm missing here is why we need to market it as a distinct Rust 2018 release. Do we have breaking changes that require a new epoch/edition? The "Language improvements" section doesn't clarify that. I just hope there is substance in this push, a real technical reason for a new release, not a marketing one.
Go is making a large push to wasm as well. There is a branch/fork with a near complete wasm Go compiler.
I'm interested in seeing how Rust and Go will compare in the future of the web.
Who will win? ;)
Some honest criticism.
I'm not a guru, but I've used a fair bit of F# and modern C++ in a commercial setting, so a lot of things in rust weren't too surprising. I learned about the different kinds of strings (they make sense, even if they're poorly named). I learned the strict borrowing rules. I learned the strict mutability rules.
But try as I might, I can't bring myself to care about the difference between the ~190 different types of iterator.
I think I should just be able to use a Iterator trait, but I can't get any of those concrete instances to match up. It very much triggers my "I don't care reflex" in a way the other stumbling blocks really didn't.
This post is so well written. It must have taken a lot of time to do this write-up. Is it written by many people or just a single person?
Any notes on const generics e.g.`Array[T, N]`?
Do we get the fearless concurrency part of rust on wasm?
Editions - great thing, thank you VERY much! I love this language and people who work on it!
I absolutely loved rust and it is very easy to use