191–200 of 213 posts
Earlier quoted context omitted.
Zig feels like a better C with modern tooling. It is a tool that works for me. Rust feels like a better C++ with modern tooling. I am a tool that works for it.
This is what people don’t understand. Zig and Rust are not competitors. Rust is a better C++ but C was the good part of C++.
Earlier quoted context omitted.
>leaving Rust for Zig for the sheer enjoyment of using it instead. What do people find more enjoyable?
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 tool…
Earlier quoted context omitted.
Yet computers are abstract concepts :-) And C is basically high level assembly for the PDP, which has little in common with x86, for example.
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.
Earlier quoted context omitted.
>leaving Rust for Zig for the sheer enjoyment of using it instead. What do people find more enjoyable?
Zig feels like a better C with modern tooling. It is a tool that works for me. Rust feels like a better C++ with modern tooling. I am a tool that works for it.
Earlier quoted context omitted.
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…
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 enter…
Earlier quoted context omitted.
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 tool…
Languages have been higher level abstractions since Fortran, there is a reason why ISO C targets an abstract machine model.
I'm absolutely struggling to understand what Synadia even does. it's been an infuriating experience navigating through their marketing site. It's been minutes and I still don't understand what it is. What is NATS? Edit: I had to google what NATS.IO is. The marketing site is infuriatingly useless. Please, can we stop doing this? Edit: At the bottom on the footer it says compare NATS to Kafka. It took me to a page that…
Let's not forget Synadia donated NATS to CNCF and tried to take it back https://www.infoq.com/news/2025/05/nats-cncf-open-source/
Earlier quoted context omitted.
Zig is orders of magnitude more pleasant and enjoyable to use than Rust.
>>> Zig is more enjoyable than Rust >> Why is that? > Zig is more enjoyable than Rust You didn't really leave the GP more informed than before.
https://doc.rust-lang.org/reference/
vs
Earlier quoted context omitted.
I don't know. I don’t doubt that TigerBeetle’s hardest correctness challenges can’t be solved by language alone. TigerBeetle has impressive guarantees! Those are inherently systems-design problems. But the language defines the failure surface and the cost of getting those systems problems right. Likewise, the difficulty and performance of implementing correctness mechanisms (lock-free data structures, concurrent logs…
More precisely, “TigerBeetle’s hardest correctness challenges can’t be solved by language AT ALL”. The “harder problems” in TigerBeetle then (and where we invested millions literally in engineering): - distributed system strict serializability (cf. our Jepsen audit) - storage fault safety (TB expects disks to write/read to/from the wrong location, or drop writes entirely, and MUST survive this, all while preserving s…
Earlier quoted context omitted.
How is Zig considered “90% safe”? It relies on manual memory management, its simple type system provides limited compile-time guarantees and it lacks a mature concurrency model (making safe parallelism difficult). Given these gaps, I struggle to see how Zig achieves a consistently high level of safety. It seems no safer than using AddressSanitizer at best?
Zig makes a lot of small choices that pile up to push you towards safety/correctness in your code. No hidden allocations is a big one. If something allocates you have to explicitly give it an allocator. This makes tracking allocations much simpler. Combined with the test allocator you can also detect memory leaks. Allocators also simplify memory management patterns. For example, it's trivially ease to use an arena. T…
- No hidden allocations: Other languages already provide abstractions for this. Are hidden allocations really a significant issue in modern systems languages, even when managing memory manually? This concern is distinct from memory leaks or general memory safety problems.
- Allocators: It's easy to use an arena in C++ or C.
- defer keyword: Similar constructs have existed in other languages and even as a GNU C extension for many years.
- Bounds checking: Not an issue in Rust. The real source of risk has always been raw pointer manipulation, which Zig doesn't (cannot?) solve. How is it better than address sanitizer? Rust solves this at the language level.
- Nullability: GCC has long supported non-null attributes and unused-result annotations and Clang provides _Nullable. C++ goes further with type-level guarantees via std::optional, gsl::not_null and related abstractions.
- Errors: Zig’s approach is clean but equivalent mechanisms exist in C++ (std::expected) and Rust (Result and error types). It’s mainly cumbersome in plain C.
All of these are useful quality-of-life improvements but they don’t address my problems in systems programming (such as efficient and composable data structures, data movement, scalable concurrency, safe memory management ...and boiler-plate, lots of boiler-plate). These problems are easier to solve with a type system that allows me to make strong correctness guarantees and extend those guarantees.
Lastly, I’m unsure that any potential boilerplate reduction would be significant if implemented in Zig.