
Zig 0.5.0 Release Notes - shritesh
https://ziglang.org/download/0.5.0/release-notes.html
======
lhorie
Zig looks like a really interesting language. I've been keeping my eye on it,
waiting excitedly for the 1.x milestone.

Out of curiosity, what's the state of the world regarding Zig's stdlib? While
the base language docs seem like they're in a pretty good state, the stdlib is
still largely undocumented. Is this because it's unstable? Or is the lack of
docs there due to lack of time/resources? Would love to get some
clarification. Thanks!

~~~
AndyKelley
[https://github.com/ziglang/zig/wiki/FAQ#where-is-the-
documen...](https://github.com/ziglang/zig/wiki/FAQ#where-is-the-
documentation-for-the-zig-standard-library)

~~~
lhorie
Yeah, I always check that. The part that says "There is no stdlib
documentation yet, but it is planned for the next release" links to a 2015
github issue. That's why I was wondering if it's still a priority or if there
were still high level concerns about stability/curation/etc preventing docs
from being written.

~~~
AndyKelley
It's an unwillingness to implement documentation generation twice. Why do it
in the c++ compiler when the goal is to become self-hosted?

I think there's a good answer to this which is, "because people really, really
need documentation." So I am kicking around ideas of how this can be done
without too much duplicate effort.

~~~
lhorie
I see. Do you think there would be value in having someone just manually
writing some interim docs (perhaps as a wiki) until the time when it can be
properly generated?

This may seem like a weird place to draw experience from, but in my early days
of programming, I've found the PHP docs extremely helpful largely thanks to
community comments sections giving examples of how to do various things. Just
some food for thought.

~~~
AndyKelley
I think that would be problematic because the standard library is still very
unstable. You can see from the release notes just how much changed from 0.4.0.
A wiki page would be outdated right away.

One of the tenets of my development process with Zig is "avoid local
maximums". A wiki for std lib documentation is not the long term solution to
the problem, and so I won't be investing any time into it. All my time is
invested in the long term solution.

------
codetrotter
One thing that immediately stood out to me was the section titled “UEFI
support” [1]. And there are demo projects and examples too. Neat!

[1]: [https://ziglang.org/download/0.5.0/release-notes.html#toc-
UE...](https://ziglang.org/download/0.5.0/release-notes.html#toc-UEFI-Support)

~~~
rvz
Zig + UEFI = Comic Neue in the BIOS.

[0]
[https://twitter.com/andy_kelley/status/1176561072398098432](https://twitter.com/andy_kelley/status/1176561072398098432)

Perhaps I could see some toy ransomware bootkit demanding the user to pay up
or face using your computer with comic neue or comic sans as the default
unchangeable font.

~~~
vanderZwan
> _Comic Neue_

For the uninitiated:

[http://www.comicneue.com/](http://www.comicneue.com/)

As far as Comic Sans-like fonts go it's quite nice

~~~
yellowapple
It's currently my main UI font:
[https://imgur.com/cTLq6Oo.png](https://imgur.com/cTLq6Oo.png)

Pairs nicely with Fantasque Sans Mono (though if there was a more Comic
Sans/Neue-like typeface, I'd set that as my terminal/editor font in a
heartbeat).

------
johnisgood
I might be alone with this thought: Zig seemed really appealing in the
beginning, but now I dislike it more and more with each release. It does not
seem to keep the simplicity of C at all, it has lots of peculiarities, and it
is becoming more and more bloated. I would consider it a C++ replacement at
this point, not a C replacement due to its increasing complexity. One of Zig's
philosophy was simplicity[1], but I do not think it applies now.

[1] [https://github.com/ziglang/zig/wiki/Why-Zig-When-There-is-
Al...](https://github.com/ziglang/zig/wiki/Why-Zig-When-There-is-Already-
CPP,-D,-and-Rust%3F#simplicity)

~~~
rhodysurf
Can you give examples of the peculiarities? I write cpp all day and zig is a
nice change for me because of how simple it is to me

~~~
richardwhiuk
> Zig both signed and unsigned integers have undefined behavior on overflow,
> contrasted to only signed integers in C

make a feature unwanted in C, worse. nice.

~~~
AnIdiotOnTheNet
debug and safe modes in zig disallow overflows entirely unless you
specifically use the wrapping operator to _clearly specify your intent_. These
checks are removed in speed-optimized builds.

In other words, the compiler will enforce that `a + b` does not overflow
through all your testing and wherever you explicitly say such checks are
required, but turns them into nops for you when you desire speed. You can let
the compiler know that you explicitly want wrapping overflow (and not some
undefined kind) using the wrapping operator `a +% b`.

------
svnpenn
Looks like its still lacking in network support:

[https://github.com/ziglang/zig/issues/2007](https://github.com/ziglang/zig/issues/2007)

I wonder though, does it already have socket support? that could be a stopgap
for me. Edit, looks like it doesnt have sockets either:

[https://github.com/ziglang/zig/issues/1271](https://github.com/ziglang/zig/issues/1271)

Edit 2, looks like it does:

[https://github.com/ziglang/zig/blob/5026db1d/lib/std/net.zig...](https://github.com/ziglang/zig/blob/5026db1d/lib/std/net.zig#L219-L247)

[https://github.com/ziglang/zig/blob/5026db1d/lib/std/os.zig#...](https://github.com/ziglang/zig/blob/5026db1d/lib/std/os.zig#L1724-L1748)

~~~
rhodysurf
You can use any c libraries networking or socket implementations in zig but I
think thats as far as it goes at the moment.

~~~
donpdonp
zig's C-interoperability is second to none and using libcurl works great for
networking.

example:
[https://github.com/donpdonp/zootdeck/blob/master/src/net.zig](https://github.com/donpdonp/zootdeck/blob/master/src/net.zig)

~~~
earenndil
Nim and d both have comparable interop, and nim even works with c++.

------
StreamBright
[https://ziglang.org/documentation/master/#Zen](https://ziglang.org/documentation/master/#Zen)
>> Minimize energy spent on coding style.

For me this is sort of important because languages not having standard coding
style end up 10000 coding styles. Rust fmt is an excellent example for
avoiding that. Does anybody use Zig + fmt?

I know they have something.
[https://github.com/ziglang/zig/issues/1523](https://github.com/ziglang/zig/issues/1523)

~~~
steveklabnik
There's a section in this notes about it
[https://ziglang.org/download/0.5.0/release-notes.html#zig-
fm...](https://ziglang.org/download/0.5.0/release-notes.html#zig-fmt)

The end even has a link to a web-based version of it.

~~~
StreamBright
Thanks, I totally missed it.

------
dev_dull
> _Speaking of performance, Zig is faster than C._

These kinds of claims make me so dubious for a language. Also who is trying to
switch from C to get an ever-so-slightly performance improvement? That use-
case goes to specialized hardware such as FPGAs.

~~~
lkey
You picked that quote from the main page, not from the release notes, here is
what directly follows:

* The reference implementation uses LLVM as a backend for state of the art optimizations.

* What other projects call "Link Time Optimization" Zig does automatically.

* For native targets, advanced CPU features are enabled (-march=native), thanks to the fact that Cross-compiling is a first-class use case.

* Carefully chosen undefined behavior. For example, in Zig both signed and unsigned integers have undefined behavior on overflow, contrasted to only signed integers in C. This facilitates optimizations that are not available in C. Zig directly exposes a SIMD vector type, making it easy to write portable vectorized code.

So the argument is "exact same compiler as C/C++, but more opportunities for
optimization thanks to better semantics and better access to native
instructions". This seems reasonable on its face, so care to elaborate on the
doubt?

The arguments for _not_ switching from C are often performance or target
related, so a language that purports to be an alternative to C would want to
point out that those issues aren't a problem.

The reasons to switch away from C are numerous and well documented.

~~~
saagarjha
> For example, in Zig both signed and unsigned integers have undefined
> behavior on overflow, contrasted to only signed integers in C.

Huh, that's a strange choice. What's the safety story for Zig? Are these
always undefined, or is that only in an "unchecked" build?

~~~
AnIdiotOnTheNet
The latter. Zig actually kinda does define this behavior as "`a + b` shall not
overflow" and inserts checks in debug and safe builds for it. To get overflow,
which zig defines as wrapping overflow, you use a different operator and no
check is inserted "`a +% b`". For speed optimized builds, unless you've
explicitly told the compiler to insert checks in that scope, it will turn the
checks into nops.

So, while it is technically correct to say that it has undefined behavior for
overflow, the practical reality is quite different.

~~~
steveklabnik
We do the same thing in Rust, but I think that characterizing this as UB is
misleading, personally. We created a new category, "program error", for this,
to distinguish from UB proper.

I'm not sure if Zig inherited the defined/implementation defined/undefined
hierarchy from C and C++ though.

~~~
snagglegaggle
Undefined as in undefined by language spec. There are various processor
implementations that have different results that are often quite useful. Would
you preclude their use?

~~~
steveklabnik
Right, the key here is that the behavior is defined. That’s why calling it
“undefined behavior” is misleading.

~~~
snagglegaggle
It is defined _if you want to restrict where your program runs_.

~~~
steveklabnik
If something is defined or not is a property of the language specification, as
you stated.

What you’re now bringing up is something different: should a specification
define this behavior, or not? I think you’ve properly identified a trade off,
but mid-identified the details. Defining a behavior here does _privilege_
certain architectures, but it doesn’t make it impossible. It means the
behavior must be replicated in code on some architectures, which is slower.

This is the trade off that Rust (and apparently Zig) are making. This is
informed by the architectures that exist, and which ones are wished to
support. At this point, two’s compliment is overwhelmingly used, and so the
decision was made that defined behavior is worth it. Note the parallel here
with POSIX specifying that CHAR_BIT must be set to 8.

Notably, the situation here is so overwhelming that even C++ is specifying
two’s compliment: C++20 says that signed integers must be. This was recently
voted in. I haven’t read the paper recently and I don’t remember if it changes
the UB rule here or not, but it does define the representation of integers, a
very similar thing that’s the motivation for UB here.

~~~
snagglegaggle
I was holding out for hardware enforced overflow and underflow checking but I
guess it has been abandoned. Thanks for the info. These choices are being made
as was made opposite in C standard deliberations... I am interested to see how
it will work out.

~~~
steveklabnik
The way we’re dealing with that is that there’s room in the spec where we’re
allowed to turn it to “always checked” as a compiler setting, and will if it
ever gets good enough hardware support. We’ll see though!

------
andrewnc
It's an exciting week for programming languages. First Nim, then Zig. Keep up
the great work!

~~~
loudmax
Does anyone here have a good understanding of the relative merits of Zig,
Crystal, and Nim? Especially compared to higher profile languages like Rust
and Go?

All of these languages seem to be statically compiled, and they all seem to
promise both performance and safety. Rust and Go are discussed all the time on
HN, so I expect most of us here have a reasonable notion of their relative
benefits, for example, performance compared to ease of learning.

What about these lesser discussed languages Zig, Nim, and Crystal? Are their
runtime performances comparable to one another? Are they equally safe to
program in? What are their relative strengths? Or does it just come down to
syntax preference?

I think there's value in having a lot of choices to program in, so I'm not
asking which language is "best" any absolute sense. We're better off for
having all of these languages coexisting. I'm just asking if anyone with
experience in the three of them has any insight or impressions of their
relative merits.

~~~
leshow
Zig and Rust both don't have a runtime/GC, they should be on par with
performance in C, meaning they are slightly faster than the others (of course
this all depends). Go is the only one you listed that doesn't have some kind
of parametric polymorphism support (generics). Rust is the only one that will
validate your program is memory safe at compile time, they call this 'data
race freedom'.

I think in the end it's really up to your tastes which you prefer. Have a look
at the tenets of each of the languages and see which resonates with you.

~~~
mratsim
I didn't try Crystal, but Nim is definitely on par with C.

Actually you can use just plain (stack) objects and ptr object and you have no
GC involved.

Pass the flag -d:useMalloc (or just call your preferred allocator) and you
have the full C experience and speed.

~~~
leshow
Maybe, but libraries that you use in Nim will probably use the GC, so will
many functions in the std library (I imagine). Additionally, the binary you
ship will still probably include the runtime & GC. So it's not really fair to
say it's on par with C/Rust, there's reasons to avoid GC besides just
performance. Say you are writing an embedded application for example. I don't
know any Nim, so correct me if I'm wrong.

~~~
nimmer
> not really fair to say it's on par with C/Rust

It is. The GC is inline, thread-local and can be run manually, disabled
completely, or switched to the new owned reference.

------
lkey
The new async/result location stuff reminds me of the _Pin_ concept that Rust
fairly recently adopted. It seems like a pretty huge step forward for the
language. Especially since it's casually mentioned that it also solved "safe
recursion".

I'm curious about the tools zig offers around doing asyc work while
guaranteeing certain invariants, and how the @Frame builtins work with that,
but I'm guessing that's going to be elaborated on in a future post.

------
sysashi
The author also livestreams (I believe on twitch) and publish VODs on youtube,
showcasing new features, updates and whatnot!

I'm quite enjoying watching progress updates, relevant examples and Q&A :)

~~~
jzelinskie
The streams are on Twitch:
[https://www.twitch.tv/andrewrok](https://www.twitch.tv/andrewrok)

------
crudbug
Looks promising.

Can we have a consistent function notation

fn name(a: int, b: int) -> void {}

This also helps with clean functional type arguments.

swift and rust support this.

A single consistent notation will be helpful for new polyglots.

------
flukus
Zig, Crystal, Nim, Rust, Go. It seems like the industry is responding to the
end of moores law and is refocusing on performance. Contrast this with 90's
languages like python, ruby, java and c# where computers were expected to get
exponentially faster and they focused on developer ergonomics instead.

Can anyone familiar with zig tell me how well it works with more macro heavy
libraries? Something like GTK ([https://developer.gnome.org/gtk-
tutorial/stable/c450.html](https://developer.gnome.org/gtk-
tutorial/stable/c450.html)) or something with generics.

------
muktabh
The windows build isn't working for me. Still stuck on 0.4 .

------
FpUser
At the very first glance: what is wrong with

    
    
        function xxx()
    

instead of

    
    
        fn xxx()
    

what are we trying to save here?

Also would be nice to do _import_ instead of _@import_. More readable I think.

Afraid to dig deeper as I do not have time to play with the languages that I
can not yet use in production.

~~~
yellowapple
The @ indicates that the function's built into the compiler itself. Yeah, it
looks ugly, but it's nice to be able to visually identify "okay, yeah, this
didn't come from any of my imports", and also (I'd assume) avoids cases where
one might inadvertently shadow them with their own function definitions.

Re: fn v. function (v. fun v. def v. defun v. defn v. define v. proc v. sub v.
label v. the cornucopia of other options here): I don't think it's all that
big of a deal. fn does happen to be short, which means more actually-useful
information can fit into the same line, so I guess that's nice. The choice of
keyword for function definition feels like a really weird criticism.

