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

211–220 of 315 posts

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

#211

Post by LexiMax »

pjmlp wrote: post #205
kibwen wrote: post #199

Earlier quoted context omitted.

I'm not expecting to convince you of this position, but I find it to be a feature, not a bug, that Rust is inherently hostile to companies whose business models rely on tossing closed-source proprietary blobs over the wall. I'm fairly certain that Andrew Kelley would say the same thing about Zig. Give me the source or GTFO.

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

NDA's means that making source available isn't as much of a concern. Quite a bit of the modern game development stack is actually source-available, especially when you're talking about game engines.

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

#212

Post by ceteia »

pron wrote: post #202
ceteia wrote: post #182

Earlier quoted context omitted.

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.

Growing in absolute numbers doesn't mean growing the market share, and even a growing market share is not necessarily sufficiently fast growth to become a safe bet. All languages that ended up becoming very popular grew their market share much faster than Rust does. Being an old language with some real market share is obviously better than being an old language with negligible market share, but being an old language…

Do you know of a good way to measure market share? I know of GitHub's and StackOverflow's surveys, but I'm not sure how well they reflect reality. There is also Redmonk.

GitHub's survey did not say much about Rust I think, despite Rust projects often having lots of starring. Rust projects might have a greater ratio of stars-to-popularity than projects in other languages, though.

StackOverflow's survey was much more optimistic or indicated popularity for Rust.

Redmonk places Rust at place 19th.

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

#213

Post by dnautics »

epolanski wrote: post #194
flohofwoe wrote: post #93

Earlier quoted context omitted.

IME Zig's breaking changes are quite manageable for a lot of application types since most of the breakage these days happens in the stdlib and not in the language. And if you just want do read and write files, the highlevel file-io interfaces are nearly identical, they just moved to a different namespace and now require a std.Io pointer to be passed in. And tbh, I take a 'living' language any day over a language that…

Sure, but considering that Zig is a modern C alternative, one should not and cannot afford to forget that C has been successful also because it stayed small and consistent for so long. The entire C, C ABI and standard lib specs, combined, are probably less words than the Promise spec from ECMAScript 262. A small language that stays consistent and predictable lets developers evolve it in best practices, patterns, desi…

I'm pretty sure the point of aggressively evolving now is to have to basically not evolve it at some point in the future?

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

#214

Post by hu3 »

derefr wrote: post #210
portly wrote: 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…

A mainstream language has predictable library-ecosystem support for most use-cases.

It's not v1.0 and they don't claim to be.

So what is your point?

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

#215

Post by Seattle3503 »

It's interesting to see this land while Rust support of io_uring in a mainstream library is lagging. And not for lack of trying, its just difficult to design a safe (zero-cost) idiomatic Rust abstraction over io_uring's completion based IO.

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

#216

Post by dnautics »

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…

It's possible to do memory safety analysis for zig. I think you could pretty easily add a noalias checker on top of this:

https://github.com/ityonemo/clr

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

#217

Post by dnautics »

vlovich123 wrote: post #184
davemp wrote: post #181

Earlier quoted context omitted.

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

wow, what a list! all of these are statically analyzable using a slightly hacked zig compiler and a library!

https://github.com/ityonemo/clr

(Btw: you can't null pointer dereference in zig without using the navigation operator which will panic on null; you can't misalign a pointer unless you use @alignCast which will also create a panic)

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

#218

Post by hu3 »

pjmlp wrote: post #192
Quothling wrote: post #161

Earlier quoted context omitted.

Zig is a drop-in for C. I'm not sure what Rust is but around here no C++ teams seem to be adopting it. Zig on the other hand is seeing adoption in teams who write C for Python binaries. Not a whole lot of it since it's not exactly safe or "stable", but some. Now I'm aware that things like UV are build with Rust, but part of why UV is adopted so widely isn't just that it's fast. It's that it is a drop-in for pip, so t…

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.

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

#219

Post by pjmlp »

ceteia wrote: post #209
pjmlp wrote: post #197

Earlier quoted context omitted.

There is an announcement already planned at NDC Toronto 2026. > Carbon: graduating from the experiment https://ndctoronto.com/agenda/carbon-graduating-from-the-exp... As for it being widely adopted, people keeping missing the point that Carbon is mostly for Google themselves, as means to integrate into existing C++ projects. They are the very first ones to assert that for green field projects there are already plenty…

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.

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

#220

Post by bbkane »

epolanski wrote: post #194
flohofwoe wrote: post #93

Earlier quoted context omitted.

IME Zig's breaking changes are quite manageable for a lot of application types since most of the breakage these days happens in the stdlib and not in the language. And if you just want do read and write files, the highlevel file-io interfaces are nearly identical, they just moved to a different namespace and now require a std.Io pointer to be passed in. And tbh, I take a 'living' language any day over a language that…

Sure, but considering that Zig is a modern C alternative, one should not and cannot afford to forget that C has been successful also because it stayed small and consistent for so long. The entire C, C ABI and standard lib specs, combined, are probably less words than the Promise spec from ECMAScript 262. A small language that stays consistent and predictable lets developers evolve it in best practices, patterns, desi…

Besides Odin? Does Odin give you most of this?
Post reply on HN