Learn Rust with entirely too many linked lists (2019) • Hacker News Board

Re: Learn Rust with entirely too many linked lists (2019)

#21

Post by saagarjha » Sat, Feb 22, 2020, 4:11 PM UTC

throwaway17_17 wrote: post #19

roblabla wrote: post #9

Earlier quoted context omitted.

The actual context of your quote: > Just so we're totally 100% clear: I hate linked lists. With a passion. Linked lists are terrible data structures. Now of course there's several great use cases for a linked list: > > - You're writing a kernel/embedded thing and want to use an intrusive list. So I’ve got no clue what you’re railing about. The project specifically acknowledges that there is a need in kerneldev for th…

The quote that the GP is talking about is included below, which copy/pasted from the project page, and the Mumble mumble line is the heading for a paragraph: ‘’’Mumble mumble kernel embedded something something intrusive. It's niche. You're talking about a situation where you're not even using your language's runtime. Is that not a red flag that you're doing something strange? It's also wildly unsafe.’’’ Also, prior…

Kernel development is niche. Most of the time you don’t need linked lists.

Re: Learn Rust with entirely too many linked lists (2019)

#22

Post by throwaway17_17 » Sat, Feb 22, 2020, 4:15 PM UTC

saagarjha wrote: post #20

fortran77 wrote: post #6

Earlier quoted context omitted.

My feelings, too. I do both embedded programming (in C/C++ and CUDA) and Erlang programming for a living. Erlang, too, doesn't let you (easily) write your own linked list structures, etc. But for embedded programming with tight memory or performance constraints these data structures are essential so we use C++ or even C. They're well understood and the implementations have simple, elegant solutions. For "safety" when…

Rust gives you just as much control as C when you need it.

I may be mistaken, but if using unsafe does not allow for the ‘borrow-checker’ to be turned off and allow for code which doesn’t abide by the checker’s requirements, then it clearly does not give “as much control as C”. Again, I might have missed some of the subtleties of circumventing Rust’s static checking, but I don’t think I can purposely create some non-deterministic racy-appearing abstractions, which would be trivial to do using global variables in C.

Re: Learn Rust with entirely too many linked lists (2019)

#23

Post by ubercow13 » Sat, Feb 22, 2020, 4:16 PM UTC

This is great as an intro to Rust, I preferred this as a Rust starter tutorial to the main rust book or any other tutorial I tried

Re: Learn Rust with entirely too many linked lists (2019)

#24

Post by saagarjha » Sat, Feb 22, 2020, 4:22 PM UTC

throwaway17_17 wrote: post #22

saagarjha wrote: post #20

Earlier quoted context omitted.

Rust gives you just as much control as C when you need it.

I may be mistaken, but if using unsafe does not allow for the ‘borrow-checker’ to be turned off and allow for code which doesn’t abide by the checker’s requirements, then it clearly does not give “as much control as C”. Again, I might have missed some of the subtleties of circumventing Rust’s static checking, but I don’t think I can purposely create some non-deterministic racy-appearing abstractions, which would be t…

> if using unsafe does not allow for the ‘borrow-checker’ to be turned off and allow for code which doesn’t abide by the checker’s requirements

It does, that’s why it’s there.

Re: Learn Rust with entirely too many linked lists (2019)

#25

Post by jasondclinton » Sat, Feb 22, 2020, 4:22 PM UTC

ajross wrote: post #15

jasondclinton wrote: post #13

Earlier quoted context omitted.

https://github.com/Amanieu/intrusive-rs implements what you're looking for with no heap. There's no need to flame or misrepresent what the book says (no one said embedded was a joke). The Rust embedded community is strong.

You're like the sixth person to argue I'm somehow "misrepresenting" what is being said in this book? I'm quoting it directly. The "flame" is in the original, and I'm responding to it. Take it out. It's bad.

Assuming that you're not trolling, I'll explain how you misinterpreted what you read: the section that you quoted is a sub-heading under:

> An Obligatory Public Service Announcement

which is an argument that:

> Linked lists are as niche and vague of a data structure as a trie.

The author then goes on to state that many people have contacted him to argue that linked lists are not niche and he puts each of those arguments under a heading:

> Mumble mumble kernel embedded something something intrusive.

is one such heading. Inside of it, he continues the argument that linked lists for embedded no-heap scenarios are niche and—to continue his argument—we therefore shouldn't be teaching undergrads linked lists just like we don't teach them tries.

Re: Learn Rust with entirely too many linked lists (2019)

#26

Post by steveklabnik » Sat, Feb 22, 2020, 4:22 PM UTC

throwaway17_17 wrote: post #22

saagarjha wrote: post #20

Earlier quoted context omitted.

Rust gives you just as much control as C when you need it.

I may be mistaken, but if using unsafe does not allow for the ‘borrow-checker’ to be turned off and allow for code which doesn’t abide by the checker’s requirements, then it clearly does not give “as much control as C”. Again, I might have missed some of the subtleties of circumventing Rust’s static checking, but I don’t think I can purposely create some non-deterministic racy-appearing abstractions, which would be t…

Unsafe doesn’t turn off the borrow checker, but it does give you access to pointers that aren’t checked.

Re: Learn Rust with entirely too many linked lists (2019)

#27

Post by zozbot234 » Sat, Feb 22, 2020, 4:25 PM UTC

throwaway17_17 wrote: post #22

saagarjha wrote: post #20

Earlier quoted context omitted.

Rust gives you just as much control as C when you need it.

I may be mistaken, but if using unsafe does not allow for the ‘borrow-checker’ to be turned off and allow for code which doesn’t abide by the checker’s requirements, then it clearly does not give “as much control as C”. Again, I might have missed some of the subtleties of circumventing Rust’s static checking, but I don’t think I can purposely create some non-deterministic racy-appearing abstractions, which would be t…

> if using unsafe does not allow for the ‘borrow-checker’ to be turned off and allow for code which doesn’t abide by the checker’s requirements

It allows the latter. 'Code that doesn't abide by the checker's requirements' uses separate facilities that are only allowed in unsafe code. This means that `unsafe` doesn't have to turn off anything, and further pinpoints the parts of the code where caution is needed in order to maintain the invariants that Safe Rust is based on.

Re: Learn Rust with entirely too many linked lists (2019)

#28

Post by nicoburns » Sat, Feb 22, 2020, 4:29 PM UTC

throwaway17_17 wrote: post #22

saagarjha wrote: post #20

Earlier quoted context omitted.

Rust gives you just as much control as C when you need it.

I may be mistaken, but if using unsafe does not allow for the ‘borrow-checker’ to be turned off and allow for code which doesn’t abide by the checker’s requirements, then it clearly does not give “as much control as C”. Again, I might have missed some of the subtleties of circumventing Rust’s static checking, but I don’t think I can purposely create some non-deterministic racy-appearing abstractions, which would be t…

You can't turn off the borrow checker for references, but Rust also provides raw pointers which are not subject to borrow checking (these are exactly like pointers in C, and can be cast to and from references (this is a no-op at runtime since they share the same memory representation)).

https://doc.rust-lang.org/1.30.0/book/first-edition/raw-poin...

You can create and manipulate raw pointers in safe code, but dereferencing them requires an `unsafe` block.

Re: Learn Rust with entirely too many linked lists (2019)

#29

Post by MaulingMonkey » Sat, Feb 22, 2020, 4:30 PM UTC

ajross wrote: post #10

steveklabnik wrote: post #7

Earlier quoted context omitted.

It explicitly says that there are good use cases, just that they’re very rare.

It does not. Maybe somewhere else it does. That section, verbatim, says: It's niche. You're talking about a situation where you're not even using your language's runtime. Is that not a red flag that you're doing something strange? It's also wildly unsafe. But sure. Build your awesome zero-allocation lists on the stack. And this is (1) wildly mistating the requirements and (2) deeply offensive to those of us who work…

> And this is (1) wildly mistating the requirements and (2) deeply offensive to those of us who work in those regimes.

Care to expand how? While not a kernel dev, I've had my share of use cases where I've done exactly this kind of thing in gamedev, and I simply cannot bring myself to disagree with what's been said, or see what's offensive.

It's strange, debugging when the pointers get corrupted by other code exhibiting UB is painful, it's a potential multithreading hazard, and flat contiguous arrays are frequently more appropriate - but it's sometimes useful. It's not arguing that an alternative paradigm can - or even should - be deployed in a heapless context. It's explicitly admitting that intrusive linked lists are an appropriate paradigm.

Re: Learn Rust with entirely too many linked lists (2019)

#30

Post by fortran77 » Sat, Feb 22, 2020, 4:36 PM UTC

throwaway17_17 wrote: post #22

saagarjha wrote: post #20

Earlier quoted context omitted.

Rust gives you just as much control as C when you need it.

I may be mistaken, but if using unsafe does not allow for the ‘borrow-checker’ to be turned off and allow for code which doesn’t abide by the checker’s requirements, then it clearly does not give “as much control as C”. Again, I might have missed some of the subtleties of circumventing Rust’s static checking, but I don’t think I can purposely create some non-deterministic racy-appearing abstractions, which would be t…

It's sad that we have to create throwaway accounts if we want to be able to simply say we prefer or use other languages over Rust without getting downvoted so much that we'll end up shadowbanned.