8 ms·

This is so cool! I'm really impressed with what I've seen out of Zig so far. I need to come up with a project to try it out with. It seems like a great successo

This is so cool! I'm really impressed with what I've seen out of Zig so far. I need to come up with a project to try it out with. It seems like a great successor to C

pron 7y ago
Yep. Zig is shaping up to be the low-level programming language I've been waiting for to replace C++ for me. It just needs to mature and stabilize a bit before it's production-quality.
- 3fe9a03ccd14ca5 7y ago
  Why not rust?
  - FpUser 7y ago
    Why Rust?
    - KnightHawk3 7y ago
      articles about rust don't have to include a link to "what is Rust" like this one does.
      - FpUser 7y ago
        For one thing I do not think you can implement allocator in Rust. This alone would disqualify it as a "low level"/"systems" language in my opinion.
        shepmaster 7y ago
        You can implement an allocator in Rust; it's unclear why you think this is not possible. One example: - https://github.com/fitzgen/bumpalo https://github.com/fitzgen/bumpalo
        FpUser 7y ago
        I said "I do not think". I do not really know Rust. Obviously I was wrong.
        deleted 7y ago
        [deleted]
        dunkelheit 7y ago
        Worth noting that support for custom allocators in standard collections is not finalized yet: https://github.com/rust-lang/rust/issues/32838 https://github.com/rust-lang/rust/issues/32838 The (awesome) bumpalo crate that you link to gets around this by providing ported implementations of Vec and String, but if you need e.g. a custom-allocated HashMap, you need to implement it yourself.
        shepmaster 7y ago
        Thanks for the additional points! What you state is true, but somewhat orthogonal to the point that the grandparent post was making (and I sought to refute). Creating an allocator is inherently possible. Using that allocator with the rest of the ecosystem is currently not stable, as you point out. As a sometimes Rust embedded developer, I look forward to both parameterized allocators and fallible allocation.
        yellowapple 7y ago
        Also worth noting that this is one thing Zig seems to have gotten quite right already: every standard library function which might need to allocate memory requires the user of that function to pass in an allocator of one's choosing, whether provided with the standard library or provided from scratch. For example, I've been (slowly, given limited free time) working on a SQLite binding for Zig. SQLite has its own allocator, which I've wrapped like so: const std = @import("std"); const Allocator = std.mem.Allocator; const ArrayList = std.ArrayList; // This is all ripped from Zig's C allocator, with adaptations to point to // SQLite's allocator instead. pub const allocator = &allocator_state; var allocator_state = Allocator{ .reallocFn = realloc, .shrinkFn = shrink, }; fn realloc(self: *Allocator, old_mem: []u8, old_align: u29, new_size: usize, new_align: u29) ![]u8 { std.debug.assert(new_align <= @alignOf(c_longdouble)); const old_ptr = if (old_mem.len == 0) null else @ptrCast(*c_void, old_mem.ptr); const buf = sqlite3_realloc64(old_ptr, @intCast(u64, new_size)) orelse return error.OutOfMemory; return @ptrCast([*]u8, buf)[0..new_size]; } fn shrink(self: *Allocator, old_mem: []u8, old_align: u29, new_size: usize, new_align: u29) []u8 { const old_ptr = @ptrCast(*c_void, old_mem.ptr); const buf = sqlite3_realloc64(old_ptr, @intCast(u64, new_size)) orelse return old_mem[0..new_size]; return @ptrCast([*]u8, buf)[0..new_size]; } And later, to actually open a database (where we need an allocator to add a null byte to a Zig string to satisfy SQLite's expectations for a database name, so we might as well use SQLite's)¹: pub fn open(name: []const u8) !Database { // "allocator" here being the const-defined one above var cstrName = try std.cstr.addNullByte(allocator, name); defer allocator.free(cstrName); var db: Database = undefined; var rc = sqlite3_open(cstrName.ptr, &db); if (rc == SQLITE_OK) { return db; } else { _ = sqlite3_close(db); return errorCode(rc); } } Of course, it'd be even better if such a wrapper actually used SQLite's own support for custom allocators to follow the Zig stdlib convention of allowing the user to supply one's own allocator. Going the other way seemed like a reasonable short-term choice, though, and it was a good enough excuse for me to learn the ropes on custom allocators (even if most of the code ultimately came from Zig's own C allocator). ---- ¹: It turns out that this specific example will apparently be entirely unnecessary in future versions of Zig; the master branch documentation seems to do away with "Zig strings" v. "C strings", instead just making strings null-terminated by default (using what looks to be new support for "sentinel-terminated" pointers/arrays/slices). Looks like I've got some work to do :)
        pjmlp 7y ago
        You also cannot fully implement libc in ISO C, without using either language extensions or an external Assembler. So I guess it is not a "low level"/"systems".
        FpUser 7y ago
        True. You beat me. But C with extensions does qualify ;)
        pjmlp 7y ago
        So does any other language with extensions, even stuff like CircuitPython.
      - jakear 7y ago
        They did when Rust was as mature as Zig is now. Language popularity is a reasonable deciding factor when one is starting a project that has a hiring component; personal projects not so much.
  - csande17 7y ago
    Rust is great for when you're writing a serious, security-critical program that can't have any memory-corruption bugs or data races. It makes writing programs a little more challenging, and sometimes you sacrifice a bit of runtime performance compared to C, but it's often worth it. But Game Boy Advance games don't really fit that description. GBA games don't accept untrusted input, and nothing bad happens if they're "compromised". (Like, when people discovered arbitrary code execution in Super Mario World, no one was worried about the security implications.) So languages like C or Zig that let you cowboy values directly into specific memory locations can be a better choice. I'm excited about Zig in particular because the mission statement seems to be "C but nicer" -- you get the same basic programming model, but with things like instance methods, generic types, better macros, arbitrary-bit-integer types and a "crash when hitting undefined behavior" compile mode.
    - swiley 7y ago
      Arbitrary code execution isn’t that big a deal when one of the features of the device is that it accepts a ram image over its synchronous serial port which is jumped into after being received.
    - shpongled 7y ago
      Idk, I use Rust wherever I would use any other programming language, but I'm also a huge fan of the language in general. There's no need to limit it to "serious" applications
    - saagarjha 7y ago
      > nothing bad happens if they're "compromised" It can make debugging your program a lot harder :)
    - Jyaif 7y ago
      > GBA games don't accept untrusted input You have a very narrow definition of untrusted input.
    - OatMilkLatte 7y ago
      On the contrary - when people discovered an ACE bug in Super Mario World, they PogChamp'd.
  - olodus 7y ago
    They are different languages and you can be exited for both and want to use both. I think it is unnecessary to have this kind of comment after every statement on other languages as if ones excitement for one would completely take the other one out of the picture. I would say why I really like Zig is because the minimalism of C is still there in the syntax and it makes a whole lot of very smart choices to keep this simplicity while being so much more expressive than C. If you really need some Rust pro's I would say it is great as the language that finally brings more of ML and functional ideas into high performance programming. Most languages nowadays have fp things but Rust has it very deep into its core. Other than that it is great to see proof systems reaching the mainstream and the security guarantees its ownership system gives is great.
  - jokoon 7y ago
    learning curve, mostly
  - LessDmesg 7y ago
    Because it's too heavy on the "fight the compiler" security stuff. Rust is well-designed all around, but no fun to program in.
  - pron 7y ago
    It's all a matter of personal preference, and Rust is just not what I'm looking for in a C++ replacement, I guess. My biggest issue with C++ is the complexity of the language. C++ is a language that fetishizes accidental complexity, making it the center of things, and now it seems that Rust is saying, "hold my beer." Zig, on the other hand, fits my aesthetics pretty much perfectly, although I'm sure that, as with all programming languages, some people would have the opposite preference. As for correctness, one thing I've learned in the years I've been using formal methods is that there are many paths to correctness, and I'm starting to think that even on that front Zig's approach (of dynamic verification) might ultimately prove a better one.
  - pjmlp 7y ago
    Not the OP, for me what I am looking forward is a systems language with automatic memory management, in the same vein as Modula-3, Active Oberon, D or System C#. Swift fills that slot, but only on Apple platforms. Linux hardly has portable support even for file access and Windows will get supported some day, and most 3rd party libraries assume Apple anyway. D has a great community, but still found lacking in some areas. .NET AOT compiled with the learnings taken from System C# (7.x - 9) is the closest for my daily coding activities. Ideally Delphi like with automatic memory management. Or maybe having a Rust IDE with visual representation of lifetimes would already be productive enough.
    - 80386 7y ago
      Maybe a stupid question: if I want to write cross-platform desktop GUI apps and be able to take full advantage of the desktop GUI (menus, status icons in the system tray, etc.), and I'm mostly developing on Windows, what should I learn? That's what I'm looking for, and I'm sure it already exists; I just don't know how to find it other than asking around. (I tried to install some Haskell GUI libraries, but that's very difficult on Windows. I eventually got haskell-gi to install, but as far as I could tell, it had no support for status icons.)
      - pjmlp 7y ago
        If you are doing Windows stuff and want native UI, then there is no way around Delphi, .NET or C++ (or C if you are masochist enough to use bare bones Win32). Qt does a pretty good job for C++ and Python, but it is not native if that is what you're looking for. JavaFX would be a good approach if you are into JVM languages, but you might need to do some JNI wrappers to call stuff like system tray, as just like Qt it does its own rendering. Some corporations, go the route of having common code for the business logic, and then create an abstraction layer for stuff like system tray, UI widgets and stuff. Although is does require additional development cost. So you call something like show_tray_message "New Email" and have an implementation for each OS that you care about. If you are using Haskell, have you tried Haskell Platform?
        7y ago
nemo1618 7y ago
I've been doing Advent of Code in Zig. It's a far cry from "real world" programming, but still a decent way to get a feel for the language.
- wycy 7y ago
  Do you have a public repo of your Advent code? I started out trying to use Zig but couldn’t find documentation on how to complete even basic tasks (like passing a filename as a command line arg, then opening and reading a file line by line), so I gave up. Maybe seeing a repo of good Zig code accomplishing these tasks would get me going.
  - turndown 7y ago
    Here[1] is a playlist of the creator of Zig coding in Zig. He also has some solutions for Advent of Code. 1. https://www.youtube.com/watch?v=hBCsWEQ_asM&list=PLviMr_WImMhHA_yCD2-VfUSB_j4qSQ8pf https://www.youtube.com/watch?v=hBCsWEQ_asM&list=PLviMr_WImM...
    - wycy 7y ago
      > He also has some solutions for Advent of Code. I had looked at his 2018 Advent repo and was disappointed to find that he simply pasted his input directly into the code, whereas I like to compile generic binaries that can read inputs from the command line. However, it looks like his 2019 solutions for days 1 and 2 at least do read input from a file, so this year looks like it'll be a better starting point.
  - crowhack 7y ago
    Check out the Zig standard library and the tests for examples on doing some basic stuff with the language. Tests are generally at the end of files, you can search for "test". 0.5.0 Documentation https://ziglang.org/documentation/0.5.0/#Introduction https://ziglang.org/documentation/0.5.0/#Introduction root std library https://github.com/ziglang/zig/tree/master/lib/std https://github.com/ziglang/zig/tree/master/lib/std examples of writing and reading to a file https://github.com/ziglang/zig/blob/master/lib/std/event/fs.zig#L1307 https://github.com/ziglang/zig/blob/master/lib/std/event/fs.... There are also a ton of projects that the creator has done with Zig, you can check those out for more examples as well. https://github.com/andrewrk?utf8=%E2%9C%93&tab=repositories&q=&type=&language=zig https://github.com/andrewrk?utf8=%E2%9C%93&tab=repositories&... Looks like he has an advent of code repo too.

This is so cool! I'm really impressed with what I've seen out of Zig so far. I need to come up with a project to try it out with. It seems like a great successor to C

pron 7y ago

Yep. Zig is shaping up to be the low-level programming language I've been waiting for to replace C++ for me. It just needs to mature and stabilize a bit before it's production-quality.

3fe9a03ccd14ca5 7y ago
Why not rust?
- FpUser 7y ago
  Why Rust?
  - KnightHawk3 7y ago
    articles about rust don't have to include a link to "what is Rust" like this one does.
    - FpUser 7y ago
      For one thing I do not think you can implement allocator in Rust. This alone would disqualify it as a "low level"/"systems" language in my opinion.
      - shepmaster 7y ago
        You can implement an allocator in Rust; it's unclear why you think this is not possible. One example: - https://github.com/fitzgen/bumpalo https://github.com/fitzgen/bumpalo
        FpUser 7y ago
        I said "I do not think". I do not really know Rust. Obviously I was wrong.
        deleted 7y ago
        [deleted]
        dunkelheit 7y ago
        Worth noting that support for custom allocators in standard collections is not finalized yet: https://github.com/rust-lang/rust/issues/32838 https://github.com/rust-lang/rust/issues/32838 The (awesome) bumpalo crate that you link to gets around this by providing ported implementations of Vec and String, but if you need e.g. a custom-allocated HashMap, you need to implement it yourself.
        shepmaster 7y ago
        Thanks for the additional points! What you state is true, but somewhat orthogonal to the point that the grandparent post was making (and I sought to refute). Creating an allocator is inherently possible. Using that allocator with the rest of the ecosystem is currently not stable, as you point out. As a sometimes Rust embedded developer, I look forward to both parameterized allocators and fallible allocation.
        yellowapple 7y ago
        Also worth noting that this is one thing Zig seems to have gotten quite right already: every standard library function which might need to allocate memory requires the user of that function to pass in an allocator of one's choosing, whether provided with the standard library or provided from scratch. For example, I've been (slowly, given limited free time) working on a SQLite binding for Zig. SQLite has its own allocator, which I've wrapped like so: const std = @import("std"); const Allocator = std.mem.Allocator; const ArrayList = std.ArrayList; // This is all ripped from Zig's C allocator, with adaptations to point to // SQLite's allocator instead. pub const allocator = &allocator_state; var allocator_state = Allocator{ .reallocFn = realloc, .shrinkFn = shrink, }; fn realloc(self: *Allocator, old_mem: []u8, old_align: u29, new_size: usize, new_align: u29) ![]u8 { std.debug.assert(new_align <= @alignOf(c_longdouble)); const old_ptr = if (old_mem.len == 0) null else @ptrCast(*c_void, old_mem.ptr); const buf = sqlite3_realloc64(old_ptr, @intCast(u64, new_size)) orelse return error.OutOfMemory; return @ptrCast([*]u8, buf)[0..new_size]; } fn shrink(self: *Allocator, old_mem: []u8, old_align: u29, new_size: usize, new_align: u29) []u8 { const old_ptr = @ptrCast(*c_void, old_mem.ptr); const buf = sqlite3_realloc64(old_ptr, @intCast(u64, new_size)) orelse return old_mem[0..new_size]; return @ptrCast([*]u8, buf)[0..new_size]; } And later, to actually open a database (where we need an allocator to add a null byte to a Zig string to satisfy SQLite's expectations for a database name, so we might as well use SQLite's)¹: pub fn open(name: []const u8) !Database { // "allocator" here being the const-defined one above var cstrName = try std.cstr.addNullByte(allocator, name); defer allocator.free(cstrName); var db: Database = undefined; var rc = sqlite3_open(cstrName.ptr, &db); if (rc == SQLITE_OK) { return db; } else { _ = sqlite3_close(db); return errorCode(rc); } } Of course, it'd be even better if such a wrapper actually used SQLite's own support for custom allocators to follow the Zig stdlib convention of allowing the user to supply one's own allocator. Going the other way seemed like a reasonable short-term choice, though, and it was a good enough excuse for me to learn the ropes on custom allocators (even if most of the code ultimately came from Zig's own C allocator). ---- ¹: It turns out that this specific example will apparently be entirely unnecessary in future versions of Zig; the master branch documentation seems to do away with "Zig strings" v. "C strings", instead just making strings null-terminated by default (using what looks to be new support for "sentinel-terminated" pointers/arrays/slices). Looks like I've got some work to do :)
      - pjmlp 7y ago
        You also cannot fully implement libc in ISO C, without using either language extensions or an external Assembler. So I guess it is not a "low level"/"systems".
        FpUser 7y ago
        True. You beat me. But C with extensions does qualify ;)
        pjmlp 7y ago
        So does any other language with extensions, even stuff like CircuitPython.
    - jakear 7y ago
      They did when Rust was as mature as Zig is now. Language popularity is a reasonable deciding factor when one is starting a project that has a hiring component; personal projects not so much.
- csande17 7y ago
  Rust is great for when you're writing a serious, security-critical program that can't have any memory-corruption bugs or data races. It makes writing programs a little more challenging, and sometimes you sacrifice a bit of runtime performance compared to C, but it's often worth it. But Game Boy Advance games don't really fit that description. GBA games don't accept untrusted input, and nothing bad happens if they're "compromised". (Like, when people discovered arbitrary code execution in Super Mario World, no one was worried about the security implications.) So languages like C or Zig that let you cowboy values directly into specific memory locations can be a better choice. I'm excited about Zig in particular because the mission statement seems to be "C but nicer" -- you get the same basic programming model, but with things like instance methods, generic types, better macros, arbitrary-bit-integer types and a "crash when hitting undefined behavior" compile mode.
  - swiley 7y ago
    Arbitrary code execution isn’t that big a deal when one of the features of the device is that it accepts a ram image over its synchronous serial port which is jumped into after being received.
  - shpongled 7y ago
    Idk, I use Rust wherever I would use any other programming language, but I'm also a huge fan of the language in general. There's no need to limit it to "serious" applications
  - saagarjha 7y ago
    > nothing bad happens if they're "compromised" It can make debugging your program a lot harder :)
  - Jyaif 7y ago
    > GBA games don't accept untrusted input You have a very narrow definition of untrusted input.
  - OatMilkLatte 7y ago
    On the contrary - when people discovered an ACE bug in Super Mario World, they PogChamp'd.
- olodus 7y ago
  They are different languages and you can be exited for both and want to use both. I think it is unnecessary to have this kind of comment after every statement on other languages as if ones excitement for one would completely take the other one out of the picture. I would say why I really like Zig is because the minimalism of C is still there in the syntax and it makes a whole lot of very smart choices to keep this simplicity while being so much more expressive than C. If you really need some Rust pro's I would say it is great as the language that finally brings more of ML and functional ideas into high performance programming. Most languages nowadays have fp things but Rust has it very deep into its core. Other than that it is great to see proof systems reaching the mainstream and the security guarantees its ownership system gives is great.
- jokoon 7y ago
  learning curve, mostly
- LessDmesg 7y ago
  Because it's too heavy on the "fight the compiler" security stuff. Rust is well-designed all around, but no fun to program in.
- pron 7y ago
  It's all a matter of personal preference, and Rust is just not what I'm looking for in a C++ replacement, I guess. My biggest issue with C++ is the complexity of the language. C++ is a language that fetishizes accidental complexity, making it the center of things, and now it seems that Rust is saying, "hold my beer." Zig, on the other hand, fits my aesthetics pretty much perfectly, although I'm sure that, as with all programming languages, some people would have the opposite preference. As for correctness, one thing I've learned in the years I've been using formal methods is that there are many paths to correctness, and I'm starting to think that even on that front Zig's approach (of dynamic verification) might ultimately prove a better one.
- pjmlp 7y ago
  Not the OP, for me what I am looking forward is a systems language with automatic memory management, in the same vein as Modula-3, Active Oberon, D or System C#. Swift fills that slot, but only on Apple platforms. Linux hardly has portable support even for file access and Windows will get supported some day, and most 3rd party libraries assume Apple anyway. D has a great community, but still found lacking in some areas. .NET AOT compiled with the learnings taken from System C# (7.x - 9) is the closest for my daily coding activities. Ideally Delphi like with automatic memory management. Or maybe having a Rust IDE with visual representation of lifetimes would already be productive enough.
  - 80386 7y ago
    Maybe a stupid question: if I want to write cross-platform desktop GUI apps and be able to take full advantage of the desktop GUI (menus, status icons in the system tray, etc.), and I'm mostly developing on Windows, what should I learn? That's what I'm looking for, and I'm sure it already exists; I just don't know how to find it other than asking around. (I tried to install some Haskell GUI libraries, but that's very difficult on Windows. I eventually got haskell-gi to install, but as far as I could tell, it had no support for status icons.)
    - pjmlp 7y ago
      If you are doing Windows stuff and want native UI, then there is no way around Delphi, .NET or C++ (or C if you are masochist enough to use bare bones Win32). Qt does a pretty good job for C++ and Python, but it is not native if that is what you're looking for. JavaFX would be a good approach if you are into JVM languages, but you might need to do some JNI wrappers to call stuff like system tray, as just like Qt it does its own rendering. Some corporations, go the route of having common code for the business logic, and then create an abstraction layer for stuff like system tray, UI widgets and stuff. Although is does require additional development cost. So you call something like show_tray_message "New Email" and have an implementation for each OS that you care about. If you are using Haskell, have you tried Haskell Platform?
      - 7y ago

nemo1618 7y ago

I've been doing Advent of Code in Zig. It's a far cry from "real world" programming, but still a decent way to get a feel for the language.

wycy 7y ago
Do you have a public repo of your Advent code? I started out trying to use Zig but couldn’t find documentation on how to complete even basic tasks (like passing a filename as a command line arg, then opening and reading a file line by line), so I gave up. Maybe seeing a repo of good Zig code accomplishing these tasks would get me going.
- turndown 7y ago
  Here[1] is a playlist of the creator of Zig coding in Zig. He also has some solutions for Advent of Code. 1. https://www.youtube.com/watch?v=hBCsWEQ_asM&list=PLviMr_WImMhHA_yCD2-VfUSB_j4qSQ8pf https://www.youtube.com/watch?v=hBCsWEQ_asM&list=PLviMr_WImM...
  - wycy 7y ago
    > He also has some solutions for Advent of Code. I had looked at his 2018 Advent repo and was disappointed to find that he simply pasted his input directly into the code, whereas I like to compile generic binaries that can read inputs from the command line. However, it looks like his 2019 solutions for days 1 and 2 at least do read input from a file, so this year looks like it'll be a better starting point.
- crowhack 7y ago
  Check out the Zig standard library and the tests for examples on doing some basic stuff with the language. Tests are generally at the end of files, you can search for "test". 0.5.0 Documentation https://ziglang.org/documentation/0.5.0/#Introduction https://ziglang.org/documentation/0.5.0/#Introduction root std library https://github.com/ziglang/zig/tree/master/lib/std https://github.com/ziglang/zig/tree/master/lib/std examples of writing and reading to a file https://github.com/ziglang/zig/blob/master/lib/std/event/fs.zig#L1307 https://github.com/ziglang/zig/blob/master/lib/std/event/fs.... There are also a ton of projects that the creator has done with Zig, you can check those out for more examples as well. https://github.com/andrewrk?utf8=%E2%9C%93&tab=repositories&q=&type=&language=zig https://github.com/andrewrk?utf8=%E2%9C%93&tab=repositories&... Looks like he has an advent of code repo too.