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.
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.
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.