Gregory's Server
Operator overloading is the one I could live without... but it still would have been very annoying to have to use functions to do all the complex GPU power management calculations that I built on top of a simple soft float implementation (no real floats in the kernel!).
I have nothing against Zig, it looks like a neat programming language and it definitely has its place!
... but I don't think that place is writing complex operating systems and drivers today. At least I'm pretty sure it wouldn't have worked for my Apple GPU driver.
Edit: I'm getting a bunch of comments pointing out Zig's compile-time evaluation and metaprogramming features. I've looked into it a bit more, and so far my conclusion is "it's impressive and clearly very well designed and powerful... but for the very specific problem I'm personally trying to solve, Rust macros still work better"
Edit 2: People have come up with solutions to my versioning problem in Zig that are pretty similar to what I do in Rust with macros, so I'll retract that point. The other three still stand though, and the safety and destructors ones are pretty important ^^
Copying a thread I tweeted about `defer` vs. `Drop`:
> with defer:
> - whilst a bit error-prone, destruction is bound to the context and you can have non-intrusive destructors, you'll need this for APIs where you need a context to destroy a resource, so storing it in each object is infeasible
This is a valid argument and I actually have run into this myself! It's a real annoyance in Rust...
... but the thing is, this is the exception, not the rule. 99% of the time automatic Drop is what I want.
One of the neat demos I did of how Rust is better than C is that my Rust OF abstractions take care of refcounts for you, even across iterators and such. All the explicit refcounting (that nobody gets right) disappears.
In Zig, it'd come back, just as "defer" everywhere instead.
It *is* possible to forbid Drop in Rust for a type and require explicit destruction, and I'd rather do that for the 1% of cases where I need it, than have to defer the other 99%.
The Zig approach really doesn't scale for complex data structures. You can't have a generic vector or map, and just destroy it. You need to write explicit code to iterate through it and destroy every element. That's a real major pain...
Much of the time I don't even have Drop impls for my objects, or they just do one trivial thing. 99% of the cleanup code is generated by the compiler recursively calling Drop on all contained types. Having to type that out would be a lot of time wasted writing error-prone code...
Copying a thread I tweeted about `defer` vs. `Drop`:
> with defer:
> - whilst a bit error-prone, destruction is bound to the context and you can have non-intrusive destructors, you'll need this for APIs where you need a context to destroy a resource, so storing it in each object is infeasible
This is a valid argument and I actually have run into this myself! It's a real annoyance in Rust...