On Sat, 01 Feb 2014 06:33:15 -0800, Frank Bauer <[email protected]> wrote:
On Saturday, 1 February 2014 at 09:27:18 UTC, Adam Wilson wrote:
For the vast majority of use cases, a GC is the right call and D has to
cater to the majority if it wants to gain any significant mindshare at
all. You don't grow by increasing specialization...
So catering to the C++ crowd who shun Java and C# not so much for JITing
their code but precisely for their forced use of a GC is a "minority"
issue then? Again, please take those of us more serious who don't like a
GC to interfere with their business and if it's only for "programming
hygiene" reasons. As you consider handling low latency requirements
undue "specialisation" anyways.
Real-time or low-latency programming is absolutely specialization, and for
more reasons than a GC. It might be what you do all day, but it's not what
the majority of programmers do all day.
As far as catering to C++. TIOBE says that C++ made up 7.5% of programmer
interest in January. Whereas Java+C# made up 22.4% of programmer interest.
That's almost three-times the interest. Like it or not, C++ IS the
minority and D's mission is not solely based on converting C++ users, many
of whom can't convert anyways. The reason I picked those three languages
is because they are D's primary audience.
On Saturday, 1 February 2014 at 12:04:56 UTC, JR wrote:
To my uneducated eyes, an ARC collector does seem like the near-ideal
solution
ARC would be a plus for heavily interdependent code. But it doesn't beat
unique_ptr semantics in local use that free their memory immediately as
they go out of scope or are reassigned.
So you want C++ back then? Got it. But the goal of D is NOT to be a
slightly better C++, it's a be a Safe, Simple, systems language with well
defined semantics that just happens to trace it's lineage back to C++.
I would *dearly* love to have concurrency in whatever we end up with,
though. For a multi-core personal computer threads are free lunches, or
close enough so.
No they are not. I want to make good use of all the cores I have
available and I don't want to share them a bit with the GC. It's myyy
... precious.
Ahem. You only have the illusion of control over the CPU, the OS scheduler
set's the rules, all you can do is provide hints. Giving some up to the GC
will not materially affect the performance of the your code since you
never had a choice anyways.
As you may have guessed, my criticism is harsh because I love the
language :)
--
Adam Wilson
GitHub/IRC: LightBender
Aurora Project Coordinator
