I have never written a line of code in Zig, but I can read it and derive a pretty good idea of what the syntax means without a lot of effort. The same cannot be said for Rust.
That’s you dawg. You probably have a different background, because I can follow zig code, but have no idea what a bunch of stuff means.
pub fn enqueue(this: *This, value: Child) !void { , !void? It’s important to return void? Watch out void is being returned? Does that mean that you can write !Child ? And what would that even mean?
const node = trythis.gpa.create(Node); what does try mean there? There’s no catch, no except. Does that mean it just kills the stack and throws the exception until it reaches a catch/except? If not, why put a try there? Is that an indication that it it can throw?
node.* = .{ .data = value, .next = null }; excuse me what? Replace the contents of the node object with a new dict/map that has the keys .data and .next?
if (this.end) |end| end.next = node // what’s the lambda for? And what’s the // for ? A forgotten comment or an operator? If it’s to escape newline, why isn’t it a backslash like in other languages?
start: ?*Node. Question pointer? A nullable pointer? But aren’t all pointers nullable? Or does zig make a distinction between zero pointers and nullable pointers?
this.start orelse returnnull is this a check for null or a check for 0 or both?
However when I read rust the first time, I had quite a good idea of what was going on. Pattern matching and move were new, but traits were quite understandable coming from Java with interfaces. So yeah, mileage varies wildly and just because you can read Zig, doesn’t mean the next person can.
Regardless, it’s not like either of us have any pull in the kernel (and probably never will). I fear for the day we let AI start writing kernel code…
Granted, everyone is different. The cognitive load of Rust has been widely written about, though, so I don’t think I’m am outlier.
Regardless, it’s not like either of us have any pull in the kernel (and probably never will). I fear for the day we let AI start writing kernel code…
Absolutely never, in my case. This isn’t what concerns me, though. If Rust is harder than C, then fewer people are going to attempt it. If it takes several hours to compile the kernel on an average desktop computer, even fewer are going to be willing to contribute, and almost nobody who isn’t creating a distribution is ever going to even try to compile their own kernel. It may even dissuade people from trying to start new distributions.
If, if, if. Maybe it seems as if I’m fear-mongering, but as I’ve commented elsewhere, I noticed that when looking for tools in AUR, I’ve started filtering out anything written in Rust unless it’s a -bin. It’s because at some point I noticed that the majority of the time spent upgrading software on my computer was spent compiling Rust packages. Like, I’d start an update, and every time I checked, it’d be in the middle of compiling Rust. And it isn’t because I’m using a lot of Rust software. It has had a noticeable negative impact on the amount of time my computer spends with the CPU pegged upgrading. God forgive me, I’ve actually chosen Node-based solutions over Rust ones just because there was no -bin for the Rust package.
I don’t know if this is the same type of “cancer” in the vitriolic Kernel ML email that led to the second-to-last firestorm, but this is how I’ve started to feel about Rust - if there’s a bin, great! But no source-based packages, because then updating my desktop starts to become a half-day journey. I’m almost to the point of actively going in and replacing the source-based Rust tools with anything else, because it’s turning updating my system into a day-long project.
Haskell is already in this corner. Between the disk space and glacial ghc compile times, I will not install anything Haskell unless it’s pre-compiled. And that’s me having once spent a year in a job writing Haskell - I like the language, but it’s like programming in the 70’s: you write out your code, submit it as a job, and then go do something else for a day. Rust is quickly joining it there, along with Electron apps, which are in the corner for an entirely different reason.
That’s you dawg. You probably have a different background, because I can follow zig code, but have no idea what a bunch of stuff means.
See samples
pub fn enqueue(this: *This, value: Child) !void {,!void? It’s important to returnvoid? Watch outvoidis being returned? Does that mean that you can write!Child? And what would that even mean?const node = try this.gpa.create(Node);what doestrymean there? There’s nocatch, noexcept. Does that mean it just kills the stack and throws the exception until it reaches acatch/except? If not, why put a try there? Is that an indication that it it can throw?node.* = .{ .data = value, .next = null };excuse me what? Replace the contents of thenodeobject with a new dict/map that has the keys.dataand.next?if (this.end) |end| end.next = node //what’s the lambda for? And what’s the//for ? A forgotten comment or an operator? If it’s to escape newline, why isn’t it a backslash like in other languages?start: ?*Node. Question pointer? A nullable pointer? But aren’t all pointers nullable? Or does zig make a distinction between zero pointers and nullable pointers?this.start orelse return nullis this a check for null or a check for 0 or both?However when I read rust the first time, I had quite a good idea of what was going on. Pattern matching and
movewere new, but traits were quite understandable coming from Java with interfaces. So yeah, mileage varies wildly and just because you can read Zig, doesn’t mean the next person can.Regardless, it’s not like either of us have any pull in the kernel (and probably never will). I fear for the day we let AI start writing kernel code…
Anti Commercial-AI license
Granted, everyone is different. The cognitive load of Rust has been widely written about, though, so I don’t think I’m am outlier.
Absolutely never, in my case. This isn’t what concerns me, though. If Rust is harder than C, then fewer people are going to attempt it. If it takes several hours to compile the kernel on an average desktop computer, even fewer are going to be willing to contribute, and almost nobody who isn’t creating a distribution is ever going to even try to compile their own kernel. It may even dissuade people from trying to start new distributions.
If, if, if. Maybe it seems as if I’m fear-mongering, but as I’ve commented elsewhere, I noticed that when looking for tools in AUR, I’ve started filtering out anything written in Rust unless it’s a -bin. It’s because at some point I noticed that the majority of the time spent upgrading software on my computer was spent compiling Rust packages. Like, I’d start an update, and every time I checked, it’d be in the middle of compiling Rust. And it isn’t because I’m using a lot of Rust software. It has had a noticeable negative impact on the amount of time my computer spends with the CPU pegged upgrading. God forgive me, I’ve actually chosen Node-based solutions over Rust ones just because there was no -bin for the Rust package.
I don’t know if this is the same type of “cancer” in the vitriolic Kernel ML email that led to the second-to-last firestorm, but this is how I’ve started to feel about Rust - if there’s a bin, great! But no source-based packages, because then updating my desktop starts to become a half-day journey. I’m almost to the point of actively going in and replacing the source-based Rust tools with anything else, because it’s turning updating my system into a day-long project.
Haskell is already in this corner. Between the disk space and glacial ghc compile times, I will not install anything Haskell unless it’s pre-compiled. And that’s me having once spent a year in a job writing Haskell - I like the language, but it’s like programming in the 70’s: you write out your code, submit it as a job, and then go do something else for a day. Rust is quickly joining it there, along with Electron apps, which are in the corner for an entirely different reason.