Comment by pron | Hacker News Reader

Comment by pron | Hacker News Reader

Parent Full thread

> but it's not a very compelling argument to avoid a language because of them.

You're looking at it from the wrong direction. Both Zig and Rust target low-level programming, i.e. domains where C and C++ are very established. You don't need a reason to avoid a language -- you need a reason to invest a great amount of effort to switch away from an established incumbent.

Now, my biggest issues with C++ are, in this order: 1. language complexity, which makes understanding and changing codebases harder, 2. long compilation times which lengthen cycles and reduce software quality, 3. lack of memory safety. Rust improves on 1 a tiny bit, and solves 3. Zig solves 1, 2, and almost completely 3. This means that I have little reason to even consider switching to Rust; I will only if it ever becomes dominant. I wouldn't switch to Zig right now -- it still needs to prove itself, but at least it's a contender, because it offers something quite radical. Rather than an improved C++, it is a whole new way to think of low-level programming, it seems to address precisely the things that bother me about C++, plus it focuses on other aspects that are very important to low-level programming, like cross-compilation.

On the other hand, what does Zig lose that C++ has? I've seen that it doesn't have destructors. Does it have some other means of ensuring that I'm closing my resources appropriately, or am I burdened with ensuring that myself? After all, memory safety is just one kind of resource safety.

It has "defer" and "errdefer" constructs for cleaning up resources, comparable to Go, but obviously applying to more things since there's no GC.

https://ziglang.org/documentation/master/#defer

AFAICT, it loses absolutely nothing. It does reject C++'s implicitness, so it replaces destructors with an explicit defer, but the mechanism is pretty much the same. That it does all this in a language you can fully learn in a day or two is remarkable.

> 2. long compilation times which lengthen cycles and reduce software quality

Seems like something that will be improved over time in Rust.

Do you see any advantages of Rust over Zig, which wouldn't fall under point 3?

No, although language preference is subjective. Rust is a language in the C++ tradition and, like C++, is one of the most complicated programming languages in the history of software, while Zig is probably among the simplest. Some people like elaborate languages and find the design, which mixes C++ and ML appealing. Zig is unlike anything else.

I would say that the biggest philosophical difference is this. While Zig and C++/Rust are all low-level languages and so suffer from low abstraction (it comes with the territory) -- i.e. implementation details are hard to hide, and changing them requires changing in the APIs clients -- C++/Rust invest a lot of complexity in trying to make the code, once written, look as if the language has good abstraction. The code is still as hard to change, but it looks like a high-level language on the page. Some people may like that, but Zig completely rejects that.

Compile times will likely improve in the future, but they're still likely to be much longer than those in zig. Especially if you also consider the body of software surrounding zig/rust. I believe zig developers are more likely to take a stance that libraries should be more specific and smaller, while rust libraries tend to be more all-encompassing. Even if the resulting code is small and efficient, the compiler has to do more work.

I think Bryan Cantrill had a pretty spot on description of this kind of thing in his "values" talk, even if zig is not on his list.

I have always been using Pascal

It used to solve 1 (although it becomes worse every year when new languages feature are introduced), it solves 2, and most of 3 (with automated reference counting)

Reference counting is a GC (and often not a very good one). In low-level domains you often don't want a GC for various reasons.

That is why Pascal also has raw pointers and inline assembly

So it is safe by default, but for those hotspots where it actually matters, you can write the most performant, unsafe code

You really have to go out of your way to get memory safety wrong in modern C++.

Not really. It's still extremely easy to trip over things like iterator invalidation or using moved objects.

Reply on news.ycombinator.com