←back to thread

200 points jorangreef | 1 comments | | HN request time: 0s | source
Show context
pron ◴[] No.24292760[source]
I think that Zig's simplicity hides how revolutionary it is, both in design and in potential. It reminded me of my impression of Scheme when I first learned it over twenty years ago. You can learn the language in a day, but it takes a while to realize how exceptionally powerful it is. But it's not just its radical design that's interesting from an academic perspective; I also think that its practical goals align with mine. My primary programming language these days is C++, and Zig is the first low-level language that attempts to address all of the three main problems I see with it: language complexity, compilation speed, and safety.

In particular, it has two truly remarkable features that no other well-known low-level language -- C, C++, Ada, and Rust -- have or can ever have: lack of macros and lack of generics (and the associated concepts/typeclasses) [1]. These are very important features because they have a big impact on language complexity. Despite these features, Zig can do virtually everything those languages do with macros [2] and/or generics (including concepts/typeclasses), and with the same level of compile-time type safety and performance: their uses become natural applications of Zig's "superfeature" -- comptime.

Other languages -- like Nim, D, C++ and Rust also have a feature similar to Zig's comptime or are gradually getting there -- but what Zig noticed was that this simple feature makes several other complex and/or potentially harmful features redundant. Antoine de Saint-Exupery said that "perfection is achieved, not when there is nothing more to add, but when there is nothing left to take away." I think that Zig, like Scheme -- and yes, there are others -- is close to that minimalist vision of perfection.

What a truly inspiring language. Rather than asking how we could make C++'s general philosophy work better as another increasingly famous language does, IMO, it asks how we could reshape low-level programming in a way that's a more radical break with the past. I think it's a better question to ask. Now all there's left to hope for is that Zig gets to 1.0 and gains some traction. I, for one, would love to find a suitable alternative to C++, and I believe Zig is the first language that could achieve that in a way that suits my particular taste.

[1]: I guess C has the second feature, but it loses both expressivity and performance because of it.

[2]: Without the less desirable things people can do with macros.

replies(5): >>24293479 #>>24293660 #>>24294000 #>>24294005 #>>24312605 #
littlestymaar ◴[] No.24294000[source]
> What a truly inspiring language

It's indeed an inspiring language, and rust is taking inspiration from it already: https://github.com/jswrenn/project-safe-transmute/blob/rfc/r...

> lack of generics

I can't wait before Zig2 comes and eventually adds generics…

replies(5): >>24294122 #>>24294488 #>>24294589 #>>24294667 #>>24296780 #
pron ◴[] No.24294488[source]
> and rust is taking inspiration from it already

But C++/Rust can never have Zig's primary feature -- simplicity. Zig's power is not that it has comptime, but that it has little else.

> I can't wait before Zig2 comes and eventually adds generics…

No need. Zig gives you the same capabilities as generics do, only through a separate feature that other languages also have in addition to generics. In other words, it has generics, but without having generics as a special construct. Zig recognises that once you have that other feature (compile-time introspection) you don't need generics as a separate construct, but they can be just an instance of that single construct.

replies(1): >>24294721 #
littlestymaar ◴[] No.24294721[source]
> But C++/Rust can never have Zig's primary feature -- simplicity

Sounds like a Go pitch, except Zig ain't Go. And while comptime is a cool feature, it's also a really complex one!

> In other words, it has generics, but without having generics as a special construct. Zig recognises that once you have that other feature (compile-time introspection) you don't need generics as a separate construct, but they can be just an instance of that single construct.

This has advantages (only one feature to know), but it also has a big drawback: the lack of orthogonality. C is also simple, for instance it has no concept of errors (only return values) or arrays (only pointers), but most people won't consider this a good idea (and Zig didn't follow C on either of those two design points)

Zig is cool, but I hoped the “generics are too complex of a feature” meme would die now that Go is getting generics, and I'd be really sad to see come back…

replies(2): >>24295037 #>>24298998 #
pron ◴[] No.24295037[source]
> it's also a really complex one!

No, it's a very simple one, so much so that it's erasable: https://news.ycombinator.com/item?id=24293611 And still it is probably the most complex aspect of Zig.

> Zig is cool, but I hoped the “generics are too complex of a feature” meme would die now that Go is getting generics, and I'd be really sad to see come back…

You've misunderstood me. Generics are a good thing -- if that's all you have. But if you have generics and procedural macros, it turns out that you can do the work of both with a feature that's simpler than either. The capability generics add is a very important one, but given that low-level languages need another one as well, it turns out that generics can be subsumed into that one without being a separate and additional construct. Zig has generic types and concepts/typeclasses; these just aren't atomic language constructs.

replies(1): >>24297905 #
littlestymaar ◴[] No.24297905[source]
> But if you have generics and procedural macros, it turns out that you can do the work of both with a feature that's simpler than either.

Here I think we just have a different subjective perception of what simplicity is. I much prefer have two orthogonal systems which do their own business than having a single more powerful tool than do both (like having slices + references instead of the all powerful pointer)

Anecdotal note: more than 10 years ago, the Go team pitched why they didn't need generics nor macros, because code generation would solve both problems (+ others), and now they're on their way back to add generics to Go (with a lot of hassle).

replies(1): >>24298572 #
1. pron ◴[] No.24298572{3}[source]
> I much prefer have two orthogonal systems which do their own business than having a single more powerful tool than do both (like having slices + references instead of the all powerful pointer)

OK, but that's not quite the situation. Here we're talking about languages that have, or will have, the single "more powerful" construct, and also the more specific, special case one, as two separate constructs, even though one of them would have sufficed.

Again, Zig has parameterized types, and very elegant and powerful ones -- they're functions that take some types as argument and return a type. It just doesn't have generics as a separate construct. Rather, it is a special case of a more general one (that Rust and C++ will also have).