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

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

#31

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

nicoburns wrote: post #28

throwaway17_17 wrote: post #22

Earlier quoted context omitted.

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 derefer…

AIUI, there are some hardware architectures where even creating a wild pointer might be undefined behavior, regardless of whether that pointer is subsequently dereferenced, and C inherits these requirements. This means that it might be desirable to restrict creation and manipulation of raw pointers to unsafe code in Rust as well, if this can be done without introducing undue incompatibilities.

(Rust editions would naturally allow for this: Rust 2021 would warn on creating/manipulating raw pointers in Safe Rust, and stop warning for "unnecessary" use of unsafe deriving from these operations; Rust 2024 would make these a hard error ouside `unsafe`.)

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

#32

Post by [deleted] » Sat, Feb 22, 2020, 4:48 PM UTC

fortran77 wrote: post #30

throwaway17_17 wrote: post #22

Earlier quoted context omitted.

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.

[deleted]

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

#33

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

fortran77 wrote: post #6

ajross wrote: post #2

> Mumble mumble kernel embedded something something intrusive. And this is why kernel/embedded/something/something developers don't take Rust as seriously as you want them to. You can't simultaneously declare your language the best choice for system software development and treat the long-evolved patterns of those paradigms as a joke. There are very good reasons for intrusive data structures, not least of which being…

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…

In before someone from rust evangelism strike force chimes in saying rust is actually very simple and borrow checker takes 2 days to get familiar.

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

#34

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

ubercow13 wrote: post #23

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

I'm loving both. The book is comprehensive and teaches you even the most basic concepts, so it's great for a broader skill range.

But I love this one too because it digs into some CS archaeology and that helps me dig into the theory and history. I doubt I'll ever have to implement a linked list but knowing how they work and are implemented and their advantages and drawbacks is great.

Tangentially, there's a wonderful game called Human Resource Machine which teaches linked lists and other assembly-like programming without you even realising it.

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

#35

Post by catatattat » Sat, Feb 22, 2020, 4:57 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…

> (2) deeply offensive to those of us who work in those regimes

You know how sometimes someone who is A Little Too Online gets offended because they think you said a Bad Thing, but it was actually just a typo or a straight misreading, and you try to explain that they’re reacting to something you didn’t even say let alone believe, but because they have already decided you are the Bad Person they interpret that as you “doubling down“ on the bad opinion that they attributed to you, so they get even angrier and even more convinced that you sincerely believe the Bad Thing?

I mean no judgment. We all have such sensitivities. But maybe now you see how easily you can wind up on the wrong side of a public debate by searching for offense where there is in fact none.

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

#36

Post by ubercow13 » Sat, Feb 22, 2020, 5:02 PM UTC

Waterluvian wrote: post #34

ubercow13 wrote: post #23

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

I'm loving both. The book is comprehensive and teaches you even the most basic concepts, so it's great for a broader skill range. But I love this one too because it digs into some CS archaeology and that helps me dig into the theory and history. I doubt I'll ever have to implement a linked list but knowing how they work and are implemented and their advantages and drawbacks is great. Tangentially, there's a wonderful…

The book is very comprehensive but it didn't click for me as a beginner, I found much of the exposition left me with unanswered questions while it went on to cover more ground. I'm not sure if those questions were answered later but I got lost very quickly. Maybe it's aimed at people with more C++ background?

This linked list tutorial answered every question I thought of almost exactly as I thought of them, which made it a joy to read. I also liked Rust By Example [1] over the book. Based on my experience I'd recommend this tutorial and then implementing something using Rust By Example as reference. But everyone learns differently!

[1] https://doc.rust-lang.org/rust-by-example/

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

#37

Post by imtringued » Sat, Feb 22, 2020, 5:03 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…

If you can't tell when to break or not break rules then maybe you are not a kernel developer? It's almost like a King only following his own laws instead of being the one making them. Why are you a King again?

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

#38

Post by Dylan16807 » Sat, Feb 22, 2020, 5:20 PM UTC

jasondclinton wrote: post #12

I went through this a few years ago for fun. It's a great guided tour of the compiler errors when working with complex memory safety needs. The most important thing to know about these is that you would almost certainly never do these in a real project: lists are in `std` but even then the vast majority of cases should use `Vec`.

Linked lists are inherently niche on modern hardware.

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

#39

Post by [deleted] » Sat, Feb 22, 2020, 5:38 PM UTC

ajross wrote: post #2

> Mumble mumble kernel embedded something something intrusive. And this is why kernel/embedded/something/something developers don't take Rust as seriously as you want them to. You can't simultaneously declare your language the best choice for system software development and treat the long-evolved patterns of those paradigms as a joke. There are very good reasons for intrusive data structures, not least of which being…

[deleted]

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

#40

Post by varjag » Sat, Feb 22, 2020, 5:42 PM UTC

Dylan16807 wrote: post #38

jasondclinton wrote: post #12

I went through this a few years ago for fun. It's a great guided tour of the compiler errors when working with complex memory safety needs. The most important thing to know about these is that you would almost certainly never do these in a real project: lists are in `std` but even then the vast majority of cases should use `Vec`.

Linked lists are inherently niche on modern hardware.

Seriously? Are trees also niche?