https://tourofrust.com/ is fun. Learning rust has a weird initial learning curve dealing with the aggressive analyzer/compiler and how you have to approach your variables, but after that initial hump it is one of the coziest languages I've used. Having what was initially a bit of a nag, is now a godsend when i'm getting red-squiggles in vscode for a typo in my SQL string for a misnamed column, or a field in my template was removed and so my struct shows how it's now unused.
Rust allows me to mainly only run the application to confirm things work from a business perspective.
For people starting out building stuff in rust - understand that there is a distinction of async code and libraries and can lead to confusing compiler errors if you don't realize there is a distinction. It's simple in hindsight but did cause me to waste hours barking up the wrong trees at first. Other wise just learn about `match` and Result/Option types asap, they're fundamental.
Rust is amazing, don't let the initial few speed bumps discourage you - building real things with rust is no more challenging today than any other modern language stack.
The resources mentioned in this list are all pretty good. However, they might be intimidating for a beginner. A beginner wants one or two high quality sources to get started with. That's the Rust Book (https://doc.rust-lang.org/stable/book/) or the interactive version of the same book (https://rust-book.cs.brown.edu)
Also, not sure how this resource classifies Rust for Rustaceans as a beginner level book.
> Also, not sure how this resource classifies Rust for Rustaceans as a beginner level book.
Yeah. It still starts pretty shallow, but by page 33 it has a listing of a non-trivial manual implementation of Debug for some arbitrary type which is iterable, and that's not something a beginner would even need to write, let alone gain insight by having it dissected.
Agreed, just starting Rust for Rustaceans (which I think is intended to be intermediate / next steps after TRPL) and eyes are glazing a bit about variance. Need to review a Crust of Rust or two, I know he's talked about this before.
The second weird comment like this I'd seen this morning. Looks like the first got edited with some context[0], apparently people are upset because Rust Foundation is updating their trademark policy.
Some great resources here. One thing I want to point out: Rustlings follows the path of The Book and provides references for each section where appropriate. So I would not advise treating them as separate learning paths. They work best when used to reinforce each other.
As someone who came mostly from Python and some C: I must say the most difficult part was stopping myself from forcing aesthetical ideas of how to structure code from the other languages into Rust.
There are three points here:
- Rust lends itself to certain structures (that you might not be used to) and makes others very harder to pull off (that you might be used to). The trick is not try to do the latter when the former is perfectly fine. E.g. me trying to do object oriented programming in Rust, or starting off with a linked list as a C programmer
- Rust can be written on different levels. For example you can go for "perfect" code in terms of performance and dive into things deep or you can just not bother at all and do the totally naive thing and still end up with quite fast programs most of the time
- Rust has a type system that it strictly enforces. This makes some things harder, others simpler. Make sure to be aware what you can do with a type system and why it can be a good thing to have one.
As a javascript/typescript developer I took a notion to learn Rust and it has been hard but rewarding on a personal level. Im concerned though that I'm learning somwthing that has very few if any real jobs right now. All I see is block chain nonsense. In your opinion is there much chance that this will change?
To be honest I would say Rust is worth learning even if you were to never use the language at all after learning it.
The problems Rust attempts to tackle are fundamental problems you will encounter in many languages. Understanding how to program or how to think in order not to get those problems in the first place is the thing Rust can teach you. A lesson that any programmer can learn from.
That being said Rust has great testability and interopability. I myself use Rust in some (work) projects in conjunction with Python.
So I definitly see some future for the language, also commercially. But even if I wouldn't, I would still recommend learning it.
Interesting take. So far I agree with what you're saying. It has given me more insight into how memory management works than I'd had before. I think one of the things that bugs me about javascript is how difficult it is to track down memory leaks. A problem I've often faced when dealing with large codebases and other peoples code. The memory management in Rust via the borrow checker is a very elegant as a solution. It's also a pain but not as hard to deal with as people make out.
Yeah, I wish there was a good list of things to hint you aren't being rusty. When you are cloning everything or have arc on everything that is a pretty good hint, but I'm sure someone could put together a better list than I could.
Clippy can help you to write more idiomatic Rust, so if you aren't already, definitely check out the clippy lints for a working program you wrote:
cargo clippy
Clippy won't tend to spot unnecessary Arcs and similar architectural mistakes, however it would notice if you act as though things aren't Copy when they are [e.g. you've probably never 100.clone() but if you did Clippy would point out that's just 100 and the same would apply to types where it's less obvious that they're Copy and you might have forgotten]
Yeah clippy is amazing, but I was thinking things everyone has to do sometimes in rust, but that if you find yourself having to resort to them often might be a hint that your overall paradigm might need a tweak to fit well. I didn't mean unnecessary arcs, but rather necessary ones. I find that if I donthings the way Ferris wants me to, that I dont have arc, rc, refcell, or clone very often, and nothing ends up needing to derive copy. When Ferris is happy my life is easier.
The trick to learning Rust is to first start learning C++; that way your motivation to learn Rust increases even further and you start getting the feeling that Rust is easy ;)
This is similar to the psychological trick of how an obese person, to make himself/herself feel better, stands next to an even more obese person :)
Not just any c++, I'd recommend performance aware modern c++. It leads towards the functional-ish zero-copy lock-free thinking rust rewards. I've been told ocaml or f# programmers also find rust easy.
I think there are definitely aspects of Rust that OCaml/F# developers would find easy because it borrows a lot of syntax and concepts from ML. But to be honest those bits are the easy parts or Rust. Knowing OCaml or F# won't help with the borrow checker.
I think C++ programmers are probably the ones that are likely to find Rust easiest because they should be familiar with lifetimes even if they never really had to write them down.
I mean, that's probably true in some broad categorical sense, for the question of "speed of execution of final program" which it's not clear your parent meant.
However it's not true in the specifics, there are so often little tweaks Rust has that otherwise comparable languages don't have that squeeze out a little better performance and this adds up. For example:
C++ std::vector is a perfectly respectable growable array type right? But no less than Bjarne Stroustrup observes that actually, to his apparent surprise, the reserve() method on this type isn't very effective in using what a programmer knows about the growth of a particular instance for improving upon the amortized exponential growth curve. Rust's Vec is superficially the same type. But it has a subtly different API and in the process it unlocks what Bjarne missed, using Vec::reserve() does allow programmers to successfully guide the growth curve and benefit. [[If you need the equivalent of the C++ API, Rust provides Vec::reserve_exact() for you, but you probably don't]]
Still, for a lot of us there are more important "speeds" than the performance of running code. Rust does a lot of "shift left" on errors, where more of the defects in your first attempt to solve the problem are compiler errors, which you notice quickly and can fix, rather than them failing tests, being spotted in review, or worst of all, getting all the way to an actual user where they cause real problems.
One speed that Rust doesn't have on its side is compilation performance. Rust is not going to be the fastest language for turning correct high level code into running binaries.
> One speed that Rust doesn't have on its side is compilation performance.
I noticed that `cargo check` alone is plenty fast, and when you give it a program with a type issue to check, it reports errors nearly instantaneously (< 0.5s).
So this is probably not all the type checking (including borrowchecking) that slows things down, but the phases that happen later, likely code generation. Which leads me to a question - why is code generation so slow even in debug mode compared to other compiled languages? (this is one thing that Golang does right).
Well I guess we can always play micro-benchmarks game if you want to go down that path, including selecting specific compiler toolchains and flags while making it a point that it is a property of language XYZ, to make it even better.
I don't see the std::vector example as a micro-benchmark, we're not talking about wasting a few microseconds in a contrived example, we're talking about destroying the amortized constant time growth performance of the data structure because of an API goof.
Except nope, it's an API design problem. If you write a std::vector or equivalent but where reserve has analogous behaviour to Vec::reserve you can't do Vec::reserve_exact at all and that can really hurt in other cases.
There really are two distinct features and C++ specifies a single API call.
Yes, it only matters that it fulfills the algorithm requirements described in ISO C++, how the implementation look like is another matter.
Still, this is going way down into the weeds and very far away that any mature AOT compiled language offers good enough speed, ignoring toy compilers done by students.
Except nope, it's an API design problem. If you write a std::vector or equivalent but where reserve has analogous behaviour to Vec::reserve you can't do Vec::reserve_exact at all and that can really hurt in other cases.
There really are two distinct features and C++ specifies a single API call.
First of all Prolog is usually not AOT compiled rather JITed, secondly regarding Haskell, it is an issue with the skill set of the developer more than anything.
Given expert skills in both Haskell and Rust, Rust is by far the fastest performing language.
And if you use idiomatic Haskell the difference is even bigger. E.g. if you use lots of Monad transformers and lazy evaluation.
Check out Odin, it's breath of fresh air, the syntax is minimal and well thought out, so unlike rust or zig (and much like jai*), things are consistent and make sense**.
Absolute beginners seems like the wrong end to focus on if you want to actually be helpful. That stage lasts a couple of days at most. Every step you progress through requires more effort.
Of course content creators typically focus on beginners because there are always more beginners than intermediates, which is why there is so much shallow beginner content flooding the market in basically any conceivable topic.
As you progress into more intermediate and expert understanding there's more and more nuance, which makes it harder to write good material anyway because there's always more you didn't cover.
Still, your observation is why Jon Gjengset's "Crust of Rust" series was created:
Crust of Rust is not intended for people who didn't write any programs before, or even for people who've written a bunch of C++ but now are interested in learning Rust (actually those people might be successful with a fairly self-guided approach to get from zero to non-trivial program). Instead it's intended for the people who're beyond beginner but have specific things they don't "get". The first one is "Lifetime annotations" which is exactly the sort of thing that years of experience in BASIC, Javascript and C++ won't help with.
For people starting out building stuff in rust - understand that there is a distinction of async code and libraries and can lead to confusing compiler errors if you don't realize there is a distinction. It's simple in hindsight but did cause me to waste hours barking up the wrong trees at first. Other wise just learn about `match` and Result/Option types asap, they're fundamental.
https://github.com/http-rs/tide tide is great to create an http server / routes
https://github.com/djc/askama I use this to template out HTML and it checks all my boxes, dynamic data, passing in functions, control flow.
https://github.com/launchbadge/sqlx sql interface for a variety of backend, async safe.
https://github.com/seanmonstar/reqwest http client to make requests
Rust is amazing, don't let the initial few speed bumps discourage you - building real things with rust is no more challenging today than any other modern language stack.