Comment by pron
1 month ago
> Without ever increasing memory/CPU, you're going to have to squeeze more performance out of the stone (more or less unchanging memory/CPUs).
The memory overhead of a moving collector is related only to the allocation rate. If the memory/CPU is sufficient to cover that overhead, which, in turn help save more costly CPU, it doesn't matter if the relative cost reduced (also, it's not even reduced; you're simply speculating that one day it could be).
> I'm not saying it will be fully gone
That's a strange expression given that the percentage of programs written in languages that rely primarily on a GC for memory management has been rising steadily for about 30 years with no reversal in trend. This is like saying that more people will find the cost of typing a text message unacceptable so we'll see a rise in voicemail messages, but of course text messaging will not be fully gone.
Even embedded software is increasingly written in languages that rely heavily on GC. Now, I don't know the future market forces, and maybe we won't be using any programming languages at all but LLMs will be outputting machine code directly, but I find it strange to predict with such certainty that the trend we've been seeing for so long will reverse in such full force. But ok, who knows. I can't prove that the future you're predicting is not possible.
> It's supported by Google's usage of Rust.
There's nothing related here. We were talking about how Zig's design could assist in code reviews and testing, and therefore in the total reduction of bugs, and you said that maybe a complex language like Rust, with lots of implicitness but also temporal memory safety could perhaps have a positive effect on other bugs, too, in comparison. What you linked to is something about Rust vs C and C++. Zig is at least as different from either one as it is from Rust.
> And the overall error rate still favors Rust.
Compared to C++. What does it have to do with anything we were talking about?
> That's a strange expression given that the percentage of programs written in languages that rely primarily on a GC for memory management has been rising steadily for about 30 years
I wish I knew what you mean by programs relying primarily on GC. Does that include Rust?
Regardless, but extrapolating current PL trends so far is a fools errand. I'm not looking at current social/market trends but limits of physics and hardware.
> There's nothing related here. We were talking about how Zig's design could assist in code reviews and testing
No, let me remind you:
> > [snip] Rust defends you from common mistakes, but overall for similar codebases you see fewer bugs.
> I understand that's something you believe, but it's not supported empirically we were talking how not having to worry about UB allows for easier defect catching.
> Compared to C++.
Overall, I think using C++ with all of its modern features should be in the ballpark of safe/fast as Zig, with Zig having a better compile time. Even if it isn't a 1-to-1 comparison with Zig, we have other examples like Bun vs Deno, where Bun incurs more segfaults (per issue).
Also don't see how much of Zig design could really assist code reviews and testing.
> Does that include Rust?
No. Most memory management in Rust is not through it's GC, even though most Rust programs do use the GC to some extent.
> I'm not looking at current social/market trends but limits of physics and hardware.
The laws of physics absolutely do not predict that the relative cost of CPU to RAM will decrease substantially. Unforeseen economic events may always happen, but they are unforeseen. It's always possible that current trends would reverse, but that's a different matter from assuming they are likely to reverse.
> Overall, I think using C++ with all of its modern features should be in the ballpark of safe/fast as Zig, with Zig having a better compile time.
I don't know how reasonable it is to think that. If Rust's value comes from eliminating spatial and temporal memory safety issues, surely there's value in eliminating the more dangerous of the two, which Zig does as well as Rust (but C++ doesn't).
But even if you think that's reasonable for some reason, I think it's at least as reasonable to think the opposite, given that in almost 30 years of programming in C++, by far my biggest issue with the language has been its complexity and implicitness, and Zig fixes both. Given how radically different Zig is from C++, my preferenece for Zig stems precisely from it solving what is, to me, the biggest issue with C++.
> Also don't see how much of Zig design could really assist code reviews and testing.
Because it's both explicit and simple. There are no hidden operations performed by a routine that do not appear in that routine's code. In C++ (or Rust), to know whether there's some hidden call to a destructor/trait, you have to examine all the types involved (to make matters worse, some of them may be inferred).
> No. Most memory management in Rust is not through it's GC, even though most Rust programs do use the GC to some extent.
Most? You still haven't proved that. So most Rust programs mostly use GC, yet it's not a GC language; those are some very mind-contorting definitions.
> The laws of physics absolutely do not predict that the relative cost of CPU to RAM will decrease substantially.
Laws of physics do absolutely tell you that more computation means more heat. Also trying to approach the size of atoms is another no-go. That's why current chip densities have stalled but have been kept on life support via chip stacking and gate redesigns. The 2nm process is mostly a marketing term (https://en.wikipedia.org/wiki/2_nm_process) the actual gate is around 45x20nm.
Not to mention that when working with the way atoms work (i.e. their random nature) and small scales, small irregularities mean low yields.
They put a soft cap on any exponential curve. And hard cap by placing a literal singularity.
> I don't know how reasonable it is to think that.
Why not? With modern collections (std::vector, std::span, and std::string) and modern pointers (std::unique_ptr, std::shared_ptr) you get decent memory safety.
> Because it's both explicit and simple.
Being a simple language doesn't guarantee lack of complexity in implementation (see Brainfuck). The question is how much language complexity buys implementation simplicity. C++ of course has neither because it started with a backwards compatibility goal (it did get abandoned at some point).
By Zig's explicitness, you mean everything is public? I've seen that stuff backfire spectacularly, because you don't get any encapsulation, which means maximum coupling.
1 reply →