On Monday, 12 May 2014 at 16:16:06 UTC, bearophile wrote:
> Perhaps the game industry has to start the creation of a language designed for its needs, like the scientific people have done (Julia), the browser ones (Rust), the Web ones have done, etc. With lot of work in less than ten years you can have an usable language.

I don't think games are unique or special. Most games are even in the "easy" space by having mostly static data. Meaning the amount of unexpected dynamic data is pretty low.  Games also have the luxury of redefining the requirements spec to match available technology. The games industry does however have its own culture and paradigms and fashions… With subcultures.

However, most interactive applications will suffer from the same issues if you increase the load so that they run out of headroom. Even unix commands like find and grep have latency requirements if the interaction is to be pleasant. By good fortune "find" and "grep" haven't changed their interface for 40+ years, so they were designed for low performance CPUs. That does not mean that you cannot design a better "find"-like application today that will run into runtime related usability issues if you freeze the world.

At the end of the day, a system level language should support key strategies used for writing performant system level code in a reliable manner. It should also not lock you to a specific runtime that you couldn't easily write yourself. It should also not lock you to a specific model of how to structure your code (like monitors). I am not even sure it should provide OS abstractions, because that is not really system level programming. That is unixy (Posix) programming. A system level programming language should be free of OS and modelling related legacy.

On Monday, 12 May 2014 at 17:03:41 UTC, Manu via Digitalmars-d wrote:
> But D is *so close*... and I like it! >_<
>
> I have to say that this discussion has certainly left me somewhat
> intrigued by Rust though.
> I've never given it a fair go because I find the syntax so distasteful
> and deterring.
> I wonder if there's a market for a rust fork that re-skin's the language ;)

Right now D has practical benefit of being more stable and library rich. But switching to Rust eventually does seem tempting as I find foundations of their type system much closer to my beliefs about "good coding practices".

It lacks any good static reflection though. And this stuff is damn addictive when you try it of D caliber.

On 5/12/2014 4:35 AM, bearophile wrote:
> I suggested to add an optional method named "onGC" to unions that if present is
> called at run-time by the GC to know what's the real type of stored data, to
> make tracing more precise.

Unions of pointers are so rare in actual code that treating them conservatively is not a big problem.

Walter Bright:

> Unions of pointers are so rare in actual code that treating them conservatively is not a big problem.

std.variant.Algebraic is based on on std.variant.VariantN, and on std.variant.VariantN is based on an union, and often you use algebraic data types to represent trees and similar data structures that contain many references/pointers. Adding Adding an onGC() method to std.variant.VariantN you allow the GC to manage Algebraic well enough.

Bye,
bearophile

On 13 May 2014 03:17, Walter Bright via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
> On 5/12/2014 4:35 AM, bearophile wrote:
>>
>> I suggested to add an optional method named "onGC" to unions that if
>> present is
>> called at run-time by the GC to know what's the real type of stored data,
>> to
>> make tracing more precise.
>
>
> Unions of pointers are so rare in actual code that treating them conservatively is not a big problem.

I find it fairly common.
I just searched through my code, and 7 out of 12 unions had pointers.

On 13 May 2014 03:14, Dicebot via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
> On Monday, 12 May 2014 at 17:03:41 UTC, Manu via Digitalmars-d wrote:
>>
>> But D is *so close*... and I like it! >_<
>>
>> I have to say that this discussion has certainly left me somewhat
>> intrigued by Rust though.
>> I've never given it a fair go because I find the syntax so distasteful
>> and deterring.
>> I wonder if there's a market for a rust fork that re-skin's the language
>> ;)
>
>
> Right now D has practical benefit of being more stable and library rich. But switching to Rust eventually does seem tempting as I find foundations of their type system much closer to my beliefs about "good coding practices".
>
> It lacks any good static reflection though. And this stuff is damn addictive when you try it of D caliber.

They have a lot more work to do.
There doesn't seem to be a useful windows compiler for a start... >_<

On 5/12/2014 10:07 AM, Dicebot wrote:
> We have already had discussion where I did state that current @nogc
> implementation is not robust enough and failed to explain the use case for
> weaker @nogc clearly. Conclusion was that we should return to this topic after
> Don's DConf talk ;)

Sure - next week!

On 5/12/2014 10:31 AM, Manu via Digitalmars-d wrote:
> I just searched through my code, and 7 out of 12 unions had pointers.

Relative number of objects with unions, not declarations with unions!

On 5/12/2014 10:25 AM, bearophile wrote:
> Walter Bright:
>
>> Unions of pointers are so rare in actual code that treating them
>> conservatively is not a big problem.
>
> std.variant.Algebraic is based on on std.variant.VariantN, and on
> std.variant.VariantN is based on an union, and often you use algebraic data
> types to represent trees and similar data structures that contain many
> references/pointers. Adding Adding an onGC() method to std.variant.VariantN you
> allow the GC to manage Algebraic well enough.

BTW, the RTinfo can be used to discriminate unions.

Walter Bright:

> BTW, the RTinfo can be used to discriminate unions.

I don't know if std.variant.VariantN is already using such RTinfo. I don't know much about RTinfo.

Bye,
bearophile