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

261–270 of 315 posts

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

#261

Post by reppap »

cbmuser wrote: post #249
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…

> As always with Zig posts, here come the haters. I really wonder why you even care about it. It's another language stack that would need to be maintained within Linux distributions for years to come (security support, architecture support etc). Upstream developers always seem to assume that there is no cost associated to introducing new software stacks. But in the end, someone has to maintain it. And they keep forge…

> And they keep forgetting the purpose of software is to serve users, not developers.

Developers are the users of these software stacks though? I don't really understand your point.

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

#262

Post by dnautics »

vlovich123 wrote: post #254
dnautics wrote: post #217

Earlier quoted context omitted.

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)

Neat. Why isn’t this in the main compiler / will it be? I’m happy to retract my statement if this becomes actually how zig compiles but it’s not a serious thing as it’s more a PoC of what’s possible today and may break later

It will never be in the main compiler, since it was written by Claude. I think that's ok. The general concept is sound and won't break (modulo names of instructions changing etc). In fact it will get better. With the new io, concurrency checks will be possible

But also, there is no reason why it should have to be in the main compiler. I've architected it as a dlload plugin. It's even crazier! The output is a zig program which you must compile and run to get the final result.

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

#263

Post by ekipan »

cbmuser wrote: post #249
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…

> As always with Zig posts, here come the haters. I really wonder why you even care about it. It's another language stack that would need to be maintained within Linux distributions for years to come (security support, architecture support etc). Upstream developers always seem to assume that there is no cost associated to introducing new software stacks. But in the end, someone has to maintain it. And they keep forge…

> And they keep forgetting the purpose of software is to serve users, not developers.

I don't have any horse in the game, but I do think Zig is interesting. This remark is funny to me because it's literally one of the tenets the Zig devs make decisions by!

https://ziglang.org/documentation/master/#Zen

> * Together we serve the users.

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

#264

Post by pron »

kibwen wrote: post #237
pron wrote: post #136

Earlier quoted context omitted.

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++ (and, in fact, any language that's ever been in the top 5 or so) achieved similar milestones. No, this completely overestimates how quickly languages gain prominence. C came out in 1972 and didn't gain its current dominance until approximately the release of the ANSI C spec in 1989/1990, after 17 years. C++ came out in 1985 and didn't become the dominant language…

> C came out in 1972 and didn't gain its current dominance until approximately the release of the ANSI C spec in 1989/1990

While it kept growing in popularity later, by 1983-5 C was already one of the top programming langugages in the world.

> C++ came out in 1985 and didn't become the dominant language for gamedev until the late 90s

Major parts of Windows and Office were being written in C++ in the early-mid 90s, before C++ turned 10. Visual C++, one of Microsoft's flagship development products, came out in 1993. Huge mission-critical, long-term, industrial and defence projects were being written in C++ during or before 1995 (I was working on such a project).

> Python came out in 1991 and labored as an obscure Perl alternative until the mid-late 2000s

Even in 2002 Python was widespread as a scripting language. But it is, indeed, the best and possibly only example of a late bloomer language.

> Javascript came out in 1995 and was treated as a joke and/or afterthought in the broader programming discourse until Node.js came out in 2009

AJAX (popularised by Gmail) pretty much revolutionised the web in 2004. When jQuery came out in 2006, JS was all over the place.

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

#265

Post by pron »

zozbot234 wrote: post #255
pron wrote: post #240

Earlier quoted context omitted.

The best sources are industry studies by market research companies that collect information from companies. The best public sources, IMO, are those based on job openings (as jobs correlate more with total number of lines of code than sources based on number of repos, PRs, or questions). Some of these are about a year out-of-date: https://www.devjobsscanner.com/blog/top-8-most-demanded-prog... https://uk.indeed.com/ca…

The first genuinely usable version of Rust was only released in late 2018. Rust is a very new language still.

Except you could say something similar about the first few years of every language that became very popular, and the comparison would still not be in Rust's favour.

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

#266

Post by hu3 »

pjmlp wrote: post #221
hu3 wrote: post #218

Earlier quoted context omitted.

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

Great clickbait title for a Rust conference.

But in the video he says they are starting with critical systems first.

Emphasis on starting.

So yeah, not as pervasive as you, the evangelists or that video title implies.

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

#267

Post by Ygg2 »

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.

Tying yourself in a knot around ABI usually isn't worth it. You pick up to two: performance, ABI stability or adaptability.

And you can still internaly have it, if your deps have sources, or compile artifacts for only allow single Rust version (additional rules may apply).

There is work on Rust ABI (crabi), but there isn't a huge push for it.

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

#268

Post by pron »

pjmlp wrote: post #243
pron wrote: post #231

Earlier quoted context omitted.

Downplaying compared to what ? This kind of adoption is certainly something Haskell never gained. But all those companies (or analogous ones) adopted C++ much faster. In fact, they've adopted faster virtually every language they're using seriously. So it's a great achievement compared to every language they've never adopted at all, but not such a great achievement compared to every other language they have adopted. >…

I don't have a use for Rust on my daily work, and would rather see Java finally adopt the features it missed down from Oberon and Modula-3 for systems programming, however we will have to disagree on the "mediocre" adoption. So many language designers would dream to have such adoption numbers by tech giants for their hobby language.

Of course Rust is very popular compared to any hobby language (and many non-hobby languages), but that is not the goal it set for itself to be judged by.

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

#269

Post by hu3 »

lukaslalinsky wrote: post #111
hu3 wrote: post #90

Earlier quoted context omitted.

They aknowlege that at the beggining of the post? > They are now available to tinker with, by constructing one’s application using std.Io.Evented. They should be considered experimental because there is important followup work to be done before they can be used reliably and robustly: And then they proceed to list 6 important pending work to be done.

It doesn't say "minor" details like networking not being implemented :)

They probably probably thought that this warning was clear enough:

"should be considered experimental because there is important followup work to be done"

I guess not clear enough to some people.

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

#270

Post by Ygg2 »

pjmlp wrote: post #188
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++.

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.

Yeah but ABI stability isn't really just magic dust you sprinkle in you language/compiler and make it more stable

It's a straightjacket that has application in few select cases.

Things ABI prevents in C++:

- better shared_ptr

- adding UTF8 to regex

- int128_t standardisation

- make most of constexpr

And so on: https://cor3ntin.github.io/posts/abi/

I get you might have particular criteria on this. But it's a feature that comes with huge, massive downsides.

Post reply on HN