Live data from Hacker News

Zig – io_uring and Grand Central Dispatch std.Io implementations landed

ziglang.org

221–230 of 315 posts

Re: Zig – io_uring and Grand Central Dispatch std.Io implementations landed

#221
post #218
post #192

Earlier quoted context omitted.

I guess C++ teams at Microsoft, Google, IBM, Adobe don't count.

It's not as widespread in these companies as you and many Rust evangelists imply it is. Specially because it's not a drop-in replacement for C++. As Zig is for C. So when Zig hits 1.0 these companies will probably consider Zig much more than they do today. Understandably.

First of all, if I am an evangelist of anything, it is about safe systems programming with automatic resource management languages, if I had a magic wand, we would be talking about languages like D and AOT C#, not Rust.

Secondly, let us know when Amazon rewrites Firecracker in Zig, Android replaces Rust with Zig, or Mark Russinovich goes to some Zig conference explaining why Azure is dropping Rust for Zig,

"Mark Russinovich, Microsoft Azure CTO tells Rust Nation UK 2025 why Azure is moving to Rust from C++"

https://www.youtube.com/watch?v=SmUprpjCWjM

Re: Zig – io_uring and Grand Central Dispatch std.Io implementations landed

#222

I 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…

I'm so sorry to hear about your diagnosis whatever it is :-P.

Re: Zig – io_uring and Grand Central Dispatch std.Io implementations landed

#223
post #205

Earlier quoted context omitted.

In the end it is a matter of which industries the Rust community sees as relevant to gain adoption, and which ones the community is happy that Rust will never take off. Do you know one industry that likes very much tossing closed-source proprietary blobs over the wall? Game studios, and everyone that works in the games industry providing tooling for AAA studios.

> Game studios, and everyone that works in the games industry providing tooling for AAA studios. You know what else is common in the games industry? C# and NDA's. C# means that game development is no longer a C/C++ monoculture, and if someone can make their engine or middleware usable with C# through an API shim, Native AOT, or some other integration, there are similar paths forward for using Rust, Zig, or whatever e…

Do you know what C# has and Rust doesn't? A binary distribution package for libraries with a defined ABI.

Re: Zig – io_uring and Grand Central Dispatch std.Io implementations landed

#224

Earlier quoted context omitted.

> ...in the cloud especially, saving server resources can make a significant impact on the bottom line. There are not nearly enough performance engineers who understand how to take inefficient systems and make improvements to move towards theoretical maximum efficiency. That's a very good point, actually. However... > with fewer footguns ..the Crab People[0] would definitely quibble with that particular claim of your…

I would quibble with all of the claims, other than easier to learn. I really see no advantage for Zig over Rust after you get past that 2 first two weeks.

Coming from Go, I'm really disappointed in Rust compiler times. I realize they're comparable to C++, and you can structure your crates to minimize compile times, but I don't care. I want instant compilation.

Zig is trying to get me instant compilation and I see that as a huge advantage for Zig (even past the first 2 weeks).

I'll probably stick with Rust as my "low level language" due to its safety, type system, maturity, library ecosystem, and career opportunities.

But I remain jealous of Zig's willingness to do extreme things to make compilation faster.

Re: Zig – io_uring and Grand Central Dispatch std.Io implementations landed

#225
post #189

As always with Zig posts, here come the haters. I really wonder why you even care about it. Can't we all be happy that Andrew and his team are doing their damnest to create something they believe in? Myself I am deeply inspired by their engineering spirit. In other posts I see people "worry" that Zig might not become mainstream. Why do people worry about these things? Just use the language if it helps you solve your…

This isn't a Zig-specific problem; the same thing has happened in waves for now decades on this site (see: Lisp, Ruby, Rust, etc).

> You don't need to treat it like an identity.

This is an eternal problem in this industry and it is by far the most annoying thing about it.

Re: Zig – io_uring and Grand Central Dispatch std.Io implementations landed

#226

Contrary to the neggies, I am positive in Zigs effort to iterate & improve. Right now there is no language that is good at io-uring. There are ok offerings, but nothing really has modern async joy that works with uring. Whoever hammers out a good solution here is going to have a massive leg up. Rust is amazing in so many ways but it has been quite a brutal road to trying to support io-uring ok, and efforts are still…

I am also positive, but when is the language going to hit a stable very LTS version that won't be touched for a long time? If you want to compete with C, you can't do so without understanding that its stability and the developers focusing on mastering its practices, design, limitations, tooling has been one of the major successes.

> when is the language going to hit a stable very LTS version that won't be touched for a long time?

Is there any reason to be rushing it? Zig isn't languishing without activity. Big things are happening, and it's better in my opinion for them to get the big important stuff right early than it is to get something stable that is harder to change and improve later.

"Competing with C" means innovating, not striving to meet feature parity so it can be frozen in time. It's not as though C has anything terribly exciting going on with it. Let them cook.

Re: Zig – io_uring and Grand Central Dispatch std.Io implementations landed

#227
I'm not a zig fan myself, but I'm glad to see a substantial project with momentum and vision moving ahead. It's not languishing. It's trying interesting new things. It's striving for incremental gains consistently over time.

There's a lot of hate in these comments. Nobody is forcing you to use Zig and it's not trying to be "done" right now. And in fact, if the only thing they were focusing on was putting a bow on the project to call it "1.0", it probably wouldn't achieve any of it's long term goals of being a mainstream systems programming language. If it takes another five years or fifteen, as long as the project moves forward with the same energy, it's going to be fine.

For a fairly small project that's largely one dude, this is far more than most of us have or could hope to ever achieve ourselves. Give the people putting in the work credit where credit is due.

Re: Zig – io_uring and Grand Central Dispatch std.Io implementations landed

#228
post #219
post #209

Earlier quoted context omitted.

What concerns me is that the design of Carbon in aspects seem to have serious issues already now. In case that you are well familiar with for instance pattern matching, might you have any opinions on the pattern matching that is currently proposed for Carbon? https://docs.carbon-lang.dev/docs/design/pattern_matching.ht...

I am not a Google employee, as such I don't care where they take Carbon, other than being a technology nerd that had compiler design as one of the areas I majored in. Regarding the linked pattern matching proposal, it seems alright to me, not everything has to be ML like.

Are you really OK with runtime "expression patterns"?

    match (0, 1, 2) {
      case (F(), 0, G()) => ...
    }
> Here (F(), 0, G()) is not an expression, but three separate expressions in a tuple pattern. As a result, this code will call F() but not G(), because the mismatch between the middle tuple elements will cause pattern matching to fail before reaching G(). Other than this short-circuiting behavior, a tuple pattern of expression patterns behaves the same as if it were a single expression pattern.

How would that work with exhaustiveness checking? As far as I can tell, they themselves believe that Carbon's exhaustiveness checking will be very poor.

And OK with implicit conversions? Especially when combined with their way of handling templates for pattern matching?

Re: Zig – io_uring and Grand Central Dispatch std.Io implementations landed

#229
post #224

Earlier quoted context omitted.

I would quibble with all of the claims, other than easier to learn. I really see no advantage for Zig over Rust after you get past that 2 first two weeks.

Coming from Go, I'm really disappointed in Rust compiler times. I realize they're comparable to C++, and you can structure your crates to minimize compile times, but I don't care. I want instant compilation. Zig is trying to get me instant compilation and I see that as a huge advantage for Zig (even past the first 2 weeks). I'll probably stick with Rust as my "low level language" due to its safety, type system, matur…

On any Go production projects I worked on or near, the incremental compile time was slower than C++ and Rust.

A full build was definitely much faster, but not as useful. Especially when using a build system with shared networked caching (Bazel for example).

Yes those projects were a bloated mess, as it always seems to be.

Re: Zig – io_uring and Grand Central Dispatch std.Io implementations landed

#230
post #76

Earlier quoted context omitted.

Here's some advice: 1. if you're a casual user (ie you don't follow the development) don't try incomplete APIs that not even the creators of fully know how they are supposed to work (because they're still tinkering with them) also you can't expect docs until the design is somewhat finalized (which is not yet, fyi) 2. llms don't help when trying to make sense of the above (a feature that is not complete, that has no d…

> if you're a casual user (ie you don't follow the development) don't try incomplete APIs that not even the creators of fully know how they are supposed to work Is the completeness of each API formally documented anywhere? Maybe I missed something but it doesn't seem like it is, in which case the only way to know would be to follow what's happening behind the scenes.

Zig cuts releases. This API is not on a release of Zig yet. It's only available through nightly builds of master. "Casual users" should stick to releases if they don't want to deal with incomplete APIs.
Post reply on HN