Zig is becoming more production-worthy

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.<p>&gt; The core team will then be able to begin thinking about: ... Exploring hot-code-swapping<p>Hot code swapping, plus Zig&#x27;s ability to cross-compile, plus release-safe&#x27;s memory assistance without mental overhead, all seem to come from one underlying drive: support and empower the programmer without getting in their way.<p>When designing a language, it&#x27;s important to keep the user&#x27;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&#x27;s way and making language mechanisms and tooling so they can iterate, experiment, and build faster.<p>I&#x27;m particularly excited about Zig&#x27;s future in webassembly, where many safety concerns are already handled by sandboxing. It&#x27;s amazing to read that someone ported an entire game to webassembly with Zig.

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&#x27;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&#x27;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&#x27;t understand why this isn&#x27;t a compiler option.<p>I don&#x27;t want to leave a purely negative comment so I&#x27;ll add that the only reason I&#x27;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.

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:<p>- 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.<p>- 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.<p>Zig is not the next Rust or the next C++ - it’s very much the next C.<p>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.

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

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

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

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&#x27;t want your in-sandbox app pwned after all)