7 ms·

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

by pron 6y ago

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.

dom96 6y ago
> 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. I'm curious where this impression of Zig comes from, as this is precisely what Nim has set out to do: a small core extensible via metaprogramming. Are there features that Nim implements which go against this premise? if so, what are they? :)
- deleted 6y ago
  [deleted]
- pron 6y ago
  > Are there features that Nim implements which go against this premise? if so, what are they? :) Nim has generics (plus concepts), templates, and macros. Zig has just comptime, through which it achieves all those goals (minus some macro capabilities that it deems harmful anyway) with just one, very simple, cohesive construct. You could argue on whether you like this or not, but you can't argue that Zig's approach isn't fundamentally more minimal. Zig is a language you can reasonably fully learn in one day; I don't think you could say the same about Nim. --- Also, note another remarkable feature. One could define a language called Zig' with the following properties: 1. Every well-formed Zig program is a well-formed Zig' program (i.e. Zig' accepts all Zig programs, potentially more). 2. Every Zig program has the same semantics as the identical program when interpreted in Zig'. This means that to analyse the semantics of a Zig program you can pretend it's a Zig' program; in fact, you don't need to create an interpreter for Zig', you can just pretend it exists. Why would you want to do that? Because Zig' is simpler. How? Here's the kicker: Zig' ignores comptime completely. It is a very simple, optionally-typed, dynamic language with reflection. In other words, to analyse the semantics of a Zig program you can forget about comptime and pretend it can do everything at runtime (and treat comptime as a pure semantics-preserving optimisation). This is not true for languages with macros, as they are not "erasable".
  - mratsim 6y ago
    > Zig has just comptime, through which it achieves all those goals (minus some macro capabilities that it deems harmful anyway) with just one, very simple, cohesive construct. You could argue on whether you like this or not, but you can't argue that Zig's approach isn't fundamentally more minimal. Zig is a language you can reasonably fully learn in one day; I don't think you could say the same about Nim. "some macros" are downplaying Nim macros, it's like saying Lisp has some AST rewrite capabilities. Nim macros goals are two-folds: 1. adding functionality to the language without baking it in the compiler. A prime example is ``async``, ``async`` including a nice async/await syntax can be completely implemented as a library without reserving keywords to do things like `pub async fn`. 2. Automating away boilerplate. From what I understood, Zig comptime is only about making compile-time function evaluation first-class.
renaicirc 6y ago
Do you have any example code? It's plain to see that Zig's comptime is powerful enough for typeclasses, but it's not at all obvious that it'd be as ergonomic as Haskell's typeclasses.
- pron 6y ago
  I don't have any particular examples in hand, but the question you're asking is one that's tough to answer because the languages that might be as ergonomic as Haskell in that regard and are also low-level are significantly more complex than either Haskell or Zig, and so I don't think we have a good point of comparison (I think Zig is revolutionary). There is definitely a price to pay for being a high-control/low-level language, and it certainly requires that you spend some of your "complexity budget" on things that high-level languages like Haskell or Java don't have to. But I think Zig shows that you can be both low-level and reasonably "expressive" without also being so much more complex than most high-level languages.
littlestymaar 6y ago
> 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/rfcs/0000-safe-transmute.md#safe-transmute-rfc https://github.com/jswrenn/project-safe-transmute/blob/rfc/r... > lack of generics I can't wait before Zig2 comes and eventually adds generics…
- dnautics 6y ago
  Zig already has generics, gp was imprecise. They are not a part of the language, but an emergent feature that is simple enough to implement using comptime. Edit: clearly gp was not mistaken, just imprecise.
- pron 6y ago
  > 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.
  - littlestymaar 6y ago
    > 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…
bigbizisverywyz 6y ago
> ...lack of macros and lack of generics ... To be fair, you can do absolutely everything you want to do in C++ without using either of these features at all, it just takes a bit of discipline. And if you see the flack that go gets for not including generics then I'm not so sure that that is a great way to get people to adopt your language.
- dnautics 6y ago
  Zig has generics, they are just not part of the language (very easy to implement using what zig gives you).
- deleted 6y ago
  [deleted]
smaddox 6y ago
I've been a financial backer of Zig for several months now, and plan to continue, because Andrew and the other contributers are pushing language design in directions that no other language is. That being said, Zig's comptime is not a proper replacement for typeclasses/traits. Zig can do both comptime duck typing and vtable-based dispatch, but it cannot do proper bounded polymorphism type checking. It always fully evaluates types before type checking them. This might make it difficult (or impossible?) to provide type checking error messages of similar quality to Rust. I'm not sure if there are any other practical consequences for realistic programs, though. I suspect there might be issues around interface stability gaurantees, though I can't quite put my finger on why.
- pron 6y ago
  Right, they are only approximately comparable, but the important thing to remember is that features of formalisms are never goals in themselves, but rather means to various ends. The goal is never "to have interfaces/typeclasses/traits" but to be able to specify an algorithm that works for a variety of data structures with shared properties. Moreover, I think it would be a mistake for Zig library authors to try and replicate styles used in other languages. Zig provides sufficient mechanisms for expressing programs, and it will develop its own style. There will be elements that are analogous to those in other lanugages, but not identical. Having said that, I do support a proposal for specifying a type at the parameter declaration with some type -> bool function. I like this quote by Leslie Lamport about comparing formalisms (he talks about specification languages rather than programming languages, but the sentiment is the same): > Comparisons between radically different formalisms tend to cause a great deal of confusion. Proponents of formalism A often claim that formalism B is inadequate because concepts that are fundamental to specifications written with A cannot be expressed with B. Such arguments are misleading. The purpose of a formalism is not to express specifications written in another formalism, but to specify some aspects of some class of computer systems. Specifications of the same system written with two different formalisms are likely to be formally incomparable… Arguments that compare formalisms directly, without considering how those formalisms are used to specify actual systems, are useless.

by pron 6y ago

dom96 6y ago

> 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. I'm curious where this impression of Zig comes from, as this is precisely what Nim has set out to do: a small core extensible via metaprogramming. Are there features that Nim implements which go against this premise? if so, what are they? :)

deleted 6y ago
[deleted]
pron 6y ago
> Are there features that Nim implements which go against this premise? if so, what are they? :) Nim has generics (plus concepts), templates, and macros. Zig has just comptime, through which it achieves all those goals (minus some macro capabilities that it deems harmful anyway) with just one, very simple, cohesive construct. You could argue on whether you like this or not, but you can't argue that Zig's approach isn't fundamentally more minimal. Zig is a language you can reasonably fully learn in one day; I don't think you could say the same about Nim. --- Also, note another remarkable feature. One could define a language called Zig' with the following properties: 1. Every well-formed Zig program is a well-formed Zig' program (i.e. Zig' accepts all Zig programs, potentially more). 2. Every Zig program has the same semantics as the identical program when interpreted in Zig'. This means that to analyse the semantics of a Zig program you can pretend it's a Zig' program; in fact, you don't need to create an interpreter for Zig', you can just pretend it exists. Why would you want to do that? Because Zig' is simpler. How? Here's the kicker: Zig' ignores comptime completely. It is a very simple, optionally-typed, dynamic language with reflection. In other words, to analyse the semantics of a Zig program you can forget about comptime and pretend it can do everything at runtime (and treat comptime as a pure semantics-preserving optimisation). This is not true for languages with macros, as they are not "erasable".
- mratsim 6y ago
  > Zig has just comptime, through which it achieves all those goals (minus some macro capabilities that it deems harmful anyway) with just one, very simple, cohesive construct. You could argue on whether you like this or not, but you can't argue that Zig's approach isn't fundamentally more minimal. Zig is a language you can reasonably fully learn in one day; I don't think you could say the same about Nim. "some macros" are downplaying Nim macros, it's like saying Lisp has some AST rewrite capabilities. Nim macros goals are two-folds: 1. adding functionality to the language without baking it in the compiler. A prime example is ``async``, ``async`` including a nice async/await syntax can be completely implemented as a library without reserving keywords to do things like `pub async fn`. 2. Automating away boilerplate. From what I understood, Zig comptime is only about making compile-time function evaluation first-class.

renaicirc 6y ago

Do you have any example code? It's plain to see that Zig's comptime is powerful enough for typeclasses, but it's not at all obvious that it'd be as ergonomic as Haskell's typeclasses.

pron 6y ago
I don't have any particular examples in hand, but the question you're asking is one that's tough to answer because the languages that might be as ergonomic as Haskell in that regard and are also low-level are significantly more complex than either Haskell or Zig, and so I don't think we have a good point of comparison (I think Zig is revolutionary). There is definitely a price to pay for being a high-control/low-level language, and it certainly requires that you spend some of your "complexity budget" on things that high-level languages like Haskell or Java don't have to. But I think Zig shows that you can be both low-level and reasonably "expressive" without also being so much more complex than most high-level languages.

littlestymaar 6y ago

> 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/rfcs/0000-safe-transmute.md#safe-transmute-rfc https://github.com/jswrenn/project-safe-transmute/blob/rfc/r... > lack of generics I can't wait before Zig2 comes and eventually adds generics…

dnautics 6y ago
Zig already has generics, gp was imprecise. They are not a part of the language, but an emergent feature that is simple enough to implement using comptime. Edit: clearly gp was not mistaken, just imprecise.
pron 6y ago
> 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.
- littlestymaar 6y ago
  > 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…

bigbizisverywyz 6y ago

> ...lack of macros and lack of generics ... To be fair, you can do absolutely everything you want to do in C++ without using either of these features at all, it just takes a bit of discipline. And if you see the flack that go gets for not including generics then I'm not so sure that that is a great way to get people to adopt your language.

dnautics 6y ago
Zig has generics, they are just not part of the language (very easy to implement using what zig gives you).
deleted 6y ago
[deleted]

smaddox 6y ago

I've been a financial backer of Zig for several months now, and plan to continue, because Andrew and the other contributers are pushing language design in directions that no other language is. That being said, Zig's comptime is not a proper replacement for typeclasses/traits. Zig can do both comptime duck typing and vtable-based dispatch, but it cannot do proper bounded polymorphism type checking. It always fully evaluates types before type checking them. This might make it difficult (or impossible?) to provide type checking error messages of similar quality to Rust. I'm not sure if there are any other practical consequences for realistic programs, though. I suspect there might be issues around interface stability gaurantees, though I can't quite put my finger on why.

pron 6y ago
Right, they are only approximately comparable, but the important thing to remember is that features of formalisms are never goals in themselves, but rather means to various ends. The goal is never "to have interfaces/typeclasses/traits" but to be able to specify an algorithm that works for a variety of data structures with shared properties. Moreover, I think it would be a mistake for Zig library authors to try and replicate styles used in other languages. Zig provides sufficient mechanisms for expressing programs, and it will develop its own style. There will be elements that are analogous to those in other lanugages, but not identical. Having said that, I do support a proposal for specifying a type at the parameter declaration with some type -> bool function. I like this quote by Leslie Lamport about comparing formalisms (he talks about specification languages rather than programming languages, but the sentiment is the same): > Comparisons between radically different formalisms tend to cause a great deal of confusion. Proponents of formalism A often claim that formalism B is inadequate because concepts that are fundamental to specifications written with A cannot be expressed with B. Such arguments are misleading. The purpose of a formalism is not to express specifications written in another formalism, but to specify some aspects of some class of computer systems. Specifications of the same system written with two different formalisms are likely to be formally incomparable… Arguments that compare formalisms directly, without considering how those formalisms are used to specify actual systems, are useless.