12 ms·

Introduction to the Zig Programming Language

98 points by AndyKelley 11y ago

m6w6 11y ago
This looks awesome, but, oh, the irony... A language to replace C implemented in C++. ;-)
- AndyKelley 11y ago
  What's ironic about that?
- giancarlostoro 11y ago
  Plenty of languages that have been used instead of C for a while have been coded in C++. I don't see the issue since he's using LLVM, which I believe is a wise decision.
  - m6w6 11y ago
    It's not an issue. Did anyone here watch the video? I mean the author said a lot of cool things about being more pragmatic and all that stuff, while implementing it in LLVM/C++, what may be, as you say, a wise decision. There's no assignment of guilt, I just found it ironic.
- adrusi 11y ago
  Note that all major C compilers — gcc, clang and msvc (also icc, if that counts as major) — are written in C++.
- vmorgulis 11y ago
  Github says it's C++ because of the .hpp/.cpp extensions but if you look at the code you will see it is more C than C++. Maybe it is because of LLVM build system?
  - iherbig 11y ago
    As you can see here[1], it's because the author utilizes C++'s templates and C++11's atomics. But eschews the rest of C++ in favor of C using specific build flags. [1]http://genesisdaw.org/post/progress-so-far.html http://genesisdaw.org/post/progress-so-far.html
Solarsail 11y ago
I wonder how feasible it would be to decouple data size from type & overflow semantics, a la this comment: https://news.ycombinator.com/item?id=7103347 https://news.ycombinator.com/item?id=7103347
- AndyKelley 11y ago
  The comment you linked is insightful and the commenter is indeed in the target audience for the language. One point I didn't understand is this: "decoupling of on-the-wire layout from in-memory layout". What does that mean? This is good stuff, and I plan to work on some embedded projects to experience firsthand the needs of this kind of project.
  - versteegen 11y ago
    On-the-wire refers to serialisation (writing to file or socket). It would be great to be able to specify both in-memory layout and serialised layout: the former typically contains padding, which is a waste of space in the later. There may also be endianness differences, different datatypes, etc. That would remove the need to manually write de/serialisation routines if they should differ.
    - chubot 11y ago
      So basically capnproto built into the language?
  - adrusi 11y ago
    I think that commenter meant that he wants to be able to separately declare physical and logicical layout of datatypes, and be able to assign multiple physical representations to a single logical representation, for different places they might be stored. I'm not sure how I understand how this would offer a benefit over just explicitly converting between identical logical representations with different physical representations, and it would definitely increase complexity.
  - deleted 11y ago
    [deleted]
lobster_johnson 11y ago
Looks very interesting. The author is apparently a contributor to Piston [1], which is written in Rust, and the language seems to share some similarities with Rust. [1] http://www.piston.rs http://www.piston.rs
AnimalMuppet 11y ago
> At the end of the day, all that really matters is whether the language helped you do what you were trying to do better than any other language. Absolutely. But one problem that new languages face is that libraries are part of how much the language helps you do what you are trying to do. So to gain any traction, a new language needs to have libraries... > Complete C ABI Compatibility ... and there they are! Nicely done, though this is a fairly common solution these days. Or, it could be regarded as a cheat, because you don't have your own library... > Alternative Standard Library ... and another point of criticism dies. I also like the difference between debug and release builds. All in all, this looks pretty nice.
blt 11y ago
Cool project. The "more pragmatic than C" design goal reminds me of game developer Johnathan Blow's Jai language [1]. It seems like Zig is still in very early stage, are you planning to incorporate any Jai-like features? I especially like its SOA keyword for quickly changing data layouts [2]. I really like this corner of the language design world. People always say that C is too entrenched and none of these languages are compelling enough to make a large number of developers switch, but I disagree. Someone said that C and Lisp are two local optima in the space of programming languages... I think that Lisp probably is, but C is only near a local optimum. There is a true local optimum remaining to be found. [1] https://github.com/BSVino/JaiPrimer/blob/master/JaiPrimer.md https://github.com/BSVino/JaiPrimer/blob/master/JaiPrimer.md [2] https://github.com/BSVino/JaiPrimer/blob/master/JaiPrimer.md#data-oriented-structures https://github.com/BSVino/JaiPrimer/blob/master/JaiPrimer.md...
- AndyKelley 11y ago
  I wrote this elsewhere in response to a similar question: > I've been following the project, and he has some great ideas that I plan to shamelessly copy such as Struct Of Array support. Running arbitrary code at compile time is on the table, but I haven't figured everything out about it yet. Jonathan Blow is an interesting character. I have a lot of respect for him, but I don't always agree with him. I feel like his perspective is insightful but also limited in some ways. I'm sure the same is true for myself, but all that is to say, our respective languages will be (and already are) different enough to warrant being different projects. For example, one of my goals is "friendly to open source package maintainers (such as Debian)". This entails things like keeping a meticulous record of how to bootstrap the compiler without compromising security, having a reproducible build, providing ways for the maintainers to configure various things, etc. Based on what I know about Jon, he'll either be completely apathetic about package maintainers, or potentially even have a hostile attitude. > Also no spoilers for The Witness please. I'm waiting until it comes out on Linux to play :-)
isaiahg 11y ago
Looks pretty promising actually. I love the methodology laid out for the language. I just wish more languages would move away from the C syntax. While we're all used to that syntax I think Python has been more successful in demonstrating the practicality of whitespace for readability. And considering that readability is a major factor for this language I think it's a shame it doesn't use whitespace more effectively.
- nordsieck 11y ago
  The big downside to using whitespace in this way is that if you are trying to generate python, especially from another language, it's a nightmare. Explicit delimiters make meta-programming much easier.
  - anentropic 11y ago
    yeah but how often do you do that though...
    - PeCaN 11y ago
      If the C preprocessor counts, I do that every day. :-) Otherwise, it's one of those things that you don't realize how useful it is until you can't do it. But not often, and ideally a Sufficiently Expressive Language wouldn't need code generation—but this is targeting C's niche, not Haskell's.
  - roryokane 11y ago
    That sounds like a good reason to not use indentation – since Zig is so low-level, it is a good candidate for machine-generation. But I can’t think of a good reason for Zig to separate statements with semicolons instead of unescaped newlines. Zig-generators should be able to generate "\n" as easily as ";". The only reason to keep semicolons I can think of is to look familiar to C programmers, so as not to scare them off. I’m not very familiar with that demographic, but I think most of them would be fine with it, especially if they have used other semicolon-less languages. Semicolons, which are present on about 50% of lines, add visual noise and the cognitive load of remembering to type them.
sova 11y ago
It's cool. Do you tinker in any lispy dialects?
- AndyKelley 11y ago
  (I (tried (once (in (college (but (lisp (is (not (my (style)))))))))))
  - stewbrew 11y ago
    Obvious question: How is that worse than I(tried(once(in(college(but(c(is(not(my(style()))))))))))
    - ludston 11y ago
      Also, you can trivially define something like: (<- I tried once in college but lisp is not my style)
    - voaie 11y ago
      Because you hardly write that way in C.
    - AndyKelley 11y ago
      I was just being flippant. It was not a real criticism.
dalailambda 11y ago
The thing I like C for is the simplicity. Writing C after working in a very verbose language for a while is refreshing. That said, my few wishes for a C replacement would be generics, methods, and namespacing. The last two are to avoid funky naming schemes everywhere. Maintaining the proper low level control and simplicity would be a top priority though. Overall this project looks interesting. I'm interested to see where it goes in the future and what design trade offs end up being implemented.
- lsd5you 11y ago
  I don't really understand this point of view. Is C not (very) verbose? Even if it's just because of the manual memory management.
  - dalailambda 11y ago
    In a way it's verbose, but less so on a syntax level. There's no need to deal with interfaces, classes, or exceptions. The boilerplate code you write tends to serve a practical purpose, as opposed to a syntactical one. Sure you have to deal with a lot of error handling and memory management yourself, but the language doesn't get in your way or create much friction.
- ori_b 11y ago
  > That said, my few wishes for a C replacement would be generics, methods, and namespacing. I think my pet language (Myrddin) actually has you almost covered. It doesn't have methods, but it does have traits, which allow similar things at compile time. https://github.com/oridb/mc https://github.com/oridb/mc You have an example of generics and traits here, in the std namespace: https://github.com/oridb/mc/blob/master/lib/std/htab.myr https://github.com/oridb/mc/blob/master/lib/std/htab.myr https://github.com/oridb/mc/blob/master/lib/std/iterutil.myr https://github.com/oridb/mc/blob/master/lib/std/iterutil.myr
gnuvince 11y ago
What is Zig's position on memory safety? Rust is, correctly IMO, memory-safe even if that can cause some discomforts when programming (I hear this is temporary, and mostly subsides as one gains a better understanding of lifetimes and borrows). On the other hand, Jonathan Blow's Jai eschews language-guaranteed memory safety in order to allow the programmer greater freedom, but does nothing to prevent use-after-free, double-free, null deref, etc. (Edit: this is based on my understanding of his language as it was in his last demo. I don't know what plans he has for the future, but I think that with him calling Rust a "big idea" language and rejecting that philosophy, we should not expect Jai to do much to prevent incorrect manipulation of memory.) If we take those two languages as the extremities of a spectrum, where would you put Zig on that spectrum?
- AndyKelley 11y ago
  Closer to Jai. That's all I really have in response to the question though. It's a bit of a simplistic measurement. To get a better feel for the answer you could browse the source code to the Tetris game implemented in Zig linked in the article.
  - roryokane 11y ago
    Direct link to the Tetris game’s source code: https://github.com/andrewrk/tetris/tree/master/src https://github.com/andrewrk/tetris/tree/master/src
- adrusi 11y ago
  Rust optimizes for correct memory management. Its borrow checker and safe/unsafe distinction makes the easiest option to make most often the one that is safe. Jai optimizes for performant memory management. Several of its features, such as SOA pointers, make organizing your data to take advantage of the processor cache easier if not as easy as managing memory in any other way. It looks like Zig optimizes for simple memory management. Without all the bells an whistles the other languages offer, the easiest way to manage your memory is the most obvious way. Which is good from a prinicple-of-least-surprise perspective.
panic 11y ago
Is there a plan to add a generic resizable array type? That's probably the number one thing I miss in C.
- AndyKelley 11y ago
  Good question. I'm going to see how well this works as part of the standard library, since it would have to allocate memory. And then operations like append or resize could return an error (since memory allocation can fail), and I want to make sure the semantics for that are reasonable. That and a Map data structure I want to make sure have convenient semantics since these primitives are used in many software applications.
sjrd 11y ago
It's quite funny how much the debug vs release builds resemble the fastOpt and fullOpt stages of Scala.js. Except that fastOpt actually produces decent runtime performance thanks to incremental whole-program optimizations. But time spent too compile and undefined behavior handling are very much the same.
zvrba 11y ago
There are many new C ripoffs, but nobody seems to acknowledge Cyclone (https://cyclone.thelanguage.org/ https://cyclone.thelanguage.org/) which is a lot older. It was even backed by a corporation (AT&T), but never succeeded. I wonder why.
- AndyKelley 11y ago
  Maybe it has something to do with this: > Cyclone is no longer supported; the core research project has finished and the developers have moved on to other things. (Several of Cyclone's ideas have made their way into Rust.) Cyclone's code can be made to work with some effort, but it will not build out of the box on modern (64 bit) platforms).

98 points by AndyKelley 11y ago

m6w6 11y ago

This looks awesome, but, oh, the irony... A language to replace C implemented in C++. ;-)

AndyKelley 11y ago
What's ironic about that?
giancarlostoro 11y ago
Plenty of languages that have been used instead of C for a while have been coded in C++. I don't see the issue since he's using LLVM, which I believe is a wise decision.
- m6w6 11y ago
  It's not an issue. Did anyone here watch the video? I mean the author said a lot of cool things about being more pragmatic and all that stuff, while implementing it in LLVM/C++, what may be, as you say, a wise decision. There's no assignment of guilt, I just found it ironic.
adrusi 11y ago
Note that all major C compilers — gcc, clang and msvc (also icc, if that counts as major) — are written in C++.
vmorgulis 11y ago
Github says it's C++ because of the .hpp/.cpp extensions but if you look at the code you will see it is more C than C++. Maybe it is because of LLVM build system?
- iherbig 11y ago
  As you can see here[1], it's because the author utilizes C++'s templates and C++11's atomics. But eschews the rest of C++ in favor of C using specific build flags. [1]http://genesisdaw.org/post/progress-so-far.html http://genesisdaw.org/post/progress-so-far.html

Solarsail 11y ago

I wonder how feasible it would be to decouple data size from type & overflow semantics, a la this comment: https://news.ycombinator.com/item?id=7103347 https://news.ycombinator.com/item?id=7103347

AndyKelley 11y ago
The comment you linked is insightful and the commenter is indeed in the target audience for the language. One point I didn't understand is this: "decoupling of on-the-wire layout from in-memory layout". What does that mean? This is good stuff, and I plan to work on some embedded projects to experience firsthand the needs of this kind of project.
- versteegen 11y ago
  On-the-wire refers to serialisation (writing to file or socket). It would be great to be able to specify both in-memory layout and serialised layout: the former typically contains padding, which is a waste of space in the later. There may also be endianness differences, different datatypes, etc. That would remove the need to manually write de/serialisation routines if they should differ.
  - chubot 11y ago
    So basically capnproto built into the language?
- adrusi 11y ago
  I think that commenter meant that he wants to be able to separately declare physical and logicical layout of datatypes, and be able to assign multiple physical representations to a single logical representation, for different places they might be stored. I'm not sure how I understand how this would offer a benefit over just explicitly converting between identical logical representations with different physical representations, and it would definitely increase complexity.
- deleted 11y ago
  [deleted]

lobster_johnson 11y ago

Looks very interesting. The author is apparently a contributor to Piston [1], which is written in Rust, and the language seems to share some similarities with Rust. [1] http://www.piston.rs http://www.piston.rs

AnimalMuppet 11y ago

> At the end of the day, all that really matters is whether the language helped you do what you were trying to do better than any other language. Absolutely. But one problem that new languages face is that libraries are part of how much the language helps you do what you are trying to do. So to gain any traction, a new language needs to have libraries... > Complete C ABI Compatibility ... and there they are! Nicely done, though this is a fairly common solution these days. Or, it could be regarded as a cheat, because you don't have your own library... > Alternative Standard Library ... and another point of criticism dies. I also like the difference between debug and release builds. All in all, this looks pretty nice.

blt 11y ago

Cool project. The "more pragmatic than C" design goal reminds me of game developer Johnathan Blow's Jai language [1]. It seems like Zig is still in very early stage, are you planning to incorporate any Jai-like features? I especially like its SOA keyword for quickly changing data layouts [2]. I really like this corner of the language design world. People always say that C is too entrenched and none of these languages are compelling enough to make a large number of developers switch, but I disagree. Someone said that C and Lisp are two local optima in the space of programming languages... I think that Lisp probably is, but C is only near a local optimum. There is a true local optimum remaining to be found. [1] https://github.com/BSVino/JaiPrimer/blob/master/JaiPrimer.md https://github.com/BSVino/JaiPrimer/blob/master/JaiPrimer.md [2] https://github.com/BSVino/JaiPrimer/blob/master/JaiPrimer.md#data-oriented-structures https://github.com/BSVino/JaiPrimer/blob/master/JaiPrimer.md...

AndyKelley 11y ago
I wrote this elsewhere in response to a similar question: > I've been following the project, and he has some great ideas that I plan to shamelessly copy such as Struct Of Array support. Running arbitrary code at compile time is on the table, but I haven't figured everything out about it yet. Jonathan Blow is an interesting character. I have a lot of respect for him, but I don't always agree with him. I feel like his perspective is insightful but also limited in some ways. I'm sure the same is true for myself, but all that is to say, our respective languages will be (and already are) different enough to warrant being different projects. For example, one of my goals is "friendly to open source package maintainers (such as Debian)". This entails things like keeping a meticulous record of how to bootstrap the compiler without compromising security, having a reproducible build, providing ways for the maintainers to configure various things, etc. Based on what I know about Jon, he'll either be completely apathetic about package maintainers, or potentially even have a hostile attitude. > Also no spoilers for The Witness please. I'm waiting until it comes out on Linux to play :-)

isaiahg 11y ago

Looks pretty promising actually. I love the methodology laid out for the language. I just wish more languages would move away from the C syntax. While we're all used to that syntax I think Python has been more successful in demonstrating the practicality of whitespace for readability. And considering that readability is a major factor for this language I think it's a shame it doesn't use whitespace more effectively.

nordsieck 11y ago
The big downside to using whitespace in this way is that if you are trying to generate python, especially from another language, it's a nightmare. Explicit delimiters make meta-programming much easier.
- anentropic 11y ago
  yeah but how often do you do that though...
  - PeCaN 11y ago
    If the C preprocessor counts, I do that every day. :-) Otherwise, it's one of those things that you don't realize how useful it is until you can't do it. But not often, and ideally a Sufficiently Expressive Language wouldn't need code generation—but this is targeting C's niche, not Haskell's.
- roryokane 11y ago
  That sounds like a good reason to not use indentation – since Zig is so low-level, it is a good candidate for machine-generation. But I can’t think of a good reason for Zig to separate statements with semicolons instead of unescaped newlines. Zig-generators should be able to generate "\n" as easily as ";". The only reason to keep semicolons I can think of is to look familiar to C programmers, so as not to scare them off. I’m not very familiar with that demographic, but I think most of them would be fine with it, especially if they have used other semicolon-less languages. Semicolons, which are present on about 50% of lines, add visual noise and the cognitive load of remembering to type them.

sova 11y ago

It's cool. Do you tinker in any lispy dialects?

AndyKelley 11y ago
(I (tried (once (in (college (but (lisp (is (not (my (style)))))))))))
- stewbrew 11y ago
  Obvious question: How is that worse than I(tried(once(in(college(but(c(is(not(my(style()))))))))))
  - ludston 11y ago
    Also, you can trivially define something like: (<- I tried once in college but lisp is not my style)
  - voaie 11y ago
    Because you hardly write that way in C.
  - AndyKelley 11y ago
    I was just being flippant. It was not a real criticism.

dalailambda 11y ago

The thing I like C for is the simplicity. Writing C after working in a very verbose language for a while is refreshing. That said, my few wishes for a C replacement would be generics, methods, and namespacing. The last two are to avoid funky naming schemes everywhere. Maintaining the proper low level control and simplicity would be a top priority though. Overall this project looks interesting. I'm interested to see where it goes in the future and what design trade offs end up being implemented.

lsd5you 11y ago
I don't really understand this point of view. Is C not (very) verbose? Even if it's just because of the manual memory management.
- dalailambda 11y ago
  In a way it's verbose, but less so on a syntax level. There's no need to deal with interfaces, classes, or exceptions. The boilerplate code you write tends to serve a practical purpose, as opposed to a syntactical one. Sure you have to deal with a lot of error handling and memory management yourself, but the language doesn't get in your way or create much friction.
ori_b 11y ago
> That said, my few wishes for a C replacement would be generics, methods, and namespacing. I think my pet language (Myrddin) actually has you almost covered. It doesn't have methods, but it does have traits, which allow similar things at compile time. https://github.com/oridb/mc https://github.com/oridb/mc You have an example of generics and traits here, in the std namespace: https://github.com/oridb/mc/blob/master/lib/std/htab.myr https://github.com/oridb/mc/blob/master/lib/std/htab.myr https://github.com/oridb/mc/blob/master/lib/std/iterutil.myr https://github.com/oridb/mc/blob/master/lib/std/iterutil.myr

gnuvince 11y ago

What is Zig's position on memory safety? Rust is, correctly IMO, memory-safe even if that can cause some discomforts when programming (I hear this is temporary, and mostly subsides as one gains a better understanding of lifetimes and borrows). On the other hand, Jonathan Blow's Jai eschews language-guaranteed memory safety in order to allow the programmer greater freedom, but does nothing to prevent use-after-free, double-free, null deref, etc. (Edit: this is based on my understanding of his language as it was in his last demo. I don't know what plans he has for the future, but I think that with him calling Rust a "big idea" language and rejecting that philosophy, we should not expect Jai to do much to prevent incorrect manipulation of memory.) If we take those two languages as the extremities of a spectrum, where would you put Zig on that spectrum?

AndyKelley 11y ago
Closer to Jai. That's all I really have in response to the question though. It's a bit of a simplistic measurement. To get a better feel for the answer you could browse the source code to the Tetris game implemented in Zig linked in the article.
- roryokane 11y ago
  Direct link to the Tetris game’s source code: https://github.com/andrewrk/tetris/tree/master/src https://github.com/andrewrk/tetris/tree/master/src
adrusi 11y ago
Rust optimizes for correct memory management. Its borrow checker and safe/unsafe distinction makes the easiest option to make most often the one that is safe. Jai optimizes for performant memory management. Several of its features, such as SOA pointers, make organizing your data to take advantage of the processor cache easier if not as easy as managing memory in any other way. It looks like Zig optimizes for simple memory management. Without all the bells an whistles the other languages offer, the easiest way to manage your memory is the most obvious way. Which is good from a prinicple-of-least-surprise perspective.

panic 11y ago

Is there a plan to add a generic resizable array type? That's probably the number one thing I miss in C.

AndyKelley 11y ago
Good question. I'm going to see how well this works as part of the standard library, since it would have to allocate memory. And then operations like append or resize could return an error (since memory allocation can fail), and I want to make sure the semantics for that are reasonable. That and a Map data structure I want to make sure have convenient semantics since these primitives are used in many software applications.

sjrd 11y ago

It's quite funny how much the debug vs release builds resemble the fastOpt and fullOpt stages of Scala.js. Except that fastOpt actually produces decent runtime performance thanks to incremental whole-program optimizations. But time spent too compile and undefined behavior handling are very much the same.

zvrba 11y ago

There are many new C ripoffs, but nobody seems to acknowledge Cyclone (https://cyclone.thelanguage.org/ https://cyclone.thelanguage.org/) which is a lot older. It was even backed by a corporation (AT&T), but never succeeded. I wonder why.

AndyKelley 11y ago
Maybe it has something to do with this: > Cyclone is no longer supported; the core research project has finished and the developers have moved on to other things. (Several of Cyclone's ideas have made their way into Rust.) Cyclone's code can be made to work with some effort, but it will not build out of the box on modern (64 bit) platforms).