Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Zig 0.8.0 Release Notes

ziglang.org

Post reply on HN
Print view View original

41–50 of 82 posts

Re: Zig 0.8.0 Release Notes

#41

Post by pjmlp »

masklinn wrote: post #37
bvrmn wrote: post #36

Earlier quoted context omitted.

> If you imagine destructors have something to do with memory management, you have much yet to learn. It is very limiting to think that destructors is the only way to solve resource scoping problem.

What alternative doesn’t add failure opportunities and require additional work by the developer where they will crop up? Both defer (and more generally scope guards) and context managers certainly do, to say nothing of try/finally.

True, but also does RAII for heap allocated objects unless one makes use of smart pointers.

Outside HN, CppCon and C++Now bubbles not all C++ codebases are as clean as we would wish them to be.

Re: Zig 0.8.0 Release Notes

#42

Post by diragon »

ncmncm wrote: post #31
slimsag wrote: post #23

Earlier quoted context omitted.

I think GP means RAII, which is still an open area of discussion in Zig: https://github.com/ziglang/zig/issues/782 I'd love to see it if it can be implemented in a way that fits the language, but that remains to be seen.

Actually, no, I mean destructors. Equivalent to Rust's Drop trait. Those are needed for RAII, but also for about everything else. (You need other things, too, to make RAII.) They were the only thing that made C++ uniquely powerful in 1985, and the only reason Rust can begin to compete. They represent the first and still only piece of runtime automation seen anywhere in the programming world. (Some would claim GC, but…

>The only code you can be completely certain is correct is the code you didn't have to write.

This reminds me of Douglas Adams.

"The major difference between a thing that might go wrong and a thing that cannot possibly go wrong is that when a thing that cannot possibly go wrong goes wrong it usually turns out to be impossible to get at and repair."

This seems to be a matter of taste with no absolute conclusion to be reached which style is better. At least until we get significantly better at analysing codebases and software quality.

Re: Zig 0.8.0 Release Notes

#43

Post by ncmncm »

dnautics wrote: post #33
ncmncm wrote: post #31

Earlier quoted context omitted.

Actually, no, I mean destructors. Equivalent to Rust's Drop trait. Those are needed for RAII, but also for about everything else. (You need other things, too, to make RAII.) They were the only thing that made C++ uniquely powerful in 1985, and the only reason Rust can begin to compete. They represent the first and still only piece of runtime automation seen anywhere in the programming world. (Some would claim GC, but…

> The only code you can be completely certain is correct is the code you didn't have to write. Not true at all, there are always compiler errors, and in many cases you can statically check your code using an external validation system. I'd be 99.999% confident of most of the WRITTEN code of SEL-4, probably more confident than ANY code "not written" in rust, because it's been formally verified by a theorem-proving ext…

Anybody who cannot tell whether a type has a destructor is qualified neither to code nor to audit cryptographic primitives. In any case, cryptographic timing behavior is verified by careful white-box testing, not just inspection. Any bonus destructor activity (if, e.g., somebody unqualified coded it) would show up then.

When your case is so weak, it is better not to present it.

Re: Zig 0.8.0 Release Notes

#44

Post by ncmncm »

pjmlp wrote: post #40
ncmncm wrote: post #16

The energy in this project is amazing! The idea of including a C++ and a C compiler gratis is brilliant, and solves a big interoperability headache very elegantly. For my own purposes, IIUIC it is fatally flawed, lacking destructors, but as a raw C replacement it has legs. Compile-time execution and types as regular compile-time values makes it actually powerful.

> The idea of including a C++ and a C compiler gratis is brilliant, and solves a big interoperability headache very elegantly. C++ did it first, having been born at same place as UNIX and C, all major C compiler vendors quickly added it into the box.

It would be better if a C or C++ header sufficed to declare things so they may be called directly from Zig, without need for matching declarations in Zig. Or, do they? For it to be useful, types would need to be imported, too. That would need destructor and overloading support. Which is doable.

Re: Zig 0.8.0 Release Notes

#45

Post by papaf »

ncmncm wrote: post #31
slimsag wrote: post #23

Earlier quoted context omitted.

I think GP means RAII, which is still an open area of discussion in Zig: https://github.com/ziglang/zig/issues/782 I'd love to see it if it can be implemented in a way that fits the language, but that remains to be seen.

Actually, no, I mean destructors. Equivalent to Rust's Drop trait. Those are needed for RAII, but also for about everything else. (You need other things, too, to make RAII.) They were the only thing that made C++ uniquely powerful in 1985, and the only reason Rust can begin to compete. They represent the first and still only piece of runtime automation seen anywhere in the programming world. (Some would claim GC, but…

I don't have to think about them, and I can't get them wrong.

... until you have to write a class yourself. Then you have to think of the complexities introduced by destructors such as copy semantics, move semantics and the destructors themselves.

You also have to deal with architectural questions such as should my file have a close method (C++) or do I always leave this to the destructor (Rust).

If I was to give an opinionated summary, a little complexity at the call site has been moved to a lot of complexity in the class implementation. Since there is, on average, one class implementation to many object uses, destructors might be considered a win. But I don't feel so strongly about it that I wouldn't consider a language for not having destructors.

Re: Zig 0.8.0 Release Notes

#46

Post by ncmncm »

papaf wrote: post #45
ncmncm wrote: post #31

Earlier quoted context omitted.

Actually, no, I mean destructors. Equivalent to Rust's Drop trait. Those are needed for RAII, but also for about everything else. (You need other things, too, to make RAII.) They were the only thing that made C++ uniquely powerful in 1985, and the only reason Rust can begin to compete. They represent the first and still only piece of runtime automation seen anywhere in the programming world. (Some would claim GC, but…

I don't have to think about them, and I can't get them wrong. ... until you have to write a class yourself. Then you have to think of the complexities introduced by destructors such as copy semantics, move semantics and the destructors themselves. You also have to deal with architectural questions such as should my file have a close method (C++) or do I always leave this to the destructor (Rust). If I was to give an…

You almost got there.

What makes a language powerful is the ability to put essential semantics into a library where they can be got right once, so all users of the library benefit. It is worth design, implementation, testing, optimization effort if the results can be delivered over and over, in many different contexts, reliably.

Destructors are the necessary ingredient to pull transaction semantics into libraries. Without, you are left to write comments explaining users' responsibilities, and users have to read and act on them perfectly, or be wrong. With, you can code them correctly once and users have no opportunity or temptation to get them wrong.

Re: Zig 0.8.0 Release Notes

#48

Post by papaf »

ncmncm wrote: post #46
papaf wrote: post #45

Earlier quoted context omitted.

I don't have to think about them, and I can't get them wrong. ... until you have to write a class yourself. Then you have to think of the complexities introduced by destructors such as copy semantics, move semantics and the destructors themselves. You also have to deal with architectural questions such as should my file have a close method (C++) or do I always leave this to the destructor (Rust). If I was to give an…

You almost got there. What makes a language powerful is the ability to put essential semantics into a library where they can be got right once, so all users of the library benefit. It is worth design, implementation, testing, optimization effort if the results can be delivered over and over, in many different contexts, reliably. Destructors are the necessary ingredient to pull transaction semantics into libraries. Wi…

I agree with your comment about libraries. Destructors biggest advantage is in well used libraries.

Any interesting code involves custom classes written by less experienced developers that are only used once or twice in an application -- it is there that that the complexity of destructors hurt.

Re: Zig 0.8.0 Release Notes

#50

Post by masklinn »

pjmlp wrote: post #41
masklinn wrote: post #37

Earlier quoted context omitted.

What alternative doesn’t add failure opportunities and require additional work by the developer where they will crop up? Both defer (and more generally scope guards) and context managers certainly do, to say nothing of try/finally.

True, but also does RAII for heap allocated objects unless one makes use of smart pointers. Outside HN, CppCon and C++Now bubbles not all C++ codebases are as clean as we would wish them to be.

I don't understand the objection (?), I think there's at least one word missing, possibly more.

If you want to use RAII for heap allocations you obviously need some sort of RAII wrapper for them. And smart pointers are the usual solution. But technically you can do without if you really really don't want to make dereference overridable, you can just have the "smart" bit (RAII / automatic deterministic deallocation) without the "pointer" bit.

Post reply on HN