They do say on their website that there's a hump that you have to climb over before everything fits into place, which is probably applicable to everything you'll learn, but sometimes I think that hump is too much of a hurdle
Right now, if I want to find the methods used by BTreeMap you have to wade through a good amount of information until you can find how to just get the keys. I'm currently on mobile where the issue is more prominent.
I mean, that works, but it's a workaround and not a solution.
That said, yeah, I hear you. It can still be tough sometimes. At some point, I'd love to work with some sort of information design / UX person to totally re-do rustdoc's output. There's a surprising number of thorny problems there. But there's always so much to do...
Varints: https://crates.io/crates/varint
Bloom filters: https://crates.io/crates/bloom
Iron: https://github.com/iron/iron
All the accessories for Iron: authentication middleware, integration with OAuth2, cookie-signing, integration with templating systems, etc. Also, an omakase framework (like Django or Rails) that pulls together a bunch of useful libraries into one crate that you can just use (with good docs) and not have to wire everything up.
Websockets: https://github.com/cyderize/rust-websocket or https://github.com/housleyjk/ws-rs
Server-sent events. I don't see a good alternative for these yet.
ElasticSearch: https://github.com/benashford/rs-es or https://github.com/erickt/rust-elasticsearch or https://github.com/KodrAus/elasticsearch-rs
An easy documentation/website generator for small libraries, that pulls examples, tests, and README files out of GitHub, runs RustDoc, and generates a professional-looking website that provides all the info that you need to get started with a library, with a minimum of extra effort for the library author. Basically, automate the job of going through libraries built to scratch someone's personal itch and "productizing" them.
Any of these could be a good project for a beginner, since there's already a lot of existing code to learn from, a small well-defined task, and an existing maintainer who has an incentive to help. Basically, just take a library, try to use it in a small test program (Linus's Law: "Never try to make a big important program. Always start with a small trivial program, and work on improving it"), and if anything is difficult or doesn't work right, figure out how to make it less difficult for the next person who runs across it and submit a pull request with that. As an added bonus, you can learn a lot of domain knowledge or basic CS data structures through digging through this, and that transfers to programming outside of Rust.
Try solving the problems without looking at the solutions first: https://github.com/brianquinlan/learn-rust
Here is a rough rank of difficultly: https://github.com/brianquinlan/learn-rust#understandability
I understand memory management in C. I understand it modern C++ (destruction when going out of scope, smart pointers etc).
Basically, a description and discussion of borrow-checking for people who have already used system programming languages would be really helpful. I feel like the book is targeting people who have only used garbage collected languages.
Or is the memory management of rust so novel it can't be described in those terms? I find the concepts aren't very concrete to me.
I try generally to keep other languages out of Rust's docs for various reasons, but agree that these kinds of resources are useful; I wrote "Rust for Rubyists" after all!
I'm hoping that others will step in and fill this gap; the repo in my sibling is a great start.
I feel I am getting over the hump of learning rust now and coding in rust is becoming less frustrating for me.
However, one thing that slows me down is the lack of indices in the documentation. For instance, if I want to know the return type of a vector len() I go here:
https://doc.rust-lang.org/std/vec/struct.Vec.html
.. and then I have to search the web page for all instances of "len". It would be good if there was an index similar to Javadoc, Godoc or Doxygen.
There might be a good reason for not having the index, but as a beginner it is lost on me.
If you click the little [-] button, you'll get an index for that page.
If you use the search bar at the top, https://doc.rust-lang.org/std/vec/struct.Vec.html?search=vec... will let you go right to the method. (In this case, you have to know that it's slice::len though)
Does that help?
EDIT: UX is hard! Glad people are discovering this. It's the same symbol HN uses, incidentally...
A polite suggestion - maybe the link marked [-], that takes you to the index, could be labelled "index".
I would echo the suggestions to make that button much more visible. Or perhaps even have the top-level description expanded by default but method/trait descriptions hidden. I can't think of a case where you'd simultaneously want to see every method description.
Seems like there's some UX improvements that could happen there.
I am waiting a good book on rust. similar to Haskell, I really did not get much until the book http://learnyouahaskell.com/
currently, "The book" is too dry.
I have resorted to using Nim for now, and it is going real well. I would like to rewrite the Nim stuff in Rust to compare for my own sake when I have done something substantial in it.
Or the rust forums: users.rust-lang.org
Or the rust subreddit: reddit.com/r/rust
Following the book, I installed Rust directly, but then i realized that I should've installed it via Rustup. Next, I want a good editing environment, so I install VS Code and Racer, but then I find out that I can't use Clippy unless I use Nightly... and I'm not interested in using Nightly, so I'll wait.
Now, coming from loose dynamic typed languages or really terrible C or C++ code bases is another matter.
We don't care about expert cases, we only care about getting productive ASAP, which means having students hoping into a language and learning it quickly. Solving the details is easy: just teach coding discipline and enforce good practice and do code reviews, and discourage "throwable" code. Security is not only the job of a programmer, it has many many facets.
In short: english is better than latin or esperanto. The more time and space you need to describe your language, parse it or the more character or syntax it requires and the longer it requires for an individual to read a program and guess what it does, the worse it is.
I'm getting a little tired of the "novelty" languages these last few years. Maybe I'm more conservative and don't like the hype. To me only D is relevant and it has been there for a long time now.
I think Rust may be useful in cases like ripgrep, where you basically rewrite an existing, established tool or service used by many to be as performant and secure as possible. But other than that niche use-case, I don't think Rust will catch on in the long-term.
It's not like I just rewrote grep. ripgrep is built on a large number of libraries that are reusable in other applications. You can see my progress on that goal here: https://github.com/BurntSushi/ripgrep/issues/162 (And those are only the ones I wrote, nevermind all of the crates I use that have been written by others!)
Hypothetical scenario: Let's say you're writing an experimental tool that doesn't exist anywhere else. You don't care about security, you don't care about speed. You just want it to exist so you can see what it does and possibly iterate on the idea if it ends up working out. Would Rust still be feasible?
From my impression of it, you would need to take care of a lot of corner cases and such (which don't exist in other languages) that may slow you down in the short run. I'd imagine those corner cases would be extremely helpful in the long run if you want to squeeze some extra performance out of it (or avoid technical debt). But from the perspective of "figuring out what's possible" I feel like Rust would get in the way a lot.
I will say that a comparison between Rust and C is much easier, because in the past, I've spent so much time debugging runtime errors in C with valgrind. Rust is an easy win there for me personally. I've never done much C++ so I can't provide a comparison point there.
After a bit of Rust coding you get quite familiar with the workings of the borrow checker, and it becomes pretty natural to work with it. There are plenty of things you can do in C that Rust's borrow checker will forbid because it isn't smart enough to prove it safe, but there are usually straight-forward work-arounds. Sometimes the borrow checker might even help make the code a bit clearer. :-) Some of this is institutional knowledge though, so there's still a lot more documentation work left to be done!
To bring this back to earth: Rust won't replace those ~100 line Python scripts that I sometimes write for quick data munging.
The other important bit of context is that before I started with Rust, I had already had quite a bit of experience with C, Standard ML and Haskell. This meant that the only truly new thing I had to cope with in Rust was the borrow checker, so it might have been easier for me to digest everything than it might have been for most.
1) Drop the semicolons and implicit returns in multiline functions (I.e. like Swift). Eliminates hard to understand errors around missing or present semicolons.
2) Allow silent lossless integer upcasts. Sprinkling as usize and friends everywhere is unergonomic.
3) ? For return is fine but the line should still have one "try" at the beginning for legibility.
4) Allow full inference of generic type parameters. Would make it much easier to split code into helper functions.
5) Macros are nicer than in C but still hostile to comprehension.
There are others, but these are ones I've personally run into. Love the language and especially love Cargo but it has some newbie-hostile rough edges like this and others.
1. Most Rust users, including me, like the implicit returns. We would face a ton of pushback if we tried to drop them. Rust doesn't actually need that many semicolons: you can frequently leave them off.
2. This is tricky, because it can have surprising semantics if not done right (e.g. right shifts). There are proposals to do something like this, though.
3. I disagree. That would eliminate much of the benefit of ? to begin with.
4. Not possible. This would complicate the already very complex typechecker too much.
5. Macros 2.0 is coming. We can't just remove macros: they're fundamental to basic things like #[derive] and string formatting.
1) If you dropped semicolons like Swift, you could keep implicit returns.
I just don't see the advantage of having them in multiline functions at the cost of having to retain semicolons. IMO, a trailing value after a multiline function also just looks plain bizarre for newbies.
I agree it's probably too late for this, but you asked how Rust could be easier to learn and this is one of the ways.
2) It would certainly be much nicer to have this.
3) See Swift for an example of where this was done more nicely IMO than in Rust.
4) Unfortunate. Splitting out a helper function means we lose Rust's inference which already exists when used in a let statement, and requires adding dependent crates from libraries to the binary's Cargo.toml and importing them into the module and hard coding the types. The client shouldn't have to care about this.
5) Great!
I still enjoy the language just the same, but you asked how it can be easier to learn and this is how I see it.
Unfortunately though, i'm back on Go. I want to be on Rust, but i had to pick a language for work and i can't ask my Team to go through what i did. Rust, despite the safety, is too unnatural for our larger codebase.
Luckily i think Rust has seated itself as the language we will use if the need is truly there. Unfortunately though, not everything.. just the specific things that need it.