cross post hn: (Rust) _ _ without GC

Vic via Digitalmars-d digitalmars-d at puremagic.com
Tue Dec 23 06:16:25 PST 2014


On Tuesday, 23 December 2014 at 04:06:33 UTC, ketmar via 
Digitalmars-d wrote:
> On Tue, 23 Dec 2014 03:32:11 +0000
> Vic via Digitalmars-d <digitalmars-d at puremagic.com> wrote:
>
>> Hence a prediction: major things will be moved out of core to 
>> 3rd party plugins to slim down the lang, because now it's more 
>> than a lang: it is a platform.
>
> D is not a platform. besides, GC is a core feature of D.

As per http://en.wikipedia.org/wiki/Java_%28software_platform%29
Java is a platform as per wikipedia. D, I'll argue has more 
features.
Hence: D *IS* a platform. It is obese. Instead of 'what if 
academics didn't write a language, but a compiler writer writes a 
language, the new culture is: academics are writing a sugary 
platform. (and do they use it on projects, a big part of open 
source is that you use what you write, at their day job their 
team use something else).

D 'has' a 'GC' for certain 'values' of working.  Data point:
My company has 6 *full* time Sr Developers (15 years +) in 
Silicon Valley - one of the larger commercial D users(sad) - so I 
say that we use D (and only D) and for heavy lifting month in and 
month out. So when all 6 tell me GC does not work .... (for 
example allocate a large associative array and run a few threads 
- I may present this example at the 'D meetup silicon valley' in 
Jan meetup and publish example in git). So I tell you, when I see 
focus of the volunteer maintainers on 'what can I add' and not on 
'what can I remove' it scares me to the bone as the CTO. 
Difference w/ Linus and Walter? Both are smart, Walter is a nice 
guy, and not a bastard.

So if maintainers decide that one of the thing to move is GC, one 
way,not the only way, is IOC | DI pattern (you can look up DI and 
IOC), it's doable, but it is like watching a fat person run 10 
yards, they would rather eat a donut).
Leave the method(init, destroy) hooks and ref counting in core. 
People(p/t users of D) than inject the default GC(amateurs by 
definition as they don't get paid to D). So it would be just like 
now.

Professional teams/commercial users write a GC that fits that 
situation, possibly create a D utils open source project - and 
now you have an eco system of downstream open source projects and 
commercial users doing heavy lifting in D and 3rd: the corner 
case of people that use D just a little a few hours a week for a 
few weeks in a year.

But, I don't know I'm saying move GC, I'm saying move somethings. 
Exceptions like GO, the 12 generics features are sugary, etc. 
just open up Andreii's book and go to town. If it's not GC, 
remove something else to the point it is maintainable and 
commercial users can lean on a working D. I am saying lots of 
things should be moved, ex: split the compiler into core and 
pre-compiler for the academic but still needed plugins.
Also, people, I' am a user, so I'm just wagging the tail. Listen 
to the maintainers as to the future direction, I focus on bigger 
or smaller as the leading indicator of weather forecast of future 
stability in D. I'm hearing C++ compatibility will be added, and 
nothing will be removed. I'm hearing other features being added. 
Did anyone hear of something being moved downstream? Nope. God 
forbid users of D have to go to another git repo to get something 
they require.

Vic





More information about the Digitalmars-d mailing list