4 ms·

I tried Zig some time ago to use with microcontrollers. It has a generator for the pins, which was nice. But subsequent versions broke as Zig changed syntax. So

I tried Zig some time ago to use with microcontrollers. It has a generator for the pins, which was nice. But subsequent versions broke as Zig changed syntax. So I started going down the rabbit-hole (it needed a newer version of llvm, for example) until I eventually decided that the game wasn't worth the candle. The fact that another breaking change has been introduced confirms my suspicion that Zig is not ready for primetime. My conclusion is to just use C. For low-level programming it's very hard to improve on C. There is not likely to be any killer feature that some other contender will allow you to write the same code in a fifth of the lines nor make the code any more understandable. Yes, C may have its quirky behaviour that people gnash their teeth over. But ultimately, it's not that bad. If you want to use a better C, use C++. C++ is perfectly fine for using with microcontrollers, for example. Now get back to work!

eddythompson80 1y ago
> The fact that another breaking change has been introduced confirms my suspicion that Zig is not ready for primetime. Huh, it was the 0.14 version number for me.
- dtech 1y ago
  0.x doesn't say as much as it used to 20 years ago, many fine projects keep it for way too long.
  - eddythompson80 1y ago
    Zig has a pretty well documented 1.0 goals. It was the first thing I heard about zig from Andrew about. https://youtu.be/5eL_LcxwwHg https://youtu.be/5eL_LcxwwHg
    - arp242 1y ago
      Yes, that was the point. To understand what that "0.14" means, we need to know those "well documented 1.0 goals" and some hour long YouTube video. That is, merely the "0.14 version number" without context is not enough, like your previous comment said.
      - eddythompson80 1y ago
        You look at the version, the milestones https://github.com/ziglang/zig/milestones https://github.com/ziglang/zig/milestones, and it makes sense. The YouTube video is just more proof. Picking up a 0.14 software without looking the most basic thing about it like “oh, what kind of 0.14 is this” then complaining that “it’s not ready for prime time” is odd behavior
- kzrdude 1y ago
  Pandas (different world: Python) arguably peaked in hype (if not popularity) before reaching 1.0
sgt 1y ago
But at some point it'll be ready. Might it be worth it then?
overflyer 1y ago
Dude Zig is clearly pre 1.0. It can introduce breaking changes with every commit and rightfully so. I mean d'oh it's Not ready for Prime Time.
- hencoappel 1y ago
  Zig uses ZeroVer so don't expect it to ever hit 1.0. https://0ver.org/ https://0ver.org/
  - bigstrat2003 1y ago
    Is that versioning site supposed to be some kind of joke? I can't really figure out if they are joking or serious - the tone comes off as joking, but it could be read as serious too.
    - dtech 1y ago
      I guess you're being Poe's lawwed but it's definitely a joke
  - deleted 1y ago
    [deleted]
self_awareness 1y ago
The point of the language stability is spon on, but it's actually very easy to improve on C, not in terms of performance or readability, but rather safety and the ability to encode more constraints in a compact form than C would ever allow. Sometimes it's not about less lines, but the same amount of lines that encode a lot more stuff than these lines in C.
juliangmp 1y ago
Obligatory C is not a low level language: https://queue.acm.org/detail.cfm?id=3212479 https://queue.acm.org/detail.cfm?id=3212479 I also have to disagree with C++ for micro controllers / bare metal programming. You don't get the standard library so you're missing out on most features that make C++ worthwhile over C. Sure you get namespaces, constexpr and templates but without any standard types you'll have to build a lot on your own just to start out with. I recently switched to Rust for a bare metal project and while its not perfect I get a lot more "high level" features than with C or C++.
- vlovich123 1y ago
  Doesn’t Rust nostd give up a comparable part that C++ would give up? It’s typically all the memory allocations that inhibit the use of data structures.
  - juliangmp 1y ago
    Yeah you don't get its std library, but Rust makes a distinction between core and std, and core is available. Doesn't sound like a lot but you get your standard types like Result and Option, you get slices since they're part of the language or if you need allocation you can define the global allocator in core::alloc. This distinction makes it really comfortable to use. Though one caveat about no_std is that you'll need some support library like https://docs.rs/cortex-m-rt/latest/cortex_m_rt/ https://docs.rs/cortex-m-rt/latest/cortex_m_rt/
  - deleted 1y ago
    [deleted]
- TuxSH 1y ago
  > You don't get the standard library Why is that? Sure, allocating containers and other exception-throwing facilities are a no-go but the stdlib still contains a lot of useful and usable stuff like <type_traits>, <utility>, <source_location>, <bit>, <optional>, <coroutine> [1] and so on [1] yes they allocate, but operator new can easily be overridden for the promise class and can get the coro function arguments forwarded to it. For example if coro function takes a "Foo &foo", you can have operator new return foo.m_Buffer (and -fno-exceptions gets rid of unwinding code gen)
vlovich123 1y ago
I haven’t done embedded stuff in Rust, but the nostd crates and automatically generated libraries from manufacturer SVDs seemed neat. The ability to trivially pull in already written functionality would also seem fantastic.
steeve 1y ago
It absolutely is and we (ZML) are using it with great success. That said, Andrew said he would absolutely would break compat if it meant things go in the right direction. Yes, it can be painful sometimes, yes I do not always agree with his choices, but it has never been a blocker nor a significant time sink. And in the end, things do improve significantly. In this case, I think the new IO stuff is incredible.
- xeonmc 1y ago
  It also helps job prospects of Zig programmers within organizations that have already adopted Zig -- more breakage, more job security.
  - ulbu 1y ago
    advances the purposes of cynics as well, so big bonus.
  - vendiddy 1y ago
    Do you honestly believe what you're saying
flohofwoe 1y ago
Well, that's why Zig is 0.x and not 1.x. I'm fine even with large scale breakage if the direction is right (and looking at the mess that C++ has become for the sake of backward compatibility, IMHO breaking changes are also the better option after 1.x, as long as there's features to help manage the required changes). Also, "Zig the language" is currently better designed than "Zig the stdlib", so breaking changes will actually be needed in the future at least in the stdlib because getting it right the first time is very unlikely, and I don't like to be stuck with bad initial design decisions which then can't be fixed for decades (again, as a perfect example of how not to do it, see C++)
scrubs 1y ago
Well, that's a sentiment I don't quite agree with. It willfully ignores industry experience with c/c++ whence zig, rust, D, and others. If your micro controller is say <5000 lines maybe ... but an OS or a mellanox verbs or dpdk API won't fall so easily to such surface level thinking. Maybe zig could help itself by providing through llvm what Google sometimes does for large api breaking changes ... have llvm tool that searches out old api invocation update to new so upgrading is faster, more operationally effective. Google's tools do this and give the dev a source code pr candidate. That's how they can change zillions of calls with confidence.
mamcx 1y ago
I can relate, because I have so much things in years that broke left and right, but at the same time (except if you are talking about pre/alphas) I think is unhealthy to be vary of breaking changes. A language, in special, should be able to do it. Extreme compatibility is the way to make the mistake that is C. A breaking change that fix something is a investing that extend infinity to the feature. Fear to do it, like in C, is how you accumulate errors, mistakes, millions of dollars wasted, because is also compound debt. P.D: I think langs should be fast to break pre 1.0, and maybe have room to do it each 5/7 years. Despite the debacle of Python (that is in fact more reflective of python than of breaking), there should be possible to make a relatively painless sunsetting with good caring
- flohofwoe 1y ago
  The problem I have with python2 vs python3 wasn't breaking backward compatibility, but that their "solution" for UNICODE strings is such a weird mess (treating string- and byte-streams as something completely separate instead of treating strings as UTF-8 encoded views on byte streams) The only string encoding that matters today is UTF-8, all others are relics from the early 90s and the sooner we get rid of those the better - e.g. Python caused a whole lot of pain for a solution that would have been useful 30 years ago, but not today.
  - kbolino 1y ago
    There's another problem that's affecting more than just Python too: grapheme clusters. It turns out that even a sequence of scalars (code points excluding surrogates) isn't always a safe abstraction anymore.

eddythompson80 1y ago

> The fact that another breaking change has been introduced confirms my suspicion that Zig is not ready for primetime. Huh, it was the 0.14 version number for me.

dtech 1y ago
0.x doesn't say as much as it used to 20 years ago, many fine projects keep it for way too long.
- eddythompson80 1y ago
  Zig has a pretty well documented 1.0 goals. It was the first thing I heard about zig from Andrew about. https://youtu.be/5eL_LcxwwHg https://youtu.be/5eL_LcxwwHg
  - arp242 1y ago
    Yes, that was the point. To understand what that "0.14" means, we need to know those "well documented 1.0 goals" and some hour long YouTube video. That is, merely the "0.14 version number" without context is not enough, like your previous comment said.
    - eddythompson80 1y ago
      You look at the version, the milestones https://github.com/ziglang/zig/milestones https://github.com/ziglang/zig/milestones, and it makes sense. The YouTube video is just more proof. Picking up a 0.14 software without looking the most basic thing about it like “oh, what kind of 0.14 is this” then complaining that “it’s not ready for prime time” is odd behavior
kzrdude 1y ago
Pandas (different world: Python) arguably peaked in hype (if not popularity) before reaching 1.0

sgt 1y ago

But at some point it'll be ready. Might it be worth it then?

overflyer 1y ago

Dude Zig is clearly pre 1.0. It can introduce breaking changes with every commit and rightfully so. I mean d'oh it's Not ready for Prime Time.

hencoappel 1y ago
Zig uses ZeroVer so don't expect it to ever hit 1.0. https://0ver.org/ https://0ver.org/
- bigstrat2003 1y ago
  Is that versioning site supposed to be some kind of joke? I can't really figure out if they are joking or serious - the tone comes off as joking, but it could be read as serious too.
  - dtech 1y ago
    I guess you're being Poe's lawwed but it's definitely a joke
- deleted 1y ago
  [deleted]

self_awareness 1y ago

The point of the language stability is spon on, but it's actually very easy to improve on C, not in terms of performance or readability, but rather safety and the ability to encode more constraints in a compact form than C would ever allow. Sometimes it's not about less lines, but the same amount of lines that encode a lot more stuff than these lines in C.

juliangmp 1y ago

Obligatory C is not a low level language: https://queue.acm.org/detail.cfm?id=3212479 https://queue.acm.org/detail.cfm?id=3212479 I also have to disagree with C++ for micro controllers / bare metal programming. You don't get the standard library so you're missing out on most features that make C++ worthwhile over C. Sure you get namespaces, constexpr and templates but without any standard types you'll have to build a lot on your own just to start out with. I recently switched to Rust for a bare metal project and while its not perfect I get a lot more "high level" features than with C or C++.

vlovich123 1y ago
Doesn’t Rust nostd give up a comparable part that C++ would give up? It’s typically all the memory allocations that inhibit the use of data structures.
- juliangmp 1y ago
  Yeah you don't get its std library, but Rust makes a distinction between core and std, and core is available. Doesn't sound like a lot but you get your standard types like Result and Option, you get slices since they're part of the language or if you need allocation you can define the global allocator in core::alloc. This distinction makes it really comfortable to use. Though one caveat about no_std is that you'll need some support library like https://docs.rs/cortex-m-rt/latest/cortex_m_rt/ https://docs.rs/cortex-m-rt/latest/cortex_m_rt/
- deleted 1y ago
  [deleted]
TuxSH 1y ago
> You don't get the standard library Why is that? Sure, allocating containers and other exception-throwing facilities are a no-go but the stdlib still contains a lot of useful and usable stuff like <type_traits>, <utility>, <source_location>, <bit>, <optional>, <coroutine> [1] and so on [1] yes they allocate, but operator new can easily be overridden for the promise class and can get the coro function arguments forwarded to it. For example if coro function takes a "Foo &foo", you can have operator new return foo.m_Buffer (and -fno-exceptions gets rid of unwinding code gen)

vlovich123 1y ago

I haven’t done embedded stuff in Rust, but the nostd crates and automatically generated libraries from manufacturer SVDs seemed neat. The ability to trivially pull in already written functionality would also seem fantastic.

steeve 1y ago

It absolutely is and we (ZML) are using it with great success. That said, Andrew said he would absolutely would break compat if it meant things go in the right direction. Yes, it can be painful sometimes, yes I do not always agree with his choices, but it has never been a blocker nor a significant time sink. And in the end, things do improve significantly. In this case, I think the new IO stuff is incredible.

xeonmc 1y ago
It also helps job prospects of Zig programmers within organizations that have already adopted Zig -- more breakage, more job security.
- ulbu 1y ago
  advances the purposes of cynics as well, so big bonus.
- vendiddy 1y ago
  Do you honestly believe what you're saying

flohofwoe 1y ago

Well, that's why Zig is 0.x and not 1.x. I'm fine even with large scale breakage if the direction is right (and looking at the mess that C++ has become for the sake of backward compatibility, IMHO breaking changes are also the better option after 1.x, as long as there's features to help manage the required changes). Also, "Zig the language" is currently better designed than "Zig the stdlib", so breaking changes will actually be needed in the future at least in the stdlib because getting it right the first time is very unlikely, and I don't like to be stuck with bad initial design decisions which then can't be fixed for decades (again, as a perfect example of how not to do it, see C++)

scrubs 1y ago

Well, that's a sentiment I don't quite agree with. It willfully ignores industry experience with c/c++ whence zig, rust, D, and others. If your micro controller is say <5000 lines maybe ... but an OS or a mellanox verbs or dpdk API won't fall so easily to such surface level thinking. Maybe zig could help itself by providing through llvm what Google sometimes does for large api breaking changes ... have llvm tool that searches out old api invocation update to new so upgrading is faster, more operationally effective. Google's tools do this and give the dev a source code pr candidate. That's how they can change zillions of calls with confidence.

mamcx 1y ago

I can relate, because I have so much things in years that broke left and right, but at the same time (except if you are talking about pre/alphas) I think is unhealthy to be vary of breaking changes. A language, in special, should be able to do it. Extreme compatibility is the way to make the mistake that is C. A breaking change that fix something is a investing that extend infinity to the feature. Fear to do it, like in C, is how you accumulate errors, mistakes, millions of dollars wasted, because is also compound debt. P.D: I think langs should be fast to break pre 1.0, and maybe have room to do it each 5/7 years. Despite the debacle of Python (that is in fact more reflective of python than of breaking), there should be possible to make a relatively painless sunsetting with good caring

flohofwoe 1y ago
The problem I have with python2 vs python3 wasn't breaking backward compatibility, but that their "solution" for UNICODE strings is such a weird mess (treating string- and byte-streams as something completely separate instead of treating strings as UTF-8 encoded views on byte streams) The only string encoding that matters today is UTF-8, all others are relics from the early 90s and the sooner we get rid of those the better - e.g. Python caused a whole lot of pain for a solution that would have been useful 30 years ago, but not today.
- kbolino 1y ago
  There's another problem that's affecting more than just Python too: grapheme clusters. It turns out that even a sequence of scalars (code points excluding surrogates) isn't always a safe abstraction anymore.