Hello I have just 100-150 hours of python experience and 20-30 hours of java experience. And now I'm trying to learn rust. I started to read The Rust Programming Language book, and i want to improve my skills fast. Is there any advices you can give me?
Rust Cookbook
Fast will be painful, go slowly
I am myself beginner, do not listen me..
Rust is C. Do you want to program in C ?
3 Likes
how did you manage to count experience by hours? via records on online courses?
7 Likes
Very good point. Fast will not only be painful but outright harmful. For most people, Rust isn't a language that can be learnt in a week. The main thing to get your head around will be the type system (which includes traits, generics and most importantly the lifetime system) - and this is best taken slow. Also, for Rust you need to negate your Python and Java instincts to make a class, a sub-class and make an object.
Not to be discouraging, but just friendly advice - take it slow.
In programming it is rarely useful to count by hours or even by lines of code. A more informal but useful heuristic would be to note the "number" of projects that you have written.
3 Likes
No, it isn't.
10 Likes
Finish reading the Rust Programming Language. 
9 Likes
Best type of learning for me (that works, again, for me, but it might for you as well):
-
Read The Book. It has a few real-world'ish projects throughout that should help you get the idea.
-
Write small programs while reading it to make something usefull for you (even if you can accomplish that faster/more efficiently in another language). I've reimplemented in Rust a few bash scripts that I've used to migrate about 200 mssql databases from one server to another, and a small server that signs loyalty cards for Apple wallet (I've cheated here a bit because Apple provides reference implementation in Ruby).
-
I found that when I'm just starting to learn the language, turning off everything besides syntax highlighting and formatting (I use vim at the moment) helps me to train muscle memory because I'm forced to type everything by hand.
-
If you have something real that you want to implement and you're doing that - I can't think of better and faster learning path.
Also yeah, I can tell from experience that amount of hours you've spent with specific language have nothing to do with your experience and abilities. It's impossible to tell based on this number alone.
4 Likes
A bit off topic, but this reminds me of installing Rust for the first time and thinking
...that rustc thing is probably some sort of C compatibility tool that helps integrate C code in Rust...
So pick your names better, lads. 
Nah. The c suffix is actually the correct naming convention, because it very commonly stands for "compiler". There is:
-
gcc, the GNU Compiler Collection, formerly the GNU C Compiler; -
javac, the Java compiler; -
ghc, the Glasgow Haskell Compiler; -
protoc, the Protocol Buffer Compiler
just to mention a few.
10 Likes
This is probably not going to be a popular response, but the fastest way to get better is to avoid switching languages and put all your focus on one. It doesn't matter which.
First, learn the fundamentals of programming and get some experience under your belt. Once you've progressed from "I know what a class is" to "I can happily write 1000+ line programs", you'll have enough transferable knowledge on programming and software engineering (the two are very different skills) that picking up a second or third language becomes really easy.
13 Likes
Not quite. But....
I do suggest read the K&R The C Programming Language at and do not stress too much on the the pointers and input/output chapters. Get an idea of what is happening with data and functions and flow control. Remember that 'c' is simple and broken and you are just learning it to learn it and only plan on doing small simple things with it. As you try to make a simple project that you will get inspired to write when you read the "c" book, you will find some things that are a bit of work in "c". Classes, vectors, objects, that stuff is all missing from "c" Oh and the part about strings is strange too, ending with a null 0.... Anyway read through the "c" book over a weekend and maybe get a compiler and try do a little practice and experiments.
Then after a weekend or two with the "C" book, your brain will have some understanding of what is happening. Then move to the "rust" book and do each example step by step. (and Rust By Example) of course.
Another good trick is to learn to type
rustup doc std::module:itemname
to jump to what you need to know.
3 Likes
I have been hearing that "Rust is hard" a lot lately, and perhaps this is a good place to put my thoughts on that. I hope this helps you, as it is really just MY journey (there might be tons of other ways).
Don't swallow Rust all at once... use a project to guide the features you learn
I have been learning Rust for a couple of years now. However, I don't use it full time (the company I work for uses Python) and Rust is just part of a SIDE PROJECT which has somehow gotten out of hands... it is relatively big now!
Choosing a project that is not too small has helped me a lot because it has helped me choose the features that I need to learn next. Rust is too big to swallow it all at once so developing tools or libraries that are not too small will naturally push to learn new specific Rust features. I have not touched Async, for instance, and I only recently realised that there were From and Into traits... but in the process I have learned about macros (Derive, Attribute and Proc ones), multithreading, random numbers, etc.
However, before your project
Assuming you know nothing about coding... This would go BEFORE starting a full project in Rust, unless—like mine—your project simple things that can help you get started (mine was a Matrix library).
Stage 0: Familiarise yourself with the tools
Grab a toy project that is mostly about math or something simple (numbers don't have pointer or lifetime issues). Learn to run at least these commands:
-
cargo test: Learn to write tests... unit tests and integration tests (in thetestsdirectory), using the#[should_panic]attribute when needed. cargo fmt-
cargo doc: Learn to write docs cargo build-
cargo build --release(it is mandatory to ask about the--releaseflag on every question about performance, by the way) -
cargo clippy
These commands and their related features will accompany you for ever.
Stage 1: Learn the syntax
- Get familiar with
Vec,arrays,i32and its cousins,f32and its cousins,bool, etc. Write tests to see if what you are thinking should happen actually happens. - Write a
structof some sort. Check the#[derive(Debug)],#[derive(Copy)],#[derive(Clone)]attributes. - Implement methods for that struct using an
implblock - Play with pointers... follow ANY simple tutorials on pointers, on any language. You should not find many complains from the borrow checker.
- Explore the basics of
for,if,while,loop, andfor x in vector... there is no need for fancier things yet
Stage 3: Starting with the funny syntax... Enums, Traits and Generics
Stages 0 and 1 basically rely on concepts that you have used many times (and pointers, if you have not heard of them before)... for, if, else, while, they are all present in pretty much every programming language. So, stage 3 introduces the first bits of less common syntax, I think.
- Learn about Enums and Pattern Matching.
- Check the
ResultandOptionenums - Follow Generics and Traits section in the book.
Stage 4: Choose a project to guide you
I might be missing something... but, to me, these have seemed like the elements with which the rest of Rust is developed (maybe, async would be one more...?) and therefore this should be enough to start something and being able to questions with the correct language, so people can answer them.
Is Rust hard?
I honestly believe that Rust is not particularly hard, but programming is. However, Rust is extremely explicit and therefore—contradicting my previous advice—sort of forces you to understand some things earlier. For example, the first compiler error raised by the infamous (yet addictive) borrow checker might make you to learn about lifetimes, race conditions, and so on. Then, fixing this issue requires some funny syntax that can look quite hard.
Of course, you can argue that this Rust is complicated because of this characteristic but the truth is that other languages also have race conditions and lifetime problems... they will just force you to learn about these issues later, the first time you find a bug that you can't explain. Even programming languages like Python or Javascript will have issues related to this, as they also have pointers... they just don't talk about them.
EDIT:
Check Youtube tutorials. There are some AMAZING ones
17 Likes
I believe that recommendations to "learn C first" are often based only on the fact that that's the way the person recommending it did it (and in the case of Rust, the only reason why that was the case is that C is much older). I. e. I do not think it's a requirement, and I do believe that Rust is probably more beginner friendly than C, and there's little value in learning all those quirks (null terminated strings, header files, incomprehensible type signatures syntax where the variable name is hidden somewhere in the middle of it, etc..) unless you actually want to program in C, too; or you simply want to learn it for fun or for unrelated reasons.
With my personal experience of what prior knowledge helped when learning Rust, I could recommend that learning functional programming before Rust is super helpful, too (in particular Haskell), but IMO the same argument applies that it isn't really necessary.
The only real benefit in either case might be that the beginner material is probably a bit better than what's available for Rust, since e. g. the Rust book does kinda assume some basic familiarity with programming. On the other hand, some exposure to Python and Java that OP has might well be enough to make things approachable.
13 Likes
This might actually be a good reason to try C first.
A lot of "why does Rust make me do X" questions non-C-programmers ask here relate to the fact that they don't recognize certain common pitfalls of memory management, and thus, transitively, they don't appreciate the need for dealing with them. For example, a common misconception people have is that shared mutability is memory-safe in a single-threaded context.
For this very reason, I find it extremely helpful to have been bitten by UaF or race conditions in C, or iterator invalidation in C++, simply because the learner will then instinctively recognize that Rust isn't just piling arbitrary restrictions on top of each other – rather, the rules are there to enforce memory safety.
7 Likes
Anecdotal, but -- a year or so ago, a friend was taking an introductory programming course and asked for some help. The course was in "C with C++ i/o" approximately, for whatever reason. Their program would run to completion, but give random-seeming incorrect solutions.
Their root problems were, roughly,
- Using arrays instead of dynamic vectors/strings (perhaps a course restriction, unsure)
- Using a 0-sized array specifically
- An off-by-one error elsewhere
And they were smashing the stack [1]. But having not touched C in awhile and being so immersed in Rust the past couple years, what really blew me away was
- No compiler errors
- Not even any warnings
- No runtime panic/abort either, just straight UB [2]
I'm still unsure I would call Rust beginner friendly [3], but that definitely put me in the "Rust is more beginner friendly than C" camp.
This is a thought-provoking point as well.
and reading past the array elsewhere ↩︎
g++ (pretty sure it was that one) did trigger a smashed-stack warning; other compilers did not ↩︎
but not sure I wouldn't either; someone here recently pointed out there isn't much data on learning programming with Rust from the start, and was curious about how much of the difficulty comes from having an established viewpoint on programming already; now I'm curious too ↩︎
6 Likes
I'm a beginner and I initially used (still using) JetBrains' Clion IDE with the Rust plug-in => it's a huge help especially for a beginner (e.g. to list available structs methods).
I think that it's free for 1 month, afterwards you have buy it to be able to keep using it (not extremely expensive for me, something like ~70$/year if I remember correctly - you can stick to the version you bought without having to pay again/renew).
I think that JetBrains' IDEA has as well such a plugin (might be better than CLion, if you need already IDEA for e.g. Java) but if I remember correctly it was slightly more expensive.
Cheers
Yes - let go of that desire. Skills can't be learned 'fast' - it's just not the way the human mammal is put together. By all means take advantage of suggestions offered, but not on the basis that they will speed things up. Do what's most relevant and appealing given your situation (your personal preferences, your purposes in learning Rust, etc). In all honesty, if you did still believe it was possible to accelerate learning, folk wisdom wouldn't be your best source of advice. Science (in this case educational & cognitive psychology) would be the place to look. People in the weeds themselves are generally far too opinionated, emotionally involved, and bound by their own limited personal experiences to have a usefully objective view.
2 Likes
How then do you account for the fact that so many seasoned programmers find Rust hard? Here's a quote from Chris Keathley, a extremely proficient Elixir developer:
I've written a non-trivial amount of Rust code (50-100k lines) .. and I feel like I barely understand Rust as a language
(heard on the Elixir Outlaws podcast #110). I've heard similar things from many others. Some, I suppose, like Andrew Kelley (Zig originator, who said he couldn't find his way to being productive in Rust) you could put down to bias or competitive outlook. But all?
All we have is anecdotes, I guess, but I can certainly tell you I find Rust hard, despite having programmed professionally in multiple languages. I can definitely do far less with it in practical terms than with any other language I've learned at a similar early stage. Though I never tried C++ 
I don't see it as a bad thing that Rust is hard to learn (I'm keeping at it with a new project right now), so I'm not totally sure where the defensiveness on that score comes from (though I have a couple of theories). It's trying to solve hard problems. We don't see difficulty in other domains as 'bad' - I've never heard quantum physics dissed because it's 'hard'. But denial can turn something that wasn't a problem into one.
I'd never think that the critiques towards Rust are based on biases and competitive outlooks. On the contrary, I think that a lot of the "difficulty" comes from the fact that programming languages shape the way we think about problems, and Rust does change the game in that sense.
In fact, this is why I like Rust: it is the first programming language that I feel to be different from all others. This happens because, instead of constantly thinking about memory and allocations/deallocations, Rust allows me to focus on what I do best, which is the math and the physics I am trying to solve using code. I am quite good at predicting and avoiding issues with Infinites and NaN but very bad at memory management (I actually did not know I had to deallocate stuff the first time I tried C). Rust is a natural complement to my programming style and way of thinking.
On the opposite end, I have had a fair amount of interaction with the code written mostly (it is Open Source, so others have participated) by an extremely experienced C programmer. I told him that, based on his coding style, he would not like Rust. According to him, he has
a tendency to write code that computers like, but people (including [himself]) have trouble reading.
These are his thoughts on Rust's borrow checker:
I had a look at Rust’s “borrow checker.” Surely, that would drive me mad. I like the unconstrained nature of malloc()/free(), and probably use it as often in C++ as I used the new and delete operators for flexibility reasons. I rarely forget to deallocate something I’ve allocated. I’d say in 50 years of coding, I don’t think I’ve ever had a memory leak issue, though I have miscalculated array sizes and paid dearly for it. Much harder for me is dealing with NaN’s when they crop up, as they obliterate everything downstream in a calculation without leaving a clue as to where they originated. In a recent bug I fixed, the actual errors didn’t even show up — they just quietly caused a critical bit of code to get bypassed (the ambient super-sampling function).
So, to some degree, I suspect that it is easier to teach basic Rust to someone who has not yet been shaped too much by a programming language/paradigm than to an experienced person who comes with a previously-shaped way of thinking. This was sort-of my case, as the nature of my work does not require THAT much from programming languages. I develop for solving finite difference calculations, ray-tracing, etc. These are fairly simple kinds of applications, from a Computer Science perspective... so, there you go, maybe there are SOME things that are very complicated in Rust and I just haven't needed them.
4 Likes
I don't think the Rust part there is right. There isn't much conceptually different about Rust for polyglot programmers. For me, learning Clojure (my first functional lanugage) a couple of years ago required much larger changes in my thinking about how to decompose problems and implement solutions than with Rust. The only really novel thing Rust brings to the table is the borrow checker, which is straightforward enough to start with (though I realise it has its hairier reaches).
The difficulty of Rust is less conceptual and more in the sheer size of the language, and the tendency of the Rust community, for perfectly good reasons given its usage patterns, to be tolerant of complexity (in commonly-used crates, not just the language). It's the details that are hard, not the concepts. I was more 'productive' in terms of actually being able to write programs that successfully do stuff after a few days of Elixir (which, again, was more conceptually new to me, because of the singular nature of the BEAM VM, than Rust is) than after a few weeks of Rust. This doesn't count 'against' Rust in any way. Difficulty is not 'bad' if its sources are intrinsic rather than accidental.
1 Like