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.

On Wed, Jan 03, 2024 at 04:20:39PM +0000, Hors via Digitalmars-d 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? [...]
> 
> If this fork also maintains interop with C, then we can still have
> control via malloc() and free() from a C library.

D has always had interop with C on this level at least.  I don't see the fork moving away from this in the foreseeable future, as this is pretty deeply ingrained in the way codegen is done in D.


T

-- 
It's amazing how careful choice of punctuation can leave you hanging:

On Wed, Jan 03, 2024 at 01:38:10PM +0000, Martyn via Digitalmars-d wrote: [...]
> Now -- a fork is happening. 2 things are going to happen. 1) Dlang will eventually die if the fork is successful, or 2) The fork fails
[...]

Actually, it's more nuanced than that. One of 5 things could happen:[*]

1) Successful forking: the original D language and the fork both survive and thrive as distinct languages;

2) The fork merges back upstream at some point, e.g., if the current
dispute(s) is/are eventually resolved.

3) The fork fails: eventually the fork burns out and is effectively discontinued.

4) The fork takes over: the original D language stagnates and falls by the wayside, while the fork takes over and assumes primary development.

5) Both fails: the fork drains resources from the original project and fragments the community, and both eventually find themselves unsustainable.

[*] https://www.cs.cmu.edu/~ckaestne/pdf/icse20-forks.pdf


Which will be the actual outcome remains to be seen.


T

-- 
All problems are easy in retrospect.

I view this development positively. The constant strife I've observed as a latecomer to D, but as someone who has done and managed software development for a very long time, was clearly not healthy or accomplishing anything other than wasting peoples' energy, because it wasn't converging. This divorce will hopefully allow the disagreements to be resolved on technical merits.

Having said that, I want to express my great respect for what Walter and the others responsible for D have accomplished. Given its conservative objectives (as opposed to something like Haskell or even Rust -- "here's a new way to think about computer programming"), I think D is very, very good and as a long-time language enthusiast, I'm familiar with the competition, such as Nim and Zig (which isn't really competition because it is still far from releasable quality, both the software and documentation). I do admit to having had little experience with C++, just enough to share Linus Torvalds' opinion.

That D hasn't taken over the world is beside the point; good things aren't always popular, e.g., Scheme, and sometimes bad things are very popular, e.g., Windows, JavaScript, C/C++. What percentage of the world's music-loving population listens to the music of Bach or Mozart?

My opinions, of course.