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

311–320 of 405 posts

Re: Flattening Rust’s learning curve

#311

Post by bloppe »

josephg wrote: post #50
bloppe wrote: post #35

Earlier quoted context omitted.

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.

Almost all of it. Rust also has the “single mutable reference” rule. If you have a mutable reference to a variable, you can be sure nobody else has one at the same time. (And the value itself won’t be mutated). Mechanically, every variable can be in one of 3 modes: 1. Directly editable (x = 5) 2. Have a single mutable reference (let y = &mut x) 3. Have an arbitrary number of immutable references (let y = &x; let z =…

Ya, I just think the `mut` thing isn't as much of a challenge to newcomers as the memory management aspect.

Re: Flattening Rust’s learning curve

#312

Post by zahlman »

ModernMech wrote: post #256
fastasucan wrote: post #166

Earlier quoted context omitted.

>Is it a lot different from std::unique_ptr in C++? Is knowing C++ a pre-requisite?

IME teaching students Rust, knowing C++ first actually is a detriment to learning because they have a bunch of C++ habits to unlearn. Those students "fight the borrow checker" much more than the blank slate students, because they have some idea about how code "should" be written.

Is this still true if they never learned pre-modern C++ and are accustomed to using all the std::foo_ptrs and expecting the rule of 3 (or 5) to be taken care of automatically that way?

Re: Flattening Rust’s learning curve

#313

Post by pessimizer »

atoav wrote: post #204
GenshoTikamura wrote: post #200

> Stop resisting. That’s the most important lesson > Accept that learning Rust requires... > Leave your hubris at home > Declare defeat > Resistance is futile. The longer you refuse to learn, the longer you will suffer > Forget what you think you knew... Now it finally clicked to me that Orwell's telescreen OS was written in Rust

But it is true. My own biggest mistake when learning Rust was that I tried to torce Object Oriented paradigms on it. That went.. poorly. As soon as I went "fuck it, I just do it like you want" things went smoothly.

Works that way with learning a spoken language, too. I couldn't learn my second language until I stopped thinking I was supposed to judge whether things in the language were "good" or not. Languages aren't meant to be "good" in a beauty contest sense, they're supposed to be useful. Accept that they are useful because many, many people use them, and just learn them.

I probably wouldn't have been able to do that with Rust if I hadn't been an Erlang person previously. Rust seems like Erlang minus the high-overhead Erlangy bits plus extreme type signatures and conscious memory-handling. Erlang where only "zero-cost abstractions" were provided by the language and the compiler always runs Dialyzer.

Re: Flattening Rust’s learning curve

#314

Post by maxbond »

Measter wrote: post #226
maxbond wrote: post #31

Earlier quoted context omitted.

Check out Jon Gjengset. https://www.youtube.com/@jonhoo

I wouldn't agree with that. Jon's content is great, but it's really not aimed at beginners, and some of his stuff really gets into the weeds.

Gjengset was very helpful to me as a beginner, and the "Crust of Rust" and "Decrusted" series are aimed at beginners, but mileage varies and there's room for more suggestions if anyone has them.

Re: Flattening Rust’s learning curve

#315

Post by prmph »

ants_everywhere wrote: post #36
alpinisme wrote: post #28

Earlier quoted context omitted.

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…

What “steep learning curve” is getting at is a situation where a lot of learning needs to occurs in a short time to make any meaningful progress.

It is not in opposition to a flat learning curve, but a gentle one

Re: Flattening Rust’s learning curve

#316

Post by Animats »

mplanchard wrote: post #230
Animats wrote: post #106

Earlier quoted context omitted.

Doubly linked lists are rare, but backlinks to the owner are often needed. It's the same problem, mostly.

Backlinks work fine with weak Arc references, don’t they?

Yes. But the Arc has to wrap a Mutex, which means you have to lock to get access. It's a dual of the Rc/RefCell/borrow mechanism.

The trouble with calling .lock() is that there is a potential for deadlock. There are some people working on static analysis for deadlock prevention, which is a dual of the static analysis for double borrow protection problem. We're maybe a PhD thesis or two from a solution. Here's some current research, out of Shanghai.[1] Outlines the theory, but code does not yet seem to be available.

[1] https://arxiv.org/pdf/2401.01114

Re: Flattening Rust’s learning curve

#317

Post by zahlman »

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.

> 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.

"Flattening the learning curve" is perhaps a wrong metaphor - you can't actually change what needs to be learned; you can only make it easier to learn.

Saying something that is usually right and can be corrected later is a standard pedagogical approach - see https://en.wikipedia.org/wiki/Wittgenstein%27s_ladder . To extend the metaphor, the ladder is there to help you climb the learning curve.

Re: Flattening Rust’s learning curve

#318

Post by zahlman »

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…

> But for some reason, people always reverse this meaning, and so the common idiom breaks down for people who try to reason it out.

Because one imagines the "curve" like physical topology, with the goal of reaching the top.

Re: Flattening Rust’s learning curve

#319

Post by SyrupThinker »

toprerules wrote: post #287

As a systems programmer I found Rust relatively easy to learn, and wonder if the problem is non-systems programmers trying to learn their first systems language and having it explicitly tell them "no, that's dangerous. no, that doesn't make sense". If you ask a front end developer to suddenly start writing C they are going to create memory leaks, create undefined behavior, create pointers to garbage, run off the end…

I think this is good insight, and I would extend this further to “coming from a less strict language to a very strict one”.

As someone who self-learned Rust around 1.0, after half a year of high school level Java 6, I’ve never had the problems people (even now) report with concepts like the ownership system. And that despite Rust 1.0 being far more restrictive than modern Rust, and learning with a supposedly harder to understand version of “The Book”.

I think it’s because I, and other early Rust learners I’ve talked to about this, had little preconceived notions of how a programming language should work. Thus the restrictions imposed by Rust were just as “arbitrary” as any other PL, and there was no perceived “better” way of accomplishing something.

Generally the more popular languages like JS or Python allow you to mold the patterns you want to use sufficiently, so that they fit into it. At least to me with languages like Rust or Haskell, if you try to do this with too different concepts, the code gets pretty ugly. This can give the impression the PL “does not do what you need” and “imposes restrictions”.

I also think that this goes the other way, and might just be a sort of developed taste.

Re: Flattening Rust’s learning curve

#320

Post by zahlman »

8s2ngy wrote: post #92

It took me a few tries to get comfortable with Rust—its ownership model, lifetimes, and pervasive use of enums and pattern matching were daunting at first. In my initial attempt, I felt overwhelmed very early on. The second time, I was too dogmatic, reading the book line by line from the very first chapter, and eventually lost patience. By then, however, I had come to understand that Rust would help me learn programm…

Out of curiousity, how many other programming languages were you familiar with before Rust?
Post reply on HN