This isn't really specific to Rust, but, while I wouldn't necessarily do all this stuff while working through a tutorial on Rust, the start of a brand new language is a great time to learn how to set up this sort of stuff on your code from the very beginning. By definition, you must not have a lot of pre-existing Rust code. :)<p>Many of these sorts of things are hell to retrofit on to existing code, but if you integrate them into your workflow early, just shy of free over time to use all along. It's "just shy of free" because the tools themselves train you over time so that you get to the point where you start with conforming code, and the tools are just cleaning up occasional slips rather than requiring you to rewrite everything. So, you actually still net out less effort than trying to retrofit later by making fewer mistakes overall in the first place.<p>I really can't recommend this enough when you're greenfielding something. It's so cheap to start out doing the right thing and so very, very hard to fix it later....<p>(Obviously, you need to tweak a few things during prototype/exploration, like requirements for docs, but a lot of this stuff is still useful right away.)
A lot of the stuff that interests me is how much this focuses on making things automatic. Use compiler plugins to automatically check your code, use rustfmt to automatically reformat your code, use highfive to automatically greet new contributors, use homu to automatically ensure good CI, use Travis to automatically upload docs, etc.<p>I like things that are automatic. That way, I don't forget about them.
What Rust and Go still misses is still the good IDE. On the C/C++ side you could even use Eclipse and IntelliJ or Visual Studio.
And still if you don't like an IDE you could use an editor, however on rust / golang you are forced to the editor, which could be aweful if the project is grown / big, at least for me.
Good practices are helping, however the best editorconfig could help you if your codepage grown too big and you don't remeber the function of a specific struct/class/whatever.
It would be nice if the Rust documentation had a centralized list of std and core traits. For example, I see a summary of the std crate's exported types, modules, and macros but no traits. Such a list would be useful for library developers who want to maximize their library's potential for reuse by implementing all relevant core and std traits.<p><a href="https://doc.rust-lang.org/nightly/std/index.html" rel="nofollow">https://doc.rust-lang.org/nightly/std/index.html</a>
What about good practice for the actual writing of Rust library code? I know C++ and there we have advice such as not reordering virtual methods, not using STL types in public APIs, not reusing enum values, exception safety, RAII, etc. What about in Rust? What are some guidelines for writing libraries which will give their users maximum convenience and safety? Is there a stable ABI, and if so what do library implementers need to know about it? How about writing C APIs in Rust?