Live data from Hacker News

Zig and the design choices within

blueberrywren.dev

61–70 of 183 posts

Re: Zig and the design choices within

#61

The author refers to casting ints to floats but seems to actually be talking about converting. Casting is when you change the type, but don't change the data.. I don't really think much of Zig myself for other reasons, but comptime seems like a good design.

Casting and type conversion are synonyms: https://en.wikipedia.org/wiki/Type_conversion

Re: Zig and the design choices within

#62
post #53

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

> a relatively advanced age.

Maybe you and I have different working definitions of "relative", but Rust hit 1.0 only 10 years ago, whereas the age of the most popular languages is 30+ years. In that sense Rust is relatively young. Indeed, Rust is the youngest language in the TIOBE top 20, and it's more popular than other languages which have been around much longer. The only language which comes close is Swift, and that one had the advantage of Apple pushing it as the main language for iOS development, Rust never had that kind of marketing and corporate support.

Re: Zig and the design choices within

#63

The authors section on comptime makes me believe they have not used zig anything non trivial. I don’t think comptime as just some macro system. It is closer to a reflection system. I use comptime to access types. You can create specialized paths depending on type. Also imo generics are “first class” in zig. Comptime is first class and thus generics are too.

> X is first class and thus Y [implemented in terms of X] is too. Is everything first class, then?

In theory it can encode 0 and 1 so anything really, right?

Re: Zig and the design choices within

#64
I find the point about memory safety to be pretty damning.

People think it's a slight on their abilities. "I can write memory safe code!" Maybe you can. There are two huge problems here, and they're problems that will never go away no matter how good you are.

The first is that this doesn't scale. As soon as you add more programmers to a project, you multiply the odds of bugs like this. Even if everyone's just as good, not everyone will have the whole program in their head or code in exactly the same style.

The second is that code rots. Your new C (or Zig) program might be totally correct and memory safe when it's first written. Then you commit it to a repo. Then you move on to another project for a while. Then someone else fixes something and you merge a PR. Then you come back to it three months later and you're under pressure to implement something. Then you work in a new feature a year later and you've forgotten some of the really nit-picky details of how things work. It's very easy over time for bugs to creep in, and if the language doesn't catch them they'll sit in the code until they cause random crashes or, worse, a CVE.

These aren't avoidable issues. They're inherent to software and its life cycle. Memory safe languages (and secure computing systems in general) are the only way to deal with them.

Re: Zig and the design choices within

#65

The author refers to casting ints to floats but seems to actually be talking about converting. Casting is when you change the type, but don't change the data.. I don't really think much of Zig myself for other reasons, but comptime seems like a good design.

> Casting is when you change the type, but don't change the data..

Is that the case? That's not what I think of when I think of C-style casts.

    float val = 12.4;
    int val_i = (int) val;
The representation in memory of `val` should not match that of `val_i`, right? The value is encoded differently and the quantity is not preserved through this transformation. I don't think that means that the data weren't changed.

Maybe you're thinking of aliasing/type-punning? Casts in C do perform conversions as they do in C++.

Re: Zig and the design choices within

#66

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…

> for Ruby is ergonomics… My impression is that this is the main thing for Zig too. The intersection of the set of languages that let you write very low-level code where you have full control over memory and allocation and the set of languages that are enjoyable to program in is pretty small. C is in there if you've internalized many of its warts are fine with all of the many many footguns it has. C++ is in there if…

Ok, that makes sense. So it’s a modern take on low level languages, like rust, but for those that dislike c for being cumbersome rather than for being less secure?

Is that a stated goal of the language? Other than the feature to gradually move from c++ it wasn’t super clear from the main pitch.

Re: Zig and the design choices within

#67

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

> But I oppositely believe the world needs more tech that treats professionals as experts, not kids.

This attitude is why we still have bounds checking memory bugs in new software in 2025.

IMHO an artisan should want superior tools that produce better results.

Re: Zig and the design choices within

#68
post #24

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

> Nice way to put it! But I oppositely believe the world needs more tech that treats professionals as experts, not kids. That’s how it was until around the turn of the century. Who needs types, we’re adults after all. Memory safety and garbage collection? Oh please go back to kindergarten. But then some of us learned that no matter how smart we are, we can make mistakes that those things can actually prevent. And tho…

When I was much dumber, I thought I was much smarter. Now that I'm smarter, I realize that I'm often quite dumb.

Re: Zig and the design choices within

#69
post #19

Why have I been seeing a Zig post every day for the past week? Is there some kind of a marketing push?

Interest on various topics comes in waves on HN. This week it's Zig, next week it's Scheme, the week after is Erlang, etc. Nothing out of the ordinary.

Programming languages in general go through hype waves here; back in the mid 2000s it was some combination of Lisp -> Ruby -> JS with bits of Erlang in and around those.

Re: Zig and the design choices within

#70

Earlier quoted context omitted.

It's interesting how much Rust has slowed down. There is still some development in linux otherwise people seem to be over it. I think Rust just doesn't offer enough in terms of features, and is overshadowed by languages like Go or C++ in terms of what developers are really looking for. Rust's popularity seems to be dropping or holding steady in indexes like TIOBE, and a lot of big "influencers" seem to be over Rust's…

> Rust's popularity seems to be dropping or holding steady in indexes like TIOBE Oh, 14th [1]. That's a lot lower than I would have expected, based purely on the amount of noise surrounding Rust. [1] https://www.tiobe.com/tiobe-index/

There appears to be a lot of noise in the Tiobe already. What does it mean if Visual Basic is shooting up and C is near the top? They are surely in no way measuring the same programming market -- so who cares?
Post reply on HN