6 ms·

Zig 0.6.0 Release Notes

131 points by alvivi 6y ago

frfl 6y ago
Disclosure: I'm not a seasoned c/c++ developer. Just started working with just 3 days ago using 0.0.5 release, it's a young language, but very nice to work with even now. Just starting to do more non-trivial things, but it's a nice alternative to doing stuff with c. Managed to do most of what I could with c after some trial and error and using the offical docs, including using C libraries without much issue. Great work Andrew and everyone else working on Zig!
mouldysammich 6y ago
I wrote a small thing with gtk and zig a while ago, it feels like magic to just import a C header and have it work, and the experience is generally very good, especially for such a young language, and any problems i had figuring things out, I found the community very friendly in helping me.
jswny 6y ago
One very cool feature of Zig is that it supports calling async/await from any function [1], not just async functions, which avoids the famous function coloring problem altogether. [1] https://ziglang.org/#Concurrency-via-Async-Functions https://ziglang.org/#Concurrency-via-Async-Functions
- Arnavion 6y ago
  I believe function coloring has never been about syntax but about semantics. It's not possible to yield while waiting for an async function to resolve without being async yourself. And if you have a choice between an async and a sync function that you could call from your async function, you should prefer to call the async one to avoid stalling whatever executor is driving your function. Zig isn't avoiding it; it's impossible to avoid. Zig is just inferring the async-ness of the function automatically without you needing to write a keyword for it.
- moonchild 6y ago
  > function coloring problem If you haven't heard of it: https://journal.stuffwithstuff.com/2015/02/01/what-color-is-your-function/ https://journal.stuffwithstuff.com/2015/02/01/what-color-is-... Highlight: > Wanna know one [programming language] that doesn’t [have this problem]? Java. I know right? How often do you get to say, “Yeah, Java is the one that really does this right.”? But there you go. In their defense, they are actively trying to correct this oversight by moving to futures and async IO. It’s like a race to the bottom.
- qqssccfftt 6y ago
  I think function colouring is a positive thing. A synchronous function cannot yield; so calling an asynchronous function from it doesn't make sense since those cannot yield either.
  - notacoward 6y ago
    A synchronous function cannot yield, but it can make sure another thread is available to take its place before it issues a blocking syscall. If properly constructed, synchronous stdlib functions would be safe to call from async functions. Any "executor" implementation that uses a fixed-size thread pool and is vulnerable to all threads in that pool being tied up this way at once is BROKEN.
zamadatix 6y ago
I'm happy to see Zig moving along. I've been using my extra spare time the last couple of weeks to play with it and it's been fun. Documentation is still sparse but there is a whole lot more of it both in general and on the stdlib (zig test cases code is still the best place to figure out the stdlib IMO). Some things just feel "right" without having to give up access to the memory; a good example being arbitrary width integers being used in packed structs to create file/network headers without having to manually bit-twiddle every 4 bit field. Cross compiling is really as easy as it says on the tin and the standard library isn't afraid to include things like net and unicode but at the same time doesn't feel like it tries to throw the kitchen sink in too. Unfortunately it is still very much the 0.x the name implies. Taking the above example defining 2 u129 or larger and trying to multiply them results in an error while compiling about it not being supported yet. Packed struct items that cross word boundaries result in a broken struct that contains a size larger than the data (which breaks pretty much all code that tries to use it due to size/type checking). Also due to comptime being as big of an idea as it is not everything works quite yet like const example: f64 = std.math.sin(4) * std.math.sin(2) being a compile time error since sin isn't defined for comptime floats yet. Like I said it's definitely fun to play with but it's still quite a few releases away from "is this a compiler bug or did the documentation skim over something I'm just supposed to know" no longer being a problem so if that's not your cup of tea best to just watch the release notes over the next year or two.
Sphax 6y ago
Congrats to the team. I've been using Zig for about a month now for personal projects and it's been fun. My experience is mostly in Go and Java and I've dabbled in C a couple of times, but I found Zig the language quite easy to understand. Things I like the most about Zig (for now, I haven't tried everything): * error handling * optionals * tagged unions * meta programming * zig fmt The API documentation of the std lib is still sparse though, I find it's best to search directly in the code to understand how to use it. Looking forward to try the async functionality.
jessicahargis 6y ago
Thank you for working so tirelessly on this, Andy! I’ve seen first hand the blood, sweat and tears you’ve put into Zig. I’m so happy to be able to support your dream, a dream that is really meant for making other people’s lives better! Keep on keeping on!
BubRoss 6y ago
There are hundreds of changes listed here and still no mention of fixing the fact that zig purposely errors out on tabs and carriage returns. This might sound too ridiculous to believe, but if you use tabs or save a file out of windows text editor with normal settings, zig just won't compile. It would be trivial to do what every other compiler in history does, but they want to screw with windows users or anyone you uses tabs for some philosophical reason.
- htfy96 6y ago
  Nim also disallows tab: https://play.nim-lang.org/#ix=2hW9 https://play.nim-lang.org/#ix=2hW9
  - platinumrad 6y ago
    As does F#.
- dbsights 6y ago
  This is the reason I can't stand zig: its so aggressively opinionated about something that doesn't matter at all.
- zamadatix 6y ago
  Run "zig fmt" before "zig build-exe" and it's not a problem. Even Notepad supports unix line endings these days.
  - BubRoss 6y ago
    Or zig could do what every other compiler does and work by default. Why would I invest time in a user hostile language?
    - zamadatix 6y ago
      Ever used or read about Fortran, Haskell, or Python? The idea that whitespace does not matter and will just be handled as-is is and has been a language design choice before and after Zig regardless how many times you pose the question. That Zig or any other language did not make the choice to treat whitespace the way you'd prefer in the compiler and instead left that it to the formatter does not make them "user hostile". The Zig docs link to the reasons they made the choice not to support varying whitespace (and other character and syntax choices), if you don't like those reasons feel free not to use it but it's a bit rude to make it out like they did it to "screw Windows users" when it's neither technically true nor the actual motive. This is all coming from a guy who has only messed with Zig on a Windows box with a preference for tabs over spaces (except post indent alignment). Zig fmt works great, haven't had an issue, less difficult to get going than mingw or vs that's for sure.
magv 6y ago
I am continuously surprised by the amount of work zig committers manage to put out every release. It is actually inspiring. How do they get to appear so productive? Anyway, here's a nitpick. In this release they've removed varargs, and now this is how a printf call looks like in zig: std.debug.warn("{}+{} is {}\n", .{1, 1, 1 + 1}); The ergonomics of typing .{} for every print seems pretty awful if you're a heavy user of debug printing. I was hoping that maybe some sort of a syntax sugar is planned so that tuples could be used without .{} -- emulating varargs, but the bug tracker doesn't turn up anything in that direction. In the previous release (0.5.0) one didn't need the .{}, but instead integer literals needed explicit casts, because the vararg implementation was limited: std.debug.warn("{}+{} is {}\n", i32(1), i32(1), i32(1 + 1)); Both of these options seem like a regression compared to the usual printf("%d+%d is %d\n", 1, 1, 1 + 1); ... and there doesn't seem to be a way to work around it by e.g. using a function overloaded in the number of arguments (no such thing in zig) or some preprocessor tricks (again, no such thing). PS. I'm also surprised to find out that zig seems to take 2.6 seconds to compile the above example.
- zamadatix 6y ago
  To be honest typing and remembering %d %f %c %s etc. seems like more hassle than typing {} and typing it for every case. I think the real gotchas are that { is escaped as {{ and } as }} instead of \{ and \} (though it does follow from the old %%) and you must either include , .{} or rewrite the function call to something significantly different to do unformatted print.
- dimator 6y ago
  Fwiw, the "{}" formatting is common in python, so that might be a reason they went that route.

131 points by alvivi 6y ago

frfl 6y ago

Disclosure: I'm not a seasoned c/c++ developer. Just started working with just 3 days ago using 0.0.5 release, it's a young language, but very nice to work with even now. Just starting to do more non-trivial things, but it's a nice alternative to doing stuff with c. Managed to do most of what I could with c after some trial and error and using the offical docs, including using C libraries without much issue. Great work Andrew and everyone else working on Zig!

mouldysammich 6y ago

I wrote a small thing with gtk and zig a while ago, it feels like magic to just import a C header and have it work, and the experience is generally very good, especially for such a young language, and any problems i had figuring things out, I found the community very friendly in helping me.

jswny 6y ago

One very cool feature of Zig is that it supports calling async/await from any function [1], not just async functions, which avoids the famous function coloring problem altogether. [1] https://ziglang.org/#Concurrency-via-Async-Functions https://ziglang.org/#Concurrency-via-Async-Functions

Arnavion 6y ago
I believe function coloring has never been about syntax but about semantics. It's not possible to yield while waiting for an async function to resolve without being async yourself. And if you have a choice between an async and a sync function that you could call from your async function, you should prefer to call the async one to avoid stalling whatever executor is driving your function. Zig isn't avoiding it; it's impossible to avoid. Zig is just inferring the async-ness of the function automatically without you needing to write a keyword for it.
moonchild 6y ago
> function coloring problem If you haven't heard of it: https://journal.stuffwithstuff.com/2015/02/01/what-color-is-your-function/ https://journal.stuffwithstuff.com/2015/02/01/what-color-is-... Highlight: > Wanna know one [programming language] that doesn’t [have this problem]? Java. I know right? How often do you get to say, “Yeah, Java is the one that really does this right.”? But there you go. In their defense, they are actively trying to correct this oversight by moving to futures and async IO. It’s like a race to the bottom.
qqssccfftt 6y ago
I think function colouring is a positive thing. A synchronous function cannot yield; so calling an asynchronous function from it doesn't make sense since those cannot yield either.
- notacoward 6y ago
  A synchronous function cannot yield, but it can make sure another thread is available to take its place before it issues a blocking syscall. If properly constructed, synchronous stdlib functions would be safe to call from async functions. Any "executor" implementation that uses a fixed-size thread pool and is vulnerable to all threads in that pool being tied up this way at once is BROKEN.

zamadatix 6y ago

I'm happy to see Zig moving along. I've been using my extra spare time the last couple of weeks to play with it and it's been fun. Documentation is still sparse but there is a whole lot more of it both in general and on the stdlib (zig test cases code is still the best place to figure out the stdlib IMO). Some things just feel "right" without having to give up access to the memory; a good example being arbitrary width integers being used in packed structs to create file/network headers without having to manually bit-twiddle every 4 bit field. Cross compiling is really as easy as it says on the tin and the standard library isn't afraid to include things like net and unicode but at the same time doesn't feel like it tries to throw the kitchen sink in too. Unfortunately it is still very much the 0.x the name implies. Taking the above example defining 2 u129 or larger and trying to multiply them results in an error while compiling about it not being supported yet. Packed struct items that cross word boundaries result in a broken struct that contains a size larger than the data (which breaks pretty much all code that tries to use it due to size/type checking). Also due to comptime being as big of an idea as it is not everything works quite yet like const example: f64 = std.math.sin(4) * std.math.sin(2) being a compile time error since sin isn't defined for comptime floats yet. Like I said it's definitely fun to play with but it's still quite a few releases away from "is this a compiler bug or did the documentation skim over something I'm just supposed to know" no longer being a problem so if that's not your cup of tea best to just watch the release notes over the next year or two.

Sphax 6y ago

Congrats to the team. I've been using Zig for about a month now for personal projects and it's been fun. My experience is mostly in Go and Java and I've dabbled in C a couple of times, but I found Zig the language quite easy to understand. Things I like the most about Zig (for now, I haven't tried everything): * error handling * optionals * tagged unions * meta programming * zig fmt The API documentation of the std lib is still sparse though, I find it's best to search directly in the code to understand how to use it. Looking forward to try the async functionality.

jessicahargis 6y ago

Thank you for working so tirelessly on this, Andy! I’ve seen first hand the blood, sweat and tears you’ve put into Zig. I’m so happy to be able to support your dream, a dream that is really meant for making other people’s lives better! Keep on keeping on!

BubRoss 6y ago

There are hundreds of changes listed here and still no mention of fixing the fact that zig purposely errors out on tabs and carriage returns. This might sound too ridiculous to believe, but if you use tabs or save a file out of windows text editor with normal settings, zig just won't compile. It would be trivial to do what every other compiler in history does, but they want to screw with windows users or anyone you uses tabs for some philosophical reason.

htfy96 6y ago
Nim also disallows tab: https://play.nim-lang.org/#ix=2hW9 https://play.nim-lang.org/#ix=2hW9
- platinumrad 6y ago
  As does F#.
dbsights 6y ago
This is the reason I can't stand zig: its so aggressively opinionated about something that doesn't matter at all.
zamadatix 6y ago
Run "zig fmt" before "zig build-exe" and it's not a problem. Even Notepad supports unix line endings these days.
- BubRoss 6y ago
  Or zig could do what every other compiler does and work by default. Why would I invest time in a user hostile language?
  - zamadatix 6y ago
    Ever used or read about Fortran, Haskell, or Python? The idea that whitespace does not matter and will just be handled as-is is and has been a language design choice before and after Zig regardless how many times you pose the question. That Zig or any other language did not make the choice to treat whitespace the way you'd prefer in the compiler and instead left that it to the formatter does not make them "user hostile". The Zig docs link to the reasons they made the choice not to support varying whitespace (and other character and syntax choices), if you don't like those reasons feel free not to use it but it's a bit rude to make it out like they did it to "screw Windows users" when it's neither technically true nor the actual motive. This is all coming from a guy who has only messed with Zig on a Windows box with a preference for tabs over spaces (except post indent alignment). Zig fmt works great, haven't had an issue, less difficult to get going than mingw or vs that's for sure.

magv 6y ago

I am continuously surprised by the amount of work zig committers manage to put out every release. It is actually inspiring. How do they get to appear so productive? Anyway, here's a nitpick. In this release they've removed varargs, and now this is how a printf call looks like in zig: std.debug.warn("{}+{} is {}\n", .{1, 1, 1 + 1}); The ergonomics of typing .{} for every print seems pretty awful if you're a heavy user of debug printing. I was hoping that maybe some sort of a syntax sugar is planned so that tuples could be used without .{} -- emulating varargs, but the bug tracker doesn't turn up anything in that direction. In the previous release (0.5.0) one didn't need the .{}, but instead integer literals needed explicit casts, because the vararg implementation was limited: std.debug.warn("{}+{} is {}\n", i32(1), i32(1), i32(1 + 1)); Both of these options seem like a regression compared to the usual printf("%d+%d is %d\n", 1, 1, 1 + 1); ... and there doesn't seem to be a way to work around it by e.g. using a function overloaded in the number of arguments (no such thing in zig) or some preprocessor tricks (again, no such thing). PS. I'm also surprised to find out that zig seems to take 2.6 seconds to compile the above example.

zamadatix 6y ago
To be honest typing and remembering %d %f %c %s etc. seems like more hassle than typing {} and typing it for every case. I think the real gotchas are that { is escaped as {{ and } as }} instead of \{ and \} (though it does follow from the old %%) and you must either include , .{} or rewrite the function call to something significantly different to do unformatted print.
dimator 6y ago
Fwiw, the "{}" formatting is common in python, so that might be a reason they went that route.