Live data from Hacker News

Zig is becoming more production-worthy

zigmonthly.org

31–40 of 73 posts

Re: Zig is becoming more production-worthy

#31
post #30

Earlier quoted context omitted.

For every feature X, there is a programming language Y that has had it for decades. It's not a question of inventing it, but rather of making it mainstream popular.

I expect that erlang is still significantly more popular than zig.

Of course it is. Zig is an up-and-comer, so most established languages will be more popular at this stage. But Zig aims to be a mostly general purpose language (which is what the majority of mainstream languages are), whereas Erlang does not.

Re: Zig is becoming more production-worthy

#32
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.

Re: Zig is becoming more production-worthy

#33
post #21

Earlier quoted context omitted.

You mean rust shouldn't allow easy to write out of bounds errors? I'm still waiting for a flag to disable runtime bound checks

I haven't mentioned Rust. I love KISS and Zig's simplicity especially but there is two sides to programming. The engineers perspective and the user perspective. I am both and prefer to have more paid hours and safer software ;)

Zig takes a different approach to safety. For example, Zig has checked arithmetic enabled by default in safe builds, can guarantee static allocation, and can recover from memory allocation failure. It depends on the definition of “safer software”, but for many domains where safety is a field [1], these are also important design decisions.

[1] https://spinroot.com/gerard/pdf/P10.pdf

Re: Zig is becoming more production-worthy

#34
post #24

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

Is this because of parenthood or something?

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.

Re: Zig is becoming more production-worthy

#35
post #29

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.

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 m…

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

Re: Zig is becoming more production-worthy

#36
post #34

Earlier quoted context omitted.

Is this because of parenthood or something?

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.

I just don't do most of these things (chores, making dinner, keeping in touch with anyone... etc.).

Re: Zig is becoming more production-worthy

#37
post #25
post #16

Earlier quoted context omitted.

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…

Still no m68k, sh2, etc?

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.

Re: Zig is becoming more production-worthy

#38
post #32

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 d…

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-10138... and also 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.

Re: Zig is becoming more production-worthy

#39
post #32

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 d…

It does make prototyping more annoying but on the other hand it's nice, when reading code, to know that all variables have a reason to be there / aren't "non sequitur"s. It also catches bugs occasionally.

Making it an optional flag has the issue of making it easier to just say "just compile this always with --allow-unused-vars" instead of cleaning up the code. We kinda see that happening with warnings in C/C++.

That said, I too think we should investigate if there's a reasonable middle ground that could be found.

Post reply on HN