9 ms·

Zig: programming language designed for robustness optimality and clarity [video]

136 points by espeed 8y ago

qop 8y ago
There are too many cool languages and too few weekends. It's becoming more problematic, but at the same time it would seem impractical to optimize my life around learning every single thing that I want to learn. How do I decide which things are important enough? I am running out of time in my life also. I watched a video a while ago about how the universe is expanding faster than light can travel, which means the portion of the universe that we can observe is an increasingly small subset of what's out there. Sometimes my hobbies and wish-i-had-time-for-that projects feel the same way, they're expanding faster than I'll ever catch up to. I wonder if zig will ever pursue some sort of memory safety. I find rust very difficult and unwieldy, but I can totally grok the appeal of RAII.
- espeed 8y ago
  > I wonder if zig will ever pursue some sort of memory safety. That's exactly what Zig is designed for [1]. Andrew Kelley (andrewrk) discusses this in the talk. Zig is similar to Rust, but with memory safety designed into the core, not bolted on as an afterthought. And as the SHA-256 demo tests in the talk show, Zig is as fast or faster than C. [1] http://ziglang.org http://ziglang.org [2] https://github.com/ziglang/zig https://github.com/ziglang/zig
  - CyberDildonics 8y ago
    I don't understand. Rust has memory safety as a core design principle. Zig has manual memory allocation like C.
    - tiehuis 8y ago
      Zig is memory-safe if you keep runtime checks enabled (e.g. with debug or release-safe optimization levels) but it does not have the compile-time guarantees of Rust. I don't think the parent comment is a fair reflection. That being said, some other potentially interesting safety aspects that are present (or are being explored) to give some idea of the target audience: - compile-time alignment checks [1] - maximum compile-time stack usage/bounding [2] I would expect safety at the end of the day in Zig will be more similar to modern C++ and its smart pointers, alongside (optional) runtime checks, than a full lifetime system. Will have to see what the future holds. [1] https://ziglang.org/documentation/master/#Alignment https://ziglang.org/documentation/master/#Alignment [2] https://github.com/ziglang/zig/issues/1006 https://github.com/ziglang/zig/issues/1006
  - tom_mellior 8y ago
    > And as the SHA-256 demo tests in the talk show, Zig is as fast or faster than C. Do you know at what timestamp (roughly) this is mentioned in the video? YouTube makes it hard to quickly skip around in the video to find this. Or, better, a link to a written source? I'd be interested in what exactly is being compared. It's easy to cheat on benchmarks, especially when you aren't doing it on purpose.
    - espeed 8y ago
      Right at about the 20m mark: https://youtu.be/Z4oYSByyRak?t=20m2s https://youtu.be/Z4oYSByyRak?t=20m2s
      - tom_mellior 8y ago
        Thanks! Grabbing the sources from https://www.nayuki.io/page/fast-sha2-hashes-in-x86-assembly https://www.nayuki.io/page/fast-sha2-hashes-in-x86-assembly and compiling them more or less as recommended (and unlike they are compiled in the talk): $ clang -O3 sha256-test.c sha256.c -o sha256-test ; for i in 1 2 3; do ./sha256-test ; done Self-check passed Speed: 197.2 MB/s Self-check passed Speed: 196.1 MB/s Self-check passed Speed: 196.1 MB/s $ gcc -O3 sha256-test.c sha256.c -o sha256-test ; for i in 1 2 3; do ./sha256-test ; done Self-check passed Speed: 209.7 MB/s Self-check passed Speed: 209.2 MB/s Self-check passed Speed: 209.1 MB/s This is a baseline for us. It has nothing to do with Zig and nothing to do with Andrew's machine (hardware or compiler versions). But wait, the page above suggests that adding -march=native might help. Indeed it does: $ clang -O3 -march=native sha256-test.c sha256.c -o sha256-test ; for i in 1 2 3; do ./sha256-test ; done Self-check passed Speed: 255.6 MB/s Self-check passed Speed: 259.0 MB/s Self-check passed Speed: 254.3 MB/s $ gcc -O3 -march=native sha256-test.c sha256.c -o sha256-test ; for i in 1 2 3; do ./sha256-test ; done Self-check passed Speed: 275.1 MB/s Self-check passed Speed: 268.4 MB/s Self-check passed Speed: 270.0 MB/s In the talk Andrew suggests that the difference might be due to using rorx instructions, which Zig might be able to do due to aggressive loop unrolling. Does -funroll-all-loops help GCC? It turns out that it doesn't, and that it cannot, on this program, because the C code for sha256_compress is already fully unrolled. But anyway, are we using rorx instructions at all? We are, but only with -march=native: $ clang -O3 -S sha256.c -o - | grep -c rorx 0 $ clang -O3 -march=native -S sha256.c -o - | grep -c rorx 542 And: $ gcc -O3 -S sha256.c -o - | grep -c rorx 0 $ gcc -O3 -march=native -S sha256.c -o - | grep -c rorx 576 [Edit: Changed the grep from "ror" to "rorx", which changed GCC's numbers a bit; it does generate "ror" without x without -march=native.] So. Testable theories: (a) On Andrew's machine, the same setup but with Clang using -march=native would outperform or at least match Zig. (b) Zig's compiler internally uses the equivalent of -march=native, possibly implicitly, at least in --release-fast mode. Nothing here is meant to imply that Andrew is dishonest. There are just lots of variables to take into account, and sometimes we don't. Also, "slower/faster than C" by a few percent is not very meaningful if even C compilers disagree by 6% or so, and the same C compiler with the right flags disagrees with itself by a lot more.
  - Yoric 8y ago
    I may be wrong, but if I read the documentation correctly, Rust looks more memory-safe than Zig. What am I missing?
    - mschwaig 8y ago
      Rust has lifetimes and ownership as language concepts so that you have to be explicit about who owns a resource, for example memory, but it does not give you a lot of control about what to do when an allocation fails. Zig is designed so that you can still peogrammatically deal with a failing allocation, as does well-written C, but it does not have a ownership system like Rust.
      - Yoric 8y ago
        Ok, got it. Apparently, espeed was using an unusual definition of "memory safety", which made their comment a bit odd :)
        tom_mellior 8y ago
        What was unusual about that? Here is Wikipedia: "Memory safety is the state of being protected from various software bugs and security vulnerabilities when dealing with memory access, such as buffer overflows and dangling pointers.[1] For example, Java is said to be memory-safe because its runtime error detection checks array bounds and pointer dereferences." This is the mainstream definition. Do you think Zig doesn't have this, or Rust has more of this than Zig? What Rust does indeed have is freedom from race conditions, which can be viewed as a concurrent memory safety property. And what Rust also has is static checking of one of the above properties, namely dangling pointers (but not the other, namely buffer overflows). Do you think that if it's not statically checked, it's not safe? Because if you think that, you are wrong.
        Yoric 8y ago
        I was referring to espeed's "Zig is similar to Rust, but with memory safety designed into the core, not bolted on as an afterthought", which he later explained with two examples, one of which actually justifies the words "bolted on as an afterthought", but refers to local handling of fallible allocation. While local handling of fallible allocation is a desirable feature for many applications, I confirm that neither me nor Wikipedia had never heard it classified as "memory safety" :)
- skybrian 8y ago
  If Zig (or some other language) turns out to be the next big thing, we'll be hearing about it again and again.
wgjordan 8y ago
This programming setup is the bomb. Zig is designed not only for robustness, optimality, and clarity, but also for great justice. It's great that Zig is an open source project so all your codebase belongs to us. I hope 'Zig' takes off everywhere.
donpdonp 8y ago
I've been building a toy project in zig in the last couple weeks. Zig is incredible. After only a short while working with it, it feels like deserves the title of a "better C". With no runtime overhead you get: * Type inference - var name = "Bob"; * Maybe types (from Elm/Haskell) that prevent NULL ptr bugs and syntactic sugar encourages its use for function return values. if (doit()) |result| { // result is always a populated Struct } else |err| { // error is always a populated Error } // a return type of !Something means Error type or Something type fn doit() !Struct { } * Nullable types - var ?&object = null; if you need it, and var &object = aObject; if you want the safety. * Great C interop, though there is more work to be done here. (gtk.h for instance is too much for zig today) Zig's approach is unique here too. You specify .h files in the zig source code and the zig compiler translates C in the .h into zig. Its not a function bridge or wrapper, its zig objects and zig functions available to your zig code. const c = @cImport({ @cInclude("curl/curl.h"); }); var curl = c.curl_easy_init(); if(curl != null) { _ = c.curl_easy_setopt(curl, c.CURLoption(c.CURLOPT_URL), url_cstr.ptr); ... * Standard library operations that allocate memory take an 'allocator object' parameter that should give great programmer control over memory management (I didnt get into this myself), webasm is a compiler target, and lots more
- dbaupp 8y ago
  I think you mean Result or Either like Haskell etc., not Maybe. Additionally, Swift has essentially the same approach to C FFI.
- MaxBarraclough 8y ago
  Do nullable types and maybe types add much over checked dereferences (a la Java)? I imagine they might be good for performance (fewer checks), but does it really help with correctness/convenience/elegance/readability/etc?
  - Yoric 8y ago
    In my experience from Rust & co, yep, this improves correctness a lot. Elegance, not so much.
gavanwoolery 8y ago
From the slides, these bullets struck me as things I have wanted for a while (to the extent that I have my own toy language that addresses some of them): - compiles faster than C - Produces faster machine code than C - Seamless interaction with C libs - robust/ergonomic error handling - Compile-time code execution and reflection - No hidden control flow - No hidden memory allocations - Ships with build system - Out-of-the-box cross compilation
- Yoric 8y ago
  > - No hidden control flow That means no destructors, right? edit Ah, if I read the documentation correctly, there are destructors.
  - nickez 8y ago
    I think it means no exceptions
  - iainmerrick 8y ago
    I think it means no destructors, no overloaded operators, no automatic getter/setters for properties. Nothing that does a function call unless you can immediately tell by looking at it that it’s a function call.
    - MaxBarraclough 8y ago
      You're right - there's no proper RAII (but there's a 'defer' keyword, which runs your expression on scope-exit, like BOOST_SCOPE_EXIT), no operator overloading, no exceptions, and all function calls look like function calls. It does have a language feature for handling error-codes though. [0] [1] [2] Contrast with C#'s 'properties', where a method call (which might throw) is disguised as reading/writing a member. My favourite example of unexpected semantics is D's lazy keyword, where, at the call-site, you have no idea whether your argument will be evaluated lazily or eagerly! [3] C# has a pass-by-reference keyword which modified the way an argument is treated, but it has the sense to force use of the keyword at the call-site too, so that everything is clear. [4] I like the language's philosophy, I'll have to keep an eye on it. I suspect they'd do well to have the language compile to C, though. Is there any reason that wouldn't be a good fit? I see it has a templates system, but at (very) first glance I don't see anything that wouldn't map cleanly to C. [0] https://ziglang.org/documentation/master/#defer https://ziglang.org/documentation/master/#defer [1] https://ziglang.org/download/0.1.1/release-notes.html https://ziglang.org/download/0.1.1/release-notes.html [2] https://andrewkelley.me/post/intro-to-zig.html https://andrewkelley.me/post/intro-to-zig.html [3] https://dlang.org/articles/lazy-evaluation.html https://dlang.org/articles/lazy-evaluation.html [4] https://docs.microsoft.com/en-us/dotnet/csharp/language-reference/keywords/ref#passing-an-argument-by-reference https://docs.microsoft.com/en-us/dotnet/csharp/language-refe...
tomsmeding 8y ago
> So let's talk about memory. I know it's every programmer's least favourite topic I thought that was time zones? (https://news.ycombinator.com/item?id=17181046 https://news.ycombinator.com/item?id=17181046)
- qop 8y ago
  What the hell are we going to do when humans are multiplanetary? Keeping computers in track of time is already a mess and we aren't even on mars yet. I've worked in some dirty gross code, but messing around with time is one of things I can just live without.
himom 8y ago
Personal taste, not factual One-True-Way™ It looks on the surface like almost Rust meets JS with a sprinkling of Ruby/Smalltalk. Semicolons in 2018, really? Indentation and line-oriented parsing makes code more beautiful. Heck, in general, enums, arrays and dictionary literals shouldn’t even need commas if there’s one tuple per line. Extra typing is a waste of time and clutters-up code with distracting, Christmas ornament “blink tags” that go “Ho, ho, ho” when anyone walks by. # package name is the same as the directory path # module name is the same as the filename sans extension # big modules can be broken up into separate include files con X: int = 6 # constant var M: int = 17 # module-public variable mix any # module-private mixin λ any? -> bool each {x| if (Block? ? yield(x) : x): return true} false ext []: mix any # module-private type extension typ T: int[10][8] λ Zero? -> bool: any? {x| x.any? {y| y == 0}} typ S a, b: int x, y: float s[7..6], t[5], u[4..2], _[1], v[0]: byte λ Good? -> bool: xGood? & yGood? # no & / && distinction, precedence by expression type λ xGood? -> bool: x > 0 λ yGood? -> bool: y > 0 uni Q # union I: int F: float λ thisIsPrivate(x: int) -> int x + M + 1 λ ThisIsPublic(x, y: float) -> float π * (x + y - X)
- flohofwoe 8y ago
  That's just your personal opinion, obviously. You need some sort of separators for putting several statements on the same line anyway, and requiring them everywhere is better than Javascript's or python's optional semicolons. Also I guess zig's main audience is C programmers, and semicolons are not one of the problems that need fixing in a "better C" language.
Yoric 8y ago
I have read quickly through the tutorial, and this looks interesting. Objectives are similar to Rust, with a few twists. A few differences that I can see: - At first glance, Rust's `enum` looks safer and more powerful than Zig's `union` + `enum`, while Zig's `union` + `enum` appears more interoperable with C. - Zig's `comptime` is quite intriguing. In particular, types are (compile-time) values and can be introspected. - Zig's generics are very different from Rust's generics. No idea how to compare them. - In particular, Zig's `printf` uses `comptime`, while Rust's `print!` is a macro. - Zig's Nullable types/Result types look bolted in and much weaker than Rust's userland implementation. - I don't see closures in Zig. - I don't see traits in Zig. - I don't see smart pointers in Zig, and more generally, I have no idea how to deallocate memory in Zig. - Zig's memory management encourages you to check whether your allocations have succeeded, while Rust's out-of-the-box memory management assumes that allocations always succeed - if you wish to handle OOM, you'll need a "let it fail" approach. - Zig's alias checker seems to be much more lenient than Rust's. - I don't see anything on concurrency in Zig's documentation. - Most of the Zig examples I see seem to fall in the "unsafe" domain of Rust by default. For instance, uninitialized memory or pointer casts seem to be ok in Zig (if explicitly mentioned), while they must be labelled as `unsafe` to be used in Rust. - According to https://andrewkelley.me/post/unsafe-zig-safer-than-unsafe-rust.html https://andrewkelley.me/post/unsafe-zig-safer-than-unsafe-ru..., Zig performs some checks that Rust does not perform in an `unsafe` block. - Zig supports varargs, Rust doesn't (yet). For the moment, I'll keep coding in Rust, but I'll keep an eye on Zig :)
- tiehuis 8y ago
  To elaborate on a few of your remarks/questions. > At first glance, Rust's `enum` looks safer and more powerful than Zig's `union` + `enum`, while Zig's `union` + `enum` appears more interoperable with C. A `union(TagType)` in Zig is a tagged union and has safety checks on all accesses in debug mode. It is directly comparable to a Rust enum. Any differences are probably more down to the ways you are expected to access them and Rust's stronger pattern matching probably helps some here. > I don't see traits in Zig. Nothing of the sort just yet although it is an open question [1]. Currently std uses function pointers a lot for interface-like code, and relies on some minimal boilerplate to be done by the implementor. See the interface for a memory allocator here [2]. An implementation of an allocator is given here [3] and needs to get the parent pointer (field) in order to provide the implementation. It isn't too bad once you are familiar with the pattern, but it's also not ideal, and I would like to see this improved. > I don't see smart pointers in Zig, and more generally, I have no idea how to deallocate memory in Zig. You would use a memory allocator as mentioned above and use the `create` and `destroy` functions for a single item, or `alloc` and `free` for an array of items. Memory allocation/deallocation doesn't exist at the language level. > I don't see anything on concurrency in Zig's documentation. There are coroutines built in to the language [4]. This is fairly recent and there isn't much documentation just yet unfortunately. Preliminary thread support is in the stdlib. I know Andrew wants to write an async web-server example set up multiplexing coroutines onto a thread-pool, as an example. > Zig supports varargs, Rust doesn't (yet). It's likely that varargs are instead replaced with tuples as a comptime tuple (length-variable) conveys the same information. I believe this fixes a few other quirks around varargs (such as using not being able to use varargs functions at comptime). [1] https://github.com/ziglang/zig/issues/130 https://github.com/ziglang/zig/issues/130 [2] https://github.com/ziglang/zig/blob/15302e84a45a04cfe94a8842318f02a608055962/std/mem.zig#L8 https://github.com/ziglang/zig/blob/15302e84a45a04cfe94a8842... [3] https://github.com/ziglang/zig/blob/15302e84a45a04cfe94a8842318f02a608055962/std/heap.zig#L41 https://github.com/ziglang/zig/blob/15302e84a45a04cfe94a8842... [4] https://github.com/ziglang/zig/blob/15302e84a45a04cfe94a8842318f02a608055962/test/cases/coroutines.zig https://github.com/ziglang/zig/blob/15302e84a45a04cfe94a8842...
zshrdlu 8y ago
He's wrong about Lisp not being capable of handling heap exhaustion through "exceptions" (conditions in Common Lisp).
jokoon 8y ago
Every time there is news about a language, the first thing I am interested in is reading the syntax, I don't really care about anything else. Unfortunately it's often hard to find code examples. Zig doesn't fail that rule, I browsed 3 or 4 pages or so on the website, and could not find decent code examples. It's frustrating. You should be proud of the syntax choices you're making and it should be the first thing you see so that developer might get a little interested, look at rust and go and nim.
- Yoric 8y ago
  I just clicked on "documentation" and found examples: https://ziglang.org/documentation/master/ https://ziglang.org/documentation/master/
jokoon 8y ago
I've been advised to a write a preprocessor so that I can make a language that compiles to C. I'm mostly fine with C, except I want to make it more readable and with a 'sweeter' syntax. Features I want are: * pythonic indent * no trailing semicolon * vector, hashmap and map containers * immutable strings
- chriswarbo 8y ago
  > Features I want are: * pythonic indent * no trailing semicolon I would recommend against making up a completely new syntax, since there would be no support in any existing tools (parsers, linters, IDEs, formatters, ...). Instead, I'd suggest picking a general-purpose syntax with the properties you want (indentation for grouping, newlines for sequencing). One excellent example is called "sweet-expressions", which was originally invented for Scheme but can actually be used to represent any structured data (especially code): https://srfi.schemers.org/srfi-110 https://srfi.schemers.org/srfi-110 You can use tools like "sweeten" and "unsweeten" from https://sourceforge.net/projects/readable/files https://sourceforge.net/projects/readable/files to convert between sweet-expressions and s-expressions. S-expressions are just raw syntax trees, so "unsweeten" is basically a ready-made parser which you can pipe into any other program you like, e.g. linters, macro expanders, pretty-printers, etc. To make your language compile to C, you would need some way to "render" those syntax trees into C code. There are existing tools to do this, for example the C-Mera system can read in C syntax trees and write out C code https://github.com/kiselgra/c-mera https://github.com/kiselgra/c-mera Your preprocessor could then be as simple as `unsweeten | cm c` To add completely new features like immutable strings you would just need to define some representation for them in the syntax trees (or, if you want to make them the default for "double quotes" you should define an alternative representation for non-immutable strings), then write some find/replace macros to convert occurrences of this representation into an equivalent (but more verbose and elaborate) set of C syntax trees. Stick this find/replace step in between `unsweeten` and `cm` and you've got brand new syntax for very little work.
- citycide 8y ago
  Have you tried Nim? It has (almost?) everything you're looking for and compiles to C, C++ or JS. https://nim-lang.org https://nim-lang.org
p0nce 8y ago
Where are the generative capabilities? It seems there is no macro-like thing in Zig, though there are comptime parameters (and I guess: monomorphized templates).
- AndyKelley 8y ago
  https://ziglang.org/documentation/master/#Case-Study-printf-in-Zig https://ziglang.org/documentation/master/#Case-Study-printf-...
  - p0nce 8y ago
    Not nearly what you have in D.
audunw 8y ago
I experimented with Zig for embedded programming. The language is very promising for this application. It still needs some features and maturity, but it's getting there. The cross-platform support is also has some missing stuff and bugs, but many of those were actually in LLVM in my case. To me, Zig is the most promising replacement to C right now. It seems to do everything right. Rust is of course another candidate, with a different philosophy, but I don't consider it a pure C replacement due to core language features requiring an advanced compiler. Zig, for the moment, should be pretty simple to write a compiler for. I consider this a strength of C, that something like TCC can exist.
white-flame 8y ago
His distinction with hidden memory allocations vs perfect software fails even in his C boolean example. Calling a C function takes up stack space. That's a hidden memory allocation which can exhaust just like heap does. But it's even worse because stack allocation failures don't have a place that return a nice clean NULL like malloc does. It's pretty strong to still call this case "perfect software" under his definitions.
- janvidar 8y ago
  Right, he answers a question about this. His plan seems to be to pre-calculate the stack space required at compile time using static callgraph analysis. This is not yet implemented.
  - white-flame 8y ago
    Yes, but I'm talking about his assertion about that C example earlier in the talk, not about Zig. It's pretty fundamental to his arguments.
  - Yoric 8y ago
    How would that work with: 1/ recursion; 2/ calling C code; 3/ being called from C?

136 points by espeed 8y ago

qop 8y ago

There are too many cool languages and too few weekends. It's becoming more problematic, but at the same time it would seem impractical to optimize my life around learning every single thing that I want to learn. How do I decide which things are important enough? I am running out of time in my life also. I watched a video a while ago about how the universe is expanding faster than light can travel, which means the portion of the universe that we can observe is an increasingly small subset of what's out there. Sometimes my hobbies and wish-i-had-time-for-that projects feel the same way, they're expanding faster than I'll ever catch up to. I wonder if zig will ever pursue some sort of memory safety. I find rust very difficult and unwieldy, but I can totally grok the appeal of RAII.

espeed 8y ago
> I wonder if zig will ever pursue some sort of memory safety. That's exactly what Zig is designed for [1]. Andrew Kelley (andrewrk) discusses this in the talk. Zig is similar to Rust, but with memory safety designed into the core, not bolted on as an afterthought. And as the SHA-256 demo tests in the talk show, Zig is as fast or faster than C. [1] http://ziglang.org http://ziglang.org [2] https://github.com/ziglang/zig https://github.com/ziglang/zig
- CyberDildonics 8y ago
  I don't understand. Rust has memory safety as a core design principle. Zig has manual memory allocation like C.
  - tiehuis 8y ago
    Zig is memory-safe if you keep runtime checks enabled (e.g. with debug or release-safe optimization levels) but it does not have the compile-time guarantees of Rust. I don't think the parent comment is a fair reflection. That being said, some other potentially interesting safety aspects that are present (or are being explored) to give some idea of the target audience: - compile-time alignment checks [1] - maximum compile-time stack usage/bounding [2] I would expect safety at the end of the day in Zig will be more similar to modern C++ and its smart pointers, alongside (optional) runtime checks, than a full lifetime system. Will have to see what the future holds. [1] https://ziglang.org/documentation/master/#Alignment https://ziglang.org/documentation/master/#Alignment [2] https://github.com/ziglang/zig/issues/1006 https://github.com/ziglang/zig/issues/1006
- tom_mellior 8y ago
  > And as the SHA-256 demo tests in the talk show, Zig is as fast or faster than C. Do you know at what timestamp (roughly) this is mentioned in the video? YouTube makes it hard to quickly skip around in the video to find this. Or, better, a link to a written source? I'd be interested in what exactly is being compared. It's easy to cheat on benchmarks, especially when you aren't doing it on purpose.
  - espeed 8y ago
    Right at about the 20m mark: https://youtu.be/Z4oYSByyRak?t=20m2s https://youtu.be/Z4oYSByyRak?t=20m2s
    - tom_mellior 8y ago
      Thanks! Grabbing the sources from https://www.nayuki.io/page/fast-sha2-hashes-in-x86-assembly https://www.nayuki.io/page/fast-sha2-hashes-in-x86-assembly and compiling them more or less as recommended (and unlike they are compiled in the talk): $ clang -O3 sha256-test.c sha256.c -o sha256-test ; for i in 1 2 3; do ./sha256-test ; done Self-check passed Speed: 197.2 MB/s Self-check passed Speed: 196.1 MB/s Self-check passed Speed: 196.1 MB/s $ gcc -O3 sha256-test.c sha256.c -o sha256-test ; for i in 1 2 3; do ./sha256-test ; done Self-check passed Speed: 209.7 MB/s Self-check passed Speed: 209.2 MB/s Self-check passed Speed: 209.1 MB/s This is a baseline for us. It has nothing to do with Zig and nothing to do with Andrew's machine (hardware or compiler versions). But wait, the page above suggests that adding -march=native might help. Indeed it does: $ clang -O3 -march=native sha256-test.c sha256.c -o sha256-test ; for i in 1 2 3; do ./sha256-test ; done Self-check passed Speed: 255.6 MB/s Self-check passed Speed: 259.0 MB/s Self-check passed Speed: 254.3 MB/s $ gcc -O3 -march=native sha256-test.c sha256.c -o sha256-test ; for i in 1 2 3; do ./sha256-test ; done Self-check passed Speed: 275.1 MB/s Self-check passed Speed: 268.4 MB/s Self-check passed Speed: 270.0 MB/s In the talk Andrew suggests that the difference might be due to using rorx instructions, which Zig might be able to do due to aggressive loop unrolling. Does -funroll-all-loops help GCC? It turns out that it doesn't, and that it cannot, on this program, because the C code for sha256_compress is already fully unrolled. But anyway, are we using rorx instructions at all? We are, but only with -march=native: $ clang -O3 -S sha256.c -o - | grep -c rorx 0 $ clang -O3 -march=native -S sha256.c -o - | grep -c rorx 542 And: $ gcc -O3 -S sha256.c -o - | grep -c rorx 0 $ gcc -O3 -march=native -S sha256.c -o - | grep -c rorx 576 [Edit: Changed the grep from "ror" to "rorx", which changed GCC's numbers a bit; it does generate "ror" without x without -march=native.] So. Testable theories: (a) On Andrew's machine, the same setup but with Clang using -march=native would outperform or at least match Zig. (b) Zig's compiler internally uses the equivalent of -march=native, possibly implicitly, at least in --release-fast mode. Nothing here is meant to imply that Andrew is dishonest. There are just lots of variables to take into account, and sometimes we don't. Also, "slower/faster than C" by a few percent is not very meaningful if even C compilers disagree by 6% or so, and the same C compiler with the right flags disagrees with itself by a lot more.
- Yoric 8y ago
  I may be wrong, but if I read the documentation correctly, Rust looks more memory-safe than Zig. What am I missing?
  - mschwaig 8y ago
    Rust has lifetimes and ownership as language concepts so that you have to be explicit about who owns a resource, for example memory, but it does not give you a lot of control about what to do when an allocation fails. Zig is designed so that you can still peogrammatically deal with a failing allocation, as does well-written C, but it does not have a ownership system like Rust.
    - Yoric 8y ago
      Ok, got it. Apparently, espeed was using an unusual definition of "memory safety", which made their comment a bit odd :)
      - tom_mellior 8y ago
        What was unusual about that? Here is Wikipedia: "Memory safety is the state of being protected from various software bugs and security vulnerabilities when dealing with memory access, such as buffer overflows and dangling pointers.[1] For example, Java is said to be memory-safe because its runtime error detection checks array bounds and pointer dereferences." This is the mainstream definition. Do you think Zig doesn't have this, or Rust has more of this than Zig? What Rust does indeed have is freedom from race conditions, which can be viewed as a concurrent memory safety property. And what Rust also has is static checking of one of the above properties, namely dangling pointers (but not the other, namely buffer overflows). Do you think that if it's not statically checked, it's not safe? Because if you think that, you are wrong.
        Yoric 8y ago
        I was referring to espeed's "Zig is similar to Rust, but with memory safety designed into the core, not bolted on as an afterthought", which he later explained with two examples, one of which actually justifies the words "bolted on as an afterthought", but refers to local handling of fallible allocation. While local handling of fallible allocation is a desirable feature for many applications, I confirm that neither me nor Wikipedia had never heard it classified as "memory safety" :)
skybrian 8y ago
If Zig (or some other language) turns out to be the next big thing, we'll be hearing about it again and again.

wgjordan 8y ago

This programming setup is the bomb. Zig is designed not only for robustness, optimality, and clarity, but also for great justice. It's great that Zig is an open source project so all your codebase belongs to us. I hope 'Zig' takes off everywhere.

donpdonp 8y ago

I've been building a toy project in zig in the last couple weeks. Zig is incredible. After only a short while working with it, it feels like deserves the title of a "better C". With no runtime overhead you get: * Type inference - var name = "Bob"; * Maybe types (from Elm/Haskell) that prevent NULL ptr bugs and syntactic sugar encourages its use for function return values. if (doit()) |result| { // result is always a populated Struct } else |err| { // error is always a populated Error } // a return type of !Something means Error type or Something type fn doit() !Struct { } * Nullable types - var ?&object = null; if you need it, and var &object = aObject; if you want the safety. * Great C interop, though there is more work to be done here. (gtk.h for instance is too much for zig today) Zig's approach is unique here too. You specify .h files in the zig source code and the zig compiler translates C in the .h into zig. Its not a function bridge or wrapper, its zig objects and zig functions available to your zig code. const c = @cImport({ @cInclude("curl/curl.h"); }); var curl = c.curl_easy_init(); if(curl != null) { _ = c.curl_easy_setopt(curl, c.CURLoption(c.CURLOPT_URL), url_cstr.ptr); ... * Standard library operations that allocate memory take an 'allocator object' parameter that should give great programmer control over memory management (I didnt get into this myself), webasm is a compiler target, and lots more

dbaupp 8y ago
I think you mean Result or Either like Haskell etc., not Maybe. Additionally, Swift has essentially the same approach to C FFI.
MaxBarraclough 8y ago
Do nullable types and maybe types add much over checked dereferences (a la Java)? I imagine they might be good for performance (fewer checks), but does it really help with correctness/convenience/elegance/readability/etc?
- Yoric 8y ago
  In my experience from Rust & co, yep, this improves correctness a lot. Elegance, not so much.

gavanwoolery 8y ago

From the slides, these bullets struck me as things I have wanted for a while (to the extent that I have my own toy language that addresses some of them): - compiles faster than C - Produces faster machine code than C - Seamless interaction with C libs - robust/ergonomic error handling - Compile-time code execution and reflection - No hidden control flow - No hidden memory allocations - Ships with build system - Out-of-the-box cross compilation

Yoric 8y ago
> - No hidden control flow That means no destructors, right? edit Ah, if I read the documentation correctly, there are destructors.
- nickez 8y ago
  I think it means no exceptions
- iainmerrick 8y ago
  I think it means no destructors, no overloaded operators, no automatic getter/setters for properties. Nothing that does a function call unless you can immediately tell by looking at it that it’s a function call.
  - MaxBarraclough 8y ago
    You're right - there's no proper RAII (but there's a 'defer' keyword, which runs your expression on scope-exit, like BOOST_SCOPE_EXIT), no operator overloading, no exceptions, and all function calls look like function calls. It does have a language feature for handling error-codes though. [0] [1] [2] Contrast with C#'s 'properties', where a method call (which might throw) is disguised as reading/writing a member. My favourite example of unexpected semantics is D's lazy keyword, where, at the call-site, you have no idea whether your argument will be evaluated lazily or eagerly! [3] C# has a pass-by-reference keyword which modified the way an argument is treated, but it has the sense to force use of the keyword at the call-site too, so that everything is clear. [4] I like the language's philosophy, I'll have to keep an eye on it. I suspect they'd do well to have the language compile to C, though. Is there any reason that wouldn't be a good fit? I see it has a templates system, but at (very) first glance I don't see anything that wouldn't map cleanly to C. [0] https://ziglang.org/documentation/master/#defer https://ziglang.org/documentation/master/#defer [1] https://ziglang.org/download/0.1.1/release-notes.html https://ziglang.org/download/0.1.1/release-notes.html [2] https://andrewkelley.me/post/intro-to-zig.html https://andrewkelley.me/post/intro-to-zig.html [3] https://dlang.org/articles/lazy-evaluation.html https://dlang.org/articles/lazy-evaluation.html [4] https://docs.microsoft.com/en-us/dotnet/csharp/language-reference/keywords/ref#passing-an-argument-by-reference https://docs.microsoft.com/en-us/dotnet/csharp/language-refe...

tomsmeding 8y ago

> So let's talk about memory. I know it's every programmer's least favourite topic I thought that was time zones? (https://news.ycombinator.com/item?id=17181046 https://news.ycombinator.com/item?id=17181046)

qop 8y ago
What the hell are we going to do when humans are multiplanetary? Keeping computers in track of time is already a mess and we aren't even on mars yet. I've worked in some dirty gross code, but messing around with time is one of things I can just live without.

himom 8y ago

Personal taste, not factual One-True-Way™ It looks on the surface like almost Rust meets JS with a sprinkling of Ruby/Smalltalk. Semicolons in 2018, really? Indentation and line-oriented parsing makes code more beautiful. Heck, in general, enums, arrays and dictionary literals shouldn’t even need commas if there’s one tuple per line. Extra typing is a waste of time and clutters-up code with distracting, Christmas ornament “blink tags” that go “Ho, ho, ho” when anyone walks by. # package name is the same as the directory path # module name is the same as the filename sans extension # big modules can be broken up into separate include files con X: int = 6 # constant var M: int = 17 # module-public variable mix any # module-private mixin λ any? -> bool each {x| if (Block? ? yield(x) : x): return true} false ext []: mix any # module-private type extension typ T: int[10][8] λ Zero? -> bool: any? {x| x.any? {y| y == 0}} typ S a, b: int x, y: float s[7..6], t[5], u[4..2], _[1], v[0]: byte λ Good? -> bool: xGood? & yGood? # no & / && distinction, precedence by expression type λ xGood? -> bool: x > 0 λ yGood? -> bool: y > 0 uni Q # union I: int F: float λ thisIsPrivate(x: int) -> int x + M + 1 λ ThisIsPublic(x, y: float) -> float π * (x + y - X)

flohofwoe 8y ago
That's just your personal opinion, obviously. You need some sort of separators for putting several statements on the same line anyway, and requiring them everywhere is better than Javascript's or python's optional semicolons. Also I guess zig's main audience is C programmers, and semicolons are not one of the problems that need fixing in a "better C" language.

Yoric 8y ago

I have read quickly through the tutorial, and this looks interesting. Objectives are similar to Rust, with a few twists. A few differences that I can see: - At first glance, Rust's `enum` looks safer and more powerful than Zig's `union` + `enum`, while Zig's `union` + `enum` appears more interoperable with C. - Zig's `comptime` is quite intriguing. In particular, types are (compile-time) values and can be introspected. - Zig's generics are very different from Rust's generics. No idea how to compare them. - In particular, Zig's `printf` uses `comptime`, while Rust's `print!` is a macro. - Zig's Nullable types/Result types look bolted in and much weaker than Rust's userland implementation. - I don't see closures in Zig. - I don't see traits in Zig. - I don't see smart pointers in Zig, and more generally, I have no idea how to deallocate memory in Zig. - Zig's memory management encourages you to check whether your allocations have succeeded, while Rust's out-of-the-box memory management assumes that allocations always succeed - if you wish to handle OOM, you'll need a "let it fail" approach. - Zig's alias checker seems to be much more lenient than Rust's. - I don't see anything on concurrency in Zig's documentation. - Most of the Zig examples I see seem to fall in the "unsafe" domain of Rust by default. For instance, uninitialized memory or pointer casts seem to be ok in Zig (if explicitly mentioned), while they must be labelled as `unsafe` to be used in Rust. - According to https://andrewkelley.me/post/unsafe-zig-safer-than-unsafe-rust.html https://andrewkelley.me/post/unsafe-zig-safer-than-unsafe-ru..., Zig performs some checks that Rust does not perform in an `unsafe` block. - Zig supports varargs, Rust doesn't (yet). For the moment, I'll keep coding in Rust, but I'll keep an eye on Zig :)

tiehuis 8y ago
To elaborate on a few of your remarks/questions. > At first glance, Rust's `enum` looks safer and more powerful than Zig's `union` + `enum`, while Zig's `union` + `enum` appears more interoperable with C. A `union(TagType)` in Zig is a tagged union and has safety checks on all accesses in debug mode. It is directly comparable to a Rust enum. Any differences are probably more down to the ways you are expected to access them and Rust's stronger pattern matching probably helps some here. > I don't see traits in Zig. Nothing of the sort just yet although it is an open question [1]. Currently std uses function pointers a lot for interface-like code, and relies on some minimal boilerplate to be done by the implementor. See the interface for a memory allocator here [2]. An implementation of an allocator is given here [3] and needs to get the parent pointer (field) in order to provide the implementation. It isn't too bad once you are familiar with the pattern, but it's also not ideal, and I would like to see this improved. > I don't see smart pointers in Zig, and more generally, I have no idea how to deallocate memory in Zig. You would use a memory allocator as mentioned above and use the `create` and `destroy` functions for a single item, or `alloc` and `free` for an array of items. Memory allocation/deallocation doesn't exist at the language level. > I don't see anything on concurrency in Zig's documentation. There are coroutines built in to the language [4]. This is fairly recent and there isn't much documentation just yet unfortunately. Preliminary thread support is in the stdlib. I know Andrew wants to write an async web-server example set up multiplexing coroutines onto a thread-pool, as an example. > Zig supports varargs, Rust doesn't (yet). It's likely that varargs are instead replaced with tuples as a comptime tuple (length-variable) conveys the same information. I believe this fixes a few other quirks around varargs (such as using not being able to use varargs functions at comptime). [1] https://github.com/ziglang/zig/issues/130 https://github.com/ziglang/zig/issues/130 [2] https://github.com/ziglang/zig/blob/15302e84a45a04cfe94a8842318f02a608055962/std/mem.zig#L8 https://github.com/ziglang/zig/blob/15302e84a45a04cfe94a8842... [3] https://github.com/ziglang/zig/blob/15302e84a45a04cfe94a8842318f02a608055962/std/heap.zig#L41 https://github.com/ziglang/zig/blob/15302e84a45a04cfe94a8842... [4] https://github.com/ziglang/zig/blob/15302e84a45a04cfe94a8842318f02a608055962/test/cases/coroutines.zig https://github.com/ziglang/zig/blob/15302e84a45a04cfe94a8842...

zshrdlu 8y ago

He's wrong about Lisp not being capable of handling heap exhaustion through "exceptions" (conditions in Common Lisp).

jokoon 8y ago

Every time there is news about a language, the first thing I am interested in is reading the syntax, I don't really care about anything else. Unfortunately it's often hard to find code examples. Zig doesn't fail that rule, I browsed 3 or 4 pages or so on the website, and could not find decent code examples. It's frustrating. You should be proud of the syntax choices you're making and it should be the first thing you see so that developer might get a little interested, look at rust and go and nim.

Yoric 8y ago
I just clicked on "documentation" and found examples: https://ziglang.org/documentation/master/ https://ziglang.org/documentation/master/

jokoon 8y ago

I've been advised to a write a preprocessor so that I can make a language that compiles to C. I'm mostly fine with C, except I want to make it more readable and with a 'sweeter' syntax. Features I want are: * pythonic indent * no trailing semicolon * vector, hashmap and map containers * immutable strings

chriswarbo 8y ago
> Features I want are: * pythonic indent * no trailing semicolon I would recommend against making up a completely new syntax, since there would be no support in any existing tools (parsers, linters, IDEs, formatters, ...). Instead, I'd suggest picking a general-purpose syntax with the properties you want (indentation for grouping, newlines for sequencing). One excellent example is called "sweet-expressions", which was originally invented for Scheme but can actually be used to represent any structured data (especially code): https://srfi.schemers.org/srfi-110 https://srfi.schemers.org/srfi-110 You can use tools like "sweeten" and "unsweeten" from https://sourceforge.net/projects/readable/files https://sourceforge.net/projects/readable/files to convert between sweet-expressions and s-expressions. S-expressions are just raw syntax trees, so "unsweeten" is basically a ready-made parser which you can pipe into any other program you like, e.g. linters, macro expanders, pretty-printers, etc. To make your language compile to C, you would need some way to "render" those syntax trees into C code. There are existing tools to do this, for example the C-Mera system can read in C syntax trees and write out C code https://github.com/kiselgra/c-mera https://github.com/kiselgra/c-mera Your preprocessor could then be as simple as `unsweeten | cm c` To add completely new features like immutable strings you would just need to define some representation for them in the syntax trees (or, if you want to make them the default for "double quotes" you should define an alternative representation for non-immutable strings), then write some find/replace macros to convert occurrences of this representation into an equivalent (but more verbose and elaborate) set of C syntax trees. Stick this find/replace step in between `unsweeten` and `cm` and you've got brand new syntax for very little work.
citycide 8y ago
Have you tried Nim? It has (almost?) everything you're looking for and compiles to C, C++ or JS. https://nim-lang.org https://nim-lang.org

p0nce 8y ago

Where are the generative capabilities? It seems there is no macro-like thing in Zig, though there are comptime parameters (and I guess: monomorphized templates).

AndyKelley 8y ago
https://ziglang.org/documentation/master/#Case-Study-printf-in-Zig https://ziglang.org/documentation/master/#Case-Study-printf-...
- p0nce 8y ago
  Not nearly what you have in D.

audunw 8y ago

I experimented with Zig for embedded programming. The language is very promising for this application. It still needs some features and maturity, but it's getting there. The cross-platform support is also has some missing stuff and bugs, but many of those were actually in LLVM in my case. To me, Zig is the most promising replacement to C right now. It seems to do everything right. Rust is of course another candidate, with a different philosophy, but I don't consider it a pure C replacement due to core language features requiring an advanced compiler. Zig, for the moment, should be pretty simple to write a compiler for. I consider this a strength of C, that something like TCC can exist.

white-flame 8y ago

His distinction with hidden memory allocations vs perfect software fails even in his C boolean example. Calling a C function takes up stack space. That's a hidden memory allocation which can exhaust just like heap does. But it's even worse because stack allocation failures don't have a place that return a nice clean NULL like malloc does. It's pretty strong to still call this case "perfect software" under his definitions.

janvidar 8y ago
Right, he answers a question about this. His plan seems to be to pre-calculate the stack space required at compile time using static callgraph analysis. This is not yet implemented.
- white-flame 8y ago
  Yes, but I'm talking about his assertion about that C example earlier in the talk, not about Zig. It's pretty fundamental to his arguments.
- Yoric 8y ago
  How would that work with: 1/ recursion; 2/ calling C code; 3/ being called from C?