@josh Reading The Book does help most people as a first step—Rust has new concepts, it's hard to just dive in, IMO. If you need to learn on something concrete, I would recommend Rustlings and Exercism for a bit. Once these seem boring, then jumping into a project of your own will be much more rewarding/accessible.

If you tag with #RustLang and wait for EU to wake up, you'll get lots of great tips.

For web, check out Leptos and Axum specifically.

Links: https://fosstodon.org/@dpom/111462470734536008

But the end result of all this is that you CAN, in fact, just look a the Rust API and know how to use it correctly for the most part. You never have to worry about reference counts, about NULL pointers, about forgetting to check results, about dropping refs in error cases.

You never have to worry about holding the right locks, about accidentally forgetting to take a ref or dropping it twice. You never have to wonder how error returns are encoded.

Because if you make a mistake with these things, your code won't compile.

Of course you can still misuse APIs, but the worst that will happen is that you'll get an error return, or maybe a deadlock (deadlocks are easy to debug with lockdep and I wrote a really neat Arc<> integration to catch potential drop/decref related locking errors).

Even with APIs that mostly are fairly rigorously documented (OpenFirmware/Device Tree comes to mind), following all the rules in C is often tedious and error prone. Look at some random OF code in a driver and there's a good chance it leaks references.

(This doesn't really matter for most systems since they don't compile kernels with OF_DYNAMIC so ref counts are ignored, so this never gets noticed and fixed.)

But with my OF Rust abstractions? They do ref counting for you. You can just forget about it.