
Ask HN: Rust topics you wish someone had explained when first getting started? - Toidiu
So I am preparing to give a getting-started talk on Rust.<p>I was wondering what are some topics that people would have liked an explanation for when they first started learning Rust?
======
_jordan
I wish someone would have explained how to approach learning Rust; It's a
really hard language to grasp - when struggling, I think it's important to
really understand _why_ whatever you're doing is hard - to learn where your
misunderstanding and errors are fundamentally. This is non technical but might
be worth mentioning.

~~~
whytaka
As a beginner who'd struggled with learning Rust over the last few months,
here's my advice:

Ownership and Borrowing is front and centre in the intro texts to Rust and
it's no coincidence. Understanding the concept(s), their relation to memory,
references, memory management and lifetimes, is central to understanding Rust.

The String type, str (string slices), and slices in general, also gave my head
a spin a few times, but getting over that hurdle made things a lot more clear
as well.

Not that I have enough experience to tell the difference between languages, I
still think Rust is a very intelligently designed language. I'm glad I learned
(am learning) it and I hope it gets adopted by more developers.

------
dumindunuwan
This is my approach,[https://medium.com/learning-
rust](https://medium.com/learning-rust)

The ORDER of we are learning Rust

It's less useful to explain about language capabilities by examples or explain
about lifetimes before structs, enums

▸ Installation & Hello World ▸ Cargo & Crates ▸ Variable bindings , Constants
& Statics ▸ Comments ▸ Functions ▸ Primitive Data Types ▸ Operators ▸ Control
Flows

▸ Vectors ▸ Structs ▸ Enums ▸ Generics ▸ Impls & Traits

▸ Ownership▸ Borrowing▸ Lifetimes & Lifetime Elision

▸ Modules ▸ Crates ▸ Workspaces ▸ Error Handling

▸ Functional programming in Rust

~~~
Toidiu
Ahh thanks for the articles! I was wondering how you chose the order in which
to introduce the topics and which you found the most difficult to explain.
Also in your opinion do you think it would have been valid to start with
ownership since that is the key differentiation in the language?

------
neuronsguy
Some things to avoid early on so you can get a working app out quickly:

1\. Don't build OO abstractions, just use structs as data and operate on it
with free functions.

2\. Don't be afraid of long argument lists with lots of references, where the
last one is possibly mutable, C-style

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.

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.

5\. Don't worry too much about error handling, just use expect and explicit
panics

6\. Don't implement your own data structures, compose the std lib ones

7\. Get good at using match and enums to represent state and transitions

Once you've got some more experience and you want to try to write more elegant
code, you will run into ownership issues.

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

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.

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.

Finally you will run into frustration structuring large projects.

1\. Use cargo workspaces. Isolate self contained chunks of functionality into
crates.

2\. Implement stdlib traits like Iterator, From, Into

3\. You can use associated types to do statically checked dependency
injection. In combination with default trait implementations it's a decent
way.

4\. Use free functions liberally inside modules, but export mostly traits,
data structs, and operation structs.

5\. Use rustdoc comments in your code and refer to them.

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.

(Crosspost of a comment I made on Reddit:
[https://www.reddit.com/r/rust/comments/6rxw21/comment/dlb048...](https://www.reddit.com/r/rust/comments/6rxw21/comment/dlb048x))

~~~
Toidiu
_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._

I think this is key and still something I am trying to fully embrace

