https://news.ycombinator.com/item?id=8781522

http://arthurtw.github.io/2014/12/21/rust-anti-sloppy-programming-language.html

c'est possible!

Oh how much free time and stability there would be if D core *moved* GC downstream.

Vic
ps: more cows waiting for slaughter: http://dlang.org/comparison.html

On Mon, 22 Dec 2014 12:28:16 +0000
Vic via Digitalmars-d <digitalmars-d@puremagic.com> wrote:

> https://news.ycombinator.com/item?id=8781522
> 
> http://arthurtw.github.io/2014/12/21/rust-anti-sloppy-programming-language.html
> 
> c'est possible!
> 
> Oh how much free time and stability there would be if D core *moved* GC downstream.
> 
> Vic
> ps: more cows waiting for slaughter:
> http://dlang.org/comparison.html

oh, how much usefullness there would be if D core suspended all other activities and maked GC on par with "industrial strength" GCs!

i'm trying to tell you that i LOVE GC. and i can't share the (growing?) attitute that GC is a poor stepson. what we really need is a better GC, not "no GC".

On Monday, 22 December 2014 at 22:02:46 UTC, ketmar via Digitalmars-d wrote:
>
> oh, how much usefullness there would be if D core suspended all other
> activities and maked GC on par with "industrial strength" GCs!
>
> i'm trying to tell you that i LOVE GC. and i can't share the (growing?)
> attitute that GC is a poor stepson. what we really need is a better GC,
> not "no GC".

The GC is good for 90% of programs. It's not good for some programs (games in particular are a common use case). Though even in games it's fine in some situations, such as during loading. D needs to support these cases.

On Monday, 22 December 2014 at 12:28:18 UTC, Vic wrote:
> https://news.ycombinator.com/item?id=8781522
>
> http://arthurtw.github.io/2014/12/21/rust-anti-sloppy-programming-language.html
>
> c'est possible!
>
> Oh how much free time and stability there would be if D core *moved* GC downstream.
>
> Vic
> ps: more cows waiting for slaughter: http://dlang.org/comparison.html

On the other side, http://www.inf.ethz.ch/personal/wirth/ProjectOberon/

http://www.ethoberon.ethz.ch/native/WebScreen.html

--
Paulo

On Tue, Dec 23, 2014 at 12:02:36AM +0200, ketmar via Digitalmars-d wrote: [...]
> oh, how much usefullness there would be if D core suspended all other activities and maked GC on par with "industrial strength" GCs!
> 
> i'm trying to tell you that i LOVE GC. and i can't share the (growing?) attitute that GC is a poor stepson. what we really need is a better GC, not "no GC".

+1000.


--T

On Mon, 22 Dec 2014 22:09:22 +0000
Kapps via Digitalmars-d <digitalmars-d@puremagic.com> wrote:

> On Monday, 22 December 2014 at 22:02:46 UTC, ketmar via Digitalmars-d wrote:
> >
> > oh, how much usefullness there would be if D core suspended all
> > other
> > activities and maked GC on par with "industrial strength" GCs!
> >
> > i'm trying to tell you that i LOVE GC. and i can't share the
> > (growing?)
> > attitute that GC is a poor stepson. what we really need is a
> > better GC,
> > not "no GC".
> 
> The GC is good for 90% of programs. It's not good for some programs (games in particular are a common use case). Though even in games it's fine in some situations, such as during loading. D needs to support these cases.

there is nothing really hard to support that: just don't allocate in main game loop. ;-)

on the other side good concurrent GC can work alongside with game logic. game engine can fine-tune it if necessary.

also, nobody says that game engine can't use other allocators. as game engines tend to skip standard libraries anyway, i can't see much sense in making Phobos "good for game engines".

On Monday, 22 December 2014 at 22:02:46 UTC, ketmar via Digitalmars-d wrote:
> On Mon, 22 Dec 2014 12:28:16 +0000
. what we really need is a
> better GC,
> not "no GC".

I am not saying no GC; I am saying:
a) something needs to be moved out of core. If not GC, what would you move downstream?

b) move, not remove. So you can plug in any gc implementation you like - the current GC if you still like it.
Like linux kernal needs gnu to do 'cd'.

hth,
Vic

On Monday, 22 December 2014 at 23:21:17 UTC, Vic wrote:
> I am not saying no GC; I am saying:
> a) something needs to be moved out of core.

And many don't agree.

> If not GC, what would you move downstream?
>
> b) move, not remove.

Move where? There is no downstream. There are no hordes of
developers waiting for the GC to be decoupled from druntime, so
that they can finally start working on it. The same people would
work on it. There would be no concentration of effort on other
areas.

> So you can plug in any gc implementation you like - the current GC if you still like it.

I think the GC is supposed to be somewhat pluggable. If it can be
made more pluggable, I don't think anyone would object.

Would the non-core GC still be shipped with releases? Could the
language and Phobos still rely on a GC being there?

If so, I see no point in any re-branding. The personnel wouldn't
change. It would still be perceived as simply D's GC.

If not, that would be a huge breaking change. The language and
Phobos would need a major overhaul to be compatible with an
optional GC. Everything D under the sun would either have the
non-core GC as a dependency, need a major overhaul, or die. The
cost to make it happen would be high. The only benefit I can see
would be a signal to end-users that the GC isn't quite there yet.
I don't think it would be a good move.

On Tuesday, 23 December 2014 at 00:49:57 UTC, anonymous wrote:
> On Monday, 22 December 2014 at 23:21:17 UTC, Vic wrote:
>> I am not saying no GC; I am saying:
>> a) something needs to be moved out of core.
>
> And many don't agree.
>
<snip>

Dear Anonymous,

IMO D needs to be more stable, the alternative is more and more features and less and less commercial users and followed by less maintainers that don't want a dead project to work on. D 'marketing' brings people in, who then leave.
So I proposed: Do like GO does w/ Exceptions ( I can send link again if need)

*What* would be another way to get stability that is not fantasy?

I consider the surface area of features vs available volunteer maintainers at hand. If you are not sold, look at CLR and JRE features relative to D features. Now look at the size of their maintenance teams as relative FTE.

Does that look as sustainable?

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.

Vic

On Tuesday, 23 December 2014 at 03:32:12 UTC, Vic wrote:
> On Tuesday, 23 December 2014 at 00:49:57 UTC, anonymous wrote:
>> On Monday, 22 December 2014 at 23:21:17 UTC, Vic wrote:
>>> I am not saying no GC; I am saying:
>>> a) something needs to be moved out of core.
>>
>> And many don't agree.
>>
> <snip>
>
> Dear Anonymous,
>
> IMO D needs to be more stable, the alternative is more and more features and less and less commercial users and followed by less maintainers that don't want a dead project to work on. D 'marketing' brings people in, who then leave.
> So I proposed: Do like GO does w/ Exceptions ( I can send link again if need)
>
> *What* would be another way to get stability that is not fantasy?
>
> I consider the surface area of features vs available volunteer maintainers at hand. If you are not sold, look at CLR and JRE features relative to D features. Now look at the size of their maintenance teams as relative FTE.
>
> Does that look as sustainable?
>
> 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.
>
> Vic

+1