
Zig 0.3.0 Released - AndyKelley
https://ziglang.org/download/0.3.0/release-notes.html
======
oblio
If Andy's watching, congrats!

Two minor things:

> zig init-lib and init-exe

Wouldn't these be better off as "zig init lib" and "zig init exe"? I.e. do
what git did when it switched from stuff like "git-annex" to "git annex":
switch from compound command names to subcommands. Easier mentally to follow
and remember.

There's also this:

> all control flow occurs exclusively via keywords.

This will probably never happen cause C looms too large in Zig's world, but I
wish "*" and especially the super non-intuitive "&" go the way of the dodo and
some short keywords replace them. Perhaps "ptr" and "deref"? This is
technically just bikeshedding, but look at Rust threads: besides the obvious
#1 difficulty of the borrow checker and ownership, the #2 complaint is that
the syntax is weird due to sigils. "Modern" programming languages don't use
many sigils, if any: Javascript, Python, Java, C#, etc.

It's not fair since those languages are GCed, but most people will be familiar
with them, not with C, these days.

I know that it's doubly unfair since Zig's target is C, so it's expected that
new Zig developers know C, but you want to get new developers wherever you can
get them, in my opinion :)

~~~
simias
The sigil thing is definitively a bikeshed. For one thing besides Python I
don't don't know why you consider that JS, Java or C# don't use many sigils,
these languages just happen not to have C-style pointers so they don't need
that particular bit of syntax.

More generally using C-style syntax means that C and C++ coders will be at
home, while people from other languages will have to familiarize themselves
with the concept anyway, sigil or not.

Beyond that, I don't think I've seen any serious study on the acceptable level
of sigils to maximize productivity and readability in source code, as far as I
can tell it's really just a matter of opinion. Personally I'd take C syntax
over Python every day of the month, and I've written quite a bit of Python. My
only sigil-related problem with C is that '->' should really just be '.' IMO.

~~~
espeed
There's was a talk at StrangeLoop a few years back about a language syntax
being designed based on user feedback from its ongoing usability studies. I'm
on my phone now, but I'll try to find and post the link later when I'm at my
computer if someone else doesn't find it first.

------
audunw
So happy to see this language develop rapidly. I want Zig for simple, rapid
and fun microcontroller development. There's just no satisfying options right
now.

I played around with it some months ago. It was an adventure so to speak. Even
discovered bugs in LLVM itself. Andy was very responsive to bug requests, so I
got a demo working pretty quickly.

I'm hoping to do another pass soon, perhaps contribute a bit to the compiler.

The demo is here: [https://github.com/skyfex/zig-nrf-
demo](https://github.com/skyfex/zig-nrf-demo)

Probably doesn't work anymore.. but that's the way it goes with a developing
language :) That's part of the fun

~~~
ac29
I've had fun writing some stuff in CircuitPython [0] (a fork of MicroPython
mostly geared towards Adafruit microcontroller boards). At the moment it is
geared more towards educational and hobbyist uses, but there is a quite a bit
you can do with it.

[0]
[https://github.com/adafruit/circuitpython](https://github.com/adafruit/circuitpython)

------
crazygringo
Just a small suggestion, but:

> _Zig intends to be so practical that people find themselves using it even if
> they dislike it._

feels awfully condescending to my ears personally, in an _I 'm-smarter-and-
know-better-than-you_ kind of way, even if you didn't intend it like that.

Just my unsolicited $0.02, but I'd recommend a more objective and non-loaded
description something along the lines of "Zig's primary motivation is
practicality, and therefore avoids issues with C such as <x, y, z>".

~~~
edmundhuber
To throw in dissenting opinion: I feel like that gets the point across to C
programmers like me.

------
sephware
Can anyone with more experience/understanding of Zig give an elevator pitch
about why and when I would use Zig? I love the concept of a low level language
that's not C, but the home page doesn't paint a clear picture to me about what
its strengths are and in what situations it really shines, and what trade-offs
it makes to get there.

~~~
jeremycw
The short of it is C without the warts plus a few small quality of life
improvements.

The long of it: The competition right now in this space as I see it is: C,
Rust, C++. Even C++ doesn't fully fit because you have to turn off language
features like exceptions to have the guarantees you need for systems
programming. So in turn.

C hasn't really changed in 40 years so all it's warts are still intact and has
specific pain points that will never be addressed.

C++ conversely has added every language feature plus the kitchen sink over the
past 30 years. People say: "Just don't use the features you don't want", but
that is unrealistic when you have to interoperate with third party libraries
etc. If you have to drop a large portion of the C++ ecosystem to use the
subset of the language you like then you've lost a major benefit of choosing
C++ in the first place.

Rust, while being more thoughtful about it than C++, has provided a large set
of features to work with. It is a much bigger language than C. It's also taken
a very opinionated stance on safety with the borrow checker which causes a
large learning curve and a lot of mental overhead.

Finally Zig is an attempt to be more safe than C where it can without being as
overbearing as Rust. Add just the necessary features that a huge boost to
quality of life while not flooding the programmers mental model of the
language. I think of it as kind of a C+.

~~~
rapsey
Rust's borrow checker does not have a lot of mental overhead while working
once you are moderately proficient.

It imposes design constraints that in the end work out for the better. This is
why Rust users are so fanatical about it.

~~~
jeremycw
> It imposes design constraints that in the end work out for the better.

I feel the jury is still out on this. It does impose design constraints that
remove a certain subclass of errors, whether this correlates to actually
causing better designed programs in the sense of readability, maintainability,
etc. I'm unsure. I understand the desire for this to be true and I feel that
some of the fanaticism around the language is the belief that this is true.
Developers like to have the 'one true way' to solve problems. Go's popularity
I feel is in part because of this as well but achieved it by having a bare
bones language with less options instead of a restrictive compiler. If you
take the 'restrictive compiler' argument to its logical conclusion for a
program that accepts input x and produces output y there would only be one
valid way to code this program. This would be good in the sense that
presumably the compiler has proven that your program works and is correct. On
the other hand though I have no inclination to believe that this program would
be the most understandable, modifiable way to get from x -> y.

~~~
sephware
Also, there are many classes of errors that Rust doesn't help solve, but which
people seem to get the impression that it does aim to solve, which can be
confusing and counterproductive when choosing a language _because of_ the
classes of errors it aims to solve (often a big motivator in both designing
and choosing a language; see Swift and Go).

~~~
vram22
>Also, there are many classes of errors that Rust doesn't help solve, but
which people seem to get the impression that it does aim to solve

What are some of those?

~~~
steveklabnik
The big one is memory leaks. People also assume “race conditions” instead of
“data races.”

~~~
vram22
Thanks for the info. I need to look up the latter point, the difference
between the two. Saw it mentioned in an article or book about Go too.

Looked it up, found these links, for anyone interested:

[https://blog.regehr.org/archives/490](https://blog.regehr.org/archives/490)

[https://stackoverflow.com/questions/11276259/are-data-
races-...](https://stackoverflow.com/questions/11276259/are-data-races-and-
race-condition-actually-the-same-thing-in-context-of-conc)

~~~
steveklabnik
Any time! And yeah, those links are excellent.

~~~
vram22
Cool, good to know :)

------
donpdonp
the amount of development described in detail the release notes is simply
amazing. thanks for your work and i'm excited to see zig continue to progress.

------
edflsafoiewq
How does generic code work in the absence of destructors? Is there an analogue
of psuedo-destructors?

------
unique_id
If anyone is interested, I'm using Zig full-time. I switched from C# to C++
for game development but I had immense difficulty accepting the language, so
when I heard of Zig I gave it a go and I've been very happy with it.

This is a serious project that I'm working on. The 'engine' uses the Vulkan
graphics API, cache efficient design, scales to the number of cores, game
logic is multithreaded, AVX is used, and so on.

I only mention this to hopefully get people interested in Zig. I'm not ready
to share screenshots yet and I'm certainly not going to be advertising my game
here.

~~~
keldaris
I've followed Zig's progress with some enthusiasm, but would have considered
it too immature for a serious project at this point. In that vein, a few
questions about your experience:

1) What's your workflow like in terms of tooling? Coming from C# and C++
people are typically used to great IDE support, debugging and profiling tools,
etc. Zig doesn't have any of that. How do you work around it and do you find
the experience reasonably productive?

2) How do you deal with the language still rapidly evolving? Do you run the
latest nightlies or freeze a particular compiler version and update
periodically?

3) What are the most important things Zig gets you over the traditional
gamedev approach of using a restricted subset of C++ (in some cases literally
just C with function/operator overloading for basic math and a few other
convenience features)?

~~~
unique_id
1) When I programmed in C++ I was using Vim and the YouCompleteMe plugin for
IDE-like features. Now I use Vim + CTags. For CTags I use the following which
uses the Zig standard library to parse Zig code:
[https://github.com/isaachier/ztags](https://github.com/isaachier/ztags). In
the future there will be support for the Language Server Protocol.

2) I git pull every few days to run on the latest compiler. The bugs that I've
hit have been minor inconveniences, nothing serious. I think Andrew would
agree with you though that Zig is probably too immature for a serious project
at this point. The transition to the self-hosted compiler has yet to take
place, that compiler is in its infancy.

3) I'm afraid that my verbal inability will never do Zig justice. The built in
slices and optionals are really nice. Pointers are non-null by default (but
can be undefined). Stack traces on crashes. Much better casting in my opinion
(once I got used to it). Error handling that's similar to Herb's C++
deterministic exception proposal. No headers. Not having to decide between
fast compile times and comfortable printing. Defer statements instead of
destructors or nothing work really well in my opinion. Built in testing (maybe
not something you use much in gamedev). +% means add with overflow, + means
overflow is undefined. Everything feels nicer, that's as good as I can put it.

edit: You can Ctrl+F "pub fn" to browse all public functions. Great when
browsing Github. It's easy to grep for the definition of anything. Overflow
and other undefined behavior is detected in debug mode, this saves me so much
time. Guaranteed inline is nice. No more make/cmake and manually listing which
files to compile.

~~~
keldaris
Thank you for the detailed responses. One, possibly silly, followup question,
since you mentioned using AVX. If I understand correctly, Zig deliberately
avoids macros, metaprogramming and doesn't have operator overloading. Given
those limitations, how do you deal with vector math over different SIMD widths
without insane verbosity? I feel like I'd be tempted to write a simple code
generator before starting on something like that.

~~~
unique_id
Zig has extensive metaprogramming support.

For SIMD I'm using ispc which is a shader-like language/compiler from Intel.
You write your code from the point of view of a single SIMD lane and the
compiler takes care of the rest. Intel kind of screwed the project over with
their stupid naming and terrible website but it's a very cool project. I take
the resulting object file and link it with the rest of the project. This is
very different from trusting a compiler to vectorize your code, with a shading
language you know it's going to vectorize. What's absolutely brilliant is when
you start to use divergent control flow and see how well it handles it.

[https://pharr.org/matt/blog/2018/04/18/ispc-
origins.html](https://pharr.org/matt/blog/2018/04/18/ispc-origins.html)

------
moron4hire
Heh, if you ever came into a place that had used Zig and we're now
transitioning to a different language, your job would be to--
literally--"remove all Zig".

~~~
AndyKelley
Too late. All your codebase are belong to us.

~~~
moron4hire
I would call all the programs "gentlemen" and inform them they were on their
way to destruction

