Hacker News Reader

Comment by pie_flavor | Hacker News Reader

As with most C++ terms, it means something completely perpendicular to what it implies. In general it means that deterministic destructors release a resource at the moment the value representing it goes out of scope, e.g. deallocating memory or closing a file handle.

IMO Odin is very wrong on this point: the important thing about destructors is that you know where to find them, so e.g. you can have closures that know how to free their captures when they are freed. There's nothing like that for Odin.

View on HN

> the important thing about destructors is that you know where to find them

The problem isn't that programmers have trouble finding a destructor. The problem is it's not apparent looking at any snippet of C++ code which objects have destructors running additional cleanup logic or other extra code without looking up each class declaration and verifying.

I believe Odin is trying to solve this by forcing the programmer to make this code explicit, but reduce the number of footguns by allowing the programmer to keep the initialization and free close to each other.

But this just shifts the problem. Now it's not apparent looking at any snippet of Odin code which objects should have cleanup logic but don't, without looking up each type and reading its documentation.

You can apply that exact same logic to languages with RAII, e.g. C++. "It's not apparently looking at any snippet of C++ code which objects have constructors and destructors, without looking up each type and reading its documentation."

Note the difference here is between being implicit vs explicit, and obvious vs hidden. RAII is implicit and hidden, which may not be a good thing in certain projects, especially when copy constructors are being called all over the place. (And move semantics don't replace copy constructors in different places, only help reduce the use of them in many cases)

Yes, that is what I replied to... my point was that neither approach is a pure improvement over the other.

I didn't say programmers have trouble finding it. My example, closures automatically calling it, is about the compiler knowing where to find it. It does not reduce the number of footguns when you have to manually free every resource, no.

Odin doesn't even have closures, or any feature that requires this kind of RAII. The whole point here is that the language doesn't deallocate for you.

I know. You say that like it's a good thing.

There's value in having a straightforward language where you know what's going to happen at any given moment. It's not good for everyone (and -thing), but languages like these have to exist, and they're needed for good reasons.

If I call a closure, I know what's going to happen - the closure is going to get called. Unless you are talking about the virtual jump, in which case that ship has sailed because Odin has function pointers. This is an allergic reaction to anything more useful than C, not a real complaint.

Reply on news.ycombinator.com