Some things to avoid early on so you can get a working app out quickly:<p>1. Don't build OO abstractions, just use structs as data and operate on it with free functions.<p>2. Don't be afraid of long argument lists with lots of references, where the last one is possibly mutable, C-style<p>3. If something needs e.g. 2 different structs as inputs and mutates a third one, make it a free function, don't impl it on any of the structs.<p>4. Don't overdo it trying to use the functional idioms for options and results like and_then or_else etc. Just use match and eventually it will be obvious where those fit.<p>5. Don't worry too much about error handling, just use expect and explicit panics<p>6. Don't implement your own data structures, compose the std lib ones<p>7. Get good at using match and enums to represent state and transitions<p>Once you've got some more experience and you want to try to write more elegant code, you will run into ownership issues.<p>1. Use guard types. Basically a struct that owns a pointer into some larger data. Write a lot of these with useful utilities for manipulating that data<p>2. Use guard types for mutating data as well. I tend to have a type which is a big bag of data (often carefully laid out in memory for performance), and then separate types whose only purpose is to contain references to e.g. 2 or 3 different pieces of data that need to be simultaneously used. That type allows you to do whatever that operation is. This saves a lot of borrow checker fighting.<p>3. Think in a data centric way. What data do you need? What operations need to be performed? Then design your ownership hierarchy such that that can happen.<p>Finally you will run into frustration structuring large projects.<p>1. Use cargo workspaces. Isolate self contained chunks of functionality into crates.<p>2. Implement stdlib traits like Iterator, From, Into<p>3. You can use associated types to do statically checked dependency injection. In combination with default trait implementations it's a decent way.<p>4. Use free functions liberally inside modules, but export mostly traits, data structs, and operation structs.<p>5. Use rustdoc comments in your code and refer to them.<p>A lot of the above is opinion and might not work for everyone. I submit that it's "a path" of many for getting productive quickly and then scaling up to writing larger systems.<p>(Crosspost of a comment I made on Reddit: <a href="https://www.reddit.com/r/rust/comments/6rxw21/comment/dlb048x" rel="nofollow">https://www.reddit.com/r/rust/comments/6rxw21/comment/dlb048...</a>)