As Andrew mentions in the post, even having a Twitter account was a source of stress. It's about more than just promoting his content.
It's a feeling I can sympathize with. In 2009 I deleted my Facebook account (or "deactivated" it, the only option at the time), and even though I wasn't using it much by then, it felt like a needless weight was suddenly lifted.
It might be rash if work had already started on it, but as with the other proposals on the issue tracker not labeled with "accepted", this is just a call for discussion and counter-proposals. At this point it's just the team collecting feedback, learning about affected use cases, and gauging feasibility -- opposite of rash, I'd say.
Gotta love goofy stunts that take effort to make! A spiritually similar programming language that also screams a lot is ArnoldC: https://lhartikk.github.io/ArnoldC/
In general Zig foregoes syntactic sugar and requires implementing higher-level APIs by composing primitives. But a new language feature is a candidate when it solves a use case that can't otherwise be solved, or opens up a path to more efficient code.
Loris' blog post points out that the new for loops address the latter:
> In the multi-sequence for loop version it’s only necessary to test once at the beginning of the loop that the two arrays have equal size, instead of having 2 assertions run every loop iteration. The multi-sequence for loop syntax helps convey intention more clearly to the compiler, which in turn lets it generate more efficient code.
It also builds on existing properties of slices/arrays, rather than adding a new "enumerate primitive".
The tension is understandable: Zig is explicitly not production-ready, yet it has such attractive performance and productivity properties, and has even proven useful in production scenarios (Bun, Uber, Tigerbeetle). But Andrew's suggestion is correctly aligned with Zig's mission and current level of maturity. If you have a complex project with lots of users like Jarred does, stick with a tagged release for now.
The highest priority of Zig pre-1.0 is to make the language the best it can be — which it will be in due time. The target audience of the master branch is those who can withstand churn and are focused on getting it there.
Same. My favorite geezer hacker/heist movie, Sneakers, drops a realistic San Francisco phone number (415 area code) near the end. I always wondered who would pick up if dialed...
Not mentioned in the talk, among the onslaught of media and merchandise following the success of the game was "Q*bert's Quazy Questions". It was one of my most treasured books as a kid because of the cute illustrations and heavy cardboard pages. The jokes are only superficially related to the game, of course.
Compiling to C source isn't planned for the reference Zig compiler, as far as I know. It's more interested in helping people moving people off of C (see `zig translate-c`).
But for supporting more esoteric targets you might be interested in the goals of this ultra-early-stage assembler. ("Planned targets: All of them.")
As a (part-time) C programmer, I wouldn't really consider a "C replacement" that can't compile to C. Part of the appeal of C is that it's easy to integrate into other projects, regardless of the build system or obscure hardware it might be targeting. If you require a compiler for a language few people have heard of (even a very cool language), it seriously limits your potential user-base.
If you tell me that I can write better, safer code by using Zig, but I can also compile it into a .c artifact that anybody can use, now that is a tempting proposition!
> Part of the appeal of C is that it's easy to integrate into other projects, regardless of the build system or obscure hardware it might be targeting.
Zig should be just as easy to integrate. Sure, it's one more thing to install, but it'll spit out .o files just like a C compiler would if you tell it to (which means you can shove it in your Makefile or what have you), and will spit out .h files for linking. You miss out on Zig's build system niceties that way, though (including the cross-compilation demonstrated in the article).
Regardless, being a "C replacement" kinda implies (if not outright explies) that it's replacing C; compiling to C kinda defeats that purpose. It'd still be useful, though, and is probably possible (might even be relatively trivial if LLVM and/or Clang provide some mechanism to generate C from LLVM IR or some other intermediate representation).
I think three intention here is not the other way round. You can add c files to your zig project to make the transition, integration with existing code, as well as collaboration with c only programmers easier. After all zig wants to replace c, not the other way round.
Unless you really really need obscure platforms, just forget about it. Make the jump, don't look back.
After you get a taste of a modern toolchain (with cross-compilation, dependency management, but withou not-quite-portable build files to endlessly fiddle with, without outdated compilers to work around), you will not want to have to compile a C file again.
Languages like Zig and Rust are easy to install. Mostly it's just a tarball, so it's less of an inconvenience than getting the right version of autotools.
its not obscure platforms, its a ton of embedded platforms (you may consider that obscure, but reality is there are millions and millions of devices out there running software on these "obscure" platforms), most of them don't have many options. At one stage I was writing write my own language to compile to C based around state machines and actors as so many devices tend to be some version (often badly implemented) of those two things. But I ended up moving out of the embedded world and kind of lost my prime motivation for doing it.
It's a feeling I can sympathize with. In 2009 I deleted my Facebook account (or "deactivated" it, the only option at the time), and even though I wasn't using it much by then, it felt like a needless weight was suddenly lifted.