On Monday, 16 November 2020 at 19:04:48 UTC, Paulo Pinto wrote:
> It doesn't matter if there some C++ to go alongside C#, most studios are polyglot and don't see a nail in every problem.

You could write a good game with javascript + C++, or Dart + C++, if you keep the game world on the GC side. Not too bad for an indie game with two developers, one doing the graphics and the other one the game mechanics.

So I don't think that is unreasonable, but the current GC that D has to to support to carry existing code bases is not in the same ballpark. If you want to create a dynamic online "streaming" game world then you deal with a lot of pointers and lots of caching...

It is not that this cannot change, but as of today that is farther away than 1-2 years... IMHO.

On Monday, 16 November 2020 at 19:12:55 UTC, Ola Fosheim Grøstad wrote:
> On Monday, 16 November 2020 at 19:04:48 UTC, Paulo Pinto wrote:
>> It doesn't matter if there some C++ to go alongside C#, most studios are polyglot and don't see a nail in every problem.
>
> You could write a good game with javascript + C++, or Dart + C++, if you keep the game world on the GC side. Not too bad for an indie game with two developers, one doing the graphics and the other one the game mechanics.
>
> So I don't think that is unreasonable, but the current GC that D has to to support to carry existing code bases is not in the same ballpark. If you want to create a dynamic online "streaming" game world then you deal with a lot of pointers and lots of caching...
>
> It is not that this cannot change, but as of today that is farther away than 1-2 years... IMHO.

But that is the whole point, what needs improving is the current implementation of D's GC, not throwing away everything.

On Monday, 16 November 2020 at 19:34:00 UTC, Paulo Pinto wrote:
> But that is the whole point, what needs improving is the current implementation of D's GC, not throwing away everything.

But D first need people to agree on the semantic constraints that can enable this... And that will break some code bases. So there is in essence a cultural resistance to improving the GC.

On Monday, 16 November 2020 at 18:19:56 UTC, Max Haughton wrote:

> Is this "Laser-D" supposed to be a separate language on just a project to document betterC?
>

My plan is document a subset of D that is maybe even more restricted than Better C - because I think not every feature of D is needed.

I would like to turn off features in the compiler to reflect the language definition, but this may be too much effort. But one thing I want to guarantee is that all Laser-D programs will also be D programs.


>
> If you really want to make -betterC better, there are still noticable flaws with it - for example you still can't use std.format at compile time in -betterC mode (https://run.dlang.io/is/TIcgW2).

If I am not mistaken there are few tests that cover the Better C option - so there are probably many bugs lurking there... I hope not but I already found that despite what the doc says, creating C++ classes in Better C does not appear to work (doc isn't clear though about whether you can only interface to C++ classes or create them too).

On Monday, 16 November 2020 at 19:51:28 UTC, Ola Fosheim Grøstad wrote:
> On Monday, 16 November 2020 at 19:34:00 UTC, Paulo Pinto wrote:
>> But that is the whole point, what needs improving is the current implementation of D's GC, not throwing away everything.
>
> But D first need people to agree on the semantic constraints that can enable this... And that will break some code bases. So there is in essence a cultural resistance to improving the GC.

Why D (and many other languages) would benefit from the equivalent of rust's editions (although I'm not sure the D dev team can carry the burden of that with the few people that they have).