I like Zig but it seems to just keep redesigning itself, while other languages like Odin “shipped” long ago and don’t seem to need to look back. Is Zig suffering from perfectionism syndrome where things are never good enough??
I think the main big thing that’s left for 1.0 is to resurrect async/await.. and that’s a huge thing because arguably very few if any language has gotten that truly right.
As the PR description mentions: “This is part of a series of changes leading up to "I/O as an Interface" and Async/Await Resurrection.”
So this work is partially related to getting async/await right. And getting IO right is a very important part of that.
I think it’s a good idea for Zig to try to avoid a Python 3 situation after they reach 1.0. The project seems fairly focused to me, but they’re trying to solve some difficult problems. And they spend more time working on the compiler and compiler infrastructure than other languages, which is also good. Working on their own backend is actually critical for the language itself, because part of what’s holding Zig back from doing async right is limitations and flaws in LLVM
this was interesting! Do you have a link or something to be able to read about it?
https://www.reddit.com/r/Zig/comments/1d66gtp/comment/l6umbt...
Interesting. I like Zig. I dabble periodically. I’m hoping that maturity and our next generation ag tech device in a few years might intersect.
Throwing another colored function debacle in a language, replete with yet another round of the familiar but defined slightly differently keywords, would be a big turn off for me. I don’t even know if Grand Central Dispatch counts, but it—and of course Elixir/Erlang—are the only two “on beyond closures/callbacks” asynch system I’ve found worked well.
This would involve removing async/await as keywords from the language.
const pick_a_global_io = ...;
fn needs_io(io:IO) void {...}
fn doesnt_take_io() void {
needs_io(pick_a_global_io);
}
now, if you want to be a library writer, yeah, you have to color your functions if you don't want to be an asshole, but for the 95% use case this is not function coloring.
Programming languages which do get used are always in flux, for good reason - python is still undergoing major changes (free-threading, immutability, and others), and I'm grateful for it.
I still think what drives languages to continuously make changes is the focus on developer UX, or at least the intent to make it better. So, PLs with more developers will always keep evolving.
JangaFX stuff is written in Odin and has some pretty big users.
I wish it moved to snake_case for functions, this is a cosmetic detail but it drives me crazy.
They’re not rushing, that’s for sure. But I’ve never felt worried about 1.0 never happening in an unending pursuit of unrealistic impossible ideals.
It seems like folks expect stability pre 1.0.
People used to compare it as simpler than Rust. I don't agree that it's simple anymore at all.
None of this is meant to be badmouthing or insulting. I'm a polyglot but love simple languages and syntaxes, so I tend to overly notice such things.
I tend to fall into the former camp. Something like BF would be the ultimate simple language, even if not particularly useful.
And I don't see "crates using nightly features" as somehow a language complexity. Are we counting "Three different compilers with their own quirks" as a C++ complexity? Nor is the six week cadence a complexity. When naked functions stabilized a handful of people went "Hooray" and nearly everybody else doesn't care. And that's not even a feature in standard C++. You have to go read your vendor instructions and do it separately each time. "Yay!".
The ecosystem is part of what means to use a specific language, though.
Yeah, having to guess what standards and extensions each C and C++ compiler implement, is also an issue with them, and will eventually come to Rust as implementations eventually come up, originally there was only CFront and UNIX System V compilers.
a few things have been removed, too. and async/suspend/nosuspend/await, usingnamesplace are headed for the woodchipper.
So where is Zig's OS, browser, docker, engine, security, whatever XYZ, that would make having Zig on the toolbox a requirement?
I don't see Bun nor Tiger Beetle being that app.
Most of it you can already get in C and C++, by using the tools that have in the market for the last 30 years.