Feedback from the Gripes and Wishes Campaign

[GrimMaple]

On Thursday, 18 May 2023 at 23:12:15 UTC, Theo wrote:
> D has little to no chance of ever having persistent, 
> large-scale traction.
>
> It simply cannot compete with the other languages out there, in 
> that arena.

I disagree, strongly. D suits several areas incredibly well, even 
as is. For example, I built this 
https://github.com/GrimMaple/mwverify UI (!) app in about 20 
minutes from scratch. And it uses zero C dependencies, it's Full 
D.

Besides that, D suits game developemnt really well, thanks to its 
easily controllable garbage collection and access to low level 
features to speed up your code when necessary. And while the GC 
implementation is sometimes lacking, just having a GC that you 
can decide when to run, gives you a great coding speed advanatage 
over C/C++, where you would spend most of your time thinking 
about proper memory management (shared pointers aren't proper 
memory management).

It also has a great advantage over C#/Java, being compiled 
natively. And with the use of LDC, you can achieve executables as 
lightning fast as C/C++ executables.

> That D could compete with C++ or C# (in terms of wide-spread, 
> persistent and large-scale use) well... that's absurd.

Again, I disagree. In fact, I came to D __from__ C++ and C#. 
Because I got tired of C++'s bs. And I got tired of C# being 
_slow_.

> D's is an experimental language. The should become the ideal 
> vision of itself.

While this is de-facto true, it doesn't have to be like that. I 
have been vouching for a stable D branch for about a year now, 
because I'm sick of having to fix my frameworks with literally 
__every__ new compiler version. The older the framework, the more 
breakage happens.

> Once everyone finally realises this, that realization is what 
> will take D forward.
>
> Taking D forward, will not come about by creating a vision for 
> persistent, large-scale traction. That is a delusion, created 
> in peoples minds.

I think that the purpose of a language is to create software. And 
D doesn't really help with achieveing that. The language itself 
does, but the infrastructure around it and its release cycles 
clearly don't. Recently, dmd deprecated `alias this` for classes. 
Do you have any idea how devastating that change was for any 
third party that used it? Now, if such feature was used, any 
class that used it would have to be split to `before` and `after` 
branches, creating quite a lot of tech debt, deprecation 
messages, and `version` to make this monstrocity at least 
remotely usable. And how do you expect me to even think about 
wrting third party when I know it will be broken by language 
developers in near future? Again, such breaking has been 
happening to `dlangui` with almost every new version of the 
compiler. I'm getting tired of fixing breakage instead of fixing 
`dlangui` itself.

And do I have to mention that I have to make sure that the 
framework code compiles with older compilers? Because people 
might use `apt install dmd`, and get a compiler that's about 1 
year out of date. That requires me to have different versions of 
compiler set-up, and I have to make sure that users are able to 
compiler & run my framework.

> D has also long-needed an experimental branch, to help motivate 
> ideas, participation, and use. ImportC should have gone 
> straight into an experimental branch, and no found its way into 
> production branch until it does what it claims to do (which is 
> still doesn't!).

I don't think that is necessary. D already has everything it 
needs to gently slide in experimental changes/features. It's just 
not being used properly. For compiler features, there are 
`preview` switches. For phobos, there's `std.experimental`.

Unfortunately, big compiler changes, like mentioned above 
deprecation of alias this, or ImportC for that matter, weren't 
hidden behind a preview switch. Heck, ImportC didn't even go 
through DIP process! And `std.experimental` is a synonim for 
graveyard, from where nothing gets out to actual `std`. Logger is 
the only exception to the case, I think.

> Instead, stagnation in stewardship is what has come to define 
> the D programming language.

I don't think that it can be attributed to stagnation itself, I 
think Walter (and other core D devs) need to get out of the 
compiler / phobos and start writing something useful in D. Apps, 
frameworks, websites, whatever. Something that can be put on the 
dlang.org main page under "Apps written in Full D". This way they 
would learn how frustrating D is in real world, and maybe they 
will stop breaking stuff and introducing features nearly nobody 
asked for.