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

121–130 of 315 posts

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

#121

Post by zozbot234 »

PaulRobinson wrote: post #117
pmarreck wrote: post #110

Earlier quoted context omitted.

An AI will be able to handle updating your code for 95% of your breaking changes

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…

Just have to wait a few months until a new model with updated pretrained knowledge comes out.

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

#122

Post by melodyogonna »

hxtk wrote: post #97
jauntywundrkind wrote: post #66

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…

It’s surprising to me how much people seem to want async in low level languages. Async is very nice in Go, but the reason I reach for a language like Zig is to explicitly control those things. I’m happily writing a Zig project right now using libxev as my io_uring abstraction.

But Zig's async is being designed to enable this low-level control.

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

#123

Post by rererereferred »

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…

No shame in waiting for 1.0. Specially if you want to read docs rather than the code itself.

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

#124

Post by zozbot234 »

sgt wrote: post #109
flohofwoe wrote: post #94

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). Rust will also never replace C or C++ in any meaningful way, at best new code gets written in new languages (and Rust being only one among many, and among languages used for new projects will also be C and C++, just maybe not that often). I th…

> 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 bit of a challenge.

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

#125

Post by strawhatguy »

flohofwoe wrote: post #98
pron wrote: post #96

Earlier quoted context omitted.

> I take a 'living' language any day over of a language that's ossified because of strict backward compatibility requirements Maybe you would, but >95% of serious projects wouldn't. The typical lifetime of a codebase intended for a lasting application is over 15 or 20 years (in industrial control or aerospace, where low-level languages are commonly used, codebases typically last for over 30 years), and while such cha…

> The typical lifetime of a codebase intended for a lasting application is over 15 or 20 years (in industrial control or aerospace). Either those applications are actively maintained, or they aren't. Part of the active maintenance is to decide whether to upgrade to a new compiler toolchain version (e.g. when in doubt, "never change a running system"), old compiler toolchains won't suddenly stop working. FWIW, trying…

You could fix versions, and probably should. However willful disregard of prior interfaces encourages developers code to follow suit.

It’s not like Clojure or Common Lisp, where a decades old software still runs, mostly unmodified, the same today, any changes mainly being code written for a different environment or even compiler implementation. This is largely because they take breaking user code way more seriously. Alot of code written in these languages seem to have similar timelessness too. Software can be “done”.

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

#127

Post by weakfish »

zozbot234 wrote: post #121
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…

Just have to wait a few months until a new model with updated pretrained knowledge comes out.

Or spend those few months doing the update :-)

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

#128

Post by solatic »

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 how to take inefficient systems and make improvements to move towards theoretical maximum efficiency. When the system is written in an inefficient language like Python or Node, fundamentally, you have no choice but to start to move the hotpath behind FFI and drop down to a systems language. At that point your choices are basically C, C++, Rust, or Zig. Of the four choices, Zig today is already simplest to learn, with fewer footguns, easier to work with, easier to read and write, and easier to test. And you're not going to write 100k LOC of optimized hotpath code. And when you understand the cost savings involved in reducing your compute needs by sometimes more than 90% by getting the hotpath optimized, you understand that there is very much indeed a business case to learning Zig today.

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

#129

Post by zozbot234 »

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…

> ...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 yours.

[0] https://en.wikipedia.org/wiki/Crab_People of course.

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

#130

Post by kibwen »

zozbot234 wrote: post #120
andrepd wrote: post #115

Earlier quoted context omitted.

I would also add that Rust manages this very well. Editions let you do breaking changes without actually breaking any code, since any package (crate) needs to specify the edition it uses. So when in 30 years you're writing code in Rust 2055, you can still import a crate that hasn't been updated since 2015 :)

Unfortunately editions don't allow breaking changes in the standard library, because Rust codes written in different "editions" must be allowed to interoperate freely even within a single build. The resulting constraint is roughly similar to that of never ever breaking ABI in C++.

> The resulting constraint is roughly similar to that of never ever breaking ABI in C++.

No, not even remotely. ABI-stability in C++ means that C++ is stuck with suboptimal implementations of stdlib functions, whereas Rust only stabilizes the exposed interface without stabilizing implementation details.

> Unfortunately editions don't allow breaking changes in the standard library

Surprisingly, this isn't true in practice either. The only thing that Rust needs to guarantee here is that once a specific symbol is exported from the stdlib, that symbol needs to be exported forever. But this still gives an immense amount of flexibility. For example, a new edition could "remove" a deprecated function by completely disallowing any use of a given symbol, while still allowing code on an older edition to access that symbol. Likewise, it's possible to "swap out" a deprecated item for a new item by atomically moving the deprecated item to a new namespace and making the existing item an alias to that new location, then in the new edition you can change the alias to point to the new item instead while leaving the old item accessible (people are exploring this possibility for making non-poisoning mutexes the default in the next edition).

Post reply on HN