Hacker News Reader

Comment by mooman219 | Hacker News Reader

It sounds like the complaints here are operator overloading, global allocator by default, and metaprogramming. I think the value of these features are certainly not objective, but it's not a very compelling argument to avoid a language because of them.

As for optional standard library support, this is actually really common in Rust and is a breeze to support. Just annotating [no_std] basically gets you there libc wise. There's even additional restrictions like [no_core] to remove even more. I believe this should be noted.

I think the author missed an opportunity to really drill into actual pain points like the steep learning curves to c++ and rust, and where/if Zig excels in specific examples.

</rust evangelism strike force>

View on HN

> 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.

> 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.

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.

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.

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

Rust is also getting configurable allocators soon. Most standard collections will take an additional, optional allocator.

There are also a few people who want to rethink the design of allocators to allow for inline storage. It definitely sounds interesting, but may end up being too complicated.

Do you have a link to the RFC for this? This sounds awesome.

EDIT: thanks to the links below I found this [1] and this [2]

[1] https://github.com/rust-lang/rust/issues/32838

[2] https://github.com/rust-lang/rfcs/pull/1398

While I don't have an RFC your you (I'm not the same person), here's an interesting thread on maybe tweaking the interface: https://internals.rust-lang.org/t/is-custom-allocators-the-r...

And here's the working group's repo: https://github.com/rust-lang/wg-allocators

I'm not sure there's an up-to-date RFC, but here's what it looks like: https://doc.rust-lang.org/nightly/std/boxed/struct.Box.html#...

Will they avoid the Transparent Comparator fudge that C++ has because the allocator is part of the type?

https://stackoverflow.com/questions/20317413/what-are-transp...

Could you elaborate on what this is, exactly?

In short, it allows a std::map<K, V> to be queried with a type that isn't K. For example,

    std::map<std::string, int> m;
    std::string_view sv = "mykey";
    auto&& iter = m.find(sv);

Oh, rust already has that.

I guess I would be in the D evangelism strike force, but I concur.

D also has a really rather nice composable allocator system in the standard library.

The “no metaprogramming” is a bit of a misnomer. The thing is that Zig uses the exact same syntax for metaprogramming as for regular programming, you just add the comptime keyword and use types like variables. This is a much more ergonomic approach than having a completely separate syntax, which is really common and imho annoying in other languages.

Reply on news.ycombinator.com