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

111–120 of 405 posts

Re: Flattening Rust’s learning curve

#111

Post by j16sdiz »

NobodyNada wrote: post #105
mplanchard wrote: post #46

Earlier quoted context omitted.

You’re passing in two references and returning a reference. The compiler knows the returned reference must be tied to one of the incoming references (since you cannot return a reference to something created within the function, and all inputs are references, the output must therefore be referencing the input). But the compiler can’t know which reference the result comes from unless you tell it. Theoretically it could…

> Theoretically it could tell by introspecting the function body, but the compiler only works on signatures Note that this is an intentional choice rather than a limitation, because if the compiler analyzed the function body to determine lifetimes of parameters and return values, then changing the body of a function could be a non-obvious breaking API change. If lifetimes are only dependent on the signature, then its…

> changing the body of a function could be a non-obvious breaking API change

This. Many trival changes breaks API. This is not ideal for library developers.

You can argue it is broken already, but this is forcing the breakage onto every api caller, not just some broken caller.

Re: Flattening Rust’s learning curve

#112

Post by saretup »

ergonaught wrote: post #55
tacitusarc wrote: post #52

Earlier quoted context omitted.

This is incorrect. A learning curve measures expertise on the x axis and effort on the y axis. Hence the saying "steep learning curve".

https://en.wikipedia.org/wiki/Learning_curve

That’s interesting. I always intuitively assumed x-axis was progress and y-axis was cumulative effort.

Re: Flattening Rust’s learning curve

#113

Post by winrid »

Const-me wrote: post #85
jandrewrogers wrote: post #58

Earlier quoted context omitted.

Rust has better defaults for types than C++, largely because the C++ defaults came from C. Rust is more ergonomic in this regard. If you designed C++ today, it would likely adopt many of these defaults. However, for high-performance systems software specifically, objects often have intrinsically ambiguous ownership and lifetimes that are only resolvable at runtime. Rust has a pretty rigid view of such things. In thes…

Interestingly, CPU-bound high-performance systems are also incompatible with Rust’s model. Ownership for them is unambiguous, but Rust has another issue, doesn’t support multiple writeable references of the same memory accessed by multiple CPU cores in parallel. A trivial example is multiplication of large square matrices. An implementation needs to leverage all available CPU cores, and a traditional way to do that y…

Hard in safe rust. you can just use unsafe in that one area and still benefit in most of your application from safe rust.

Re: Flattening Rust’s learning curve

#114

Post by [deleted] »

worik wrote: post #71
mre wrote: post #6

Earlier quoted context omitted.

For people who don't get the reference, this might be referring to the notoriously gnarly task of implementing a doubly-linked lists in Rust [1] It is doable, just not as easy as in other languages because a production-grade linked-list is unsafe because Rust's ownership model fundamentally conflicts with the doubly-linked structure. Each node in a doubly-linked list needs to point to both its next and previous nodes…

I am working on a code base, that among its many glories and poo balls every list is a doubly linked list. Stop! If you are using a doubly linked list you (probably) do not have to, or want to. There is almost no case where you need to traverse a list in both directions (do you want a tree?) A doubly linked list wastes memory with the back links that you do not need. A singly linked list is trivial to reason about: T…

[deleted]

Re: Flattening Rust’s learning curve

#115

Post by andrewflnr »

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.

Practically, I think it suggests that learning the borrow checker should start with learning how memory works, rather than any concepts specific to Rust.

Re: Flattening Rust’s learning curve

#116

Post by psychoslave »

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…

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 related vocabulary as an alternative presentation perspective might help?

Re: Flattening Rust’s learning curve

#118

Post by devjab »

mdwhatcott wrote: post #42

[flagged]

I think you can have a lot of debate on the design decisions on Rust, but I don't think the need for these articles tell you a lot about the language itself. I'd argue that Python needs articles like this more so than Rust does, but for entirely different reasons. In two decades of more and more programmers who aren't coming from an engineering background, I've yet to see anyone who used a Python generator or slots. Data Classes are less rare, but mainly in the form of pydantics "version". Which doesn't exactly matter for a lot of Python code... This is a world where 4chan can serve 4 million concurrent users an apache server running a 10k line PHP file neither of which have been updated since 2015... so you can be fine doing inefficient and entirely in-memory Python code 95% (or more) of the time.

That doesn't mean you should though. Imagine how much energy is being wasted globally on bad Python code... The difference is of course that anyone can write it, and not everyone can write Rust. I'm not personally a big fan of Rust, I'd chose Zig any day of the week... but then I'd also choose C over C++, and I frankly do when I optimise Python code that falls in those last 5%. From that perspective... of someone who really has to understand how Python works under the hood and when to do what, I'd argue that Rust is a much easier langauge to learn with a lot less "design smell". I suppose Python isn't the greatest example as even those of us who love it know that it's a horrible language. But I think it has quite clearly become the language of "everyone" and even more so in the age of LLM. Since our AI friends will not write optimised Python unless you specifically tell them to use things like generators and where to use them, and since you (not you personally) won't because you've never heard about a generator before, then our AI overlords won't actually help.

Re: Flattening Rust’s learning curve

#119

Post by bigstrat2003 »

Animats wrote: post #21
mre wrote: post #6

Earlier quoted context omitted.

For people who don't get the reference, this might be referring to the notoriously gnarly task of implementing a doubly-linked lists in Rust [1] It is doable, just not as easy as in other languages because a production-grade linked-list is unsafe because Rust's ownership model fundamentally conflicts with the doubly-linked structure. Each node in a doubly-linked list needs to point to both its next and previous nodes…

Rust still needs a way out of that mess. It's conceptually possible to have compile time checking for this. Think of RefCell/Weak and .upgrade() and .borrow() being checked at compile time. I've discussed this with some of the Rust devs. The trouble is traits. You'd need to know if a trait function could borrow one of its parameters, or something referenced by one of its parameters. This requires analysis that can't…

> Rust still needs a way out of that mess.

It has one: use raw pointers and unsafe. People are way too afraid of unsafe, it's there specifically to be used when needed.

Post reply on HN