Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

ziglang.org

Post reply on HN
Print view View original

151–160 of 315 posts

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

#151

Post by dxdm »

radarroark wrote: post #108
BrouteMinou wrote: post #59

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…

Pretty typical jaded HN comment there, chief. "This language's churn is more than I prefer -- why would anyone use it?" If you're not interested, just downvote and move on. Wondering out loud why anyone would actively use it ("for some reasons?") is a lame waste of bytes.

That comment you're complaining about is a useful signal for me who only watches zig from the far periphery. I feel like I'm getting good mileage out of it, just like I do from other, different ones. I'm glad it's in the mix.

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

#152

Post by ozgrakkurt »

solatic wrote: post #128
BrouteMinou wrote: post #59

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…

To each his own, but while I can certainly understand the hesitancy of an architect to pick Zig for a project that is projected to hit 100k+ lines of code, I really think you're missing out. There is a business case to using Zig today. True in general but 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…

As a counter argument to this. I was able to replicate the subset of zig that I wanted, using c23. And in the end I have absolute stability unless I break things to “improve”.

Personally, it is a huge pain to rewrite things and update dependencies because the code I am depending on is moving out from under me. I also found this to be a big problem in Rust.

And another huge upside is you have access to best of everything. As an example, I am heavily using fuzz testing and I can very easily use honggfuzz which is the best fuzzer according to all research I could find, and also according to my experience so far.

From this perspective, it doesn’t make sense to use zig over c for professional work. If I am writing a lot of code then I don’t want to rewrite it. If am writing a very small amount of code with no dependencies, then it doesn’t matter what I use and this is the only case where I think zig might make sense.

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

#153

Post by [deleted] »

Cloudef wrote: post #148
lioeters wrote: post #142

Earlier quoted context omitted.

It sounds like Zig would benefit from someone like you on the inside, as a member or active contributor, reviewing and participating in the development of the standard library. Zig is one of my favorite new languages, I really like the cross-compiler too. I'm not a regular user yet but I'm hopeful for its long-term success as a language and ecosystem. It's still early days, beta/dev level instability is expected, and…

I dont think the core team accepts LLM generated code in the std.

[deleted]

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

#154

Post by metaltyphoon »

pron wrote: post #136
metaltyphoon wrote: post #118

Earlier quoted context omitted.

> Given that Rust is quite an old language now and its adoption is still so low, So being part of 3 major OS (Windows, Android and now Linux), the big 3 cloud providers having SDKs for the language, used by so much tooling (js + python) and being part of major internet infrastructure means its “slow” adoption then wow…

Very much so once you compare it to how quickly C++ (and, in fact, any language that's ever been in the top 5 or so) achieved similar milestones. Rust's adoption is very impressive when you compare it to, say, Haskell or Clojure, but not when you compare it to languages that achieved significant and long-lasting popularity. It's roughly similar to Ada's adoption when it was of a similar age (Ada was more prevalent th…

> Very much so once you compare it to how quickly C++

C++ came out in 1985 and competed with C, COBOL, Pascal and FORTRAN. It was an overall improvement than those and therefore there is a legit reason for it to take off.

> how many of them end up using it (and to what extent) you see it's not like it's been with languages that ended up achieving real popularity

I assume many places that have a huge codebase in C++ would just do a port to Rust. That would almost always cause problems but for greenfield projects it's a no brainer IMO.

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

#155

Post by program_whiz »

vlovich123 wrote: post #146
solatic wrote: post #137

Earlier quoted context omitted.

Eh, I'd say that Rust has a different set of footguns. You're correct that you won't run into use-after-free footguns, but Rust doesn't protect you from memory leaks, unsafe code is still unsafe, and the borrow checker and Rust's language complexity are their own kind of footguns. But I digress. I was thinking of Zig in comparison to C when I wrote that. I don't have a problem conceding that point, but I still believ…

> but Rust doesn't protect you from memory leaks In theory no. In practice it really does. > unsafe code is still unsafe Ok, but most rust code is not unsafe while all zig code is unsafe. > and the borrow checker and Rust's language complexity are their own kind of footguns Please elaborate. They are something to learn but I don’t see the footgun. A footgun is a surprisingly defect that’s pointed at your foot and eas…

Not the GP, but I've noticed that because if you don't anticipate how you might need to mutate or share state in the future, you can have a "footgun" that forces large-scale code changes for relatively small "feature-level" changes, because of the rust strictness. Its not a footgun in the sense that your code does what you don't expect, its a footgun in that your maintenance and ability to change code is not what you expect (and its easy to do). I'm sure if you are really expert with rust, you see it coming and don't use patterns that will cause waves of changes (but if you're expert at any language you avoid the footguns).

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

#156

Post by flohofwoe »

pmarreck wrote: post #133
PaulRobinson wrote: post #117

Earlier quoted context omitted.

No it won't. LLMs are good at dealing with things they've seen before, not at novel things. When novel things arise, you will either have to burn a shed ton of tokens on "reasoning", hand hold them (so you're doing advanced find and replace in this example, where you have to be incredibly precise and detailed about your language, to the point it might be quicker to just make the changes), or you have to wait until th…

Apologies, but your information is either outdated from lack of experience with the latest frontier models, or you don't realize the fact that 99.9% of the work you do is not novel in all capacities. Have you only used Copilot, or something? Because that's what it sounds like. Since the performance of the latest models (Opus 4.6 max-effort, gpt-5.3-Codex) is nothing short of astonishing. Real-world example: Claude is…

> so I had it write a language guide for 0.15.2

Tbh, while impressive that it appears to work, that guide looks very tailored to the Zig stdlib subset used in your projects and also looks like a lot more work than just fixing the errors manually ;) For a large code base which would amortise the cost of this guide I still wouldn't trust the automatic update without carefully reviewing each change.

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

#157

Post by ozgrakkurt »

ozgrakkurt wrote: post #152
solatic wrote: post #128

Earlier quoted context omitted.

To each his own, but while I can certainly understand the hesitancy of an architect to pick Zig for a project that is projected to hit 100k+ lines of code, I really think you're missing out. There is a business case to using Zig today. True in general but 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…

As a counter argument to this. I was able to replicate the subset of zig that I wanted, using c23. And in the end I have absolute stability unless I break things to “improve”. Personally, it is a huge pain to rewrite things and update dependencies because the code I am depending on is moving out from under me. I also found this to be a big problem in Rust. And another huge upside is you have access to best of everyth…

Also I was also thinking that breaking doesn’t matter that much, but my opinion changed around 10k lines of code very quickly. At some point I really stopped caring about every piece and wanted to forget about it and move on really

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

#158

Post by ceteia »

zozbot234 wrote: post #124
sgt wrote: post #109

Earlier quoted context omitted.

> I think Rust and Zig really don't overlap much when it comes to target audience. E.g. if you're attracted to Rust, you'll probably find Zig terrible (and the other way around). This is ironic since these two crowds are mostly solving the same type of problems. It's just democrats vs republicans type of split, some of it is just for show and philosophical.

Rust is solving the memory safety problem, Zig is solving the 'idiomatic interop with existing C coding patterns' problem. These couldn't be more different - C-like idiomatic code is generally antithetical to 'safe' modularity since it often relies on tacit global invariants for correct behavior. Interestingly, Carbon is kinda trying to tackle both at the same time (though starting from C++ in their case) which is a…

I am not sure how Carbon will go. The Carbon compiler is not ready to be used yet by the public as I understand it, and the roadmap has not been updated for some time now, it seems.

https://docs.carbon-lang.dev/docs/project/roadmap.html

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

#159

Post by ceteia »

kartoffelsaft wrote: post #132
zozbot234 wrote: post #124

Earlier quoted context omitted.

Rust is solving the memory safety problem, Zig is solving the 'idiomatic interop with existing C coding patterns' problem. These couldn't be more different - C-like idiomatic code is generally antithetical to 'safe' modularity since it often relies on tacit global invariants for correct behavior. Interestingly, Carbon is kinda trying to tackle both at the same time (though starting from C++ in their case) which is a…

I hear Cardon get mention on rare occasion, and with how rare that is I have to assume it's been completely stagnant. Does it offer anything over C++ in current year? Seems like C++ interop begets turning your language into C++ with different syntax in a way that C interop just doesn't.

The GitHub project has some activity at least, and they might be coming with some announcement later this year.

https://github.com/carbon-language/carbon-lang/

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

#160

Post by solatic »

vlovich123 wrote: post #146
solatic wrote: post #137

Earlier quoted context omitted.

Eh, I'd say that Rust has a different set of footguns. You're correct that you won't run into use-after-free footguns, but Rust doesn't protect you from memory leaks, unsafe code is still unsafe, and the borrow checker and Rust's language complexity are their own kind of footguns. But I digress. I was thinking of Zig in comparison to C when I wrote that. I don't have a problem conceding that point, but I still believ…

> but Rust doesn't protect you from memory leaks In theory no. In practice it really does. > unsafe code is still unsafe Ok, but most rust code is not unsafe while all zig code is unsafe. > and the borrow checker and Rust's language complexity are their own kind of footguns Please elaborate. They are something to learn but I don’t see the footgun. A footgun is a surprisingly defect that’s pointed at your foot and eas…

> a footgun is a surprising defect that's pointed at your foot and easy to trigger

Close, but not the way I think of a footgun. A footgun is code that was written in a naive way, looks correct, submitted, and you find out after submitting it that it was erroneous. Good design makes it easy for people to do the right thing and difficult to do the wrong thing.

In Rust it is extremely easy to hit the borrow checker including for code which is otherwise safe and which you know is safe. You walk on eggshells around the borrow checker hoping that it won't fire and shoot you in the foot and force you to rewrite. It is not a runtime footgun, it is a devtime footgun.

Which, to be fair, is sometimes desired. When you have a 1m+ LOC codebase and dozens of junior engineers working on it and requirements for memory safety and low latency requirements. Fair enough trade-off in that case.

But in Zig, you can just call defer on a deinit function. Complexity is the eternal enemy, and this is just a much simpler approach. The price of that simplicity is that you need to behave like an adult, which if the codebase (hotpath optimization) is <1k LOC I think is eminently reasonable.

Post reply on HN