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

181–190 of 405 posts

Re: Flattening Rust’s learning curve

#181

Post by pjmlp »

pornel wrote: post #8
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?

So that you learn that loaning is for giving temporary shared^exclusive access within a statically-known scope, and not for storing data. Trying to construct permanent data structures using non-owning references is a very common novice mistake in Rust. It's similar to how users coming from GC languages may expect pointers to local variables to stay valid forever, even after leaving the scope/function. Just like in C…

Note that some users of GC languages that support stack allocation, are used that it is a compiler error trying to have such a pointer/reference.

D example, https://godbolt.org/z/bbfbeb19a

> Error: returning `& my_value` escapes a reference to local variable `my_value`

C# example, https://godbolt.org/z/Y8MfYMMrT

> error CS8168: Cannot return local 'num' by reference because it is not a ref local

Re: Flattening Rust’s learning curve

#182

Post by scotty79 »

sesm wrote: post #37

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.

In-place mutability and stack allocation are for speed. This made them have variables and values inside them both as separate first-class citizens. The entire borrow checker is just for tracking variables access so that you don't need to clone values. I'd say that given this one guiding decision there are very little arbitrary ones in Rust. The rest of it pretty much had to be made exactly the way it is. Rust is more of a discovery than a construct.

C++ is just Rust without any attempt at tracking variable access and cloning which leads to a mess because people are too terrible at that to do that manually and ad-hoc. So Rust fixes that.

Re: Flattening Rust’s learning curve

#183

Post by make3 »

cyber1 wrote: post #180

"Safe" Rust is generally a simple language compared to C++. The borrow checker rules are clean and consistent. However, writing in it isn't as simple or intuitive as what we've seen in decades of popular systems languages. If your data structures have clear dependencies—like an acyclic graph then there's no problem. But writing performant self-referential data structures, for example, is far from easy compared to C++…

"raw pointers are one of the most important concepts in CS" that's a reach and a half, I don't remember the last time I've used one

Re: Flattening Rust’s learning curve

#184

Post by explodes »

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…

I had quite a similar experience. During the 3rd attempt at learning, everything seemed to click and I was able to be effective at writing a few programs.

This is all despite a long career as a programmer. Seems like some things just take repetition.

The "Dagger" dependency injection framework for the JVM took me 3 'learning attempts' to understand as well. May say more about myself than about learning something somewhat complicated.

Re: Flattening Rust’s learning curve

#185

Post by darthrupert »

baalimago wrote: post #120

>For instance, why do you have to call to_string() on a thing that’s already a string? It's so hard for me to take Rust seriously when I have to find out answers to unintuitive question like this

On the other side where this question is not asked we have things like

    > "1" + 2 
    3
And it's utter madness that everyone does anything important with languages like that.

Re: Flattening Rust’s learning curve

#186

Post by frankie_t »

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…

Maybe it's my learning limitations, but I find it hard to follow explanations like these. I had similar feelings about encapsulation explanations: it would say I can hide information without going into much detail. Why, from whom? How is it hiding if I can _see it on my screen_.

Similarly here, I can't understand for example _who_ is the owner. Is it a stack frame? Why would a stack frame want to move ownership to its callee, when by the nature of LIFO the callee stack will always be destroyed first, so there is no danger in hanging to it until callee returns. Is it for optimization, so that we can get rid of the object sooner? Could owner be something else than a stack frame? Why can mutable reference be only handed out once? If I'm only using a single thread, one function is guaranteed to finish before the other starts, so what is the harm in handing mutable references to both? Just slap my hands when I'm actually using multiple threads.

Of course, there are reasons for all of these things and they probably are not even that hard to understand. Somehow, every time I want to get into Rust I start chasing these things and give up a bit later.

Re: Flattening Rust’s learning curve

#187

Post by scotty79 »

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?

It's not that it doesn't understand doubly linked list. It's just that you don't understand their consequences and have no objections against turning your program state briefly into inconsistent bullshit to facilitate them. The compiler minds. Unless you use Rc. That's what this language has for expressing inconsistency. Or unsafe {} if you are cocky. Borrows are not named pointers for a reason.

Re: Flattening Rust’s learning curve

#188

Post by ShroudedNight »

mikepurvis wrote: post #88
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.

"Rust basically just calls 'free' for you the moment something goes out of scope." C++ does that too with RAII. Go ahead and use whatever STL containers you like, emplace objects onto them, and everything will be safely single-owned with you never having to manually new or delete any of it. The difference is that C++'s guarantees in this regard derive from a) a bunch of implementation magic that exists to hide the fa…

> a bunch of implementation magic that exists to hide the fact that those supposedly stack-allocated containers are in fact allocating heap objects behind your back

The heap is but one source for allocator-backed memory. I've used pieces of stack for this, too. One could also use an entirely staticly sized and allocated array.

Re: Flattening Rust’s learning curve

#189

Post by Ragnarork »

whyever wrote: post #173
etbebl wrote: post #132

Earlier quoted context omitted.

Maybe people need persuading to learn Rust not just because they think it's hard, but also because they think it's bad? Not everything hard is worth doing. Difficulty is just one of the factors to consider. I started to learn Rust, but I was put off by the heavy restrictions the language imposes and the attitude that this is the only safe way. There's a lack of acknowledgement, at least in beginner materials, that by…

> by choosing to write safe Rust you're sacrificing many perfectly good patterns that the compiler can't understand in exchange for safety Historically, programmers drastically overestimate their ability to write perfectly safe code, so it's an enormous benefit if the compiler is able to understand whether it's actually safe.

The first part of your statement feels true, although that's... unverified and lacks actual backing up.

The second part of your statement is very debatable based on what safe means in this case, and whether it's an enormous benefit for a given situation.

There's plenty of stories [0][1] about Rust getting in the way and being very innappropriate for certain tasks and goals, and those "enormous benefits" can become "enormous roadblocks" in different perspectives and use cases.

In my personal and very subjective opinion I think Rust can be very good when applied to security applications, realtime with critical safety requirements (in some embedded scenarios for example), that sort of stuff. I think it really gets in the way too much in other scenarios with demanding rules and pattern that prevent from experimenting easily and exploring solutions quickly.

[0]https://barretts.club/posts/rust-for-the-engine/ [1]https://loglog.games/blog/leaving-rust-gamedev/

Re: Flattening Rust’s learning curve

#190

Post by swiftcoder »

throwawaymaths wrote: post #129
mikepurvis wrote: post #88

Earlier quoted context omitted.

"Rust basically just calls 'free' for you the moment something goes out of scope." C++ does that too with RAII. Go ahead and use whatever STL containers you like, emplace objects onto them, and everything will be safely single-owned with you never having to manually new or delete any of it. The difference is that C++'s guarantees in this regard derive from a) a bunch of implementation magic that exists to hide the fa…

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.
Post reply on HN