D is our last hope

[Hipreme]

On Monday, 11 December 2023 at 18:28:10 UTC, GrimMaple wrote:
> On Monday, 11 December 2023 at 07:18:44 UTC, Dukc wrote:
>> That D treats those two domains equally is supposed to be its 
>> unique selling point that no mainstream language does. I still 
>> fail to see why so many people pick D and then advocate for 
>> killing that fundamental feature. Aren't you excited about the 
>> thought that you can use one language to excel in both domains?
>>
>
> Actually, having written D full time for over 2 years now (I 
> chose D for my indie game stuff), I don't really see D 
> excelling in pretty much anything. The only stuff where I'd 
> barely consider using D now is its `betterC` stuff where it at 
> least does as advertised, and even then getting C dependencies 
> is problematic enough that I'd rather just use C in the first 
> place. High level stuff though... Yeah, D goes straight into 
> the bin. C# gets me where I need to be faster, even though the 
> actual code writing is slightly slower. D has the potential to 
> match it, but it all boils down to the lack of sane 3rd party 
> libraries. Dub is a graveyard at this point. And when you have 
> to reinvent the wheel all the time, it wears you down very 
> quickly.
>
>> Consider the two probably biggest companies using D. Symmetry 
>> investments used D for high level purposes. Weka.io on the 
>> other hand vendors a file system, which is a systems langauge 
>> job. If we were to declare either domain a second class 
>> citizen, we have to anger one of those companies.
>
> I would've definitely rephrased that to `Consider the two 
> probably **only** companies using D`. I'm sorry, but this point 
> is laughable, considering how many companies **ditched** D in 
> comparison. Yeah, those two (and some more) are using D. But 
> how many have moved on? Take a look at "D Success Stories" 
> page, you will find that most of the corps listed there stopped 
> using D a while back.


I still think that D's problem is how much work a single person 
needs to do.
Right now, I'll list projects that I'm maintaining that was 
supposed to be unrelated to my project:

- GLES Binding
- Metal Binding
- DirectX binding
- A custom runtime for being able to use real D on WASM
- OpenSL ES binding
- AVAudioEngine binding
- A custom build tool because `dub` is far from being enough to 
my purpose
- Windowing libraries because when I started it, I didn't knew 
about adam's simpledisplay
- Even JSON I had to reimplement, since the implementations I 
tested bring features which I don't have in my custom runtime, D 
code just seem to depend on everything, always.



Beyond that, I have forfeit:

- Phobos usage, since it is not portable enough for me, it breaks 
on releases, and it makes your compilation time go down a lot
- Code completion (I don't remember when it worked again on 
Windows)
- Go-to definition (yes, it is simply faster to just try to 
memorize in which file something was defined)
- Using C dependencies: this is more of a C problem, but I really 
find it hard to manage multiple dependencies from C with D, and 
this should be easier since this is what the language sells


Most of the problems we have is the lack of existing work. D's 
std coverage is very good, but has this big problem which is a 
lot more of a concern when you're not using it as a script.

I'm not that unhappy with D, but it is quite exhausting to beyond 
having to develop your project, develop the tools for helping you 
develop the project.