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

241–250 of 405 posts

Re: Flattening Rust’s learning curve

#241

Post by echelon »

xiphias2 wrote: post #128
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…

I think the most important lesson is this: Ownership is easy, borrowing is easy, what makes the language super hard to learn is that functions must have signatures and uses that together prove that references don't outlive the object. Also: it's better not store referenced object in a type unless it's really really needed as it makes the proof much much more complex.

> Ownership is easy, borrowing is easy

100%. It's the programmer that needs to adapt to this style. It's not hard by any means at all, it just takes some adjustment.

Re: Flattening Rust’s learning curve

#242

Post by dsego »

melodyogonna wrote: post #141
mdwhatcott wrote: post #42

[flagged]

Rust design decisions are pretty hard to understand sometimes, Mojo is another language with a borrow-checker but it is not nearly as hard to learn as Rust due to making a few decisions. First is value semantics, in Rust people are told to always clone when learning, why isn't this semantics built into the language? It is what you have in most static languages - C, C++, Go, etc. This is the mental model many people c…

> but values will be destroyed immediately after their last use

Is this reference counting?

Re: Flattening Rust’s learning curve

#243

Post by psychoslave »

imtringued wrote: post #197
psychoslave wrote: post #116

Earlier quoted context omitted.

This explanation doesn't expose anything meaningful to my mind, as it doesn't define ownership and borrowing, both words being apparently rooted in an analogy with financial asset management. I'm not acquainted with Rust, so I don't really know, but I wonder if the wording plays a role in the difficulty of concept acquisition here. Analogies are often double edged tools. Maybe sticking to a more straight memory relat…

You think borrowing a lawn mower or owning a power drill is financial asset management?

On the most abstract level, even "I" and "think" are misleading notions of what’s passing through current attention. So "borrowing" and "owning" are not really great starting point notions to "think" in that sense. But on the more mundane level of mentally handling stuffs, that’s an analogy that can have its own merits (and flaws, of course).

Re: Flattening Rust’s learning curve

#244

Post by zigzag312 »

AStonesThrow wrote: post #233
ajross wrote: post #231

Earlier quoted context omitted.

Yeah, but the whole purpose here is "flattening the learning curve", and telling people code will work when it won't is doing the opposite. That bullet, at its most charitable, defines the "idealized goal" of the borrow collector. The actual device is much less capable (as it must be, as the goal is formally undecidable!), and "learning rust" requires understanding how.

Ironically, most people understand "learning curves" counterintuitively. If a "learning curve" is a simple X-Y graph with "time" and "knowledge" being on each axis respectively, then what sort of learning curve is preferable: a flatter one or a steep one? Clearly, if you graph large increases of knowledge over shorter periods of time, a steeper learning curve is more preferable. "Flattening the learning curve" makes…

Replace "knowledge" with "required knowledge". It's not about how efficiently you can learn, but how much do you need to learn in a specific amount of time. If you need to learn a lot in short amount of time (which is a hard thing to do) the curve is steep. You can flatten the curve by increasing the time you have available or by requiring less knowledge.

Re: Flattening Rust’s learning curve

#246

Post by zigzag312 »

ajross wrote: post #231
zigzag312 wrote: post #224

Earlier quoted context omitted.

A great teaching technique I learned from a very good match teacher is that when explaining core concepts, the simplified definitions don't need to be completely right. They are much simpler to grasp and adding exceptions to these is also quite easy compared to trying to understand correct, but complex, definitions at the beginning.

Yeah, but the whole purpose here is "flattening the learning curve", and telling people code will work when it won't is doing the opposite. That bullet, at its most charitable, defines the "idealized goal" of the borrow collector. The actual device is much less capable (as it must be, as the goal is formally undecidable!), and "learning rust" requires understanding how.

> ... defines the "idealized goal" of the borrow collector. The actual device is much less capable

I think here you expanded on the original point in a good way. I would then continue with adding additional set of points covering the issue in greater detail and a set of examples of where this commonly happens and how to solve it.

Re: Flattening Rust’s learning curve

#247

Post by throwawaymaths »

swiftcoder wrote: post #190
throwawaymaths wrote: post #129

Earlier quoted context omitted.

the tradeoff is that ~you have to guess where rust is doing the frees, and you might be wrong . in the end this would be strictly equivalent to an explicit instruction to free, with the compiler refusing to compile if the free location broke the rules. It's really too bad rust went the RAII route.

There's no guessing - Rust has well defined drop order. It also has manual drop, should you wish to override the defined order.

sorry i shouldn't have said guess. i meant consider

Re: Flattening Rust’s learning curve

#248

Post by throwawaymaths »

whyever wrote: post #171
throwawaymaths wrote: post #129

Earlier quoted context omitted.

the tradeoff is that ~you have to guess where rust is doing the frees, and you might be wrong . in the end this would be strictly equivalent to an explicit instruction to free, with the compiler refusing to compile if the free location broke the rules. It's really too bad rust went the RAII route.

How often do you care about the order in which objects are dropped?

anything where you need to have stuff run in constant time.

Re: Flattening Rust’s learning curve

#249

Post by echelon »

Const-me wrote: post #78
Salgat wrote: post #32

Earlier quoted context omitted.

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.

> I've been using it in C# One reason why async-await is trivial in .NET is garbage collector. C# rewrites async functions into a state machine, typically heap allocated. Garbage collector automagically manages lifetimes of method arguments and local variables. When awaiting async functions from other async functions, the runtime does that for multiple async frames at once but it’s fine with that, just a normal objec…

None of this is scary.

> The concurrency runtime is implemented by “Tokio” external library.

Scare quotes around Tokio?

You can't use Rails without Rails or Django without Django.

The reason Rust keeps this externally is because they didn't want to bake premature decisions into the language. Like PHP's eternally backwards string library functions or Python's bloated "batteries included" standard library chock full of four different XML libraries and other cruft.

> instead, it has a borrow checker who insists on exactly one owner of every object at all times, makes all memory allocations explicit, and exposed all these details to programmer in the type system

Table stakes. Everyone knows this. It isn't hard or scary, it just takes a little bit of getting used to. Like a student learning programming for the first time. It's not even that hard. Anyone can learn it.

It's funny people complain about something so easy. After you learn to ride the bike, you don't complain about learning to ride the bike anymore.

> Rust is very different.

Oh no!

Seriously this is 2025. I can write async Rust without breaking a sweat. This is all being written by people who don't touch the language.

Rust is not hard. Stop this ridiculous meme. It's quite an easy language once you sit down and learn it.

Re: Flattening Rust’s learning curve

#250

Post by echelon »

Measter wrote: post #235
echelon wrote: post #33

Earlier quoted context omitted.

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

My biggest issue with the whole "function colour" thing is that many functions have different colours. Like, these two: fn foo() -> String fn bar() -> Result I can't just treat `bar` the same as `foo` because it doesn't give me a String, it might have failed to give me a String. So I need to give it special handling to get a String. async fn qux() -> String This also doesn't give me a String. It gives me a thing that…

Excellent retort!
Post reply on HN