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

61–70 of 405 posts

Re: Flattening Rust’s learning curve

#61

Post by School-Cotton »

Salgat wrote: post #32
bigstrat2003 wrote: post #19

Earlier quoted context omitted.

"Just write everything async" is not remotely a good solution to the problem. Not everything needs to be async (in fact most things don't), and it's much harder to reason about async code. The issue is very much not overblown.

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.

> Why is async code harder to reason about?

I don't know about C#, but at least in Rust, one reason is that normal (non-async) functions have the property that they will run until they return, they panic, or the program terminates. I.e. once you enter a function it will run to completion unless it runs "forever" or something unusual happens. This is not the case with async functions -- the code calling the async function can just drop the future it corresponds to, causing it to disappear into the ether and never be polled again.

Re: Flattening Rust’s learning curve

#62

Post by School-Cotton »

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.

In practice, it really doesn't. The difficulty of implementing doubly linked lists has not stopped people from productively writing millions of lines of Rust in the real world. Most programmers spend less than 0.1% of their time reimplementing linked data structures; rust is pretty useful for the other 99.9%.

Re: Flattening Rust’s learning curve

#63

Post by landr0id »

sesm wrote: post #59
abirch wrote: post #43

Earlier quoted context omitted.

I think the major decisions behind Rust is being explicit and making the programmer make decisions. No NULLs, no Implicit conversions, no dangling pointers. Lifetimes, Optional, Results, each Match branch needs to exist, etc. Side note: Stack allocation is faster to execute as there's a higher probability of it being cached. Here is a free book for a C++ to Rust explanation. https://vnduongthanhtung.gitbooks.io/migra…

> being explicit and making the programmer make decisions Why RAII then? > C++ to Rust explanation I've seen this one. It is very newbie oriented, filled with trivial examples and doesn't even have Rust refs to C++ smart pointers comparison table.

>> being explicit and making the programmer make decisions

>Why RAII then?

Their quote is probably better rephrased as _being explicit and making the programmer make decisions when the compiler's decision might impact safety_

Implicit conversion between primitives may impact the safety of your application. Implicit memory management and initialization is something the compiler can do safely and is central to Rust's safety story.

Re: Flattening Rust’s learning curve

#66

Post by lmm »

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?

Because you care about productivity and safety more than l33t h4x0r hazing rituals?

Re: Flattening Rust’s learning curve

#67

Post by ajross »

> Use String and clone() and unwrap generously; you can always refactor later

At that point you might as well be writing Java or Go or whatever though. GC runtimes tend actually to be significantly faster for this kind of code, since they can avoid all those copies by sharing the underlying resource. By the same logic, you can always refactor the performance-critical stuff via your FFI of choice.

Re: Flattening Rust’s learning curve

#68

Post by worik »

LAC-Tech wrote: post #56
mdwhatcott wrote: post #42

[flagged]

I have taken the time to learn rust and you're absolutely right. It's a very complex, design-by-committee language. It has brilliant tooling, and is still much less complex than it's design-by-committee competitor C++, but it will never be easy to learn.

There is a trade off. Rust gave us fast, and safe. It did not give us "easy to learn".

I think it is a very good example of why "design by committee" is good. The "Rust Committee" has done a fantastic job

Thank you

They say a camel is a horse designed by a committee (https://en.wiktionary.org/wiki/a_camel_is_a_horse_designed_b...)

Yes:

* Goes twice as far as a horse

* On half the food and a quarter the water of a horse

* Carries twice as much as a horse

Yes, I like design by committee. I have been on some very good, and some very bad committees, but there is nothing like the power of a good committee

Thank you Rust!

Re: Flattening Rust’s learning curve

#69

Post by ajross »

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…

The second bullet in the second section is overpromising badly. In fact there are many, many, many ways to write verifiably correct code that leaves no dangling pointers yet won't compile with rustc.

Frankly most of the complexity you're complaining about stems from attempts to specify exactly what magic the borrow checker can prove correct and which incantations it can't.

Re: Flattening Rust’s learning curve

#70

Post by landr0id »

ajross wrote: post #67

> Use String and clone() and unwrap generously; you can always refactor later At that point you might as well be writing Java or Go or whatever though. GC runtimes tend actually to be significantly faster for this kind of code, since they can avoid all those copies by sharing the underlying resource. By the same logic, you can always refactor the performance-critical stuff via your FFI of choice.

So long as you're aware that you're not optimizing, it's fine. Trying to build something useful as a new Rust dev while worrying about lifetimes is going to be quite challenging, unless your intention is to specifically learn about lifetimes and the borrow checker.

Yes the borrow checker is central to Rust, but there are other features to the language that people _also_ need to learn and explore to be productive. Some of these features may attract them to Rust (like pattern matching / traits / etc.)

Post reply on HN