4 ms·

Rust does have a GC, but I agree it planted its flag at some intermediate point on the spectrum. Zig didn't "go backwards" but planted its own flag ever so slig

by pron 10mo ago

Rust does have a GC, but I agree it planted its flag at some intermediate point on the spectrum. Zig didn't "go backwards" but planted its own flag ever so slightly closer to C than to ATS (although both Rust and Zig are almost indistinguishable from C when compare to ATS). I don't know if where Rust planted its flag is universally better than where Zig planted its flag, but 1. no one else does either, 2. both are compromises, and 3. it's uncertain whether a universal sweet spot exists in the first place. > How did you derive this from the top 25 of CWEs? Let's say you completely remove the spatial memory issues. You still get temporal memory issues at #6. Sure, but spatial safety is higher. So if Rust's compromise, we'll exact a price on temporal safety and have both temporal and spatial safety, is reasonable, then so is Zig's that says, the price on temporal safety is too high for what you get in return, but spatial safety only is a better deal. Neither go as far as ATS in offering, in principle, the ability to avoid all bugs. Nobody knows whether Rust's compormise is universally better than Zig's or vice versa (or perhaps neither is universally better), but I find it really strange to arbitrarily claim that one compromise is reasonable and the other isn't, where both are obviously compromises that recognise there are different benefits and different costs, and that not every benefit is worth any cost.

Ygg2 10mo ago
> Rust does have a GC It doesn't. Not by any reasonable definition of having a GC. And "opt-in non-tracing GC that isn't used largely throughout the standard library" is not a reasonable definition. > Nobody knows whether Rust's compormise is universally better than Zig's When it comes to having more segfaults, we know. Zig "wins" most segfaults per issue Razzie Award. This is what happens when you ignore one type of memory safety. You have to have both. Just ask Go.
- pron 10mo ago
  > And "opt-in non-tracing GC that isn't used largely throughout the standard library" is not a reasonable definition. Given that refcounting and tracing are the two classic GC algorithms, I don't see what specifying "non tracing" here does, and reference-counting with special-casing of the one reference case is still reference counting. I don't know if the "reasonable definition" of GC matters at all, but if it does, this does count as one. I agree that the one-reference case is handled in the language and the shared reference case is handled in the standard library, and I think it can be reasonable to call using just the one-reference case "not a GC", but most Rust programs do use the GC for shared references. It is also true that Rust depends less on GC than Java or Go, but that's not the same as not having one. > When it comes to having more segfaults, we know. Zig "wins" most segfaults per issue Razzie Award. And Rust wins the Razzie Award for most painful development and lack of similarly powerful arenas. It's like declaring that you win by paying $100 for something while I paid $50 for something else without comparing what we got for the money, or declaring that you win by getting a faster car without looking at how much I paid for mine. > This is what happens when you ignore one type of memory safety. When you have less safety for any property, you're guarnateed to have more violations. This is what you buy. Obviously, this doesn't mean that avoiding those extra violations is necessarily worth the cost you pay for that extra safety. When you buy something, looking just at what you pay or just at what you get doesn't make any sense. The question is whether this is the best deal for your case. Nobody knows if there is a universal best deal here let alone what it is. What is clear is that nothing here is free, and that nothing here has infinite value.
  - Ygg2 10mo ago
    > I don't know if the "reasonable definition" of GC matters at all If you define all non-red colors to be green, it is impossible to talk about color theory. > And Rust wins the Razzie Award for most painful development and lack of similarly powerful arenas. That's a non-quantifiable skill issue. Segfaults per issue is a quantifiable thing. > When you have less safety for any property, you're guarnateed to have more violations. If that's what you truly believed outside some debate point. Then you'd be advocating for ATS or Ada.SPARK, not Zig.
    - pron 10mo ago
      > If you define all non-red colors to be green, it is impossible to talk about color theory. Except reference counting is one of the two classical GC algorithms (alongside tracing), so I think it's strange to treat it as "not a GC". But it is true that GC/no-GC distinction is not very meaningful given how different the tradeoffs that different GC algorithms make are. Even within these basic algorithms there are combinations. For example a mark-and-sweep collector is quite different from a moving collector, or CPython uses refcouting for some things and tracing for others. > That's a non-quantifiable skill issue. Segfaults per issue is a quantifiable thing. That it's not as easily quantifiable doesn't make it any less real. If we compare languages only by easily quantifiable measures, there would be few differences between them (and many if not most would argue that we're missing the differences that matter to them most). For example, it would be hard to distinguish between Java and Haskell. It's also not necessarily a "skill issue". I think that even skilled Rust users would admit that writing and maintaining a large program in TypeScript or Java takes less effort than doing the same in Rust. Also, ATS has many more compile-time safety capabilities than either Rust or Zig (in fact, compared to ATS, Rust and Zig are barely distinguishable in what they can guarantee at runtime), so according to your measure, both Rust and Zig lose when we consider other alternatives. > Then you'd be advocating for ATS or Ada.SPARK, not Zig. Quite the opposite. I'm pointing out that, at least as far as this discussion goes, every added value comes with added cost that needs to be considered. If what you truly believed is that more compile-time safety always wins, then it is you who should be advocating for ATS over Rust. I'm saying that we don't know where the cost-benfit sweet point is or, indeed, even if there's only one such sweey point or multiple. I'm certainly not advocating for Zig as a universal choice. I'm advocating for selecting the right tradeoffs for every project, and I'm rejecting the claim that whatever benefits Rust or Zig have compared to the other are free. Both (indeed, all languages) require you to pay in some way to get what they're offering. In other words, I'm advocating can both be more or less appropriate than the other, depending on the situation and against the position that Rust is always superior, which is based on only looking at its advantages and ignoring its disadvantages (which, I think, are quite significant).

by pron 10mo ago

Ygg2 10mo ago

> Rust does have a GC It doesn't. Not by any reasonable definition of having a GC. And "opt-in non-tracing GC that isn't used largely throughout the standard library" is not a reasonable definition. > Nobody knows whether Rust's compormise is universally better than Zig's When it comes to having more segfaults, we know. Zig "wins" most segfaults per issue Razzie Award. This is what happens when you ignore one type of memory safety. You have to have both. Just ask Go.

pron 10mo ago
> And "opt-in non-tracing GC that isn't used largely throughout the standard library" is not a reasonable definition. Given that refcounting and tracing are the two classic GC algorithms, I don't see what specifying "non tracing" here does, and reference-counting with special-casing of the one reference case is still reference counting. I don't know if the "reasonable definition" of GC matters at all, but if it does, this does count as one. I agree that the one-reference case is handled in the language and the shared reference case is handled in the standard library, and I think it can be reasonable to call using just the one-reference case "not a GC", but most Rust programs do use the GC for shared references. It is also true that Rust depends less on GC than Java or Go, but that's not the same as not having one. > When it comes to having more segfaults, we know. Zig "wins" most segfaults per issue Razzie Award. And Rust wins the Razzie Award for most painful development and lack of similarly powerful arenas. It's like declaring that you win by paying $100 for something while I paid $50 for something else without comparing what we got for the money, or declaring that you win by getting a faster car without looking at how much I paid for mine. > This is what happens when you ignore one type of memory safety. When you have less safety for any property, you're guarnateed to have more violations. This is what you buy. Obviously, this doesn't mean that avoiding those extra violations is necessarily worth the cost you pay for that extra safety. When you buy something, looking just at what you pay or just at what you get doesn't make any sense. The question is whether this is the best deal for your case. Nobody knows if there is a universal best deal here let alone what it is. What is clear is that nothing here is free, and that nothing here has infinite value.
- Ygg2 10mo ago
  > I don't know if the "reasonable definition" of GC matters at all If you define all non-red colors to be green, it is impossible to talk about color theory. > And Rust wins the Razzie Award for most painful development and lack of similarly powerful arenas. That's a non-quantifiable skill issue. Segfaults per issue is a quantifiable thing. > When you have less safety for any property, you're guarnateed to have more violations. If that's what you truly believed outside some debate point. Then you'd be advocating for ATS or Ada.SPARK, not Zig.
  - pron 10mo ago
    > If you define all non-red colors to be green, it is impossible to talk about color theory. Except reference counting is one of the two classical GC algorithms (alongside tracing), so I think it's strange to treat it as "not a GC". But it is true that GC/no-GC distinction is not very meaningful given how different the tradeoffs that different GC algorithms make are. Even within these basic algorithms there are combinations. For example a mark-and-sweep collector is quite different from a moving collector, or CPython uses refcouting for some things and tracing for others. > That's a non-quantifiable skill issue. Segfaults per issue is a quantifiable thing. That it's not as easily quantifiable doesn't make it any less real. If we compare languages only by easily quantifiable measures, there would be few differences between them (and many if not most would argue that we're missing the differences that matter to them most). For example, it would be hard to distinguish between Java and Haskell. It's also not necessarily a "skill issue". I think that even skilled Rust users would admit that writing and maintaining a large program in TypeScript or Java takes less effort than doing the same in Rust. Also, ATS has many more compile-time safety capabilities than either Rust or Zig (in fact, compared to ATS, Rust and Zig are barely distinguishable in what they can guarantee at runtime), so according to your measure, both Rust and Zig lose when we consider other alternatives. > Then you'd be advocating for ATS or Ada.SPARK, not Zig. Quite the opposite. I'm pointing out that, at least as far as this discussion goes, every added value comes with added cost that needs to be considered. If what you truly believed is that more compile-time safety always wins, then it is you who should be advocating for ATS over Rust. I'm saying that we don't know where the cost-benfit sweet point is or, indeed, even if there's only one such sweey point or multiple. I'm certainly not advocating for Zig as a universal choice. I'm advocating for selecting the right tradeoffs for every project, and I'm rejecting the claim that whatever benefits Rust or Zig have compared to the other are free. Both (indeed, all languages) require you to pay in some way to get what they're offering. In other words, I'm advocating can both be more or less appropriate than the other, depending on the situation and against the position that Rust is always superior, which is based on only looking at its advantages and ignoring its disadvantages (which, I think, are quite significant).