Smart pointers instead of GC?

[Adam Wilson]

On Sat, 01 Feb 2014 16:07:20 -0800, Frank Bauer <y at 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 at 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