Learn Rust with entirely too many linked lists (2019)
rust-unofficial.github.io
Learn Rust with entirely too many linked lists (2019)
1–10 of 179 posts
Re: Learn Rust with entirely too many linked lists (2019)
#2And 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 their ability to operate in contexts where no heap is available. If you don't understand them or don't want to talk about them or want to limit your discussion to situations with different requirements, then say so.
Re: Learn Rust with entirely too many linked lists (2019)
#3> 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…
Re: Learn Rust with entirely too many linked lists (2019)
#4> 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…
Re: Learn Rust with entirely too many linked lists (2019)
#5> 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…
E.g., if you want to write text to a small screen, the kernel driver gives you a memory region that you write bytes to, and they're shown on the screen immediately, without requiring the CPU.
Re: Learn Rust with entirely too many linked lists (2019)
#6> 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…
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 we don't need absolute control, we'll choose a GC language like C# or F#. No need for the complication of Rust.
Re: Learn Rust with entirely too many linked lists (2019)
#7> 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…
Re: Learn Rust with entirely too many linked lists (2019)
#8> 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…
To explain what I think this comment means. When working on embedded systems, you can interact with hardware devices by writing directly to specially mapped memory areas. E.g., if you want to write text to a small screen, the kernel driver gives you a memory region that you write bytes to, and they're shown on the screen immediately, without requiring the CPU.
And why can't you do this in rust?
Re: Learn Rust with entirely too many linked lists (2019)
#9> 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…
> 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 those data structures.
I’m a kernel dev using Rust for my kernel. I use both intrusive linked list and growable vectors in it. The thing is, the sentiment expressed in the article really resonates in me: in most cases, growable vectors are a better choice, performance-wise.
Re: Learn Rust with entirely too many linked lists (2019)
#10> 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…
It explicitly says that there are good use cases, just that they’re very rare.
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 in those regimes.
Obviously, yes, there's room for a reasoned argument about this stuff and whether alternative paradigms can be deployed in heapless contexts. This isn't it.