Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Flattening Rust’s learning curve

corrode.dev

Post reply on HN
Print view View original

21–30 of 405 posts

Re: Flattening Rust’s learning curve

#21

Post by Animats »

mre wrote: post #6
dmitrygr wrote: post #2

> Treat the borrow checker as a co-author, not an adversary Why would I pair-program with someone who doesn’t understand doubly-linked lists?

For people who don't get the reference, this might be referring to the notoriously gnarly task of implementing a doubly-linked lists in Rust [1] It is doable, just not as easy as in other languages because a production-grade linked-list is unsafe because Rust's ownership model fundamentally conflicts with the doubly-linked structure. Each node in a doubly-linked list needs to point to both its next and previous nodes…

Rust still needs a way out of that mess. It's conceptually possible to have compile time checking for this. Think of RefCell/Weak and .upgrade() and .borrow() being checked at compile time.

I've discussed this with some of the Rust devs. The trouble is traits. You'd need to know if a trait function could borrow one of its parameters, or something referenced by one of its parameters. This requires analysis that can't be done until after generics have been expanded. Or a lot more attributes on trait parameters. This is a lot of heavy machinery to solve a minor problem.

Re: Flattening Rust’s learning curve

#22

Post by Waterluvian »

Write a CHIP8 emulator!

Bonus: do it with no heap allocation. This actually makes it easier because you basically don’t deal with lifetimes. You just have a state object that you pass to your input system, then your guest cpu system, then your renderer, and repeat.

And I mean… look just how incredibly well a match expression works for opcode handling: https://github.com/ablakey/chip8/blob/15ce094a1d9de314862abb...

My second (and final) rust project was a gameboy emulator that basically worked the same way.

But one of the best things about learning by writing an emulator is that there’s enough repetition you begin looking for abstractions and learn about macros and such, all out of self discovery and necessity.

Re: Flattening Rust’s learning curve

#24

Post by Animats »

ameliaquining wrote: post #20
Animats wrote: post #18

It's like reading "A Discipline of Programming", by Dijkstra. That morality play approach was needed back then, because nobody knew how to think about this stuff. Most explanations of ownership in Rust are far too wordy. See [1]. The core concepts are mostly there, but hidden under all the examples. - Each data object in Rust has exactly one owner. - Ownership can be transferred in ways that preserve the one-owner ru…

Summarizing a set of concepts in a way that feels correct and complete to someone who understands them, is a much easier task than explaining them to someone who doesn't. If we put this in front of someone who's only worked with call-by-sharing languages, do you think they'll get it right away? I'm skeptical.

Right. If you come to Rust from C++ and can write good C++ code, you see this as "oh, that's how to think about ownership". Because you have to have a mental model of ownership to get C/C++ code to work.

But if you come from Javascript or Python or Go, where all this is automated, it's very strange.

Re: Flattening Rust’s learning curve

#25

Post by SoftTalker »

woah wrote: post #4

Does anyone still have trouble learning Rust? I thought that was kind of a 2015 thing

For me it was like Haskell. I spent an afternoon on it, my brain hurt too much, and I relegated it to the category of languages that are too complicated for what I need to do with a computer.

Languages I liked, I liked immediately. I didn’t need to climb a mountain first.

Re: Flattening Rust’s learning curve

#26

Post by cadamsdotcom »

Rust is wonderful but humbling!

It has a built in coach: the borrow checker!

Borrow checker wouldn't get off my damn case - errors after errors - so I gave in. I allowed it to teach me - compile error by compile error - the proper way to do a threadsafe shared-memory ringbuffer. I was convinced I knew. I didn't. C and C++ lack ownership semantics so their compilers can't coach you.

Everyone should learn Rust. You never know what you'll discover about yourself.

Re: Flattening Rust’s learning curve

#27

Post by lucasyvas »

echelon wrote: post #7
Havoc wrote: post #5

I thought it was quite manageable at beginner level…though I haven’t dived into async which I gather is a whole different level of pain

Async and the "function color" "problem" fall away if your entire app is in an async runtime. Almost 90% of the Rust I write these days is async. I avoid non-async / blocking libraries where possible. I think this whole issue is overblown.

It’s completely overblown. Almost every language with async has the same “problem”.

I’m not calling this the pinnacle of async design, but it’s extremely familiar and is pretty good now. I also prefer to write as much async as possible.

Re: Flattening Rust’s learning curve

#28

Post by alpinisme »

ants_everywhere wrote: post #16

A learning curve measures time on the x axis and progress on the y axis. A flat learning curve means you never learn anything :-\

You may be able to draw one that way but it completely neglects the way people use the term ordinarily “a steep learning curve” is not an easy to learn thing.

In point of fact, I think the intended chart of the idiom is effort (y axis) to reach a given degree of mastery (x axis)

Re: Flattening Rust’s learning curve

#29

Post by autoexec »

ants_everywhere wrote: post #16

A learning curve measures time on the x axis and progress on the y axis. A flat learning curve means you never learn anything :-\

What we want is an "effort/difficulty curve" that measures how difficult something typically is over time from introduction to proficiency

Re: Flattening Rust’s learning curve

#30

Post by noman-land »

cadamsdotcom wrote: post #26

Rust is wonderful but humbling! It has a built in coach: the borrow checker! Borrow checker wouldn't get off my damn case - errors after errors - so I gave in. I allowed it to teach me - compile error by compile error - the proper way to do a threadsafe shared-memory ringbuffer. I was convinced I knew. I didn't. C and C++ lack ownership semantics so their compilers can't coach you. Everyone should learn Rust. You nev…

Got recommended learning paths? I tend to prefer follow along adventures via video.
Post reply on HN