We are forking D

[matheus]

On Wednesday, 3 January 2024 at 12:54:10 UTC, JN wrote:
> On Wednesday, 3 January 2024 at 09:28:15 UTC, Martyn wrote:
>> The only area I personally would disagree on is:-
>> `Embracing the GC and improving upon it, disregarding betterC 
>> and nogc in the process`
>>
>> I think GC should be optional or, atleast, have some kind of 
>> Allocator feature so we can have control if needed.
>>
>> D allows you to code whatever way you like, or a combination 
>> of them... why not provide this power when it comes to memory?
>>
>
> Or perhaps that power comes with maintenance cost. I don't have 
> experience with language design, but I assume there are some 
> features that are easier to implement or possible at all only 
> if you assume a GC is present. But if you always have to assume 
> GC may not be present, you are limiting the development of the 
> language. Not saying whether GC is the right way or refcounting 
> or anything else, but it's certainly easier if you only have 
> one real memory management method to deal with.

What called my attention about D back in the day, was a 
Native/Compiled language like C/C++ but with GC built-in.

I think sometimes you need to have constrains and keep with it, 
there are a lot of languages out there, it will be very hard to 
do what everyone is doing (At least not in high level bases).

So I'd prefer a nice language with some constrains than a 
half-baked one.

This is a "new language" (Fork!) from another one, I think that 
if people don't want GC, they just keep with the current one or 
go with another alternative.

In my opinion I think the first 2 priorities: GC and Safe by 
default is a nice thing to start with, and maybe even String 
Interpolation should be added as it's already developed but in 
alpha/toy mode, so people could taste it more.

Matheus.