I'm too dumb for Zig's new IO interface • Hacker News Board

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

#271

Post by pron » Sun, Aug 24, 2025, 4:41 PM UTC

zozbot234 wrote: post #270

pron wrote: post #269

Earlier quoted context omitted.

> It turns out that using more RAM costs you more CPU Yes, memory bandwidth adds another layer of complication, but it doesn't matter so much once your live set is much larger than your L3 cache. I.e. a 200MB live set and a 100GB live set are likely to require the same bandwidth. Add to that the fact that tracing GCs' compaction can also help (with prefetching) and the situation isn't so clear. > That's the kind of p…

> The point remains that it's very useful to have a memory management approach that can turn the RAM you've already paid for to reduce CPU consumption. That approach is specifically arenas: if you can put useful bounds on the maximum size of your "dead" data, it can pay to allocate everything in an arena and free it all in one go. This saves you the memory traffic of both manual management and tracing GC. But coming…

> It goes without saying that memory compaction involves a whole lot of extra traffic on the memory subsystem

It doesn't go without saying that compaction involves a lot of memory traffic, because memory is utilised to reduce the frequency of GC cycles and only live objects are copied. The whole point of tracing collection is that extra RAM is used to reduce the total amount of memory management work. If we ignore the old generation (which the talk covers separately), the idea is that you allocate more and more in the young gen, and when it's exhausted you compact only the remaining live objects (which is a constant for the app); the more memory you assign to the young gen, the less frequently you need to do even that work. There is no work for dead objects.

> when it comes to how it's impacted by the memory bottleneck is one that I have some trouble understanding also - especially since you've been arguing for using up more memory for the exact same workload.

Memory bandwidth - at least as far as latency is concerned - is used when you have a cache miss. Once your live set is much bigger than your L3 cache, you get cache misses even when you want to read it. If you have good temporal locality (few cache misses), it doesn't matter how big your live set is, but the same is if you have bad temporal locality (many cache misses).

> which, AIUI, is also what the talk is about

The talk focuses on tracing GCs, but it applies equally to manual memory management (as discussed in the Q&A; using less memory for the same algorithm requires CPU work regardless if it's manual or automatic)

> when that's a forced choice

I don't think tracing GCs are ever a forced choice. They keep getting chosen over and over for heavy workloads on machines with >= 1GB/core because they offer a more attractive tradeoff than other approaches for some of the most popular application domains. There's little reason for that to change unless the economics of DRAM/CPU change significantly.

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

#272

Post by CRConrad » Sun, Aug 24, 2025, 6:31 PM UTC

Ygg2 wrote: post #237

pron wrote: post #198

Earlier quoted context omitted.

It isn't optional, and yet it's also not at any cost, or we'd all be programming in ATS/Idris. From those languages' vantage point, the guarantees Rust makes are almost indistinguishable from C. Yet no one says, "the conversation is over unless we all program in languages that can actually guarantee correctness" (rather than one that guarantees the lack of the eighth most dangerous software weakness). Why? Because it…

> It isn't optional, and yet it's also not at any cost, or we'd all be programming in ATS/Idris. In a better, saner world, we'd writing Ada++ not C++. However, we don't live in a perfect world. > The goal isn't to write the most correct program; it's to write the most correct program under the project's budget and time constraints. The goal of ANY software engineer worth their salt should be minimizing errors and def…

> The goal of ANY software engineer worth their salt should be minimizing errors and defects in their end product.

...to the extent possible within their project budget. Otherwise the product would — as GP already pointed out — not exist at all, because the project wouldn't be undertaken in the first place.

> This goal can be reached by learning to write Rust; practice makes perfect.

Pretty sure it could (at least) equally well be reached by learning to write Ada.

This one-note Rust cult is really getting rather tiresome.

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

#273

Post by Ygg2 » Sun, Aug 24, 2025, 7:23 PM UTC

CRConrad wrote: post #272

Ygg2 wrote: post #237

Earlier quoted context omitted.

> It isn't optional, and yet it's also not at any cost, or we'd all be programming in ATS/Idris. In a better, saner world, we'd writing Ada++ not C++. However, we don't live in a perfect world. > The goal isn't to write the most correct program; it's to write the most correct program under the project's budget and time constraints. The goal of ANY software engineer worth their salt should be minimizing errors and def…

> The goal of ANY software engineer worth their salt should be minimizing errors and defects in their end product. ...to the extent possible within their project budget. Otherwise the product would — as GP already pointed out — not exist at all, because the project wouldn't be undertaken in the first place. > This goal can be reached by learning to write Rust; practice makes perfect. Pretty sure it could (at least) e…

> The goal of ANY software engineer worth their salt should be minimizing errors and defects in their end product. > > ...to the extent possible within their project budget.

Sure, but when other engineers discover that shit caused us many defects (e.g., asbestos as a fire insulator), they don't turn around and say, "Well, asbestos sure did cause a lot of cancer, but Cellulose Fibre doesn't shield us from neutron radiation. So it won't be preventing all cancers. Ergo, we are going back to asbestos."

And then you have team Asbestos and team Lead paint quarrelling who has more uses.

That's my biggest problem. The cyclic, Fad Driven Development that permeates software engineering.

> Pretty sure it could (at least) equally well be reached by learning to write Ada.

Not really. Ada isn't that memory safe. It mostly relies on runtime checking [1]. You need to use formal proofs with Ada SPARK to actually get memory safety on par with Rust.

> Pretty sure it could (at least) equally well be reached by learning to write Ada.

See above. You need Ada with Spark. At that point you get two files for each method like .c/.h, one with method definition and one with proof. For example:

    // increment.ads - the proof
    procedure Increment
        (X : in out Integer)
    with
      Global  => null,
      Depends => (X => X),
      Pre     => X  X = X'Old + 1;

    // increment.adb - the program
    procedure Increment
      (X : in out Integer)
    is
    begin
      X := X + 1;
    end Increment;

But you're way past what you call programming, and are now entering proof theory.

[1] https://ajxs.me/blog/How_Does_Adas_Memory_Safety_Compare_Aga...

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

#274

Post by Ygg2 » Sun, Aug 24, 2025, 7:45 PM UTC

pron wrote: post #254

Ygg2 wrote: post #236

Earlier quoted context omitted.

> Given Zig's safety guarantees (which are stronger than C++'s), and given its goals (which are different from C++'s), the question should be what should we be willing to give up to gain safety from use-after-free given the language's goals. Would more safety be better if it cost nothing? The problem with this statement is that without a memory safety invariant your code doesn't compose. Some code might assume no UAF…

> The problem with this statement is that without a memory safety invariant your code doesn't compose Yes, but that holds for any correctness property, not just the 0.0001% of them that memory safe languages guarantee. That's why we have bugs. The reason memory safety is a focus is because out-of-bounds access is the leading cause of dangerous vulnerabilities. > The goal of all engineering disciplines, including soft…

> Yes, but practical minimisation, not hypothetical minimisation, i.e. how can I get the least bugs while keeping all my constraints, including budget. Like I said, a language like Rust exists because minimisation of errors is not the only constraints, because if it were, there are already far more popular languages that do just as much.

Rust achieves practical minimization, if not outright eradication, of a set of errors even in practice. And not just memory safety errors.

> Like I said, a language like Rust exists because minimisation of errors is not the only constraints, because if it were, there are already far more popular languages that do just as much.

The reason Rust exists is that the field hasn't matured enough to accept better engineering practices. If everyone could write and think in pre/post/invariant way, we'd see a lot fewer issues.

> I'm not sure I buy this, because physical, engineered objects break just as much as software does, certainly when weighted by the impact of the failure.

Dude, the front page was about how Comet AI browser can be hacked by your page and ordered to empty your bank account. That's like your fork deciding to gut you like a fish.

> the assumption that the most likely explanation to something is that the majority of practitioners are irrational seems strange to me.

Why? Just because you are intelligent doesn't mean you are rational. Plenty of smart people go bonkers. And looking at the state of the field as a whole, I'd have to ask for proof it's rational.

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

#275

Post by Ygg2 » Sun, Aug 24, 2025, 7:47 PM UTC

pron wrote: post #271

zozbot234 wrote: post #270

Earlier quoted context omitted.

> The point remains that it's very useful to have a memory management approach that can turn the RAM you've already paid for to reduce CPU consumption. That approach is specifically arenas: if you can put useful bounds on the maximum size of your "dead" data, it can pay to allocate everything in an arena and free it all in one go. This saves you the memory traffic of both manual management and tracing GC. But coming…

> It goes without saying that memory compaction involves a whole lot of extra traffic on the memory subsystem It doesn't go without saying that compaction involves a lot of memory traffic, because memory is utilised to reduce the frequency of GC cycles and only live objects are copied. The whole point of tracing collection is that extra RAM is used to reduce the total amount of memory management work. If we ignore th…

> It doesn't go without saying that compaction involves a lot of memory traffic

It definitely tracks with my experience. Did you see Chrome on AMD EPYC with 2TB of memory? It reached like 10% of Mem utility but over 46% of CPU around 6000 tabs. Mem usage climbed steeply at first but got overtaken by CPU usage.

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

#276

Post by uecker » Sun, Aug 24, 2025, 8:10 PM UTC

antonvs wrote: post #243

uecker wrote: post #214

Earlier quoted context omitted.

I also write C all the time, and it does not crash. There are certainly memory safety concerns with C, but there are also certainly many programmers that can write C code that does not crash all the time.

Survivor bias and selection bias. The list of CVEs tells a different story.

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 crashes all the time" which is blatantly wrong.

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

#277

Post by pron » Sun, Aug 24, 2025, 9:02 PM UTC

Ygg2 wrote: post #275

pron wrote: post #271

Earlier quoted context omitted.

> It goes without saying that memory compaction involves a whole lot of extra traffic on the memory subsystem It doesn't go without saying that compaction involves a lot of memory traffic, because memory is utilised to reduce the frequency of GC cycles and only live objects are copied. The whole point of tracing collection is that extra RAM is used to reduce the total amount of memory management work. If we ignore th…

> It doesn't go without saying that compaction involves a lot of memory traffic It definitely tracks with my experience. Did you see Chrome on AMD EPYC with 2TB of memory? It reached like 10% of Mem utility but over 46% of CPU around 6000 tabs. Mem usage climbed steeply at first but got overtaken by CPU usage.

I have no idea what it's using its CPU on, whether it has anything to do with memory management, or what memory management algorithm is in use. Obviously, the GC doesn't need to do any compaction if the program isn't allocating, and the program can only allocate if it's actually doing some computation. Also, I don't know the ratio of live set to total heap. A tracing GC needs to do very little work if most of the heap is garbage (i.e. the ration of live set to the total memory is low), but any form of memory management - tracing or manual - needs to do a lot of work if the ratio is low. Remember, a tracing-moving GC doesn't spend any cycles on garbage; it spends cycles on live objects only. The more heap you give it (assuming the same allocation rate and live set), means more garbage and less CPU consumption (as GC cycles are less frequent).

All you know is that CPU is exhausted before the RAM is, which, if anything, means that it may have been useful for Chrome to use more RAM (and reduce the liveset-to-heap ratio) to reduce CPU utilisation, assuming this CPU consumption has anything to do with memory management.

There is no situation in which, given the same allocation rate and live set, adding more heap to a tracing GC makes it work more. That's why in the talk he says that a DIMM is a hardware accelerator for memory management if you have a tracing-moving collector: increase the heap and voila, less CPU is spent on memory management.

That's why tracing-moving garbage collection is a great choice for any program that spends a significant amount of CPU on memory management, because then you can reduce that work by adding more RAM, which is cheaper than adding more CPU (assuming you're running on a machine that isn't RAM-constrained, like small embedded devices).

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

#278

Post by josephg » Sun, Aug 24, 2025, 11:18 PM UTC

mwcampbell wrote: post #245

josephg wrote: post #235

Earlier quoted context omitted.

Yeah async rust is definitely the exception. That and Pin, which in my opinion totally missed the mark. The feature rust needs is the ability to have self reference in a struct. Pin is a hacky, inadequate half solution.

Can we all please stop complaining about async Rust and just acknowledge that the problem they were solving was both really hard and urgent for the success of the language (particularly given priorities among the most well-resourced tech companies in the late 2010s)? All things considered, I think they did a good job. I certainly wouldn't have done any better. And the feature was well thought through, with years of w…

The problem is really hard. But I think bringing it up is useful, because it motivates people to think about how they would solve it better. It’s certainly a question I’ve asked myself a bunch of times.

If we all stopped complaining about memory safety in C and C++, we would never have gotten rust in the first place. Rob pike would never have let generics make it into Go if people didn’t spend years pestering him about it.

I think I fail by taking for granted all the work that’s gone into languages like rust. Lots of smart people have poured themselves into these discussions and designs. Thankyou. I don’t say that enough.

But yeah, async rust seems like one of those places where people arguing it out on github didn’t converge at a great design. It’s a really hard problem - really, combining a borrow checker with stack suspension is a CS research problem. I think it’s interesting and important to acknowledge that committees don’t always do great research. Sometimes you need a bunch of iterations of an idea. And a bright cookie or two who can work without justifying their designs.

So no, I don’t think I’ll stop talking about it. Making async rust v1 was an incredible amount of work and I’m very grateful. But I also really want to seed the idea space so some bright sparks can think about what async rust v2 might look like.

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

#279

Post by [deleted] » Mon, Aug 25, 2025, 1:38 AM UTC

littlestymaar wrote: post #222

ksec wrote: post #195

Earlier quoted context omitted.

That is actually a valid point on expectation given the attracted people's demographic. I will hopefully wait for comments from Ghostty, Bun or Tigerbeetle Devs. On another point that is wroth mentioning, I hope Andrew will at least put it out publicly, IMO Zig isn't Anti-Rust. But it did attract the type of people who are not too happy with Rust. I dont remember a single time Zig came out to bash anything about Rust…

I don't think Andrew is anti-Rust. But Loris, whose hn profile says he's “vp of community of the zig software foundation” is as anti-Rust as you can get: he's pathologically obsessed by Rust and spent significant amount of energy outright insulting Rust maintainers here or on Twitter (when he's not buzzy writing anti-Rust rant on his blog). But as you say, there's no reason why Zig ought to be anti-Rust, both languag…

[deleted]

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

#280

Post by pron » Mon, Aug 25, 2025, 1:41 AM UTC

Ygg2 wrote: post #274

pron wrote: post #254

Earlier quoted context omitted.

> The problem with this statement is that without a memory safety invariant your code doesn't compose Yes, but that holds for any correctness property, not just the 0.0001% of them that memory safe languages guarantee. That's why we have bugs. The reason memory safety is a focus is because out-of-bounds access is the leading cause of dangerous vulnerabilities. > The goal of all engineering disciplines, including soft…

> Yes, but practical minimisation, not hypothetical minimisation, i.e. how can I get the least bugs while keeping all my constraints, including budget. Like I said, a language like Rust exists because minimisation of errors is not the only constraints, because if it were, there are already far more popular languages that do just as much. Rust achieves practical minimization, if not outright eradication, of a set of e…

> Rust achieves practical minimization, if not outright eradication, of a set of errors even in practice. And not just memory safety errors.

It achieves something in one way, while requiring you to pay some price, while other languages achieve something in a different way, with a different cost. I've been involved with software correctness for many, many years (early in my career I worked on safety-critical, hard realtime software, and then practised and taught formal methods for use in industry), and there is simply no research, none, suggesting that Rust's approach is necessarily the best. Remember that most software these days - not the kind that flies aeroplanes or controls pacemakers, that's written mostly in C, but the kind that runs your bank, telecom supplier, power company, healthcare etc. but also Facebook - is written in languages that offer the same guarantees as Rust, for better or worse.

> If everyone could write and think in pre/post/invariant way, we'd see a lot fewer issues.

Except I've worked with formal methods in a far more rigorous way than Rust offers (well, it offers almost nothing), and in this field there is now the acknowledgement that software correctness can be achieved in many different ways. In the seventies there was a consensus about how to write correct software, and then in the nineties it all got turned around.

> That's like your fork deciding to gut you like a fish.

I don't think so, because everyone uses a fork but this is the first time I hear about Comet AI. The most common way to empty people's bank accounts is still by conning them.

> Why? Just because you are intelligent doesn't mean you are rational.

Intelligence has nothing to do with it. But "rational" here means "in accordance with reality", and since software is a major competitive economic activity, which means that if some organisations act irrationally, there's both a strong motivation and an ability to take their lunch money. If they still have it, they're probably not behaving irrationally.