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

141–150 of 405 posts

Re: Flattening Rust’s learning curve

#141

Post by melodyogonna »

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 come to Rust with.

Secondary, Mojo's lifetime does not tell the compiler when a value is safe to use but when it is safe to delete, in this way the lifetime is not scope based, references will extend the lifetime of the value they reference, but values will be destroyed immediately after their last use. In Mojo you'll never see "value does not live long enough".

Just these two design decisions defines away so many ergonomic issues.

Re: Flattening Rust’s learning curve

#142

Post by ithkuil »

Renaud wrote: post #121
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…

I find it strange that you relate borrowing and ownership to financial asset management. From that angle, it indeed doesn’t seem to make sense. I think, but might be completely wrong, that viewing these actions from their usual meaning is more helpful: you own a toy, it’s yours to do as tou please. You borrow a toy, it’s not yours, you can’t do whatever you want with it, so you can’t hold on to it if the owner doesn’…

Analogies often leak.

1. In real life I can borrow a toy from you and while I have that toy in my hands, the owner can exchange ownership with somebody else, while the object is borrowed by me. I.e. in real life the borrowing is orthogonal to ownership. In rust you can't do that.

2. Borrowing a toy is more akin to how mutable references work in rust. Immutable references allow multiple people to play with the same toy simultaneously, provided they don't change it.

Analogies are just analogies

Re: Flattening Rust’s learning curve

#143

Post by winrid »

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

The question is worded weird for fun. One is a string slice (like char*) and one is String or &String, which is closer to an object.

Re: Flattening Rust’s learning curve

#145

Post by yodsanklai »

namuol wrote: post #101
yodsanklai wrote: post #94

Earlier quoted context omitted.

> It's a very complex I find it relatively simple. Much simpler than C++ (obviously). For someone who can write C++ and has some experience wth OCaml/Haskell/F#, it's not a hard language.

Sure, C++ has a more complex spec, nobody can argue against that. Complex is the wrong word. Baffling is a better word. Or counterintuitive, or cumbersome. If “easy enough for someone with experience in C++, OCaml, Haskell, and F#” were the same thing as “not hard” then I don’t think this debate would come up so frequently.

Of course, this is very subjective. For someone who only knows python or javascript at a superficial level, Rust may seem out of reach. But if you're ok with the most common programming paradigms, I don't find Rust baffling.

I mean, you can't expect to learn a new language in a few days, it'll always take a bit of work. My feeling is that people complaining of the language being hard aren't putting the effort.

My experience is that Rust is a relatively small language which doesn't introduce a lot of new concepts. The syntax is quite intuitive, and the compiler super helpful. The borrower checker was the only new thing for me. I'm not an expert at all, but my experience is that after spending 2 weeks full-time reading books and experimenting, I was able to work professionally with the language without feeling too much friction.

On the other hand, after spending much more time on C++, I don't feel really comfortable with the language.

Re: Flattening Rust’s learning curve

#146

Post by throwaway81523 »

codeflo wrote: post #138
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…

That's not explaining ownership, that motivating it. Which is fine. The thing that's hard to explain and learn is how to read function signatures involving (...) -> &'a [&'b str] or whatever. And how to understand and fix the compiler errors in code calling such a function.

Is it a lot different from std::unique_ptr in C++?

I thought the Rust Book was too verbose but I liked Comprehensive Rust: https://google.github.io/comprehensive-rust/

I felt like I understood the stuff in the book based on cursory reading, but I haven't tried to actually use it.

Re: Flattening Rust’s learning curve

#147

Post by School-Cotton »

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

I’m not sure why it’s counterintuitive that &str and String are different things. Do you also find it counterintuitive in C++ that std::string is different from const char* ? What about &[u8] and Vec ?

Re: Flattening Rust’s learning curve

#148

Post by akewovtsn »

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

Python community famously learned the hard way that sometimes the programmer needs to know that there are multiple kinds of string.

Personally, I’ve been using to_owned instead. Some of the people looking at my code don’t write rust, and I figure it makes things a bit easier to understand.

Re: Flattening Rust’s learning curve

#149

Post by School-Cotton »

MasterYoda wrote: post #135

What is it that make that rust is said to have steep learning curve compared to other programing languages (in the same category)?

It doesn’t. The only language I know of in the same category as Rust is C++, which is much harder to learn and use.

Re: Flattening Rust’s learning curve

#150

Post by BlackFly »

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…

That really doesn't explain the model because you have completely left out the distinction between exclusive/shared (or mutable/immutable) borrows. Rust made a large number of choices with respect to how it permits such borrows and those do not follow from this brief outline nor from intuition or common sense. For example, the no aliasing rule is motivated not by intuition or common sense but from a desire to optimize functions.

The most complicated aspect of the borrows comes about from the elision rules which will silently do the wrong thing and will work fantastically until they don't at which point the compiler error is pointing at a function complaining about a lifetime parameter of a parameter with the trait method implying that the parameter has to live too long but the real problem was a lifetime in the underlying struct or a previous broken lifetime bound. Those elision rules are again not-intuitive and don't fall out of your explanation axiomatically. They were decisions that were made to attempt to simplify the life of programmers.

Post reply on HN