As a developer which coming to Rust from dynamic languages for language with static typing (I like static typing), and a web developer, I very dislike such phrases. I hope this person have nothing to do with Rust core team. Otherwise, if he/she is right, and Rust is not for web developers, please point this on the rust-lang.org explicitly.
I can assure you that Rust is not just for low-level programmers, and there are many people working on libraries and frameworks to make it suitable for web development. @sinistersnare is not on the core team (nor am I, or most people in this thread), his comments represent only his own opinion.
3 Likes
I am also a web developer coming to Rust from dynamic languages with a history of strong (not static) typing. I am no OS developer (though I would like to be), and I think you misinterpreted me.
I view Rust as a language to use when you need fast code (because everything should be safe), with minimal footprint. Usually, in web sites, the bottleneck is with the database, and not the application code, so there is not really a need for Rust when you have safe languages like Python, Java, or Haskell.
However, if you, for example, only have an instance where you have 10 megabytes of RAM, like if you dont want to spend tons of money on hundreds of megs of ram on DigitalOcean or AWS for a hefty runtime like a JVM, then the minimal footprint of Rust is perfect.
The average web dev does not need Rust, it is not an insult, its a personal opinion held by me. I do not appreciate your comment, but I am not going to assume malice (done that too much before), and I want to say that I am sorry if i offended you.
Thanks, @lambda for the defense. <3
I am also +1 for the book to be light on Cargo, I think it would be good to be able to run all non-cargo specific examples on play.rust-lang.org (although im pretty sure that is the case, just wanted to reiterate).
Personally, when I am reading a book about clojure, I donāt care about leiningen, same thing with Python and Pip, I want to learn the language, not the infrastructure.
Since when Python is a safe language? Look at Ruby performance and you will realize that code performance matters too (although not so much). In web sites, memory footprint per connection is a bottleneck too - for scaling (even when you have 32Gb of RAM per instance), so languages like Go and Rust are very attractive for web development. Also, what is attractive personally for me is static (exactly static) typing and explicit errors handling, so you can catch a lot of errors on the compilation step, so you can save huge amount of time in debugging step.
And second time you write message which can be read by some web developer as "you are not welcomed in Rust, go away". Let web devs decide what they need, especially when nobody asks you.
I've also just come to Rust as a newcomer, and I have to agree with the general comments left initially by @terpstra.
Sparing you from the backstory of how I came across Rust and my own personal background, I found the book to be a little directionless at times, and often not backing up or expanding upon claims it makes.
There's at least one area where the book mentions that doing something in some way is "considered poor style" (I believe this was referring to explicit use of the return keyword, but never goes on to discuss idiomatic Rust or what is considered "good style" (and why).
Also, I can basically confirm @qwertie's general points, especially his point regarding iterators:
I saw the "strictly worse" comment and asked myself "why? what makes it worse? what should I be doing to access indexes?". Of course, @steveklabnik's answer:
answers my question, and this should probably be in the book.
I can appreciate that the language is fast-moving and the documentation sometimes suffers from this pace, but I found the book to be "Much Ado About Nothing" for the most part. Some of Rust's most interesting aspects (it's ownership model and lifetimes) were under-explained to the point I knew they existed, but I had no idea how to use them or how they even worked.
I found the book useful as a basic syntax guide and telling me about a few gotchas and getting me oriented with the syntax, but I believe that the book definitely needs some work for people who come looking for in-depth explanations of Rust's features and the reasoning behind them.
Thanks @steveklabnik for your efforts, and I hope that the book can be improved to help people like me in the future 
1 Like
I generally find a good coding style for Rust can be found in Python, as they share a lot of syntactic and semantic similarities. The reason I say this is because I find that Raymond Hettingerās video āTransforming Code into Beautiful, Idiomatic Python,ā is actually quite effective at showcasing good Rust code too 
, for example, the video contains a great explanation at why enumerate is recommended over length based iteration.
I also find myself consulting the zen and pep8 for good practices in general coding.
Thats usually what I say to people who seem unguided by the Rust documentation, hope it helps!
@OZ_ please stop being offended, this is the internet, things are communicated badly, just relax and do not assume malice. Thats all im going to say, you are going way off topic.
I really want to stop having this converstion, but this is not an opinion shared by me. While it's true that you should try to assume something charitable, 'it's just the internet' is not an acceptable response for bad behavior, generally speaking.
Now, as I said above, let's move past this. It's not a big deal.
Hey @JoeHazzers, thanks 
You're possibly right in this case. The thing is: it depends. I'm not sure I've ever actually used enumerate in my own code, just like I rarely ever used each_with_index in the Ruby I wrote. It's very hard to write a general-purpose doc, as differnet people do different things in different styles. if you go on at length about every detail, you get the above complaints about Cargo, for example: covering stuff that is 'boring'.
It's impossible to generally please everyone, which is why I can't wait until some other people start writing more long-form documentation and tutorials. There's a few blog series that are shaping up, but we need more!
This is absolutely true. A significant amount of this has been in flux, historically, which is why the book sticks to the basics. You have to cover everything, so you cover easy things, and things that are unlikely to change. Now that things are settling down, it's easier to do so, but there's a lot, even for the basics: last I checked, the book was already 50,000 words, which is the size of a small novel. And when I re-did the TOC, I found a feature or two I still hadn't even gotten the basics covered with yet.
So, I guess what I'm saying is, you're right, but you also have to be patient. 
(which you are, I mean the general 'you')
1 Like
It depends actually. I would say that you want to spend the most time optimizing your front page, because thatās what 90% of visitors will be seeing. This means you want to avoid having DB queries on the front page. Even if you pull data from the DB, you should still use a caching layer so that youāre getting very low response times.
If your page loads slowly, a greater percentage of people will turn back instead of waiting for it to load.
So yes, your website might have enough RAM to run Ruby on Rails, but if it takes a few hundred milliseconds more to render the page youāre still losing customers.
Personally, when I am reading a book about clojure, I don't care about leiningen, same thing with Python and Pip, I want to learn the language, not the infrastructure
But when you read a book about writing Javascript in Node, you likely want to hear about npm don't you? This is a more suitable example of the connection between Rust & Cargo IMO
Personally, I have no good feelings about JavaScript, or its ecosystem, so I donāt use it as an example because of my lack of experience.
It could be, but I am not sure. I also personally thing that, like I said, Id rather learn about the language and then its infrastructure, not both at once.
From what Iāve seen in most Ruby and Node books, they glance over the package management stuff and simply assume that you pretty much know how to use the tools.
In this respect, I view the inclusion of cargo as a first-class topic in the Rust book quite refreshing and beneficial .
Itās true that at first I didnāt care much about cargo as such, but it was good knowing that it is there if/when I will need it and at least I knew how to fetch external dependencies - then I simply skipped the rest until cargo became an integral part of my workflow and then I knew where to go back for more information on its usage.
So in my view, yes - you donāt need cargo right out of the gate, but you can always just skip the irrelevant sections and come back later, that said I do agree that perhaps it could be moved to the end as a sort of appendix.
2 Likes
I skipped the cargo section and went straight to the language stuff. Then I went back to the cargo section when I cared about it.
I donāt see why people here think the book must be read linearly. Now, in OTHER chapters there are many concepts that get introduced quickly that you might miss if you skip them, but not for using Cargo or installing Rust. Those are actually as described.
I am not a fan of any of the personal attacks going on in this thread, please try to keep the discussion on topic, and not dissect me. I dont need to explain my experiences with JS, I was stating my opinion.
Can we please keep the discussion on topic? If you want to discuss how much you hate me, or anyone else, please leave a private message.
1 Like
Just in case you were still wondering about a case for this:
Using .lock() will return an error if any previous code block which held the lock panicked. This is to protect you from incomplete data inside the Mutex in case an operation panicked midway through modifying the data.
Here's an example which invokes this behavior:
use std::sync::{Arc, Mutex};
use std::thread;
fn main() {
let data = Arc::new(Mutex::new(vec![1u32, 2, 3]));
for i in 0..2 {
let data = data.clone();
thread::spawn(move || {
let mut data = data.lock().unwrap();
if i == 1 {
panic!("AHhhhhhh");
}
data[i] += 1;
});
}
thread::sleep_ms(50);
}
The result:
thread '<unnamed>' panicked at 'AHhhhhhh', <anon>:13
thread '<unnamed>' panicked at 'called `Result::unwrap()` on an `Err` value: "PoisonError { inner: .. }"', /home/rustbuild/src/rust-buildbot/slave/beta-dist-rustc-linux/build/src/libcore/result.rs:774
This is mentioned briefly in Mutex in std::sync - Rust, though I think it would be good to include it in the relevant section of the book.
The old behavior for this was just to panic the thread borrow a lock after a previous thread had panicked, so I think this is at least somewhat of an improvement.
An enormous +1 on the suggested changes in terpstraās comment ā these match up almost spookily exactly with the pain points Iāve experienced in picking up Rust, particularly that around Boxing.
Thereās a few occurrences (such as the discussion about lifetimes) where things fell a little more towards āhow it worksā rather than āhow/when to useā. Maybe for the current audience for the language though (curious enthusiasts!) thats appropriate.
a lot more convenient that repeatedly running cargo new println --bin and then having to navigate in to println/src/main.rs (which is the same filename for every project
FWIW, I ended up with cargo new playground && cd playground && mkdir src/bin, so all my experiments are in playground/src/bin and I run them with cargo run println(for src/bin/println.rs) etc.
1 Like
Ah, thatās a good point. That is a more convenient way to create a single project with multiple binaries easily with Cargo. Perhaps that should be mentioned in Hello, Cargo!; or maybe the Cargo docs could be organized such that that would be easier to discover.
Right now, to find out how to use multiple executables in a single Cargo project, you have to scroll all the way to the bottom of http://crates.io to find any docs links at all, read through Getting Started and the Guide that doesnāt describe this, find that now thereās a documentation dropdown in the upper right (which wasnāt there on the front page where I had looked for it originally), go through that until you get to the Manifest Format page, read down to the The Project Layout section that describes where to put things that should compile to binaries, then check man cargo to figure out how to run separate binaries, but it doesnāt say, so finally try cargo help run and see that you need to run cargo run --bin println (though actually, as pointed out, (nope, it looked like cargo run println is sufficient)cargo run println worked when I only had one executable, but that was actually running my one executable with the argument println, once I have more than one I got the error that I need to use --bin to disambiguate).
Whew! Thatās a bit hard to discover. I hope the above isnāt taken too critically, Iām just trying to describe the process I went through trying to figure this out, in order to help suggest places where it might make sense to improve things. I had actually given up some somewhere around the part when reading the Manifest Format page, since I said to myself āI donāt want to have to define a separate [[bin]] entry for each binary, I want it to just work automatically for any file I drop inā, so I fell back to using a Makefile and rustc directly. Now that @kstep has pointed this out, I went back through to see what I missed, and wrote down the above steps.
Finally, one more thing that has bothered me ever since first reading the Cargo docs; why are libraries defined in a section [lib] with single brackets, but binaries in a section [[bin]] with double brackets? And how the Cargo organization interacts with the crate structure is also a little poorly defined; can one Cargo project handle multiple crates?
Anyhow, I should probably break this comment up into a number of tickets and/or PRs on both the Rust and Cargo documentation; just writing it out here to clarify why I had gotten lost and given up on Cargo for this kind of simple task. Donāt have time to do that right now, but Iāll try to do that this evening.
Cargoās docs have been a longstanding thing, they havenāt gotten a lot of love yet. Iāve been meaning to fix them up, but the language is more important right now.
Because you can only have one library, but N binaries.
1 Like