Live data from Hacker News

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

ziglang.org

241–250 of 315 posts

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

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

To make this go away, I think you’d have to change/mitigate the economic incentives (real and perceived) that influence programming practitioners.

People see the languages/libraries they use as their sellable articles. And why wouldn’t they? Every job application begins with a vetting of which “tools” you can operate. A language, as a tool, necessarily seeks to grow its applicability, as securing the ROI of if its users.

And even when not tied to direct monetary incentives, it can still be tied to one’s ability to participate and influence the direction of various open source efforts.

Mix in barely informed decision makers, seeking to treat those engineers as interchangeable assets, and the admirable position being promoted above falls down the priority chain.

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

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

This is pretty close to saying Rust is not very different than C because it has the unsafe keyword. That is, either an ignorant (of Zig) or disingenuous statement.

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

#243
post #231
post #201

Earlier quoted context omitted.

To this day C++ has hardly won the hearts of C devs on the embedded space, on both sides of the camp there are individuals that start religious discussions about the C/C++ abreviation, there is something like Orthodox C++ that basically means using C++ compiler to write what is mostly Better C, and most frameworks that were so hyped in the 1990's are now gone, or subsyst in maintenance contracts on applications that…

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.

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

#244
post #228
post #219

Earlier quoted context omitted.

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.

Are you really OK with runtime "expression patterns"? match (0, 1, 2) { case (F(), 0, G()) => ... } > Here (F(), 0, G()) is not an expression, but three separate expressions in a tuple pattern. As a result, this code will call F() but not G(), because the mismatch between the middle tuple elements will cause pattern matching to fail before reaching G(). Other than this short-circuiting behavior, a tuple pattern of ex…

As mentioned I have no interest in ever using Carbon, the language still isn't 1.0, and full end to end compiler is yet to be made available.

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

#245
post #76

Earlier quoted context omitted.

> if you're a casual user (ie you don't follow the development) don't try incomplete APIs that not even the creators of fully know how they are supposed to work Is the completeness of each API formally documented anywhere? Maybe I missed something but it doesn't seem like it is, in which case the only way to know would be to follow what's happening behind the scenes.

Zig cuts releases. This API is not on a release of Zig yet. It's only available through nightly builds of master. "Casual users" should stick to releases if they don't want to deal with incomplete APIs.

That's not really the issue. The stable API is incompatible with the API that will launch with 0.16. It's not really relevant if I'm playing with incompletely API, I want to know how I can migrate to it. I did not move yet to 0.16, but I wanted to see.

The migration pain will be the same once it launches unless they revert back, which does not seem likely at all.

But the point is: potentially every API is unstable.

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

#246
post #199
post #190

Earlier quoted context omitted.

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…

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.

> I'm fairly certain that Andrew Kelley would say the same thing about Zig. Give me the source or GTFO.

Thus it will never be even considered outside the tech bubble.

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

#247
post #178

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…

> Rust will also never replace C or C++ in any meaningful way Not only do I disagree it never will, I think it's already well on its way to doing exactly that.

Is it? rust has to ditch llvm to be able to replace c++ - or rewrite llvm in rust.

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

#248
post #237
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…

These languages have origin in a different era, without Reddit, Twitter or HN to spam about them, do we cannot really compare adoption rates.

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

#249
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 forgetting the purpose of software is to serve users, not developers.

And I'm not sure what's so revolutionary about Zig that couldn't have been solved by improving other languages.

For Zig in particular, the language isn't even stable enough that you can compile packages like Ghostty with any recent version of the Zig compiler. It has to be a very specific version of the compiler.

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

#250
post #235
post #210

Earlier quoted context omitted.

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

A language, and by definition it's libraries, does not have to solve most use cases.

A new software stack isn't free. Someone has to maintain it.

And if the new software stack just improves a fraction of the ecosystem, it isn't worth the effort.

Post reply on HN