Hacker News Reader

Comment by Dwedit | Hacker News Reader

Lack of destructors/RAII is the deal breaker for me. I know that this causes a function call to be made when a variable goes out of scope, which is "hidden control flow" and therefore banned by the language design.

View on HN

Lack of proper interfaces/traits is also a deal-breaker. One appears to need to do un-readable hacks to get a basic interface in Zig.

Interfaces/traits is syntactic sugar for a function dictionary/vtable. It could probably be done via Zig's compile time subset.

Standardized language-defined syntactic sugar is deeply important - esp for something as important as interfaces/traits - which are the foundation blocks for setting component contracts in libraries and modules.

Not if the standardised way is worse than the naive way, like in C++. Then I will rather take manual virtual calls, like in C: https://elixir.bootlin.com/linux/latest/source/include/linux...

It isn't that much more work and it's not something you end up doing terribly often. I think destructors are a much more important to help day to day development and avoid bugs.

In Rust, traits can be used via a vtable, but also (and the vast majority of the time) as regular old statically dispatched functions.

That doesn't mean Zig couldn't do something similar if they want to, just pointing out that it's not always the case that it means dynamic dispatch.

I didn't mention run-time dynamic dispatch, only a function dictionary (which C++ calls a vtable). Using traits for bounded subtype polymorphism is much like having a dictionary of functions that can be resolved completely at compile time, making it possible to use monomorphization and static dispatch.

Okay. It's clear we're using some words in very different ways (this is not subtype polymorphism in Rust either) but I see what you're getting at.

Another problem for me was the lack of error "payloads" (i.e. you can't give some values, like even an error message, with your errors - they're just pure enums without any context) which basically means you need to invent your own custom error system if you don't want your error reporting to suck... but I believe they were going to fix that (not sure if they've done anything yet as I haven't been following too closely, would be happy to be corrected).

I just pass a "diag" struct to functions that may need to return an error context. It was weird at first but then it dawned on me how much less friction I experienced being able to create error variants on the fly. There's also something to be said for seeing all (or most) of the relevant logic inline vs jumping around trying to make sense of separate definitions.

If you can avoid all hidden control flow, that's actually a great choice. Rust couldn't do this originally because it needed panics, which must auto-destruct objects on the stack.

No it is not - because it means you don't get RAII and so you have to clutter your code with calls to destruct things. In real code there are often several paths that things could be destroyed in and so there is a lot more manual code. Code that we know from experience people often forget to write. (memory leaks are a thing)..

Okay, you can solve the forget problem with static analysis. But since in most cases I don't care about destruction so long as it happens, when reading the code I prefer this hidden.

Abstraction means hiding details and done right is a great thing. Yes abstraction often is abused to hide the wrong thing, but that isn't the fault of abstraction as a concept.

I prefer explicit blocks for automatic object destruction to RAII. For example,

  withThing { thing => doStuffWith(thing) }

This makes it clear to me that the object is only valid within this block. There is no copy constructor madness where I might completely lose track of where the object might be alive and in scope.

Note that C++'s design of RAII and Rust's design have important differences.

The problem with blocks is that you can forget them.

Rust does keep track of where the object is alive and in scope, even if that happens to be decided dynamically, e.g. an object may only exist in a condition branch or as the result of a loop running at least once.

Objects also won't be silently copied unless they are types that explicitly marked as trivial to copy (i.e. bytewise).

It then also guarantees cleanup if the object actually does exist.

Rust already does what many people want for deterministic, safe cleanup, which like C++ includes RAII, but unlike C++ is not limited to RAII.

> But since in most cases I don't care about destruction so long as it happens

But you might want to care about where in the code the destruction happens. This is quite normal in a low level language. Of course I do agree that it should be easy to avoid leaking resources, but static analysis can ensure this in most cases as you point out.

RAII always gives me cleanup at the last possible moment. Sometimes I might want to force the cleanup sooner, but later than this always means never which is not what I want.

That's indeed one of the downsides of RAII in C++ (unless the type supports zero-cost moved-from objects), but it's not a universal issue. Rust's implementation lets you transfer ownership of an object ("move" it) from one variable to another. Afterward, the old variable will be uninitialized, and the new variable will hold the object, with its scope determining when the object is destroyed.

If the new variable has a smaller scope, then the object will be destroyed sooner than it would have been otherwise. In particular, to assist in early cleanup, the standard library has a drop(value) function, that takes ownership of any value and immediately lets it fall out of scope, destroying it.

This is especially useful for things like destroying RAII mutex guards to immediately unlock the corresponding mutex.

Everything's a tradeoff. Zig's insistence on banning hidden control flow does force you to write destructors, yes. But that has led to the Zig standard library (and wider idiomatic culture) having standard allocators as parameters. So in practice you can just choose an arena allocator and stop worrying about cleaning things up yourself.

In real code in Zig you'd just use "defer" so you still write that destructor call only once, and it would normally immediately follow the declaration-and-initialization code.

If you're writing the kind of things where you don't care at all about destruction so long as it happens, why even consider something as low-level as Zig? There are many other languages already covering that niche.

A benefit to making some things annoying to do is that people will do less of them. For example, if there is no RAII, more types will be written in such a way that they do not require deinit to be called.

As an aside, solely for the purpose of making Zig usable as an environment for people whose primary professional responsibility is not really software (quantitative researchers, data scientists, etc.) I would prefer if RAII was somehow very painful to implement for a type rather than impossible. That's the status quo for dynamic dispatch.

Same with lack of vector operators for me. I've asked a lot :(

We have them.... for SIMD vectors.

This forces us to use homogeneous 4D vectors for 3D ops ({vec3, 0} for directions and {vec3, 1} for points), which basically wastes registers when we're doing the right thing with the right vec3 types on a e.g. 32-wide vector machine.

If Zig really wanted to do the best job here, it should recognise that we're semantically not using this 4th padding dimension if we're not doing 4D projective stuff. If it really is going to force you up to 4D space, then it should be doing compile time checks e.g. sorry, you tried to add point plus a point which makes no sense, unlike vectors, or vectors and points.

This might become more important if Zig to GPU code translation becomes a thing...

Right, clearly SIMD vector primitive ops are not what you want for a 3d math lib.

Honestly, most everything listed on the page as an advantage of Zig, is a disadvantage from my point of view.

I'm sure Zig has its use cases. For what I write, I not only don't care if there's a hidden function call or error handling, I see those as 100% necessary for a modern language.

Needing to handle errors inline is a huge mess for anything nontrivial. It distracts from the logic that's important at that point in the code. Being able to override an accessor to do something instead of being a raw access is incredibly useful; a tiny change and rebuild is all that's required to track information that you would otherwise need to rewrite an entire app to support.

If you're writing extremely low level code and libraries, especially embedded, then fine, minimizing hidden behavior is important. Being able to operate without a standard library is also important in that case. Outside of that niche, though, there are few places I'd call those "features" of Zig an advantage.

> Needing to handle errors inline is a huge mess for anything nontrivial

Maybe try zig first before you make such a blanket statement?

Zig's error handling is unobtrusive. You can just write `try` if you want to propagate errors instead of handling them in some specific way.

Yeah zig just doesn't offer enough advantages over "I'll just use c++ as a better c with raii, containers, safe string class, template functions, and very simple classes/powerful structs (no inheritance), and a threading standard library"

Reply on news.ycombinator.com