Remix.run Logo
Ygg2 6 hours 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 6 hours ago | parent [-]

> 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).

Ygg2 34 minutes ago | parent [-]

> 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.

That's not the issue. Calling anything with opt-in reference counting a GC language. You're just fudging definitions to get to the desired talking point. I mean, C is, by that definition, a GC language. It can be equipped with

> That it's not as easily quantifiable doesn't make it any less real.

It makes it more subjective and easy to bias. Rust has a clear purpose. To put a stop to memory safety errors. What does it's painful to use? Is it like Lisp to Haskell or C to Lisp.

> For example, it would be hard to distinguish between Java and Haskell.

It would be possible to objectively distinguish between Java and Haskell, as long as they aren't feature-by-feature compatible.

If you can make a program that halts on that feature, you can prove you're in language with that feature.

> 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.

Yeah, because you fight a strawman. Having a safe language is a precondition but not enough. I want it to be as performant as C as well.

Second, even if you have the goal of moving to ATS, developing ATS-like isn't going to help. You need a mass of people to move there.