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

31–40 of 82 posts

Re: Zig 0.8.0 Release Notes

#31

Post by ncmncm »

slimsag wrote: post #23
dnautics wrote: post #20

Earlier quoted context omitted.

> lacking destructors seriously? write a `deinit(self: *Self)` function into your struct and explicitly call `defer obj.deinit()`. Explicit is better than implicit. And the penalty? One line of code per destroy site, plus writing the `allocator.destroy(self)` line in your deinit method. As a result of being explicit, SO many headaches are solved. What are the rules again when you have a C++ class that polymorphically…

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 it doesn't do anything.)

Destructors are necessary for correct-by-construction coding. The only code you can be completely certain is correct is the code you didn't have to write. None of dnautics's questions ever arise. I don't have to think about them, and I can't get them wrong.

If you imagine destructors have something to do with memory management, you have much yet to learn.

Zig is doing almost everything right to become essential infrastructure, but will need to add some equivalent of destructors to get there.

Re: Zig 0.8.0 Release Notes

#32

Post by ksec »

Jarred wrote: post #26

I’ve been using Zig for a new JavaScript build tool and I really like it. It’s great for writing performance-critical code. It took me about two weeks to feel comfortable & productive in it.

Any timeline when that would be released to the public? Cant wait to see that insanely fast build time.

Re: Zig 0.8.0 Release Notes

#33

Post by dnautics »

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.

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 external system that enforces far more invariants that the rust compiler. To be dramatic, the rust compiler after all will not throw a fit if you write

    fn add(a: i32, b: i32) -> i32 { a - b; }
but if that kind of a mistake happened in the SEL-4 codebase you bet your butt the theorem prover would be unhappy.

Correctness also can be other things that you might not be able to lean on the compiler to check so easily. For example, cryptographic side channels (timing e.g.). If there is ANY ambiguity caused by the inexplicitness of the code you produce, maybe because you're not thinking about the cost of the destruction event, because, after all, you didn't write it, and there's not lexical artifact left over, it can get extremely challenging to audit for those sorts of things.

Re: Zig 0.8.0 Release Notes

#34

Post by adrusi »

c0ast wrote: post #24
lenkite wrote: post #19

Earlier quoted context omitted.

I really, really wish Zig had RAII. I am so used to this in C++ and have grave difficulty living without it. But it has been shot down as RAII is considered a high-level feature. Well, I guess I will admire the language from a distance but I am unlikely to use it practically. https://github.com/ziglang/zig/issues/782

With regards to RAII (as in constructors/destructors, not the stuff in the issue you linked), I think it simply didn't fit within Zig's goals. A big part of Zig is readability; what you read is what you get, and RAII is very much not that. Looking at a block of C++ code, there's no way to tell what happens unless you also know what the constructors/destructors of each data type in the block does.

And more concretely, a language design rule of thumb in Zig is that if a function is called, there should be an explicit function call. Zig offers defer and errdefer as the closest substitute for RAII that makes all calls explicit.

Re: Zig 0.8.0 Release Notes

#35

Post by pjmlp »

tialaramex wrote: post #14
slimsag wrote: post #4

Earlier quoted context omitted.

Accidents happen, and LLVM is a really large complex project with tons of downstream users (like Zig and Rust) discovering issues not caught by LLVM's test suite / clang. It's definitely a real problem[0][1][2][3], I would argue LLVM needs a longer release-candidate cycle before a release is cut - to give downstream users more to pick up and report regressions, as well as LLVM contributors to fix them. A higher quali…

It's definitely a problem that LLVM has features which are in practice not really exercised by C++ (because the ISO C++ standard says something is Undefined Behaviour) and so clang doesn't need to use those features yet LLVM developers too often act as though only C++ matters. Rust spent a while with trivial crashes if you have an infinite loop. Here's how that happened as I understand it: From Rust's point of view i…

Add Swift, C and Objective-C to the "customers" list that really matter.

Re: Zig 0.8.0 Release Notes

#36

Post by bvrmn »

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…

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

Re: Zig 0.8.0 Release Notes

#37

Post by masklinn »

bvrmn wrote: post #36
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…

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

Re: Zig 0.8.0 Release Notes

#38

Post by vanderZwan »

AndyKelley wrote: post #30
losvedir wrote: post #21

This is an astounding amount of work for such a small project. Looks like the 0.7.0 release was about a year and a half ago. I've been sponsoring for a couple months now. I love the passion here and want to support a smart, dedicated guy leading a project in the open. I'm curious just to see what happens and where the project goes. Watching Andy brainstorm, experiment, and triage in GitHub issues has been worth the $…

0.7.0 was 7 months ago. Thanks for your support :)

Which in Covid years is both 1.5 years ago and last week at the same time

Re: Zig 0.8.0 Release Notes

#39

Post by vanderZwan »

geodel wrote: post #28

As the military aphorism go "Amateurs talk strategy. Professionals talk logistics." I like that Zig seems to talk about compiler/linker logistics in great details as opposed to just endless list of new language features and APIs that so many languages do.

(tangent) Huh, I wonder how well that ahorism maps to Linus Torvalds' code/data structures quote:

> git actually has a simple design, with stable and reasonably well-documented data structures. In fact, I'm a huge proponent of designing your code around the data, rather than the other way around, and I think it's one of the reasons git has been fairly successful […] I will, in fact, claim that the difference between a bad programmer and a good one is whether he considers his code or his data structures more important.

Re: Zig 0.8.0 Release Notes

#40

Post by pjmlp »

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.

Post reply on HN