On Sat, 01 Feb 2014 16:07:20 -0800, Frank Bauer <y...@z.com> wrote:
Granted, low latency apps are the minority. C++ apps are a minority
compared to C# and Java combined. Beyond any doubt there is merit to a
GC in all apps that don't have to squeeze the last bit of performance
out of the machine, yes, the vast majority, I know.
But maybe we should ask ourselves if it makes sense to get the low
latency developers on board, especially if D's syntax remains basically
unchanged in the process. Heck, we could even keep 'new' instead of
Rusts '~' for owning pointers.
On Saturday, 1 February 2014 at 19:40:20 UTC, Adam Wilson wrote:
On Sat, 01 Feb 2014 06:33:15 -0800, Frank Bauer <x...@y.com> wrote:
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.
Ahem ... no you don't. I tried to make my point as clear as possible.
Unique_ptr *semantics*, e.g. Rusts 'let x = ~X' *without* GC is as easy
to use as 'auto x = new X' *with* GC. In both cases the runtime takes
care of freeing the object without user intervention.
So newbies should not be turned off, if that is your concern.
In general, I don't understand your arguments against dumping the GC if
it does not make much difference in your code anyways? Getting rid of
mandatory GC would not take away one iota of your D expressiveness. It
means more work on the part of D's implementers, to be sure.
I'm close to Stuttgart and Ingolstadt where Mercedes Benz and Audi
produce their flagship cars for a tiny minority of customers. Yet their
reputation with the average buyer relies heavily on how well their top
of the line products fare.
Do we want D to be the flagship?
The problem isn't syntax, it's semantics. It's not 'new' versus '~' (which
by the way is not easy to type on a standard US keyboard, it's a shift+key
that's in an an uncomfortable position). It's the number of rules and
special cases around what happens when I do something. You're right, you
are not asking for a big syntactic change, and I know that. What you are
asking for is a massive semantics change, and that means new rules and
most likely, more of them.
Let's look at some numbers. TIOBE, Go is #36, Rust does not even make the
Top 100. On TIOBE, there are three non-GC languages in the entire top 20
(C, C++, Obj-C) the rest feature a non-ARC GC of some form. I am not
concerned with how the languages manage memory under-the-hood, only how
they present their memory management semantics to the user.
It's interesting that you bring up Mercedes and Audi. Yes, their
reputation is defined by their high-end products. But how many people
actually buy an R8 or an SLK Black? The vast majority or everyday don't
buy a completely bonkers super-car, they by cars that get the job done.
Why do Toyota and Volkswagen produce the most cars in the world? Not
because either company (yes, I am aware of VW's 13 name-plates, I'm
talking about the VW name-plate here) is particularly renowned for
producing supercars, but because their cars reliably get the job done. A
Corolla is not the fastest, it's not the prettiest, and it's certainly not
the most expensive. More Corolla's have been sold world-wide (40 million)
than any other single car model in history.
You want a super-car, with all the fancy buttons and knobs and options,
and ARC is very analogous to a super-car in this respect. In fact many of
the complaints I see about Obj-C's ARC have to do with the semantics of
it. ARC is by definition semantically more complex than a GC. But most
people don't want those options, they just want to put the key in and have
the car reliably do what they ask within reasonable boundaries and that is
what a GC does best. The semantics of a good GC are nearly transparent.
But that's where the analogy breaks down. You can stratify car models. You
can't deliver multiple exclusive strata in a programming language. A
language is what it is, there are no multiple levels.
You say, let's bring on the low-latency developers to prove how fast D is
and how it has all these great options. The problem is most programmers
don't need those options on a day to day basis, but having to carry around
the semantics for them everywhere is wearying. I say, let's fix the GC to
so that the masses can do what they need to do without any fuss.
Most car drivers aren't Jeremy Clarkson. And most programmers aren't
real-time embedded developers. A friend of mine has a saying "Sell to the
masses, eat with the classes. Sell to the classes, eat with the masses."
It's a catchy way of saying, you don't make money or gain popularity by
catering to the most demanding of users or the most wealthy of clients.
You gain popularity by catering to the NEEDS of the everyday user, or the
middle-class client.
The reason I am being to vehement, is that I unlike most people here, I
see D as needing to focus on making the experience better for the every
day programmer, NOT the experience of the most demanding users. And as C++
has proven, the two are distinct, writing a language that caters to the
high-end often precludes the semantics that appeal to the everyday
precisely because those semantics are too slow.
--
Adam Wilson
GitHub/IRC: LightBender
Aurora Project Coordinator
