Ask HN: Rust topics you wish someone had explained when first getting started?
9 comments
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.
I agree with this point. I do believe Rust contains some difficult concepts but there is a reason behind them. Understanding those reason is the key motivator behind learning the language.
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.
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.
This is my approach,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
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
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?
[deleted]
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...)
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...)
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
I think this is key and still something I am trying to fully embrace
I was wondering what are some topics that people would have liked an explanation for when they first started learning Rust?