In Zig, we would just allocate the list with an allocator, store pointers into it for the tag index, and mutate freely when we need to add or remove notes. No lifetimes, no extra wrappers, no compiler gymnastics, that’s a lot more straightforward.
What happens to the pointers into the list when the list needs to reallocate its backing buffer when an “add” exceeds its capacity?
Rust’s borrow checker isn’t usually just a “Rust-ism”. It’s all low level languages, and many times also higher level languages. Zig doesn’t let you ignore what Rust is protecting against, it just checks it differently and puts more responsibility on the developer.
anaVal@lemmy.dbzer0.com
on 23 Sep 19:21
nextcollapse
The two languages are polar opposites in this regard, Zig places the burden on the developer and makes it easy for them to produce memory safe software, whereas Rust places the burden on the compiler and makes it hard for developers to produce memory unsafe software.
The article even points this out. I personally think it’s very good to have these two languages for these separate use cases.The right tool for the job and all that.
I agree, Zig is awesome. But the author missed the entire point of the borrow checker. It exists to make you a better programmer, not to just annoy you. The author immediately then showcased why the borrow checker exists in their example of why it’s annoying lol.
In general, you are right. Once you explain to the borrow check you are doing the right thing then you have a fair level of confidence in it being right.
I think the point from the article is if it is worth it. Give the single sentence in the article about a list and pointer. There are various ways to do it safely (and ways to do it unsafely like you pointed out) and sometimes it might be ok to put the onus of that onto the developer and validated with valgrind, asans, and unit tests. For some this is far more enjoyable than worry about the borrow collector.
It’s all a trade off and it’s ok to have difference criteria when approaching a problem like a cli tool or even a business critical service. The problem becomes when Rust people claim that the borrow checker is the only way and we all roll our eyes.
dihutenosa@piefed.social
on 23 Sep 19:00
nextcollapse
Reads like it was written by a LLM.
thenextguy@lemmy.world
on 23 Sep 19:09
nextcollapse
Or to avoid ad hominem accusations: No code. Don’t Care.
And no benchmarks either. That intro about stack vs. heap also reads like someone who never went further than sophomore-level knowledge, or someone explaining things to kids.
Yeah the intro read as weird to me. If you’re writing for a programming crowd there’s no need to explain all that, and anyway the rest of the article wasn’t about the stack/heap distinction.
Man, I don’t know what kind of CLIs this guy is building, where you need to keep long-lived references around and whatnot.
CLIs are typically quite easy to build in Rust, because in most cases, you just load your ~/.notes, iterate over the files/lines once, print out the result and then exit. I have a hard time coming up with a scenario where building an in-memory (!) tag index benefits you in a CLI.
threaded - newest
What happens to the pointers into the list when the list needs to reallocate its backing buffer when an “add” exceeds its capacity?
Rust’s borrow checker isn’t usually just a “Rust-ism”. It’s all low level languages, and many times also higher level languages. Zig doesn’t let you ignore what Rust is protecting against, it just checks it differently and puts more responsibility on the developer.
The article even points this out. I personally think it’s very good to have these two languages for these separate use cases.The right tool for the job and all that.
I agree, Zig is awesome. But the author missed the entire point of the borrow checker. It exists to make you a better programmer, not to just annoy you. The author immediately then showcased why the borrow checker exists in their example of why it’s annoying lol.
In general, you are right. Once you explain to the borrow check you are doing the right thing then you have a fair level of confidence in it being right.
I think the point from the article is if it is worth it. Give the single sentence in the article about a list and pointer. There are various ways to do it safely (and ways to do it unsafely like you pointed out) and sometimes it might be ok to put the onus of that onto the developer and validated with valgrind, asans, and unit tests. For some this is far more enjoyable than worry about the borrow collector.
It’s all a trade off and it’s ok to have difference criteria when approaching a problem like a cli tool or even a business critical service. The problem becomes when Rust people claim that the borrow checker is the only way and we all roll our eyes.
Reads like it was written by a LLM.
Doesn’t seem like that to me.
Or to avoid ad hominem accusations:
No code. Don’t Care.
And no benchmarks either. That intro about stack vs. heap also reads like someone who never went further than sophomore-level knowledge, or someone explaining things to kids.
Yeah the intro read as weird to me. If you’re writing for a programming crowd there’s no need to explain all that, and anyway the rest of the article wasn’t about the stack/heap distinction.
Man, I don’t know what kind of CLIs this guy is building, where you need to keep long-lived references around and whatnot.
CLIs are typically quite easy to build in Rust, because in most cases, you just load your
~/.notes, iterate over the files/lines once, print out the result and then exit. I have a hard time coming up with a scenario where building an in-memory (!) tag index benefits you in a CLI.yeah, it even sounds like they’re building an index to use it once and throw it away