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

71–80 of 405 posts

Re: Flattening Rust’s learning curve

#71

Post by worik »

mre wrote: post #6
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?

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: There is this node and the rest. A doubly linked list more than doubles that cognitive load.

Think! Spend time carefully reasoning about the data structures you are using. You will not need that complicated, wasteful, doubly linked list

Re: Flattening Rust’s learning curve

#73

Post by awesome_dude »

codr7 wrote: post #60
kupopuffs wrote: post #57

Earlier quoted context omitted.

Wow who pissed in your coffee? he likes rust ok?

And he's telling other people they should like it as well, because he has seen the light. My gut feeling says that there's a fair bit of Stockholm Syndrome involved in the attachments people form with Rust. You could see similar behavioral issues with C++ back in the days, but Rust takes it to another level.

> You could see similar behavioural issues with C++ back in the days

I think that it's happened to some degree for almost every computer programming language for a whiles now - first was the C guys enamoured with their NOT Pascal/Fortran/ASM, then came the C++ guys, then Java, Perl, PHP, Python, Ruby, Javascript/Node, Go, and now Rust.

The vibe coding people seem to be the ones that are usurping Rust's fan boi noise at the moment - every other blog is telling people how great the tool is, or how terrible it is.

Re: Flattening Rust’s learning curve

#74

Post by dmitrygr »

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…

> There is almost no case where you need to traverse a list in both directions

But you might need to remove a given element that you have a pointer to in O(1), which a singly linked list will not do

Re: Flattening Rust’s learning curve

#75

Post by rat87 »

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.

its not design by committee its design by Pull request It doesn't have a central https://en.wikipedia.org/wiki/Benevolent_dictator_for_life like python used to so people suggest and implement features as a group, with code counting for a lot (although theoretical issues with safety/design also matter) as opposed to companies arguing for their pet features endlessly without much difference. Look at how long it takes C++ to get any new features.

Re: Flattening Rust’s learning curve

#76

Post by Ar-Curunir »

jandrewrogers wrote: post #58
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.

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…

> However, for high-performance systems software specifically, objects often have intrinsically ambiguous ownership

What is the evidence for this? Plenty of high-performance systems software (browsers, kernels, web servers, you name it) has been written in Rust. Also Rust does support runtime borrow-checking with Rc>. It's just less ergonomic than references, but it works just fine.

Re: Flattening Rust’s learning curve

#78

Post by Const-me »

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.

> I've been using it in C#

One reason why async-await is trivial in .NET is garbage collector. C# rewrites async functions into a state machine, typically heap allocated. Garbage collector automagically manages lifetimes of method arguments and local variables. When awaiting async functions from other async functions, the runtime does that for multiple async frames at once but it’s fine with that, just a normal object graph. Another reason, the runtime support for all that stuff is integrated into the language, standard library, and most other parts of the ecosystem.

Rust is very different. Concurrency runtime is not part of the language, the standard library defined bare minimum, essentially just the APIs. The concurrency runtime is implemented by “Tokio” external library. Rust doesn’t have a GC; instead, it has a borrow checker who insists on exactly one owner of every object at all times, makes all memory allocations explicit, and exposed all these details to programmer in the type system.

These factors make async Rust even harder to use than normal Rust.

Re: Flattening Rust’s learning curve

#79

Post by galangalalgol »

codr7 wrote: post #60
kupopuffs wrote: post #57

Earlier quoted context omitted.

Wow who pissed in your coffee? he likes rust ok?

And he's telling other people they should like it as well, because he has seen the light. My gut feeling says that there's a fair bit of Stockholm Syndrome involved in the attachments people form with Rust. You could see similar behavioral issues with C++ back in the days, but Rust takes it to another level.

I think most of us enamoured with rust are c++ refugees glad the pain is lessened. The tooling including the compiler errors really are great though. I like the simplicity of c, but I would still pick rust for any new project just for the crates and knowing I'll never have to debug a segfault. I like pytorch and matlab fine for prototyping. Not much use for in-between languages like go or c# but I like the ergonomics of them just fine. I don't think it is at all weird for people coming from c++ or even c to like rust and prefer it over those other languages. We have already paid the cost of admission, and it comes with real benefits.

Re: Flattening Rust’s learning curve

#80

Post by dwattttt »

dmitrygr wrote: post #74
worik wrote: post #71

Earlier quoted context omitted.

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…

> There is almost no case where you need to traverse a list in both directions But you might need to remove a given element that you have a pointer to in O(1), which a singly linked list will not do

If that's a specific use case you need to handle, it's O(1) again if you have a pointer to both the node to be removed and the previous node.

Whether it's more efficient to carry a second pointer around when manipulating the list, or store a second pointer in every list node (aka double linked list) is up to your problem space.

Or whether an O(n) removal is acceptable.

Post reply on HN