Permalink
Reply
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.
