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

31–40 of 405 posts

Re: Flattening Rust’s learning curve

#31

Post by maxbond »

noman-land wrote: post #30
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.

Check out Jon Gjengset.

https://www.youtube.com/@jonhoo

Re: Flattening Rust’s learning curve

#32

Post by Salgat »

bigstrat2003 wrote: post #19
echelon wrote: post #7

Earlier quoted context omitted.

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.

"Just write everything async" is not remotely a good solution to the problem. Not everything needs to be async (in fact most things don't), and it's much harder to reason about async code. The issue is very much not overblown.

Why is async code harder to reason about? I've been using it in C# and the entire point is that it lets you write callbacks in a way that appears nearly identical to synchronous code. If you dive into concurrency (which is a separate thing but can be utilized with async code, such as joining multiple futures at the same time), that parts hard whether you're doing it with async or with explicit threads.

Re: Flattening Rust’s learning curve

#33

Post by echelon »

lucasyvas wrote: post #27
echelon wrote: post #7

Earlier quoted context omitted.

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.

The "function color is a problem" people invented a construct that amplifies the seriousness. It's not really a big deal.

Re: Flattening Rust’s learning curve

#34

Post by gerdesj »

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…

"Rust is wonderful but humbling!"

It's an abstraction and convenience to avoid fiddling with registers and memory and that at the lowest level.

Everyone might enjoy their computation platform of their choice in their own way. No need to require one way nor another. You might feel all fired up about a particular high level language that you think abstracts and deploys in a way you think is right. Not everyone does.

You don't need a programming language to discover yourself. If you become fixated on a particular language or paradigm then there is a good chance you have lost sight of how to deal with what needs dealing with.

You are simply stroking your tools, instead of using them properly.

Re: Flattening Rust’s learning curve

#35

Post by bloppe »

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.

For me it really clicked when I realized ownership / lifetimes / references are just words used to talk about when things get dropped. Maybe because I have a background in C so I'm used to manual memory management. Rust basically just calls 'free' for you the moment something goes out of scope.

All the jargon definitely distracted me from grasping that simple core concept.

Re: Flattening Rust’s learning curve

#36

Post by ants_everywhere »

alpinisme wrote: post #28
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)

I don't think the idiom has in mind any particular curve. I think it's just another case of a misuse becoming idiomatic without any meaning beyond the phrase taken as a unit. E.g.

- another think coming -> another thing coming

- couldn't care less -> could care less

- the proof of the pudding is in the eating -> the proof is in the pudding

It's usually not useful to try to determine the meaning of the phrases on the right because they don't have any. What does it mean for proof to be in a pudding for example?

The idiom itself is fine, it's just a black box that compares learning something hard to climbing a mountain. But learning curves are real things that are still used daily so I just thought it was funny to talk as if a flat one was desirable.

Re: Flattening Rust’s learning curve

#37

Post by sesm »

Is there a concise document that explains major decisions behind Rust language design for those who know C++? Not a newbie tutorial, just straight to the point: why in-place mutability instead of other options, why encourage stack allocation, what problems with C++ does it solve and at what cost, etc.

Re: Flattening Rust’s learning curve

#39

Post by ants_everywhere »

LambdaComplex wrote: post #23
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 :-\

"Flattening the derivative of Rust's learning curve" really doesn't roll off the tongue though

Yeah that's true. But it would be on brand for a post that emphasizes the importance of accuracy and attention to detail.

Re: Flattening Rust’s learning curve

#40

Post by mplanchard »

spion wrote: post #11
echelon wrote: post #7

Earlier quoted context omitted.

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.

How are async closures / closure types, especially WRT future pinning?

Async closures landed in stable recently and have been a nice QoL improvement, although I had gotten used to working around their absence well enough previously that they haven’t been revolutionary yet from the like “enabling new architectural patterns” perspective or anything like that.

I very rarely have to care about future pinning, mostly just to call the pin macro when working with streams sometimes.

Post reply on HN