
Introduction to the Zig Programming Language - AndyKelley
http://andrewkelley.me/post/intro-to-zig.html
======
blt
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...](https://github.com/BSVino/JaiPrimer/blob/master/JaiPrimer.md#data-
oriented-structures)

~~~
AndyKelley
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 :-)

------
lobster_johnson
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
> 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.

------
zvrba
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
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).

------
dalailambda
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
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
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.

------
isaiahg
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
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.

~~~
roryokane
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.

~~~
AndyKelley
Having semicolons introduces simple redundancy to the language. If you leave
off semicolons you introduce more ambiguity, which can make error messages
less clear since it's less obvious to the compiler exactly what was the
mistake the programmer made.

Think of it like a sliding scale: on the far extreme of no redundancy, a typo
could be a runtime error instead of a compile error. On the far extreme of
redundancy, you have to express your code twice in different ways. Having
semicolons is a reasonable balance between the extremes.

~~~
roryokane
I think I understand why semicolons make good error messages easier to
implement. However, I don't see anything that makes that same quality of error
messages _impossible_ in a language without semicolons. It's just a matter of
how much time the language writer is willing to spend on slightly improving
the user experience.

Semicolons help get a better error message for the following typo, if `foo`
can take either 0 or 1 arguments:

    
    
      if (true) {
        foo(;
        bar *= 2;
        baz(
          "first",
          "second",
        );
      }
    

The compiler can easily tell you that you forgot a ) on line 2. If semicolons
were optional, the program would be this:

    
    
      if (true) {
        foo(
        bar *= 2
        baz(
          "first",
          "second",
        )
      }
    

The simplest error message to implement would complain that you forgot a )
somewhere within lines 2 to 7, and also that the argument to `foo` contains
two statements instead of one expression. This error message would be less
helpful.

However, with the semicolonless language, you _could_ still write the compiler
to give the better error message. You could have a heuristic that that this
combination of errors suggests a different error, or you could parse
indentation for error-checking purposes. It would just require more work on
the part of the compiler writer.

------
Solarsail
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
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
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
So basically capnproto built into the language?

------
gnuvince
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
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
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)

------
sjrd
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.

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

~~~
AndyKelley
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.

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

~~~
AndyKelley
(I (tried (once (in (college (but (lisp (is (not (my (style)))))))))))

~~~
stewbrew
Obvious question: How is that worse than

    
    
        I(tried(once(in(college(but(c(is(not(my(style()))))))))))

~~~
AndyKelley
I was just being flippant. It was not a real criticism.

------
m6w6
This looks awesome, but, oh, the irony...

A language to replace C implemented in C++. ;-)

~~~
giancarlostoro
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
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.

