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

181–190 of 315 posts

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

#181

Post by davemp »

vlovich123 wrote: post #163
solatic wrote: post #160

Earlier quoted context omitted.

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

> 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. You’re contradicting yourself a bit here I think. Erroneous code generally won’t compile whereas in Zig it will happily do so. Also, Zig has plenty of foot guns (eg forgetting to call defer on a deinit but even misusing noalias or having an out of bounds result in memory corruptio…

> IMHO the zig footgun story with respect to UB behavior is largely unchanged relative to C/C++

The only major UB from C that zig doesn’t address is use after free afaik. How is that largely unchanged???

Just having an actual strong type system w/o the “billion dollar mistake” is a large change.

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

#182

Post by ceteia »

pron wrote: post #91
small_model wrote: post #78

I like Zig, lots of great features that work in unison. However the worry is by the time it reaches v1 Rust will have consumed the space that C/C++ used to. I think it will be a mainstream language though and gain a lot more traction after v1. There is also the issue of will people actually code by then.

> the worry is by the time it reaches v1 Rust will have consumed the space that C/C++ used to Given that Rust is quite an old language now and its adoption is still so low, I don't think that should be much of a worry, although that doesn't mean Zig will be the option of choice, and not stabilising is certainly not a good sign. At Rust's adoption rate, a language that hasn't been invented yet and that would show a mo…

Rust projects generally use licenses like MIT instead of GPL, and thus some major corporations support Rust a lot, and thus Rust will continue getting popular.

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

#183

Post by srcreigh »

There's a relevant open issue[1] here about stack memory optimization. It would be nice to be able to use a [500]u8 in a block and another [500]u8 in another block, and have that only contribute 500 bytes to the stack frame, but Zig can't currently do this.

(The green threads coro stack stuff makes this more important.)

[1]: https://github.com/ziglang/zig/issues/23475#issuecomment-279...

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

#184

Post by vlovich123 »

davemp wrote: post #181
vlovich123 wrote: post #163

Earlier quoted context omitted.

> 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. You’re contradicting yourself a bit here I think. Erroneous code generally won’t compile whereas in Zig it will happily do so. Also, Zig has plenty of foot guns (eg forgetting to call defer on a deinit but even misusing noalias or having an out of bounds result in memory corruptio…

> IMHO the zig footgun story with respect to UB behavior is largely unchanged relative to C/C++ The only major UB from C that zig doesn’t address is use after free afaik. How is that largely unchanged??? Just having an actual strong type system w/o the “billion dollar mistake” is a large change.

Depends how you compile it. If you’re compiling ReleaseFast/ReleaseSmall, it’s not very different from C (modulo as you said it has some language features to make it less likely you do it):

* Double free

* Out of bounds array access

* Dereferencing null pointers

* Misaligned pointer dereference

* Accessing uninitialized memory

* Signed integer overflow

* Accessing a union field for which the active tag is something else.

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

#185

Post by vlovich123 »

ozgrakkurt wrote: post #165
vlovich123 wrote: post #146

Earlier quoted context omitted.

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

As an example to this, I was using polars in rust as a dependency in a fairly large project. It has issues like panicking or segfaulting when using some data types (arrow array types) in the wrong place. It is extremely difficult to write an arrow implementation in Rust. It is much easier to do it in zig or c(without strict aliasing). I also had the same experience with glommio in Rust. Also the binary that we produc…

> To make it clear, I mean the huge footgun in rust is producing a ton of bloat and subpar code because you can’t write much and you end up depending on too many libraries

Nothing is forcing you to do that other than it’s easy to add dependencies. I don’t see how zig is much different

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

#186

Post by the_mitsuhiko »

pmarreck wrote: post #144
maleldil wrote: post #126

Earlier quoted context omitted.

They just did a massive reactor that broke nearly 100% of existing code. Only an early language can do that.

What version are you referring to? I've had zero issues updating my zig stuff to 0.15.2 with frontier LLM assistance.

0.16 changes things around dramatically.

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

#187

Post by LexiMax »

wolvesechoes wrote: post #169
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…

> Of the four choices, Zig today is already simplest to learn, Yes, with almost complete lack of documentation and learning materials it is definitely the easiest language to learn.

For reference, here's where Zig's documentation lives:

https://ziglang.org/learn/

I remember when learning Zig, the documentation for the language itself was extensive, complete, and easily greppable due to being all on one page.

The standard library was a lot less intuitive, but I suspect that has more to do with the amount of churn it's still going through.

The build system also needs more extensive documentation in the same way that the stdlib does, but it has a guide that got me reasonably far with what came out of the box.

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

#188

Post by pjmlp »

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

Compiler vendors are free to chose what ABI stability their C++ implementations provide.

ISO C++ standard is silent on how the ABI actually looks like, the ABI not being broken in most C and C++ compilers is a consequence of customers of those compilers not being happy about breakages.

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

#189

Post by portly »

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 problems. You don't need to treat it like an identity.

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

#190

Post by pjmlp »

kibwen wrote: post #130
zozbot234 wrote: post #120

Earlier quoted context omitted.

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

Only because Rust is a source only language for distribution.

One business domain that Rust currently doesn't have an answer for, is selling commercial SDKs with binary libraries, which is exactly the kind of customers that get pissed off when C and C++ compilers break ABIs.

Microsoft mentions this in the adoption issues they are having with Rust, see talks from Victor Ciura, and while they can work around this with DLLs and COM/WinRT, it isn't optimal, after all Rust's safety gets reduced to the OS ABI for DLLs and COM.

Post reply on HN