Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

I'm too dumb for Zig's new IO interface

openmymind.net

Post reply on HN
Print view View original

301–310 of 329 posts

Re: I'm too dumb for Zig's new IO interface

#301

Post by hitekker »

littlestymaar wrote: post #299
hitekker wrote: post #282

Earlier quoted context omitted.

Much of that bad blood comes from how Rust's leadership attacks other programming languages, online and offline. pcwalton infamously declared zig was "a massive step back for the industry" https://x.com/pcwalton/status/1568306598795431936?s=46&t=OCi... . He and the Rust Core Team had a big reputation for burning bridges. Even to this day, the new Rust leaders are happy to attack other memory safe languages like Go, d…

> Rust supremacism. I can't believe you really wrote that.

It's true. Or rather, it's the emergent behavior of the community. Other languages typically don’t openly say, in writing:

> Then [Anti Rust person] should have been perma-banned long ago [on an open forum]. Until this is done, we'll have to warn people about engaging with him…

You can hate kristoff, ignore him or attack his arguments. You can also love a piece of software and treat it as sacred. But other people should not be subjected to that love nor should they be canceled on account of it. Flag it or downvote. Beyond that, it's outside of our control.

I do agree though that kristoff should focus on Zig and not indulge in provoking old enemies. His valid points— deferring premature documentation for newbies until concepts are ironed out— are being lost in programming language holy wars.

Re: I'm too dumb for Zig's new IO interface

#302

Post by sothatsit »

simonask wrote: post #285
uecker wrote: post #276

Earlier quoted context omitted.

Bias is a good keyword with respect to CVEs. As long as there is not much Rust code which is relevant to my daily life I think this is not comparable. And the few Rust packages which now ended up on my system, see no regular security support because they pose a maintenance burden, so actually make me less safe: https://www.debian.org/releases/trixie/release-notes/issues.... But the original claim was that "C code cra…

No, the original claim was that "writing C code that does not crash all the time is significantly harder/expensive", which I think is uncontroversial.

> writing C code that does not crash all the time is significantly harder/expensive

This is just plain not true. The fact of the matter is that if you stick to good practices, writing C code that does not crash under regular usage is not at all difficult. The problem is that writing C code that is guaranteed not to contain memory issues is extremely hard. But writing programs that don't crash "all the time" is not at all difficult.

This is why I can understand the push to use memory-safe languages to avoid memory safety issues in critical or widely-relied-upon programs. But the main reason you are using it in these cases is to avoid memory safety bugs, not to help you write programs that don't "crash all the time". And even then, the main incentive is that memory safety bugs can be quite severe bugs in areas like networking code, where they might become a significant security risk. The crashes aren't even the main concern here.

Re: I'm too dumb for Zig's new IO interface

#303

Post by zozbot234 »

pron wrote: post #296
tialaramex wrote: post #295

Earlier quoted context omitted.

> Wat? Where did you get that? The talk you're so excited about actually shows this asymptote. In reality a GC doesn't actually want zero garbage because we're trading away RAM to get better performance. So they don't go there, but it ought to have pulled you up short when you thought you could apply this understanding to an entirely unrelated paradigm. Hence the V2 comparison. So long as you're thinking about those…

> The talk you're so excited about actually shows this asymptote. Oh, I see the confusion. That asymptote is for the hypothetical case where the allocation rate grows to infinity (i.e. remains constant per core and we add more cores) while the heap remains constant. Yes, with an allocation rate growing to infinity, the cost of memory management (using any algorithm) also grows to infinity. That it's so obvious was hi…

> When you claim some technique would give a corporation a significant competitive edge, and yet most corporations don't take it (at least not for most projects), then that is evidence against that claim because usually companies are highly motivated to gain an advantage.'

Corporations will generally want to optimize for ease of development and general ecosystem maturity. Rust is at a clear disadvantage at least wrt. the latter - the first generally usable version of the language was only released in late 2018 - and other safe languages are generally GC-based (compare Java/C# with C++). It's quite normal that a lot of performance would be left on the table wrt. both CPU and memory footprint.

Re: I'm too dumb for Zig's new IO interface

#304

Post by uecker »

sothatsit wrote: post #302
simonask wrote: post #285

Earlier quoted context omitted.

No, the original claim was that "writing C code that does not crash all the time is significantly harder/expensive", which I think is uncontroversial.

> writing C code that does not crash all the time is significantly harder/expensive This is just plain not true. The fact of the matter is that if you stick to good practices, writing C code that does not crash under regular usage is not at all difficult. The problem is that writing C code that is guaranteed not to contain memory issues is extremely hard. But writing programs that don't crash "all the time" is not at…

It is also not "extremely difficult" to avoid memory-safety issues in most code, although I agree that Rust has a clear advantage. Essentially you need to have a clear policy on memory ownership and avoid pointer arithmetic by using safe buffer and string abstractions. That this often not done in practice is the issue, but I think the narrative that it is impossible in C or "extremely difficult" is more harmful than good as it shifts the blame to the language and rejects responsibility for sloppy or lazy code.

Re: I'm too dumb for Zig's new IO interface

#305

Post by littlestymaar »

hitekker wrote: post #301
littlestymaar wrote: post #299

Earlier quoted context omitted.

> Rust supremacism. I can't believe you really wrote that.

It's true. Or rather, it's the emergent behavior of the community. Other languages typically don’t openly say, in writing: > Then [Anti Rust person] should have been perma-banned long ago [on an open forum]. Until this is done, we'll have to warn people about engaging with him… You can hate kristoff, ignore him or attack his arguments. You can also love a piece of software and treat it as sacred. But other people sho…

> Other languages typically don’t openly say, in writing:

I'm no language though…

> You can hate kristoff, ignore him or attack his arguments. You can also love a piece of software and treat it as sacred.

It's not about “love” or “being sacred” or even about Rust or Zig, it is about behaving in society. Most successful communities at some point meet toxic people who want to start holly wars and insult people. Successful communities are the one who ban those people, or at least coerce them into behaving through social pressure.

When you don't do that, you end up with bullies like Loris occupying prominent positions, and that's very bad for the community because it attracts people like that.

It has nothing to do with programming languages at all.

And sorry to say that bluntly, your discourse about “supremacism” “love” or “sacred” sounds very immature: programming languages are tools and engineering projects, not icons that should be worshipped or hated, they all have their strong points and warts (and god knows Rust has its share of annoyances…). Don't get dragged in holy wars by cult leaders like Loris.

Re: I'm too dumb for Zig's new IO interface

#306

Post by sothatsit »

uecker wrote: post #304
sothatsit wrote: post #302

Earlier quoted context omitted.

> writing C code that does not crash all the time is significantly harder/expensive This is just plain not true. The fact of the matter is that if you stick to good practices, writing C code that does not crash under regular usage is not at all difficult. The problem is that writing C code that is guaranteed not to contain memory issues is extremely hard. But writing programs that don't crash "all the time" is not at…

It is also not "extremely difficult" to avoid memory-safety issues in most code, although I agree that Rust has a clear advantage. Essentially you need to have a clear policy on memory ownership and avoid pointer arithmetic by using safe buffer and string abstractions. That this often not done in practice is the issue, but I think the narrative that it is impossible in C or "extremely difficult" is more harmful than…

Easier said than done. In the real-world, in real projects, sustaining zero memory-safety bugs in large C codebases is exceedingly rare. Microsoft and Chrome have each reported that ~70% of their serious security bugs are memory‑safety issues, and curl attributes about 40% of its vulnerabilities to using C. Memory safety problems are really hard to avoid in practice in large C codebases. You can't just blame developers.

On using C from the creators of curl:

> We count about 40% of our security vulnerabilities to date to have been the direct result of us using C instead of a memory-safe language alternative. (https://daniel.haxx.se/blog/2025/04/07/writing-c-for-curl)

And, like what I was referring to, it is even more difficult to prove the absence of memory safety issues entirely. We have only managed to actually prove it for a handful of non-trivial programs, like the seL4 microkernel.

Now, this is all an entirely different question to whether the extra work required to write your program in Rust to avoid memory safety problems is actually worthwhile. If you are writing a program with no networking code, no privilege escalation, and no confidential information, the answer is probably that it doesn't matter. If a game has a buffer overflow in some weird edge case, it doesn't really matter. If your data processing code has a problem, you can probably spot that and it probably won't lead to any security concerns. If your file system scanner runs into a memory safety issue, it probably won't negatively impact you that much.

But if your crypto library has memory safety problems, you are in for a bad time.

Re: I'm too dumb for Zig's new IO interface

#307

Post by CRConrad »

0x696C6961 wrote: post #294
CRConrad wrote: post #291

Earlier quoted context omitted.

> Where did I accuse anyone of a false dichotomy? You didn't accuse anyone of it, you presented one ( https://news.ycombinator.com/item?id=44995714 ) and then claimed it wasn't one ( https://news.ycombinator.com/item?id=44994200 ). And then you blithely went on to talk about "the false equivalency" ( https://news.ycombinator.com/item?id=44996188 ), which nobody had been talking about. What's that, if not "moving goal…

You seem confused, I don't think I'll be responding further.

I don't think I am "confused". What's "confused" about pointing out the error -- or hypocrisy -- in accusing someone else of "moving goalposts" when it was you who did that? (NB, BTW, it wasn't me you accused; dunno if you noticed that I'm a different person.)

And I think if you won't be responding further it's because I either confused you or, more probably, just simply made you realise you were wrong. (Or maybe you knew that all along and just brazenly projected your own goalpost-moving onto someone else, Idunno.)

But if you change your mind and do respond, I'd be grateful for an explanation of how you came to the conclusion that I "seem confused", and about what exactly.

Re: I'm too dumb for Zig's new IO interface

#308

Post by littlestymaar »

hitekker wrote: post #282
mirashii wrote: post #172

Earlier quoted context omitted.

> Maybe, or maybe the fact that Zig is a small independent project with limited resources has also something to do with it Or, maybe it's this kind of redirection and evidence of a victim complex. Part of the reason that there's a patina of anti-Rust sentiment includes the dismissive attitude and swipes you, a the VP of Community at the Zig Software Foundation, take towards Rust and Rust developers by writing about t…

Much of that bad blood comes from how Rust's leadership attacks other programming languages, online and offline. pcwalton infamously declared zig was "a massive step back for the industry" https://x.com/pcwalton/status/1568306598795431936?s=46&t=OCi... . He and the Rust Core Team had a big reputation for burning bridges. Even to this day, the new Rust leaders are happy to attack other memory safe languages like Go, d…

“Zig not being memory safe” is what's being called “a massive setback for the industry”.

Maybe you can make a hierarchy between technical criticism like this and the fact that Go isn't technically memory-safe[1], with Loris' abusive behavior of calling Rust maintainers names like “wankers”…

[1]: which is a criticism mostly coming from the Java crowd, by the way, not Rust, like the criticism of the simplistic garbage collection management in Go

Re: I'm too dumb for Zig's new IO interface

#309

Post by baranul »

hitekker wrote: post #282
mirashii wrote: post #172

Earlier quoted context omitted.

> Maybe, or maybe the fact that Zig is a small independent project with limited resources has also something to do with it Or, maybe it's this kind of redirection and evidence of a victim complex. Part of the reason that there's a patina of anti-Rust sentiment includes the dismissive attitude and swipes you, a the VP of Community at the Zig Software Foundation, take towards Rust and Rust developers by writing about t…

Much of that bad blood comes from how Rust's leadership attacks other programming languages, online and offline. pcwalton infamously declared zig was "a massive step back for the industry" https://x.com/pcwalton/status/1568306598795431936?s=46&t=OCi... . He and the Rust Core Team had a big reputation for burning bridges. Even to this day, the new Rust leaders are happy to attack other memory safe languages like Go, d…

There are a couple things about that take, that many would say deserves push back on: (1) Rust supremacism has been aimed at many other languages, not just Zig in particular. It's been a wide spray. (2) Many would say that Zig's leadership has done similar to what you are saying about Rust. Very clear examples have been the relentless unleashing on Vlang and its creator, and to a lesser extent on C3.

What might be the better critique about this, is that any programming language's leadership should not be engaging in that kind of bad behavior. And any ill words coming from them about another language, should always be taken with a grain of salt and seen as likely bias.

Re: I'm too dumb for Zig's new IO interface

#310

Post by baranul »

pjmlp wrote: post #89
littlestymaar wrote: post #71

Earlier quoted context omitted.

The key problem with Zig nowadays is how much of its community and adoption is driven by anti-Rust sentiment. As a result, while Rust puts beginner onboarding and documentation at the center of its culture, as opposed to the “C neckbeard”'s culture, Zig is going the other way around. (Loris Cro being a key community figure isn't helping in any way, and it's a good remainder that if you don't clear up your community f…

Not only, the whole handmade movement puts me off. It is the anti-intelectualism from Go culture, gone wild against C++, Rust, Swift, anything modern, or even tools, using game engines versus doing the whole computer from scratch for a game.

If you didn't know, Casey has made comments on a YouTube video, that he does not like Zig. His review of Zig, was that it's a language that he rather not use and would not recommend.
Post reply on HN