Even during months on and off with Rust I couldn't do much more than a few 100 lines of finger exercises. Why? No effence, but at the same time I did much more in C, learned the language coming from C++ and translated my little framework, some 3000loc.
I was trying to learn with the Rust book (I am not into videos, you don't know how good they are until you watched them and anyway the information density is usually low).
It is a tiring read because of the constant bickering with other languages. Look at books of the other systems language like Gustedt: Modern C, Preschern: Fluent C, Seacord: Effective C. There is usually not a single word about other languages, no distraction from the subject. My suggestion: just leave that out, saves 10s of pages and people can focus on learning Rust.
Second, I find the book lacks exercises, lots of exercises to get people coming from OO or procedural languages used to the functional way. And maybe split it. A good book has 2 - 300 pages to have it lying before the keyboard while typing without it blocking the space key :-).
Thirdly, feature creep was one of the points why I abandoned C++ in favour of C. Is Rust on the same way? Do we have to run after the carrot, even after having mastered that steep initial climb aka learning curve?
In the end, a language is a tool to get things done, not a world view.
A side note, Rust claims to be memory safe, but crates.io appears to be inherently unsafe to use. And the opaque handling of dependencies by cargo makes my neck hair tingle. While one can usually rely on the stuff in the Linux repositories. A (human) maintainer-mechanism might be a good idea for crates.io?
Whatever, maybe most of this has already come up. Hope nobody feels offended.
There are several efforts within the Rust community on how to improve the learning materials / how to better teach Rust, and a key point to doing it is the background of the individual attempting to learn Rust.
I'm pretty sure your feedback could be useful to such efforts.
None of what follows is intended as a "no, ur wrong!", but rather to just add some context. (Yes, the room is on fire, but in fairness Jim has been practising fire eating...)
Rust has this problem where it's harder to use and less convenient than its contemporaries. This primarily comes down to lessons learned from other languages.
For example, the single biggest reason I learned Rust was because it would have prevented one of the worst bugs I ever encountered when writing D. It's hard to justify (sharing XOR mutation) restriction without a concrete example, and such an example can't be written in Rust.
I would not want to be responsible for writing those.
Over the years, I've found that the "OO" part is specifically one of the hardest things to translate in Rust. There's no clean mapping from OO concepts to Rust, so every time someone asks about it, it turns into a quagmire of arguing about context and details that aren't easy or quick to explain. Which, yes, is excellent motivation for exercises... and a contributing factor for why there aren't any.
As for procedural, I'm not sure why you flag that specifically. To my mind, Rust isn't a functional language; it's a procedural language with some functional abstractions on top. A lot of the time, I'm writing Rust like C with extra bells and whistles.
It's funny; I see someone complaining about Rust constantly changing only slightly more often than I see someone complaining about Rust not changing fast enough.
Rust will probably never be as "stable" (in the "unchanging" sense of the word) as C. It's always open to new ideas and improvements that make it better or easier to use.
That said, I don't get the same "random agglomeration of features" feeling that I get from C++. Every feature added to Rust tends to be argued about at length, and forced to prove its worth, completeness, and consistency with the rest of the language. If it can't, the core team has a default position of denying additions.
For example: I've lost track of how long I've been waiting for generators.
Also: Rust has one of the absolute best backwards compatibility approaches of any language I've ever used. I had a codebase I left on the 2018 edition for something like 2 years simply because there was no significant benefit to updating it, and it was a sizeable job to do so.
I actually feel like this isn't entirely true in Rust's case. Learning it fundamentally changed the way I design and write programs. It was a bit like learning about higher-order functions for the first time.
I feel like this probably seeps through to some degree with educational material. I think it's easier to convince someone to put up with Rust's limitations if you can sell them on the change in perspective many of us have experienced.
So perhaps... Rust is a tool, but it's a slightly unusual one born from a slightly unusual word view.
I think it would be useful if you could expand on this point. Specifically: why do you say crates.io is "inherently unsafe" to use, and how that relates to memory safety. Also, what you mean by "opaque handling of dependencies".
My belief is that dependencies are handled the way they are for numerous reasons: you can't rely on system package managers because they largely don't have the features that were desired (assuming they existed at all), you'd have to package every crate for all of them individually (or wait for a package you want to be included), dependency lists would be an unmanageable mess of distro-specific names and versions.
I'm not sure what a "human in the loop" would realistically do, besides (probably) slow down releases and provide people a false sense of security.
Again, thank you for taking the time to write this up.
I have not looked at the Rust book in a long time, but I don't think mentioning other languages is inherently a bad thing. If someone knows C++, the fastest way to explain Arc is probably to say "this is Rust's version of shared_ptr". But perhaps this isn't what you mean?
As for exercises, you might want to check out rustlings. I've heard that it has good exercises.
As for feature creep, well, I think most complaints of this form are from people that don't think async/await should be part of the language. But I think that async/await has been very important for Rust to break into the backend space, so I think that feature has a good reason to exist.
As for crates.io and supply chain security, it's funny, when I met Linus Torvalds at the Linux Plumbers conference last month and introduced myself as someone who works on Rust in the Linux kernel, he made exactly the same point: that he dislikes how Cargo just downloads code off the internet. (At least in userspace - we don't use cargo in the kernel.) And I actually think it's a very legitimate issue. Where I work, we vendor all third party dependencies for all languages, and I think that this is an important step for making sure that your supply chain is up to snuff. That said, it's still a trade-off, and I do think that easy dependency management in Rust has improved the adoption of Rust.
I have looked into other sources, I am well aware that 1:1 translations aren't possible, and I haven't even said something about asynchronous processing. That's not constructive, as are wordings like "you might want to".
What I tried to convey was the opinion that is difficult to get productive with Rust (and I am not the only one), and that learning resources could be improved.
Sorry if I hit a nerve. I'll return to my own devices and wish everybody happy coding.
If there are misunderstandings, then they are in both directions. You didn't hit a nerve with me, at least not with your first post. I mean, for example, you said that you weren't able to find enough exercises, and I gave you a link to a resource with exercises. I don't see how that could possibly be unconstructive.
No, I did not say I wasn't able to find exercises. You might want to read the OP again.
I said the Rust book could be improved with exercises.
You know, I find Rust's functional way is not like C or C++ concepts which are more intuitive to understand in isolated, procedural steps. Even objects in the end brake down to isolated functionality in data and methods.
For Rust, one needs a lot of exercise to understand the concatenation of calls that combine for instance input, parsing and error handling in a single LOC and the possibilities that are already there in a standrad library.
As someone who started learning Rust with that book some months ago, I would like to add a few comments. First let me say, that I was thankful that the book was freely available, and for me it gave me a good introduction to the Rust language. (I am not sure if I ever will really use Rust for projects, after using Nim for the last nine years, I consider Julia, Zig, Go, Mojo, and a few more languages as well.)
What people expect from books is very different -- that is one reason why we have so many books about the same stuff. For me the book was just good enough, I read it fast, with Textmarker Firefox extension, which allows me to mark interesting or confusing parts.
What I regard as a bit strange is, that the book, while it is already available a long time and has been even printed, has many open pull requests and open issues, which should be really addressed. When reading fast, I initially noticed only a few content related issues and reported them at GitHub, but I noticed later that there are many more.
For exercises and examples: In the form of plain homework task like "Create a tool that scans a Wikipedia page and ..." I regards that not as too useful. And with provided and explained solutions, that would take a few hundred pages more. As others wrote, we have for Rust many more learning resources, Rust-by_example and similar, or all the code at Rosetta. And of course many more books.
For the official book, fixing all the open issues would be nice. And then one could create a shortened version, by removing all the redundant stuff. And maybe a version with even more fundamental explanations for absolute beginners, and maybe a second part with examples and case studies, which is sometimes labeled as "... in action". All that is of course possible, and with AI tools like ChatGPT doable even for people who can not write perfect English grammar.
I've been developing mostly with java for the latest 20 years, give or take.
Rust is quite a different language, with the borrow checker and the "nagging compiler that doesn't allow me to do what I want" thing ( I'm being satirical here ).
I'm not under pressure to learn the language: it it not a job requirement, I'm basically exploring the language potential, so I'm going slow.
The latest thing I've discovered is the https://exercism.org that has a (quite significant) set of exercises written in rust.
One of the advantages of exercism is that it doesn't take "a view" of the solution: you solve the exercise in any way you see fit, and then you can either ask for mentoring (a "meh" feature, at least for experienced programmers), but, most valuable of all, you can see other people's solutions. Which have been, well, wow...
Thanks, guys, for sharing your experience. Appreciate that.
Will keep an eye on Rust in the future. For now I decided to stick with C (and C++ if unavoidable) because I want to get things done, people in tech/science tend to know these languages more, there is already a codebase and apis are C anyway.
Edit: this post is meant to be a reneral reply, not one to a particular user.
That's OK. I love C as well. I love it for its simplicity and the fact that one man could still write a compiler for it in a reasonable time frame, all be it with out heaps of modern optimisations and compiler technology.
I'm not surprised you found C easily after C++ after all C is almost a subset of C++. Rather more surprised Rust is causing such problems. My first Rust attempts basically looked like C. Perhaps not optimal, certainly not "idiomatic" [*], but it worked and is still running in production some years later. Only later did I start to find the time to devolve into Rust more deeply.
Of course Rust's *memory safety" is a totally different thing to the security or the lack of that crates.io has. It seems unlikely that crates.io would ever have a team of human maintainers like for example the Debian package system.
There is a view among philosophers that what one can think is very much determined by language. Arguably ones programming language does shape ones view of the software world.
[*] Anyone know what "idiomatic" means in Rust world? My view is that it's for the compiler to decide. The Rust compiler is so fussy surely anything that I get compiled and working is "idiomatic". The compiler says so (Well, perhaps compiler plus clippy).
I think it’s decent but in need of some long and very well thought examples but i enjoy the eco-system. lib.rs is great. Idk how long it’s been around but i stopped learning rust in like 2021 but have been back and fourth since 2018. A lot better then looking at java docs Other then springboot docs it’s brutal. Js learned this years ago with simple examples but if you go into most js frameworks now or look for repos on how to do something you’ll find it. I’d wait it out until that microsoft money hits once i heard that, plus the like $10 million microsoft is spending internally with rust, i was like yep! Rust it is. The web content is solid too. They just need to figure out the folder structure that works and sticks. It isn’t embedded systems projects or whatever else rust is used for. loco.rs has the right idea. Mimicking ruby on rails but let’s see. I’m just some random guy who probably knows nothing