On Monday, 6 June 2016 at 09:16:45 UTC, Walter Bright wrote:
On 6/6/2016 1:15 AM, Russel Winder via Digitalmars-d wrote:
* Safety has holes and bugs.
Then so does C, C++ and Rust, so this is just a comment made
because it
can be made and sounds bad. Bad enough to salve the conscience
of the
speaker as to why they are not already using D.
It's pretty clear when they say that, and then continue using
C++ which has no safety, that safety isn't the real reason.
Reminds me of an anecdote Andrei is tired of. In the 80s, a C++
developer said that compilation speed, speed, speed is the most
important thing in a C++ compiler. This went on until it was
pointed out to him that he was using Microsoft C++, which was
the slowest at compiling by a factor of 4.
Clearly, what was actually most important to him was a name
brand compiler (social proof), but he needed a more palatable
reason, so he just latched on to one without much thought.
We have to be careful about being led down the garden path by
people who say "I'd use your product if only it did X." I have
a lot of experience with that, and it's very rare that they'll
use it if you do X. They'll just respond with "yeah, ok, but
what I really need is Y." This process never ends. Sometimes
it's because they're embarrassed by the real reason, sometimes
they just take pleasure in you dancing to their tune.
Paying attention to our existing users is a much more reliable
source of information.
I think this is a really important point and I 100% agree with
Walter. Also, the idea that more people will adopt D if you just
"get rid of the GC" ignores the fact that you don't just "get rid
of the GC," you replace it with another memory management scheme
(manual, RAII, RC). If you replace all the parts of the language
and phobos that rely on GC with, e.g., a poor implementation of
RC, then you're just going to get another round of complaints,
and no real adoption.
In my experience, GC complaints are split between existence and
implementation. Some folks are dead against and GC code, others
just don't like how the current GC works. In my world---which is
not AAA gaming or HFT, but is still very concerned with
performance---a GC is tolerable, but a clunky stop-the-world GC
with big unpredictable pauses is less so. Having a high quality
GC that can be avoided (with some agreed-to and well-documented
limitations) would be great.
My concern is that the kill-the-GC craze is going to fall into a
second-system trap, and be replaced with buggy
half-implementations of, say RC, that I can't rely on, or will be
combing through piles of stale bug reports about in 6 months.
I believe a big issue for D, and for any not-mainstream language,
is being straight about what works and what doesn't. D is not
alone in this, but I often feel I'm sold on features that I later
find out are not fully implemented or have big holes in them. The
limitations themselves aren't the problem---the trust is the
problem. I never know if I can tell someone else "D can do that"
safely (turning off the GC is a good example---it took me weeks
of reading forums and documentation to see how practical that
really was after initially reading that it was straightforward.)
