Comprehensive Rust: course used by the Android team at Google
github.com
github.com
It's assumed that this book is accompanied by an experienced rust dev for a lecturer.
The posted link is to the GitHub repo, here's the link to the book:
We've made an attempt at making Comprehensive Rust useful for self-learners by providing speaker notes on many of the pages. However, they're still quite terse and could be expanded in many places. PRs for that will be gratefully accepted :-)
I did some Rust training with Ferrous but by far the most useful way to learn was just picking up a project and building it.
I had experience with PHP, JavaScript, and Python, but when at first coding in Go it would take me as much as 10x as long. But with more practice it's now only about 2x as long as in other languages. Keep practicing ;)
By the way, I can write code very easily in Java/Kotlin/Groovy/Dart/JS/TS/Go/Lisp.
I think that most programs should be written in easier languages than Rust, since most of the time the engineering cost of creating a system is higher than the cost of running it. You can rewrite it in Rust once your system is large enough that eliminating the garbage collector will save you a few million dollars a year. By then you’ll have a complete understanding of the requirements, and you won’t have to experiment to get it right. Use a language like Lisp, which is designed for easy and fast experimentation, to write the first version of your software.
And most of the time the cost of _maintaining_ the system is higher than the cost of creating it. This is where Rust truly excels, it makes it much harder to write any hard to find bugs.
In principle you should be able to approach zero maintenance costs with any language, but writing your system in Rust generally means you have abandoned complexities like garbage collection. Garbage collection speeds up development by an order of magnitude or more, but at the cost of having to monitor the performance of the GC, tune it as loads change and computers get more and more memory but don’t get any faster at accessing it, etc, etc.
Exceptions are another thing that speeds up development at the cost of maintenance down the road. You have to log the exceptions that are happening and monitor them to make sure that they are rare otherwise they’ll silently become more common over time as your program gets more complex. Meanwhile Rust’s explicit error handling really makes you think at every step about exactly what odd conditions your program might encounter. If you use Rust’s type system correctly, you can encode very specific information about exactly which errors are possible or impossible at every point in your system. It’s more work up front but it saves a huge amount of time down the road.
Never gonna happen.
I consider those bugs. Please file tickets for that. The errors should provide enough context for an uncaffeinated developer to understand what went wrong.
For me, in large part, the borrow checker is encoding in the compiler rules that you should be following in C++ anyway.
A few hours debugging dangling references or iterator invalidation will make you appreciate what the borrow checker is trying to prevent.
You also have experience knowing the difference between pass by reference, pass by const reference, copy, and move.
Also, if you want to keep your sanity, you will learn to take ownership seriously. Deciding what owns what and whether objects will be owned by the scope (on the stack), be owned by unique_ptr, or be shared with shared_ptr is a large part of designing a C++ program.
Again these all map very neatly onto Rust idioms, and as a benefit are enforced by the compiler.
Coming from a garbage collected language where you previously did not have to care about things like that, and now, not only being forced to care, but having the compiler yell at you for every mistake can be a pretty big learning curve.
However, I would say that not knowing C++ doesn't mean that you can't learn Rust, only that it may take a little longer because you have to learn new concepts with regards to memory management and ownership, and so give yourself some slack and do not be discouraged.
My experience was sort of the inverse of yours: I knew a little C++ before learning Rust, and being educated by the borrow checker has really helped me writing C++.
I looked at C++ many years ago but never used it professionally. About 6-7 years ago, I learnt Rust and a few years later, I started working full time in a C++ team at Google. There are many things in the Google C++ Style Guide[1] that reminds me of Rust, from the ban on exceptions to the use of `std::optional` for optional inputs and outputs.
> Also, if you want to keep your sanity, you will learn to take ownership seriously. Deciding
> what owns what and whether objects will be owned by the scope (on the stack), be owned by unique_ptr, or
> be shared with shared_ptr is a large part of designing a C++ program.
https://www.youtube.com/watch?v=TJTDTyNdJdY
Agree with the quote: that's the biggest challenge with Rust... I have been trying to pretend Rust is like Java and I think that was my big mistake.
When you design anything in Rust, even the most basic stuff, you will need to decide "what owns what", unless you clone everything on every usage. Try some very simple code that requires allocation and you will quickly notice that. I am now back at Rust and redesigning all my code to make "what owns what" the first question I ask when writing anything, and that is already being very helpful.
But of course: if you don't need the performance of Rust or the small footprint, it's just not worth it spending time on stuff like that can be completely and utterly ignored in any non-systems language.
I felt a lot like that with Rust.
I'd encourage people to start their Rust journey with little web services.
I've never written linked lists the same way in other languages since.
Rust made me better in languages that aren't Rust.
https://rust-unofficial.github.io/too-many-lists/
You can skip her explanation of why the Linked List is a bad first data structure, and get straight to doing, but if you have no idea why a very experienced programmer would think this data structure is terrible (so terrible she tried but failed to have it removed from Rust's Standard Library before Rust 1.0) you should read her whole PSA too.
Before long you'll be running the compiler in your head and rapidly churning out code.
It makes you faster because you still don't have to handle errors but allows you to add context.
In the past, `&str` was just so huge block for me (now I wonder why!) and instead of getting stuck just ask about it. I think was a stream of a few question on reddit that unblock Rust for me after like 3 months of going nowhere.
After a short while, it gets really tiring... but like others are saying, now we have ChatGPT to ask and it never gets tired!
The more Rust proliferates, the better. It's good at client, server, systems, and so many other things.
Go was pushed primarily by Google
Swift was pushed primarily by Apple
C# was pushed primarily by Microsoft
I am seeing a push for Rust by Microsoft, Google, and Amazon.
In retrospect, it almost seems that Mozilla closing the Rust team was a good thing for Rust as a lot of the Rust developers ended up at other companies and Rust became more than just a Mozilla language.
I would argue Rust is definitely suited towards small companies and individuals for a lot of projects that C/C++ would’ve been used for before, even things like small audio units or plugins
Sort of the philosophy where you design by programming instead of whiteboard or clearcut stuff. Less flexible design but more automatic correctness is worth it for big companies because projects involve millions of lines of code and thousands of people over the lifecycle.
It's sort of like writing microservices when you're an one man shop. The correct philosophy is monolith first - until you're doing something useful, don't obsess that much.
If you've got a clear vision of each project, or perhaps it's a larger scale project more similar to those in big tech, then perhaps Rust is best. But those kinds of projects typically don't even need C++/Rust. I use C++ for high performance experimental software.
I would like a C++ replacement also though, maybe through a design like Carbon where it's built above it. You could also then do stuff like making the borrow checker optional and with parts of the program instead, as a sort of finalization refactor. Combining the best of both worlds.
I'm a big C# fan but I see very few use cases where I'd consider both.
Go and C# are not systems languages. Maybe a stretch goal at best.
The older Rust-Embedded Discovery book [0] also used Microbit but the later edition [1] suggests a STM32F3DISCOVERY. For RISC-V and Extensa fans there is also Ferrous Systems' Embedded Rust on Espressif training material [2] which has a coordinated board [3] that has been "cloned" by Wokwi [4].
0. https://docs.rust-embedded.org/discovery/microbit/index.html
1. https://docs.rust-embedded.org/book/index.html
2. https://esp-rs.github.io/espressif-trainings/
The only slight problem is the noise when 30 boards are powered on at once :-D They ship with an elaborate demo program which plays sounds and blinks the LEDs when you start it up.
> This site uses cookies from Google to deliver and enhance the quality of its services and to analyze traffic. [Learn more] [Ok, Got it!]
No reject? :|
I am partly joking but judging by the state of the last couple of Android versions, that doesn't sound as good as it used to be.
That's a good idea, thanks! I'm gonna do that too