| |
| Posted by Stanislav Blinov in reply to H. S. Teoh | PermalinkReply |
|
Stanislav Blinov
Posted in reply to H. S. Teoh
| On Wednesday, 17 November 2021 at 02:32:21 UTC, H. S. Teoh wrote:
> And you know what? In spite of all this time and effort, programmers get it wrong anyway -- typical C code is full of memory leaks, pointer bugs, and buffer overflows.
People write bugs. You don't say!
> Most of them are latent and only trigger in obscure environments and unusual inputs, and so lie undiscovered, waiting for the day it suddenly explodes on a customer's production environment.
GC isn't solving those issues. It's masking them. If you have a stale pointer somewhere, the bug *is* that the pointer is stale. Making it point to some forgotten piece of data is not a solution, it's a write off of a lost cause. Yeah, it's @safe, sure. Because you're leaking.
> Or somebody comes up with a security exploit...
Your susceptibility to security (and other) exploits grows proportional to the number of dependencies, of which druntime (and, consequently, GC) is one. So that's kind of a moot point.
> With a GC, you instantly eliminate 90% of these problems. Only 10% of the time, you actually need to manually manage memory -- in inner loops and hot paths where it actually matters.
It's so funny how you keep talking about this mythical 90% vs 10% split. When you have 16ms *for everything*, and a single collection takes 8ms, during which the whole world is stopped, you can't have 90/10. When you can't actually disable the GC (and you can't *actually* disable the GC), you can't have 90/10, because eventually some forced collection *will* turn that 90 into 99. So, practically, it comes down to either you use the GC, or you don't, period. That is not the fault of GC per se, but it's the consequence of lack of control. Unfortunately, price of convenience sometimes is just too high.
> GC phobia is completely irrational and I don't see why we should bend over backwards to please that crowd.
Simply put? Because any decent API doesn't transfer its garbage to its callers. And because, surprise, sometimes deterministic run time is a requirement. If the cost of calling your function is 100 cycles now and a million at some poorly specified point in the future, I'd consider looking for something that would just take the million up front.
|