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

Zig and the design choices within

blueberrywren.dev

Post reply on HN
Print view View original

131–140 of 183 posts

Re: Zig and the design choices within

#131

Post by ivanjermakov »

torginus wrote: post #110
ivanjermakov wrote: post #15

> Zig's comptime is a very large and all-encompassing feature that ultimately brings very little to the table that smaller features cannot. > I am personally a proponent of a good macro system. Comptime is much more constraint than any macro system: no code generation (including AST rewrite), no arbitrary tokens. Thus it's much harder to "go overboard" with Zig's comptime. This constraints of cource have their drawba…

Not an expert, but isn't Zig's comptime essentially an AST generator?

Kind of, but such functionality is not exposed to the user.

Great post on what comptime won't do: https://matklad.github.io/2025/04/19/things-zig-comptime-won...

Re: Zig and the design choices within

#132

Post by JuniperMesos »

pron wrote: post #53
ivanjermakov wrote: post #15

> Zig's comptime is a very large and all-encompassing feature that ultimately brings very little to the table that smaller features cannot. > I am personally a proponent of a good macro system. Comptime is much more constraint than any macro system: no code generation (including AST rewrite), no arbitrary tokens. Thus it's much harder to "go overboard" with Zig's comptime. This constraints of cource have their drawba…

>> Much of Zig seems to me like "wishful thinking"; if every programmer was 150% smarter and more capable, perhaps it would work. ... and the same could be said about Rust, only with Rust we can already see that it suffers from relatively low adoption at a relatively advanced age. The funny thing about that claim is that it leads to an obvious question: if working harder to satisfy the compiler is something that requ…

> ... and the same could be said about Rust, only with Rust we can already see that it suffers from relatively low adoption at a relatively advanced age.

How much adoption should we expect Rust to have at this point, and how does it compare to other languages? I certainly don't have the impression that Rust has relatively low adoption in a general sense, although I'm also a fan of the language and make a point of being in programming communities that are interested in Rust too.

Re: Zig and the design choices within

#133

Post by JuniperMesos »

torben-friis wrote: post #4

This article works really well to illustrate a question I have: why is Zig so popular in posts here? For most languages I can usually see one or two “killer features” that push the language: For Rust is taking C space with memory safety + modern semantics, for Go is being easy to learn by most engineers + parallelization, for Ruby is ergonomics… I don’t see any similar pitch for zig other than a general “I kinda enjo…

It's doing something novel in the systems programming space, and makes a bunch of different trade-offs compared to Rust. That's interesting, even if you might reasonably conclude that Rust is still a better language to use in most cases. It's good to explore different corners of the programming language design space.

Every single commonly-used programming language has a couple red flags, often much more than a couple. Javascript, C, C++, Go, Python - these languages all have serious flaws and are nonetheless used by extremely large numbers of people for all sorts of tasks.

Re: Zig and the design choices within

#134

Post by JuniperMesos »

torginus wrote: post #113
pron wrote: post #28

Earlier quoted context omitted.

Turns out that "killer features" are frequently not killer enough. You mentioned Rust with its memory-safety killer-feature, and yet Rust is quite old now (about as old as Java was when JDK 6 came out or JS was when jQuery came out) and its adoption rate is low for such an old age. I have no idea if Zig will be successful or not, but even if you look just at memory safety, I think it does a better job at that than Ru…

And the thing is Rust's borrow checker isn't such a difficult customer to just eliminate use after free - it's to stop all undefined behavior, like mutable aliasing, data races etc. If it was about just lifetimes, Rust would be a much friendlier language. Sometimes I wonder if a less rigorous Rust would be more popular.

"A less rigorous Rust" is in some ways what Zig is trying to be, although that's not the only thing that differentiates the two languages.

Re: Zig and the design choices within

#135

Post by pron »

ModernMech wrote: post #126
pron wrote: post #78

Earlier quoted context omitted.

It's actually hard to find any language that has ever very popular (JS, TS, Python, Java, C++, C#, C, and you can even throw in PHP, Ruby, Go, Kotlin, and even COBOL and Fortran) that has such a low adoption rate at age 10. I'm not saying that means Rust won't buck the historical trend and achieve that, but its adoption clearly does not resemble that of any language that's ever become very popular.

I dunno, I think you're trying to split hairs if top 20 isn't "very popular". But I don't think the comparison you're trying to make works, because then isn't now. In general, in order to convince someone to leave their current tools, you have to not only be better but a lot better. As in, you need to offer the entire feature set of the old tool plus something else compelling enough to overcome the network effects (e…

> I dunno, I think you're trying to split hairs if top 20 isn't "very popular".

It's very popular compared to Prolog or Haskell, but not compared to languages people use professionally: https://www.devjobsscanner.com/blog/top-8-most-demanded-prog...

> In general, in order to convince someone to leave their current tools, you have to not only be better but a lot better.

I agree.

> So when C++ came on the scene, they had to compete against ~20 years of accumulated legacy systems and language history. Rust had to compete with 50 years of legacy systems and language history.

Ok, but Go and TypeScript are pretty much the same age, and when Java came out, it took over much of C++'s market very quickly.

I agree Rust has some clear benefits over C++, but it also has intrinsic challenges that go well beyond mere industry momentum (and other languages have shown that momentum is very much defeatable).

> Moreover, developer expectations are a lot different today.

But there are more programmers today, and many more people worked on Rust than on C++ in its early years. And besides, Rust has had all those things you mentioned for quite some time, and C++ still doesn't have some of them.

> Also, I don't know why you've chosen "very popular" as a metric. Very popular isn't something a language needs to be, it just needs to be big enough to sustain a community.

I agree it doesn't need to be very popular to survive. But popularity is a measure of the actual benefit a language brings or, at least, lack of popularity is a measure of lack of sufficient benefit, because software is a competitive business. So claims that Rust is some huge game-changer don't really square with its rate of adoption.

Re: Zig and the design choices within

#136

Post by JuniperMesos »

pron wrote: post #111
NobodyNada wrote: post #104

Earlier quoted context omitted.

> it's just silly to draw a a particular sharp line between Rust and Zig because they perform exactly the same (in terms of sound guarantees; we're ignoring any softer effects) for most top weaknesses. There is a very clear sharp line between them in that Rust has no undefined behavior outside of an unsafe block. This matters because the effects of undefined behavior -- particularly memory-corrupting undefined behavi…

> There is a very clear sharp line between them in that Rust has no undefined behavior outside of an unsafe block. Yes, but that's an intrinsic language feature whose value needs to be justified somehow. If you justify it by saying it prevents dangerous vulnerabilities, we're back to my point. > This matters because the effects of undefined behavior -- particularly memory-corrupting undefined behavior -- are unbounde…

Maybe we should be using ATS. Or more likely, maybe we should be using some novel language that doesn't exist yet that brings the benefits of ATS to a language with good tooling and good DX that you can use to build practical system software with - that is, a Rust for ATS instead of C/C++. I think we should be designing programming languages that help eliminate as many classes of bug as possible, and Rust is not the culmination of the line here.

Re: Zig and the design choices within

#138

Post by lerno »

bsder wrote: post #121
lerno wrote: post #115

Earlier quoted context omitted.

Odin, Jai, C3, C.

Jai isn't open source so it is completely and totally irrelevant. Zig builds C faster than most C compilers. You're going to have to do better than just mention it. However, if those are the only things that are even possibly faster than Zig, then the Zig compiler qualifies as fast, not slow--which was my original point.

”Zig builds C faster than most C compilers” is a nonsense statement, which I don’t know how to answer.

The fact is simply that despite Zig uses LLVM as a backend in the same way Odin and C3 does, it compiles much slower. Exactly why that is, is something I can only guess at, but the fact is that Zig cached is still much slower to compile than Odin or C3.

(There are a few possible candidates as to why this is so that I identified and can share if it is interesting)

In any case, Zig is only ”fast to compile” if you compare to the triad of infamously slow languages: Swift, C++ and Rust.

Anything else is just hype.

Re: Zig and the design choices within

#139

Post by lerno »

ModernMech wrote: post #128
bsder wrote: post #121

Earlier quoted context omitted.

Jai isn't open source so it is completely and totally irrelevant. Zig builds C faster than most C compilers. You're going to have to do better than just mention it. However, if those are the only things that are even possibly faster than Zig, then the Zig compiler qualifies as fast, not slow--which was my original point.

> Jai isn't open source so it is completely and totally irrelevant. Worse, there's not even a compiler available. I don't even think there's even a spec.

This is just a convenient excuse. If Zig is to be fast to compile, it doesn’t help to make excuses for it.

Saying something it ”fast enough” because one is comparing with even slower languages is likely what made both Rust and Swift so slow to compile - they all just compared with C++, and it wasn’t until much later - when larger projects appeared - that the problem was taken more seriously. But at that time core architectural and language design concerns were already locked in.

This is why it’s not good for Zig to rest on its laurels and compare with worst of the class. And actually, faster Zig compile times benefits Jai, Odin and C3 as well, because then THOSE compilers can’t afford to slow down either. It’s a win-win.

If we compare with the worst though, then that’s a lose-lose proposition.

Re: Zig and the design choices within

#140

Post by pron »

JuniperMesos wrote: post #136
pron wrote: post #111

Earlier quoted context omitted.

> There is a very clear sharp line between them in that Rust has no undefined behavior outside of an unsafe block. Yes, but that's an intrinsic language feature whose value needs to be justified somehow. If you justify it by saying it prevents dangerous vulnerabilities, we're back to my point. > This matters because the effects of undefined behavior -- particularly memory-corrupting undefined behavior -- are unbounde…

Maybe we should be using ATS. Or more likely, maybe we should be using some novel language that doesn't exist yet that brings the benefits of ATS to a language with good tooling and good DX that you can use to build practical system software with - that is, a Rust for ATS instead of C/C++. I think we should be designing programming languages that help eliminate as many classes of bug as possible, and Rust is not the…

One of the lessons of the past 50 years in software correctness is that sound guarantees are not always the most effective path to correctness. The problem is that proving something correct takes a lot of effort (and there are fundamental computational complexity reasons for that), while unsound methods are significantly cheaper and surprisingly effective in practice. A famous 1996 paper by Tony Hoare [1] expresses amazement at how software had become so reliable without proofs, something that in the 1970s was thought impossible. Since then, the field has moved to enthusiastically adopt more unsound methods.

And remember that a software system, unlike an abstract algorithm, is a physical system that cannot be proven correct, since the behaviour of the physical hardware cannot be proven. We're always dealing in probabilities, and so the question is: how do we get the most value (in terms of reducing the probability of costly bugs) for a unit of effort.

Since the 1970s, the size of software that can be proven correct in practice using deductive methods has only fallen compared to the average size of a program (i.e. the size of acceptably-reliable software we write has grown much more rapidly than the size of software we can prove correct using deductive methods). The largest programs ever proven correct using deductive methods are on the order of 10KLOC.

So the field of software correctness has long ago abandoned the position (held by some in the 70s) that proof is always the most effective way toward correctness.

[1]: https://gwern.net/doc/math/1996-hoare.pdf

Post reply on HN