-
zig
General-purpose programming language and toolchain for maintaining robust, optimal, and reusable software.
A few notes:
1) Lack of a garbage collector does not make your program faster, it makes the performance more easily predictable in terms of latency.
It also makes it more friendly for memory bandwidth, CPU cache and to overall memory usage, which in turn results in better performance in real-case scenarios vs synthetic/toy benchmarks. This is particularly noticeable in constrained environments (like embedded systems).
2) Zig was never about memory safety, and it is not a memory-safe language.
It might have better plumbing than C, it might add better way to implement and abstract concepts.. but so does C++, for instance.
The more striking differences between C++ and Zig, IMHO, are syntax and the ability to use the same language instead of a separate one to do meta-programming (templates vs comptime).
3) Aliasing enforcement in Rust is there for a reason.
Two examples I quickly found on Zig's issue tracker:
https://github.com/ziglang/zig/issues/3696
-
CodeRabbit
CodeRabbit: AI Code Reviews for Developers. Revolutionize your code reviews with AI. CodeRabbit offers PR summaries, code walkthroughs, 1-click suggestions, and AST-based analysis. Boost productivity and code quality across all major languages with each PR.
-
For a pure Rust answer to “how to make a primarily-safe gc-lang in Rust”, see Piccolo (Lua) with its ‘Stackless VM’:
https://github.com/kyren/piccolo
That’s not to say Piccolo couldn’t theoretically benefit from having its (already isolated) unsafe parts rewritten in Zig, but that’s up to the Zig developer community to chip away at with upstream contributions.
-
I wouldn’t use this in production, but this was in HN earlier this year and I love the idea: https://github.com/borgo-lang/borgo
-
> The drop trait has its warts too. Zig's version sets up a point in time where the given cleanup code _will_ run (ignoring power outages and the like), and Rust's sets up a point in time where the given cleanup code is _allowed_ to run.
You're making it sound like Drop is regularly not called, which could lead someone to think that you're talking about them not running on panics, which they do: https://play.rust-lang.org/?version=stable&mode=debug&editio...
The reason they are allowed to run is because panics can be configured to be abort, so people are discouraged from using Drop to maintain safety constraints. But any language will have issue executing code before exiting if you go out of your way to set things up so normal unwinding doesn't occur.
> It solves UAF, but it makes performance harder to reason about and makes leaks easier to write (a common theme in my complaints about Rust -- it's mostly a nice language, but many of the design choices slightly encourage leaky code, so most projects of any size and complexity have leaks).
I don't see how Drop causes leaks.
> Having drops be that easy to write also encourages programmers to think in terms of small units of data rather than collections and common lifetimes, typically resulting in increased execution times.
Beyond my skepticism about the mechanism being a significant source of performance degradation, writing collections that take responsibility over dropping their contents in one go isn't particularly difficult or restricted by the language.