The part complaining about missing details in the error message seems weird. You get a pretty detailed error even without using `--explain`:
error[E0384]: cannot assign twice to immutable variable `x`
--> src/main.rs:4:5
|
3 | let x = 3;
| -
| |
| first assignment to `x`
| help: make this binding mutable: `mut x`
4 | x = 5;
| ^^^^^ cannot assign twice to immutable variable
error: aborting due to previous error; 2 warnings emitted
For more information about this error, try `rustc --explain E0384`.
As someone who started learning Rust a few days ago I find its compiler errors incredibly helpful!
I don’t quite understand the author‘s complaint either - the error message in the example (like most others) does state quite precisely what went wrong and how to fix it (By default, variables in Rust are immutable. To fix this error, add the keyword
`mut` after the keyword `let` when declaring the variable.).
Default mutability like practically every large language? I’ll admit, both have their uses, but if you’re striving for less runtime errors, default immutability makes more sense.
> The book really led me to believe there are literally two types of strings in Rust
Oh you sweet summer child :) The joys of discovering that on lower levels, a String is not a str is an OsStr but is not a str and why that is are coming back to me.
Also, I particularly like the periodic table of rust types:
This compared to almost any other language should tell you that Rust trades compilation speed for strictness and execution speed. It's really helpful to understand what you need to care about if you don't have a garbage collector working for you.
Rust has String, OsString, PathBuf, CString and Vec<u8> plus their borrowed equivalents. And the borrowed versions are often wrapped in `&`, `&mut`, `Cow` or `Box`.
So many options in the standard library alone. There are several popular crates which add even more string/buffer types.
And the cool thing is that thanks to borrowing and traits like Deref and Display, most of these types have a zero-cost common denominator in `&str` or `&[u8]` which makes them reasonably interoperable.
In 2001 I witnessed five Java devs (all with over a year of experience) huddled around a desk looking at a line of code like this:
int x = foo?bar:baz;
"Question mark and colon aren't legal characters in variable names!"
"They must be. The code compiles!"
"But where is this symbol defined? How can it be in scope here?"
"The code compiles, but it doesn't work, right? It must be a compiler bug!"
That's the risk of learning a language "on the job" or from piecemeal tutorials, instead of reading a book or similar resource from start to end. Sometimes there's a corner of the language that by chance you just haven't seen yet, even after years.
A very junior dev once called me over for help with some JavaScript.
Going through his code, all his numbers were in the form of 1,234,567 with coma place separators. The code worked somewhat purely by accident. It took a surprising amount of convincing on my part to have them understand that wasn’t a thing they could do in JavaScript.
Btw. there are parts in the standards library which are not suited for learning rust by understanding it.
Not only might your run into some but trivial edge case complexity which add the user of the standard library you don't have to know about at all but you will also run into a bunch of unstable nightly and as such often but that well documented thinks, some of which might never get stabilized.
So if you start learning rust this can lead to unnecessary confusion.
Btw. one of the reasons I like rust is that for a lot of the (more hidden) complexity you get away without knowing it and (important) if you don't get away with it you run into a compiler error. Which is in difference to C++ where a bunch of the (more hidden) complexity has quite a high potential to screw you up if you run into it without knowing about it.
> I see a very sharp knife; but this knife is completely and utterly shrouded and encased in tamper-proof, child-proof, thief-proof hardened and sealed plastic shells.
Yeah, because that knife is made of uranium.
Anyone not handling that uranium as they should, should be shunned, isolated and enclosed in a lead vault.
DISCLAIMER: I did work on some Rust code (XML parser for Servo), but I'm not Rust dev by any stretch of imagination. I haven't touched it in months/years tbh.
My daily grind is Java. And I've seen enough idiots opening the plastic and licking the glow-in-the-dark knife in Java.
It always leads to fun and interesting problems.
By fun I mean "Get me out of this hell" and by interesting I mean "I obviously need more drugs to understand this code".
> Ah, so that's what happened to the Actix developer. What a welcoming community!
No. He realized his mistake and isolated himself.
Here is the approximate recollection of events regarding his work on Actix:
-------
Have a safe function that does the same thing as your garbled mess of unholy unsafe abomination.
Use unsafe.
Gotta go fast!
-------
People submit PR to fix your unsafe hell spawns.
Reject!
Gotta go fast.
-------
People call you out on it.
Delete all the code.
No code = fast.
-------
In the end, he had a change of heart set new maintainers and restored the project. Then went off to write code to benchmark in C.