1. 55
    1. 11

      I wanted to see what Zig is like, so I ported a small C program of mine. It was very easy to do a ~1:1 port, and then zig build-exe --release-small --single-threaded --strip gave me a ~10kB, zero-dependency executable, which I really appreciated. I spent some time making it nicer, and learning more about the language, and I have to say I’m smitten. I think this could eventually replace C for me, which is not the impression I got from Rust (which is fine; it just seems to have different priorities.)

      I updated the Nix package to 0.5.0 so I could give it a go, but unfortunately LLVM 9 is not in unstable yet, so I haven’t been able to try it, but I’m looking forward to it.

      1. 6

        I tend to think of Rust as able to replace C libraries and C applications at that sort-of systems-applications boundary, sort of like a restrained C++, and similarly if you restrict the feature set of Rust you can use it for systems or embedded. Zig to me feels like an actual replacement for C code rather than applications of C code, and it’s not for it’s own sake; it brings real advantages over some things which are extremely error prone or just painful in C, my personal favourites being sane handling of tagged unions, the ability to metaprogram without breaking out to code generation tools, and handling of errors.

        1. 4

          In my mind, Rust is much more a replacement for C++, than it is for C.

          1. 2

            I think that’s a fair assessment to make. You definitely can make the Rust compiler target things that C does, but the necessary stripping back of the language definitely makes it resemble less the language and ecosystem that higher level Rust users have. Kind of like IOKit C++ I guess (though I’ve not looked into that much).

            The side I was more alluding to was application level and userland libraries that have traditionally been written in C because it was the most portable language to write native code libraries with a C ABI (C++ being reliably portable across platforms is a fairly recent development as far as it’s history goes, and arguably it’s image regarding this is still tarnished now) and especially ones that involve protocol or file format parsing which have been easy to get catastrophically wrong in C in security terms.

        2. 2

          similarly if you restrict the feature set of Rust you can use it for systems or embedded.

          I wonder what restriction that might be?

          Rust can be easily used on those systems with a full feature set. What’s missing is the std (and with that, all allocating types).

    2. 4

      The async feature looks interesting. I like how explicit it is. How would you return a value from an async function?

      EDIT: I’m apparently unable to read:

      var global_download_frame: anyframe = undefined;
      fn fetchUrl(allocator: *std.mem.Allocator, url: []const u8) anyerror![]u8 {
          const result = try std.mem.dupe(allocator, u8, "expected download text");
          errdefer allocator.free(result);
          if (suspend_download) {
              suspend {
                  global_download_frame = @frame();
          if (simulate_fail_download) return error.NoResponse;
          std.debug.warn("fetchUrl returning\n");
          return result;
      1. 10

        return value;

        It works exactly like a normal function. The only difference is you can start the function call (async) and finish the function call (await) in different locations.