On Tuesday, 8 October 2013 at 15:43:46 UTC, ponce wrote:
At least on Internet forums, there seems to be an entire
category of people dismissing D immediately because it has a GC.
http://www.reddit.com/r/programming/comments/1nxs2i/the_state_of_rust_08/ccne46t
http://www.reddit.com/r/programming/comments/1nxs2i/the_state_of_rust_08/ccnddqd
http://www.reddit.com/r/programming/comments/1nsxaa/when_performance_matters_comparing_c_and_go/cclqbqw
The subject inevitably comes in every reddit thread like it was
some kind of show-stopper.
Now I know first-hand how much work avoiding a GC can give
(http://blog.gamesfrommars.fr/2011/01/25/optimizing-crajsh-part-2-2/).
Yet with D the situation is different and I feel that criticism
is way overblown:
- first of all, few people will have problems with GC in D at
all
- then minimizing allocations can usually solve most of the
problems
- if it's still a problem, the GC can be completely disabled,
relevant language features avoided, and there will be no GC
pause
- this work of avoiding allocations would happen anyway in a
C++ codebase
- I happen to have a job with some hardcore optimized C++
codebase and couldn't care less that a GC would run provided
there is a way to minimize GC usage (and there is)
Whatever rational rebutal we have it's never heard.
The long answer is that it's not a real problem. But it seems
people want a short answer. It's also an annoying fight to have
since so much of it is based on zero data.
Is there a plan to have a standard counter-attack to that kind
of overblown problems?
It could be just a solid blog post or a @nogc feature.
I thought about an alternative approach:
Instead of using a (yet another) annotation, how about
introducing a flag similar to -cov, which would output lines in
which the GC is used.
This information can be used by an IDE to highlight those lines.
Then you could quickly navigate through your performance-critical
loop and make sure it's clean of GC.
