5 ms·

Zig is becoming more production-worthy

126 points by Shoop 4y ago

SV_BubbleTime 4y ago
My benchmark for how serious a C replacement is, is when it successfully moves to not embedded and people actually use it. So far Rust has the smallest of inroads to embedded. I hope Zig makes it, but I’ve been down this road before.
- anonymoushn 4y ago
  A bunch of people on the discord care about and use the freestanding target, but I don't know much about this.
- slimsag 4y ago
  Check out[0] and the Zig Embedded Group[1] - it's not well publicized right now, but there's actually quite a lot of work going on here & Zig seems quite suitable for embedded compared to some other languages. > The standard library can be used unmodified on freestanding targets thanks to explicit allocation, comptime is extremely useful for things like precalculated lookup tables, and the unfinished C backend (part of the stage 2 compiler) means we’ll be able to target exotic architectures that LLVM can’t. [0] https://allyourcodebase.com/embedded/ https://allyourcodebase.com/embedded/ [1] https://github.com/ZigEmbeddedGroup https://github.com/ZigEmbeddedGroup
  - dleslie 4y ago
    Still no m68k, sh2, etc?
    - Toaster-King 4y ago
      Both these arch's are contingent on LLVM support, as there is no self-hosted backend (yet). m68k support was merged in LLVM 13, but I haven't seen anyone use it with Zig.
- girvo 4y ago
  I’m excited for Zig’s possible future in embedded, too. I currently use Nim for our firmware at work, because at the end of the day —compileOnly means it’s just C. It’s been excellent for ESP-IDF/FreeRTOS, but I’d love to see Zig tackle it as well. One lovely side effect of using Nim is our “business logic” code is remarkably simple in the firmware, as I got PPPoS working nicely with our Cat-M1/LTE NB-IoT modem, so making network requests is literally a single line of standard-library Nim. Quite lovely! The less we have to write C/C++ the better, and I’d love to see Zig and Rust do a great job in embedded-land!
  - birdfood 4y ago
    I've been diving into Nim in my free time after experimenting with Zig and Rust. I really appreciate how clearly I can layout business logic in code without needing to qualify what the compiler should do (my biggest issue with rust is all the stuff you need to do to satisfy the borrow checker I feel obfuscates your intention). Getting to use Nim for your day job sounds like a dream! I'm particularly keen on Nim's UFCS
    - girvo 4y ago
      > I'm particularly keen on Nim's UFCS One of my favourite parts about UFCS is how it can turn C libraries that I've had to bind into nice clean looking interfaces! esp_err_t sw_enableRx(SwSerial *self, bool State) Becomes proc sw_enableRx*(self: ptr SwSerial, State: bool): esp_err_t {.importc: "$1", header: "<SwSerial.h>".} Which when called is super lovely! var port = sw_open(params, etc) port.enableRx(true)
      - birdfood 4y ago
        The end result doesn't look anything like C! Really nice. Nim almost feels like I'm writing a dynamic scripting language, except that I've worked with a typed python code base and it sucked because typing always felt taped on. With generics in Nim I feel like I'm duck typing, but my ducks are compile time checked! I'm keen on experimenting with protocol oriented programming and as far as I understand, UFCS provides this really neatly to the language. I really like the idea of being able to define my own types and have them seamlessly work with functionality of other libs (and vice-versa) without needing to resort to a language feature like traits.
elromulous 4y ago
It's been really great watching zig progress. I'm on the fence on some of its design choices, but I think there's room in this world for zig as a truly modern c.
verdagon 4y ago
I love how Zig is pushing the state of the art forward. I have some expertise in the area, and I think the future is in languages that prioritize simplicity and developer velocity like Zig is doing. > The core team will then be able to begin thinking about: ... Exploring hot-code-swapping Hot code swapping, plus Zig's ability to cross-compile, plus release-safe's memory assistance without mental overhead, all seem to come from one underlying drive: support and empower the programmer without getting in their way. When designing a language, it's important to keep the user's ultimate goal in mind: making useful software. For some domains that might mean adding restrictions, but for other domains it means getting out of the programmer's way and making language mechanisms and tooling so they can iterate, experiment, and build faster. I'm particularly excited about Zig's future in webassembly, where many safety concerns are already handled by sandboxing. It's amazing to read that someone ported an entire game to webassembly with Zig.
- giancarlostoro 4y ago
  > I think the future is in languages that prioritize simplicity and developer velocity like Zig is doing. I kind of dont like Zig because of the syntax its just a little out of the norm from what I'm used to. I like D more if I want to go the C-like route, just hate that its not quite as popular as Go or Rust seem to be. Currently I'm diving into Nim more than anything though, it feels like the sweet spot for me.
  - NinoScript 4y ago
    One gets used to syntax, don’t let that be the reason you don’t like a language.
    - giancarlostoro 4y ago
      It's not just syntax, it is obviously C-like which I like, but it is the way programs look, I think Zig is maybe more low level than I care for.
  - sam0x17 4y ago
    I wish I had known about D like a decade ago. I swear it was just too ahead of its time.
xupybd 4y ago
Wow 40-60 hours at work then 40 on a project at home. I'm lucky to get an hour a week for hobbies.
- anonymoushn 4y ago
  Is this because of parenthood or something?
  - xupybd 4y ago
    Yeah exactly, a wife and child. I'm happy with the deal. It's just an eye opener to see how much time people can dedicate to their craft. Even when I was single I don't remember having that much time. Chores, making dinner, keeping in touch with friends and family would have left me with less than 40 hours if I'd worked 60 hours. I'm impressed with their diligence.
    - saurik 4y ago
      I just don't do most of these things (chores, making dinner, keeping in touch with anyone... etc.).
suby 4y ago
Zig looks very promising, but there are a few nitpicks I have which keep me from deep diving into it. The most annoying thing I've found so far is treating unused variables as compiler errors. I understand this is something more and more languages are doing, but I can't get over it. It makes writing and prototyping code annoying and tedious, especially during the initial learning phase. Zig trusts the programmer to do things like manually manage their memory, but unused variables is a bridge too far I guess. I don't understand why this isn't a compiler option. I don't want to leave a purely negative comment so I'll add that the only reason I'm posting in the first place is because, my own personal annoyances aside, the language does look very nice. Especially comptime, I wish every language had a similar construct built in as seamlessly as it is in zig.
- chienandalou 4y ago
  If the 'unused variable'-handling is the only thing that holds you back: it's quite simple to build the zig compiler and patch it. See this post by ryuukk in the corresponding issue on github: https://github.com/ziglang/zig/issues/335#issuecomment-1013800916 https://github.com/ziglang/zig/issues/335#issuecomment-10138... and also https://github.com/ziglang/zig/issues/335#issuecomment-1018439327 https://github.com/ziglang/zig/issues/335#issuecomment-10184... I use this method to build a zig compiler to work with, and when I build a release build of my zig-project I switch to the official compiler and fix the handful 'unused variable' errors. Works fine for me.
  - delphLonepaw 4y ago
    I think the unused error is great, and a lot of people once they got used to it, it becomes quite the useful message, some bugs and some mistakes not easy to catch are quite there now. Giving it a bit of time is a good way to get used to it and ends generally (at least in my opinion) in better code. Outside that :shrug:
  - ihateolives 4y ago
    Having to build your own version of the compiler to fix this annoyance is like using a sledgehammer to crack a nut. It should be a simple flag, whichever way the default, but it shouldn't require building a compiler. That's nuts, both in a bad and a good way.
japhib 4y ago
I used Zig for a couple of Advent of Code problems last year. I decided that Zig is not a language I’m going to be using. Here’s why: - If you ever want to allocate memory, you have to pass in an allocator to the function doing the allocating. You also have to explicitly allocate and deallocate. - Zig has no concept of a string - it’s just a slice of bytes. This also means Zig has no support for string concatenation, UTF-8, regex, or any of the other many niceties we’ve come to expect as standard. Zig is not the next Rust or the next C++ - it’s very much the next C. Zig may be fine for people programming an OS or very highly performance sensitive application. But it’s too low level, and too obtuse about being low-level, for me to ever want to actually use it.
- nyberg 4y ago
  - Passing the allocator gives the user of the container control over where memory is allocated and the scheme used to clean it all up. You can always set a global allocator if you wish, nothing forces you to use it as a parameter. - Regex can be provided as a library and specialized at comptime. There's never been a need for regex to be part of a primitive type and many other languages do fine without it. Concatenation is a question of "where do you allocate memory" as you have explicit allocation it's not clear what zig should do with it thus the default is to let you call std.mem.concat and dealing with the possible failure or having a look at the problem and asking if you really need concat in the first place. Often you don't as formatting string is better done with std.fmt and ArrayList(u8)'s writer().
- hn92726819 4y ago
  > Zig has no concept of a string - it’s just a slice of bytes. This also means Zig has no support for ... regex I used to think the same thing but it makes sense that for a finite state machine, the matcher doesn't need to work with validated strings at all. You should read the first 2 paragraphs of burntsushi's (wrote rust regex implementation and a lot more) doc comment here: https://docs.rs/bstr/latest/bstr/#when-should-i-use-byte-strings https://docs.rs/bstr/latest/bstr/#when-should-i-use-byte-str...
- ksec 4y ago
  >t’s very much the next C And that is great, once Zig is fully settled down we need something like Objective-Zig, or may be call it Zag.
fulafel 4y ago
Zig seems like a reasonable fit for WebAssembly for some cases if the memory safety story can be made good enough. (Even though wasm is sandboxed you don't want your in-sandbox app pwned after all)

126 points by Shoop 4y ago

My benchmark for how serious a C replacement is, is when it successfully moves to not embedded and people actually use it. So far Rust has the smallest of inroads to embedded. I hope Zig makes it, but I’ve been down this road before.

anonymoushn 4y ago
A bunch of people on the discord care about and use the freestanding target, but I don't know much about this.
slimsag 4y ago
Check out[0] and the Zig Embedded Group[1] - it's not well publicized right now, but there's actually quite a lot of work going on here & Zig seems quite suitable for embedded compared to some other languages. > The standard library can be used unmodified on freestanding targets thanks to explicit allocation, comptime is extremely useful for things like precalculated lookup tables, and the unfinished C backend (part of the stage 2 compiler) means we’ll be able to target exotic architectures that LLVM can’t. [0] https://allyourcodebase.com/embedded/ https://allyourcodebase.com/embedded/ [1] https://github.com/ZigEmbeddedGroup https://github.com/ZigEmbeddedGroup
- dleslie 4y ago
  Still no m68k, sh2, etc?
  - Toaster-King 4y ago
    Both these arch's are contingent on LLVM support, as there is no self-hosted backend (yet). m68k support was merged in LLVM 13, but I haven't seen anyone use it with Zig.
girvo 4y ago
I’m excited for Zig’s possible future in embedded, too. I currently use Nim for our firmware at work, because at the end of the day —compileOnly means it’s just C. It’s been excellent for ESP-IDF/FreeRTOS, but I’d love to see Zig tackle it as well. One lovely side effect of using Nim is our “business logic” code is remarkably simple in the firmware, as I got PPPoS working nicely with our Cat-M1/LTE NB-IoT modem, so making network requests is literally a single line of standard-library Nim. Quite lovely! The less we have to write C/C++ the better, and I’d love to see Zig and Rust do a great job in embedded-land!
- birdfood 4y ago
  I've been diving into Nim in my free time after experimenting with Zig and Rust. I really appreciate how clearly I can layout business logic in code without needing to qualify what the compiler should do (my biggest issue with rust is all the stuff you need to do to satisfy the borrow checker I feel obfuscates your intention). Getting to use Nim for your day job sounds like a dream! I'm particularly keen on Nim's UFCS
  - girvo 4y ago
    > I'm particularly keen on Nim's UFCS One of my favourite parts about UFCS is how it can turn C libraries that I've had to bind into nice clean looking interfaces! esp_err_t sw_enableRx(SwSerial *self, bool State) Becomes proc sw_enableRx*(self: ptr SwSerial, State: bool): esp_err_t {.importc: "$1", header: "<SwSerial.h>".} Which when called is super lovely! var port = sw_open(params, etc) port.enableRx(true)
    - birdfood 4y ago
      The end result doesn't look anything like C! Really nice. Nim almost feels like I'm writing a dynamic scripting language, except that I've worked with a typed python code base and it sucked because typing always felt taped on. With generics in Nim I feel like I'm duck typing, but my ducks are compile time checked! I'm keen on experimenting with protocol oriented programming and as far as I understand, UFCS provides this really neatly to the language. I really like the idea of being able to define my own types and have them seamlessly work with functionality of other libs (and vice-versa) without needing to resort to a language feature like traits.

elromulous 4y ago

It's been really great watching zig progress. I'm on the fence on some of its design choices, but I think there's room in this world for zig as a truly modern c.

verdagon 4y ago

I love how Zig is pushing the state of the art forward. I have some expertise in the area, and I think the future is in languages that prioritize simplicity and developer velocity like Zig is doing. > The core team will then be able to begin thinking about: ... Exploring hot-code-swapping Hot code swapping, plus Zig's ability to cross-compile, plus release-safe's memory assistance without mental overhead, all seem to come from one underlying drive: support and empower the programmer without getting in their way. When designing a language, it's important to keep the user's ultimate goal in mind: making useful software. For some domains that might mean adding restrictions, but for other domains it means getting out of the programmer's way and making language mechanisms and tooling so they can iterate, experiment, and build faster. I'm particularly excited about Zig's future in webassembly, where many safety concerns are already handled by sandboxing. It's amazing to read that someone ported an entire game to webassembly with Zig.

giancarlostoro 4y ago
> I think the future is in languages that prioritize simplicity and developer velocity like Zig is doing. I kind of dont like Zig because of the syntax its just a little out of the norm from what I'm used to. I like D more if I want to go the C-like route, just hate that its not quite as popular as Go or Rust seem to be. Currently I'm diving into Nim more than anything though, it feels like the sweet spot for me.
- NinoScript 4y ago
  One gets used to syntax, don’t let that be the reason you don’t like a language.
  - giancarlostoro 4y ago
    It's not just syntax, it is obviously C-like which I like, but it is the way programs look, I think Zig is maybe more low level than I care for.
- sam0x17 4y ago
  I wish I had known about D like a decade ago. I swear it was just too ahead of its time.

xupybd 4y ago

Wow 40-60 hours at work then 40 on a project at home. I'm lucky to get an hour a week for hobbies.

anonymoushn 4y ago
Is this because of parenthood or something?
- xupybd 4y ago
  Yeah exactly, a wife and child. I'm happy with the deal. It's just an eye opener to see how much time people can dedicate to their craft. Even when I was single I don't remember having that much time. Chores, making dinner, keeping in touch with friends and family would have left me with less than 40 hours if I'd worked 60 hours. I'm impressed with their diligence.
  - saurik 4y ago
    I just don't do most of these things (chores, making dinner, keeping in touch with anyone... etc.).

suby 4y ago

Zig looks very promising, but there are a few nitpicks I have which keep me from deep diving into it. The most annoying thing I've found so far is treating unused variables as compiler errors. I understand this is something more and more languages are doing, but I can't get over it. It makes writing and prototyping code annoying and tedious, especially during the initial learning phase. Zig trusts the programmer to do things like manually manage their memory, but unused variables is a bridge too far I guess. I don't understand why this isn't a compiler option. I don't want to leave a purely negative comment so I'll add that the only reason I'm posting in the first place is because, my own personal annoyances aside, the language does look very nice. Especially comptime, I wish every language had a similar construct built in as seamlessly as it is in zig.

chienandalou 4y ago
If the 'unused variable'-handling is the only thing that holds you back: it's quite simple to build the zig compiler and patch it. See this post by ryuukk in the corresponding issue on github: https://github.com/ziglang/zig/issues/335#issuecomment-1013800916 https://github.com/ziglang/zig/issues/335#issuecomment-10138... and also https://github.com/ziglang/zig/issues/335#issuecomment-1018439327 https://github.com/ziglang/zig/issues/335#issuecomment-10184... I use this method to build a zig compiler to work with, and when I build a release build of my zig-project I switch to the official compiler and fix the handful 'unused variable' errors. Works fine for me.
- delphLonepaw 4y ago
  I think the unused error is great, and a lot of people once they got used to it, it becomes quite the useful message, some bugs and some mistakes not easy to catch are quite there now. Giving it a bit of time is a good way to get used to it and ends generally (at least in my opinion) in better code. Outside that :shrug:
- ihateolives 4y ago
  Having to build your own version of the compiler to fix this annoyance is like using a sledgehammer to crack a nut. It should be a simple flag, whichever way the default, but it shouldn't require building a compiler. That's nuts, both in a bad and a good way.

japhib 4y ago

I used Zig for a couple of Advent of Code problems last year. I decided that Zig is not a language I’m going to be using. Here’s why: - If you ever want to allocate memory, you have to pass in an allocator to the function doing the allocating. You also have to explicitly allocate and deallocate. - Zig has no concept of a string - it’s just a slice of bytes. This also means Zig has no support for string concatenation, UTF-8, regex, or any of the other many niceties we’ve come to expect as standard. Zig is not the next Rust or the next C++ - it’s very much the next C. Zig may be fine for people programming an OS or very highly performance sensitive application. But it’s too low level, and too obtuse about being low-level, for me to ever want to actually use it.

nyberg 4y ago
- Passing the allocator gives the user of the container control over where memory is allocated and the scheme used to clean it all up. You can always set a global allocator if you wish, nothing forces you to use it as a parameter. - Regex can be provided as a library and specialized at comptime. There's never been a need for regex to be part of a primitive type and many other languages do fine without it. Concatenation is a question of "where do you allocate memory" as you have explicit allocation it's not clear what zig should do with it thus the default is to let you call std.mem.concat and dealing with the possible failure or having a look at the problem and asking if you really need concat in the first place. Often you don't as formatting string is better done with std.fmt and ArrayList(u8)'s writer().
hn92726819 4y ago
> Zig has no concept of a string - it’s just a slice of bytes. This also means Zig has no support for ... regex I used to think the same thing but it makes sense that for a finite state machine, the matcher doesn't need to work with validated strings at all. You should read the first 2 paragraphs of burntsushi's (wrote rust regex implementation and a lot more) doc comment here: https://docs.rs/bstr/latest/bstr/#when-should-i-use-byte-strings https://docs.rs/bstr/latest/bstr/#when-should-i-use-byte-str...
ksec 4y ago
>t’s very much the next C And that is great, once Zig is fully settled down we need something like Objective-Zig, or may be call it Zag.

fulafel 4y ago

Zig seems like a reasonable fit for WebAssembly for some cases if the memory safety story can be made good enough. (Even though wasm is sandboxed you don't want your in-sandbox app pwned after all)