In a way, it's a return to simpler times. I remember learning programming C and it was about programming computers, not abstract concepts. As languages got higher level abstractions, we lost touch with the computer. That's why programs are so bloated today. Zig respects that we are programming a computer, with concrete behaviours, it doesn't try to abstract things away, doesn't hide complexity, and yet gives you tools for managing it. That's why I enjoy it.
I truly do not understand why anyone would think Rust is abstracting things away.
Like, to be clear: if you want to develop in Zig because you like it for whatever reason, you should do that. There is no world, nor will there ever be a world, where there's "one language to rule them all". This comment should not be read as "you should write Rust instead".
I just don't find any of your descriptions of Zig to be things that Rust is guilty of. You can (mostly) write the same things in each language, ship a static binary, and your users would never know the difference. IME you are generally as "in touch with the computer" in Rust as you are in Zig.
Well, for example, every function that allocates expects allocator as an argument, it is not abstracted away. Resource deallocation is not abstracted away, you have to explicitly free your resources. Ever function that uses IO expects it as an argument. It doesn't have operator overloading, which is also an abstraction.
I left the "mostly" in my comment because custom allocators is one area where Rust as an ecosystem is still in need of some work, and I'm aware of that - hell, in part because of TigerBeetle's blog posts on the subject.
Everything you're describing is a stylistic preference, though - and doesn't contribute to bloat, which is what the parent comment was implying. If your program is bloated, that's on you to clean up - it doesn't matter if it's in C, C++, Rust, or Zig. Every single one of these languages has nothing that stops you from getting it right.
(A weird aside but the downvotes on this chain are just odd to me. I'm not telling y'all to not write Zig, chill already)
Look, I'm working on an async I/O engine, not unsimilar to Tokio. I started running benchmarks only to realize that I'm significantly faster than Tokio. Go, which is a garbage collected language with preemptive scheduling, is also faster than Tokio on these benchmarks. And Tokio is fast, I'm not claiming it's not. Rust developers program in terms of traits, and borrow checker behaviours. That's fine if you want enterprise kind of safety by tooling. It's just not enjoyable to me and that seems fairly common view. There are people who enjoy languages like Rust, Scala, Haskell. They allow you to create your own world in the type system and that's fine, but it is more disconnected from the actual computer the code is running on.
Local allocators are also in the works for Rust, as well as a general effect system (including potentially an IO effect). Rust also doesn't have fully general operator overloading, it currently uses traits instead. (Though explicit local notations are generally a better way of handling operator semantics, and a future edition of Rust could potentially achieve this via macros.)
I think what happens is that people discover a new language, find that they really enjoy it and then struggle to explain why they like it. While they’re struggling they sometimes put down a “competing” language even if no one asked.
They could say it just really vibed with them but they don’t.
And so have the various editions of standard Fortran. In fact, ISO Fortran’s abstract floating-point model is so old now that it’s confusing, since it’s basically IEEE-754 but off by one in its exponents.
The PDP is remarkably similar to x86. The complaints that people have written at length about typically come down to superscalar features not being exposed in the instruction set, which means that it can't be exposed to the programming model.
On the other hand, every architecture that has tried to expose them so far has failed; nobody wants to manually apply the Tomasulo algorithm to their code, or manage shuffling data elements into and out of their cache hierarchy.
These arguments never really hold water for me. The C VM is flexible enough to apply to literally any piece of hardware with relatively few pains. For experienced systems programmers, it is also extremely easy to brain-compile C code. C++ and Rust are both much harder in this respect.
