3 ms·
What the author is saying sadly also applies to his own arguments. And this is even worse: "Dangling reference out of memory errors are rare (maybe 1 in 10 pr
by stephc_int13 7y ago
What the author is saying sadly also applies to his own arguments.
And this is even worse:
"Dangling reference out of memory errors are rare (maybe 1 in 10 programs?) whereas regular memory bugs like use-after-free, double free, off by one errors, etc are very common (100-1000 in every program)."
In my opinion, this is a weak statement, it does not match my experience at all, and I've been programming at a professional level for about twenty years.
- crazygringo 7y agoPlease tell me your comment is satire, yes? That you're making the author's point for them -- that you're responding not to the point of the article, that you're 100% technically correct, but "missing the entire point" of the article? :)
- axaq 7y agoWhat is the point of the article? To insert absolutist "truths" about a whole range of issues while disallowing anyone to disagree lest he is a pedant? Calling out outrageous statements is not pedantry.
- stephc_int13 7y agoI think the case would have been much stronger if the author didn't mix his argument with his opinions about GC, Python, etc.
- travisjungroth 7y agoWhen someone makes a pretty soft general statement, pointing out small details that are on the other side doesn’t disprove them and doesn’t help anything. I see it all the time online. Someone makes a statement, and then someone implicitly or explicitly disagrees and offers up a detail that doesn’t actually refute anything. When I get hit by these I ask “what did I say that you disagree with?” Take the first example. The main point is GCs save time. A bad refutation is pointing out the downsides that exist. Of course there are downsides. A good disagreement is something like “Garbage collected languages don’t end up saving time in the long run. They’re so widely used now that most projects start with them, even the ones that grow into huge applications. And since the developers aren’t used to handling memory directly, relatively rare bugs can spiral out of control and slow down a whole company.” That’s not an argument I would make, but it’s a decent one that refutes the actual point of the statement.
- AlanSE 7y agoHow have you seen dangling reference OOM situations in the real world? Speaking for a python / Django stack, there's a very concrete reason that these are rarely seen in my experience. Code never lives long enough for it to matter. In any practical situation, workers are recycled at a furious rate. uWSGI will recycle a worker for many reasons, or for no reason at all. There are plenty of apps out there where, if you changed the settings to make the processes fairly persistent, they would OOM on a regular basic. This might be the vast majority of Django apps out there. But that's just it - no long trusts python enough to keep it running in the background forever. So OOM like this is a non-issue.
- GoblinSlayer 7y agoWhen code lives long enough. If your process is short living, you don't need any form of memory management at all, just allocate and terminate the process when done.