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.
Zig is becoming more production-worthy
31–40 of 73 posts
Re: Zig is becoming more production-worthy
#32I 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
#33Earlier 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 ;)
Re: Zig is becoming more production-worthy
#34Wow 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?
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
#35My 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…
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
#36Earlier 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.
Re: Zig is becoming more production-worthy
#37Earlier 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?
Re: Zig is becoming more production-worthy
#38Zig 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…
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
#39Zig 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…
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.