On Thursday, 12 November 2020 at 21:22:37 UTC, Dibyendu Majumdar wrote:
>
> Sorry I didn't make myself clear.
> In Rust for example unions are unsafe whereas enumerated types aren't (caveat: this is based on my imperfect knowledge). So having it in the language allows the compiler to better infer safety of the code, and thus help the programmer make better choices.

In D, unions are @system and SumTypes are @safe, which as far as I can tell amounts to basically the same thing. Is there something I'm missing here?

Obviously D's safety analysis is not quite as sophisticated as Rust's, but that would still be true even if D had built-in discriminated unions.

On Thursday, 12 November 2020 at 21:22:37 UTC, Dibyendu Majumdar wrote:
> On Thursday, 12 November 2020 at 18:33:39 UTC, Paul Backus wrote:
>> On Thursday, 12 November 2020 at 18:07:08 UTC, Dibyendu
>
>>
>>> Also the compiler cannot assist you in making this choice.
>>
>> I'm not aware of any compiler, for any language, than can provide this kind of assistance. Until we invent AIs that can write code for us, we programmers are going to be stuck making our own choices. :)
>
> Sorry I didn't make myself clear.
> In Rust for example unions are unsafe whereas enumerated types aren't (caveat: this is based on my imperfect knowledge). So having it in the language allows the compiler to better infer safety of the code, and thus help the programmer make better choices.

I think you are mistaken. Rust only helps to make the only choice possible.

On 11/12/20 1:07 PM, Dibyendu Majumdar wrote:
> On Thursday, 12 November 2020 at 15:39:53 UTC, Paul Backus wrote:
>> On Thursday, 12 November 2020 at 14:50:33 UTC, Dibyendu Majumdar wrote:
>>> On Thursday, 12 November 2020 at 00:48:24 UTC, Paul Backus wrote:
>>>>
>>>> They're available as a library:
>>>>
>>>> https://code.dlang.org/packages/sumtype
>>>
>>> Thanks. Although without language support it probably doesn't get you safety?
>>
>> SumType is both type-safe and memory-safe, if that's what you're asking.
> 
> Hi no, my point was that it not being a language feature means that people have to consciously use it. And that means it is probably not going to be.
> 
> Also the compiler cannot assist you in making this choice.

FWIW SumType is solid enough to be a good candidate for the standard library.

On Wednesday, 11 November 2020 at 22:15:18 UTC, ryuukk_ wrote:
> NO GC at all! custom allocator friendly

Out of interest, what are your problems with GC?

On Friday, 13 November 2020 at 22:56:03 UTC, rinfz wrote:
> On Wednesday, 11 November 2020 at 22:15:18 UTC, ryuukk_ wrote:
>> NO GC at all! custom allocator friendly
>
> Out of interest, what are your problems with GC?

for game engines, GC is not a good thing

Unity for example has lot of issues with it, and just recently started to introduce an incremental GC to help make the situation a little better

D has an interesting GC situation where you can pause it, but still is stopping the world, and the bigger your heap is (wich happens with games), the longer the GC pauses will be, GC impact in D is minimal in the std lib, BUT, when a gc pause happen, you miss lot of frame, wich results in visible stutter ingame

On Sunday, 15 November 2020 at 07:11:01 UTC, ryuukk_ wrote:
> On Friday, 13 November 2020 at 22:56:03 UTC, rinfz wrote:
>> On Wednesday, 11 November 2020 at 22:15:18 UTC, ryuukk_ wrote:
>>> NO GC at all! custom allocator friendly
>>
>> Out of interest, what are your problems with GC?
>
> for game engines, GC is not a good thing
>
> Unity for example has lot of issues with it, and just recently started to introduce an incremental GC to help make the situation a little better
>
> D has an interesting GC situation where you can pause it, but still is stopping the world, and the bigger your heap is (wich happens with games), the longer the GC pauses will be, GC impact in D is minimal in the std lib, BUT, when a gc pause happen, you miss lot of frame, wich results in visible stutter ingame

The problem is not having a GC, rather which algorithms get used and when.

US Navy has no issues using realtime Java GCs for weapon systems control, where a frame drop costs real human lives.

> The Aegis Weapons System software was recently rewritten into real-time Java as part of the Aegis Modernization activity. This project involved replacement of about 200,000 lines of CMS-2 and Ada code with roughly 500,000 lines of Java. The effort began in 2003 and the new Java implementation of Aegis Weapons System is now being deployed on warships.

https://dl.acm.org/doi/abs/10.1145/2402676.2402699

However these are not the kind of implementations get offered as free beer, from devs working on side projects.

On Sunday, 15 November 2020 at 07:11:01 UTC, ryuukk_ wrote:
> On Friday, 13 November 2020 at 22:56:03 UTC, rinfz wrote:
>> On Wednesday, 11 November 2020 at 22:15:18 UTC, ryuukk_ wrote:
>>> NO GC at all! custom allocator friendly
>>
>> Out of interest, what are your problems with GC?
>
> for game engines, GC is not a good thing

As a blanket statement, that's just not true. There's a whole universe of games and game engines you can make where the GC isn't even going to be a blip on the radar.

On Sunday, 15 November 2020 at 07:55:22 UTC, Mike Parker wrote:
> On Sunday, 15 November 2020 at 07:11:01 UTC, ryuukk_ wrote:
>> On Friday, 13 November 2020 at 22:56:03 UTC, rinfz wrote:
>>> On Wednesday, 11 November 2020 at 22:15:18 UTC, ryuukk_ wrote:
>>>> NO GC at all! custom allocator friendly
>>>
>>> Out of interest, what are your problems with GC?
>>
>> for game engines, GC is not a good thing
>
> As a blanket statement, that's just not true. There's a whole universe of games and game engines you can make where the GC isn't even going to be a blip on the radar.


those who don't write games or game engines are always the ones telling you that you shouldn't care

then you listen to them and you wonder why your game stutters with 50ms pauses (4frames at 60fps) every few seconds

On Sunday, 15 November 2020 at 15:24:39 UTC, ryuukk_ wrote:
> On Sunday, 15 November 2020 at 07:55:22 UTC, Mike Parker wrote:
>> On Sunday, 15 November 2020 at 07:11:01 UTC, ryuukk_ wrote:
>>> On Friday, 13 November 2020 at 22:56:03 UTC, rinfz wrote:
>>>> On Wednesday, 11 November 2020 at 22:15:18 UTC, ryuukk_ wrote:
>>>>> NO GC at all! custom allocator friendly
>>>>
>>>> Out of interest, what are your problems with GC?
>>>
>>> for game engines, GC is not a good thing
>>
>> As a blanket statement, that's just not true. There's a whole universe of games and game engines you can make where the GC isn't even going to be a blip on the radar.
>
>
> those who don't write games or game engines are always the ones telling you that you shouldn't care
>
> then you listen to them and you wonder why your game stutters with 50ms pauses (4frames at 60fps) every few seconds

Then there are those that keep forgeting that there is more to the game developers world than trying to crack out yet another Fortnite or Crysis.

Thankfully Markus Persson ignored opinions like yours.

On 15.11.20 16:24, ryuukk_ wrote:
> On Sunday, 15 November 2020 at 07:55:22 UTC, Mike Parker wrote:
>> On Sunday, 15 November 2020 at 07:11:01 UTC, ryuukk_ wrote:
>>> On Friday, 13 November 2020 at 22:56:03 UTC, rinfz wrote:
>>>> On Wednesday, 11 November 2020 at 22:15:18 UTC, ryuukk_ wrote:
>>>>> NO GC at all! custom allocator friendly
>>>>
>>>> Out of interest, what are your problems with GC?
>>>
>>> for game engines, GC is not a good thing
>>
>> As a blanket statement, that's just not true. There's a whole universe of games and game engines you can make where the GC isn't even going to be a blip on the radar.
> 
> 
> those who don't write games or game engines are always the ones telling you that you shouldn't care
> 
> then you listen to them and you wonder why your game stutters with 50ms pauses (4frames at 60fps) every few seconds
> 
> 

In D the only reason this would happen is because you (continuously) allocate memory during the main game loop. Don't do that and you'll be fine. I can understand wanting to avoid binary bloat, but the GC does not cause stuttering on its own.