Hacker News Reader

Comment by zozbot234 | Hacker News Reader

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.

View on HN

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.

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.

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.

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.

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.

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

The problem with blocks is that you can forget them.

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.

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

Reply on news.ycombinator.com