[flagged]
You're right that zig is vaporware - not because of other languages - but because programming is going away entirely.
Zig – io_uring and Grand Central Dispatch std.Io implementations landed
51–60 of 315 posts
Re: Zig – io_uring and Grand Central Dispatch std.Io implementations landed
#52Earlier quoted context omitted.
Instead of debating for years (like other languages), zig just tries things out. Worst case you can always rollback changes. IMO best APIs and designs are those that are battle tested by end users, not won in an argument war during committee meetings. This makes zig unique. It's fun to use and it stays fresh. You can always just stay on older version of zig. But if you choose to update to newer version, you get new t…
> Instead of debating for years (like other languages), zig just tries things out. So did Rust pre-1.0 Stability guarantees are a pain in the neck. You can't just break other people's code willy nilly. > This makes zig unique. It's fun to use and it stays fresh. You mean like how Rust tried green threads pre-1.0? Rust gave up this one up because it made runtime too unwieldy for embedded devices.
Just on this point:
> You mean like how Rust tried green threads pre-1.0? Rust gave up this one up because it made runtime too unwieldy for embedded devices.
The idea with making std.Io an interface is that we're not forcing you into using green threads - or OS threads for that matter. You can (and should) bring your own std.Io implementation for embedded targets if you need standard I/O.
Re: Zig – io_uring and Grand Central Dispatch std.Io implementations landed
#53Earlier quoted context omitted.
So no one should even try because they will never win over all of the C/C++ crowd so are doomed to fail and forever to be a wannabe? I think Andrew has gone about things in a good way, going back to C and exploiting hindsight, not trying to offer everything as quickly as possible. Extend C but keep C interoperability and do both better than C++ instead of trying to be the next big thing and he goes about it in a very…
One should try, while being aware of the realities of language adoption. I disagree Zig is that great deal of a language, it would have been if we were talking about 1990's programming language ecosystem, not in 21st century. Use-after-free problems should not be something we still need to worry about, when tooling like PurifyPlus trace back to 1992.
I don't think Andrew believes Zig is going kill C or C++, he probably has hope but I think he is aware of the reality. He found a way to make a living on something he was passionate about.
Use-after-free is a fact of life until something kills C, but the realities of language adoption are against that. Zig seems interesting and worthwhile in offering a different perspective on the problem and does it in a way more agreeable than Rust or the like for all those who love C and are adverse to large complex languages. The realities of language adoption are as much for as against Zig, large numbers of people are still getting drawn to C and Zig seems to do a better job addressing why so many are drawn to it than the alternatives.
Re: Zig – io_uring and Grand Central Dispatch std.Io implementations landed
#54Earlier quoted context omitted.
Except for Tiger Beetle customers and the few ones using Bun, what traction?
I've read Bun is just a wrapper, not actual Zig implementation anyway. Also, making a financial database in beta language that constantly changes and breaks is "really smart".
You can actually go and read the source yourself [1]. If Bun is "just a wrapper", then surely Node.js and Deno are too?
Re: Zig – io_uring and Grand Central Dispatch std.Io implementations landed
#55Earlier quoted context omitted.
Instead of debating for years (like other languages), zig just tries things out. Worst case you can always rollback changes. IMO best APIs and designs are those that are battle tested by end users, not won in an argument war during committee meetings. This makes zig unique. It's fun to use and it stays fresh. You can always just stay on older version of zig. But if you choose to update to newer version, you get new t…
> Instead of debating for years (like other languages), zig just tries things out. Good > Worst case you can always rollback changes. No, you cannot. People will leave in masses. In perl they announced experiments with a mandatory use experimental :feature. You couldnt publish modules with those, or else you are at risk. This made perl exciting and fresh. Python on the other hand constantly broke API's, and had to in…
I recently ditched zig because of this.
I thought it was stable enough initially but they completely broke fuzz testing feature and didn’t fix it.
Also build system API and some other APIs change and it is super annoying.
Find it much better to use c23 with _BitInt integers and some macros and context passing for error handling.
Also some things like stack traces were broken in small ways in zig. It would report wrong lines in stack traces when compiling with optimizations. Also wasn’t able to cleanly collect stack traces into strings in production build.
It is understandable that breaking APIs is good for development but in most cases new API isn’t that good anyway.
And recently saw they even moved the time/Instant API to some other place too. This kind of thing is just super annoying with seemingly no benefit. Could have left the same API there and re-used it from somewhere else. But no, have to make it “perfect”
Re: Zig – io_uring and Grand Central Dispatch std.Io implementations landed
#56[flagged]
Instead of debating for years (like other languages), zig just tries things out. Worst case you can always rollback changes. IMO best APIs and designs are those that are battle tested by end users, not won in an argument war during committee meetings. This makes zig unique. It's fun to use and it stays fresh. You can always just stay on older version of zig. But if you choose to update to newer version, you get new t…
> IMO best APIs and designs are those that are battle tested by end users
Battle testing an API however requires time and the API to not constantly change.
Re: Zig – io_uring and Grand Central Dispatch std.Io implementations landed
#57Earlier quoted context omitted.
Can you elaborate? Zig has a lot of traction already.
Except for Tiger Beetle customers and the few ones using Bun, what traction?
Ghostty
Re: Zig – io_uring and Grand Central Dispatch std.Io implementations landed
#58Earlier quoted context omitted.
Kinda weird to blame Zig for not being at 1.0 yet while Jai is still in closed beta after 11 years. Meanwhile Zig is being in used in big-ish projects all over while Jai has... a single game engine? Jai looks cool but it's far far FAR behind and losing ground.
The fallacy of that argument would be if its author would seek adoption, however like Naughty Dog with their Lisp based language, John has no plans to have Jai win world adoption beyone his game engine.
That may be, but OP tried to claim that
> once Jai comes out, Zig will become obsolete
If Jai is happy to have limited adoption (which is fine), other languages will by definition not be displaced by Jai. That is even if we accept OPs implied point, that Jai is good enough to displace Zig, without further discussion. But even that seems to be rather doubtful.
Re: Zig – io_uring and Grand Central Dispatch std.Io implementations landed
#59I feel like it's worthless to keep up with Zig until they reach 1.0.
That thing, right here, is probably going to be rewritten 5 times and what not.
If you are actively using Zig (for some reasons?), I guess it's a great news, but for the Grand Majority of the devs in here, it's like an announcement that it's raining in Kuldîga...
So m'yeah. I was following Zig for a while, but I just don't think I am going to see a 1.0 release in my lifetime.