Hey there! I wrote the course and you're spot on: the course is meant for classroom training (at Google and elsewhere). If you have the time to read a book, then I highly recommend diving into one of the many great Rust books. I've linked some of the freely available ones here: https://google.github.io/comprehensive-rust/other-resources.....
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'm very happy I dug into rust half a decade ago. The language has been fun to learn as it evolved futures and async/await, and the future continues to look promising. I've had the pleasure of working professionally in Rust twice in my life (once at Full story, now at Deno) and I can say it's by far my favourite language to work in.
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 envy people who can pick up Rust and just get stuff done.
I've tried many times but every time, I find it far more difficult to build things than any other language I know, so I just give up and go back to "easier" languages.
I think previous experience programming in C++ can be helpful, in picking up Rust faster.
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.
> For me, in large part, the borrow checker is encoding in the compiler rules that you should be following in C++ anyway.
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've seen that too: having experience with Rust made C++ feel easy.
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.
I would love if you could expand on this. I've much experience with higher level languages such as Python, but as I get into C++ I find these nuggets of advise invaluable.
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.
What I find difficult is to switch my 2 decade C++ career into a rust job, despite learned Rust and finished some hobby projects touching ui, async and http server/client in Rust. Somehow most Rust job is about crypto currency.
I agree with the OP that the best way to learn it is to work through a real project, but I wouldn’t necessarily equate that with “picking it up and just getting stuff done”. At least, that’s not how it went for me, anyway! I hit all the real roadblocks along the way and it took a good few months before I felt actually comfortable. Until then, it felt like I kept running up against mismatches between how I wanted to solve a problem and how Rust wanted me to do it. It was more difficult to build stuff and I had to rewrite things many times. For background, I had worked with C/C++, Java, JS/TS, Ruby, and some others prior to Rust, and it was the first time in a while that learning a new language was pretty hard even after the syntax made sense.
The first time I ever experienced lane assist in a car was in a borrowed Honda Accord. Any time I drifted towards the lane line without signalling, an alarm would go off. This doesn't mean the Accord is hard to drive. It's not even hard to learn to drive. I already knew I was supposed to signal before making a lane change. It just made me concerned about how often I must have drifted over lines in other cars without lane assist. "I'm a great driver. I've driven fine for decades without lane assist. I don't need lane assist." I added lane assist to the list of features I wanted in my next car. You know, for my kid's sake (glances left and right).
I find that a lot of people just pick wrong kinds of projects to dig their teeth into Rust with. It is a systems programming language. If you don't know much about it and set out to build a website, things are inevitably going to go south.
Yeah, that's familiar. I chose for myself a project in which the data structure was a tree that should be generated randomly, but under some constraints. Also I tried to write it using functional paradigms, using many closures. I hit so many walls doing that that when it sort of worked, finally, I never wanted to touch Rust again.
Hah, yes. I thought I'd get started with Rust going through building some basic data structures. Linked lists were near the top of my list so I didn't get very far with that first approach XD
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.
I didn't end my Rust learning with that. I did a bit of a deep dive into articles about linked lists in Rust out of curiosity before pivoting to more fruitful projects. My favourite "project" being last year's Advent of Code.
Have you tried asking? The Rust reddit was a major reason I stop hitting my head against the wall.
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.
Yes, I was on the Rust Discord for a while... without their help I wouldn't have even gone past the most basic things, so yeah, it did help... it was funny to see the huge stream of people asking the same questions over and over again :D.
After a short while, it gets really tiring... but like others are saying, now we have ChatGPT to ask and it never gets tired!
Pick up Actix or Axum and clone() and unwrap() all day for your first month. Write some little web servers for fun. Sqlx is great for sql, and you can do some heavy hitting stuff like media streaming and transcoding as you get deeper into it. It's got good torch bindings for ML too.
Before long you'll be running the compiler in your head and rapidly churning out code.
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 ;)
I think my experience is actually the problem. I don't have enough patience anymore to spend lots of time trying to understand errors where I have zero idea why it's complaining, when I know the same thing in another language works totally fine the first time I try (and without bugs, it's mostly lifetime issues or the lovely borrow checker, which don't even exist in other languages).
But I do keep trying Rust, because the alternatives as I see it, C and Zig, have their own problems that are bigger (C's build tools and lack of package management, very weak type checking and unavoidable UB, and Zig's overall lack of maturity and consequently tooling).
By the way, I can write code very easily in Java/Kotlin/Groovy/Dart/JS/TS/Go/Lisp.
> I don't have enough patience anymore to spend lots of time trying to understand errors where I have zero idea why it's complaining
I consider those bugs. Please file tickets for that. The errors should provide enough context for an uncaffeinated developer to understand what went wrong.
Yea, that's a common complaint coming from other safe languages where the safety is accomplished by runtime features (such as garbage collection) instead of compile–time rules.
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.
>most of the time the engineering cost of creating a system is higher than the cost of running it.
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.
Yes, I include maintenance in the cost of running the system. And I agree with you that a well–written Rust program usually has quite low maintenance costs.
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.
Why do you say that? We’ve all read articles from Cloudflare and Microsoft and others about rewriting services in Rust once it becomes obvious how much money they can save, so we know that it does happen. I’ve seen it happen at much smaller companies as well.
Then you don’t have good enough documentation or tests, and you probably tried to rewrite too much. You should rewrite that portion of your code where the performance is most critical, because that’s where you will save the most money.
Yes. A good example would be Firefox. Mozilla is gradually replacing core components of Firefox with replacements written in Rust. It is not cheap to do this without causing regressions, but they have a great test suite and they know that it will save money in the long run. It increases performance, decreases memory usage, and most importantly it greatly reduces the defect rate. They’ll probably never bother to replace _all_ of the C++ code with Rust, because a lot of it works well or isn’t security–critical. They’ve been doing this since Rust 1.0, with measurable improvements in every release of the last few years.
I'm glad I've been following rust since <1.0 when it was lot smaller (tbh because it was missing stuff), I don't know if I'd have the perseverance to start learning it today from scratch just because the depth it has. Admittedly having bit of C++ background smoothed the curve too.
Rust is the first systems programming language since C++ I have seen pushed by multiple large tech companies.
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.
Yes, it is a general purpose language. It's original motivation (and main strengths) come from system networking domains, but it is way more high-level and easier than rust to build general things.
Rust is actually more suited to those companies than the general public (small companies and individual programmers) so it makes sense they do push it hard.
Why would you say that is, or why do you think so?
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
Jonathan Blow puts it as the "cost of experimentation being too high" which I would agree with. Generally, as an individual or small group the limiting factor for you at times becomes time.
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.
Well that's not saying much. So does TypeScript. Those features that make it suitable for larger teams also make it a solid choice for smaller teams. It's hard to imagine a feature that benefits a large team much more than would benefit a smaller team but I'm open to an argument
The benefits of making illegal states unrepresentable, providing safe abstractions over unsafe boundaries, and high-quality built-in documentation scale quite nonlinearly to large teams is all.
It is interesting that they have a day devoted to embedded using MicroBit v2.
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].
My colleguage Andrew wrote the bare-metal part. I believe he picked the micro:bit board because it's readily available around the world. It also has a lot of fun sensors (microphone, rudimentary speaker, compass, ...). I'm sure there are other boards around, but so far people seem very happy with this board in our classroom training.
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.
That makes sense. The first was great fun and v2 looks even better. I had written them off due to chip shortages but it looks like availablity is better now.
Cool thing. I currently use ChatGPT to provide me some exercises as I get better at the language. This is more like a presentation that needs accompanying conversation from the presenter.
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:
https://google.github.io/comprehensive-rust/