D is our last hope

[Hors]

On Monday, 18 December 2023 at 14:08:19 UTC, bachmeier wrote:
> On Sunday, 17 December 2023 at 12:32:13 UTC, Hors wrote:
>
>> How many is "a lot" actually, we literally only have two 
>> sponsors, many of dead projects in DUB and hardly seeing new 
>> projects registered (only to get abandoned after a few months 
>> or even a few weeks).
>
> There are only two kinds of languages: the ones with many dead 
> projects and the ones nobody use.
>
>> Also telling they get the job done "quietly", are you trying 
>> to hide the fact dlang is nearly dead
>
> It doesn't add anything to the conversation to make ridiculous 
> claims like this with no evidence. Calling D "nearly dead" 
> indicates you're not making a good faith effort to participate 
> in a discussion.
>
>> and say "they just do it quietly", Dlang's libraries are 
>> really limited, you either have to write from scratch, or 
>> interop with another language (which will usually require to 
>> write some bridge code by hand)
>
> You weren't using Python in the 1990s. You couldn't do a heck 
> of a lot with it. Someone spent a lot of time writing a lot of 
> libraries between then and now. They didn't post complaints, 
> they wrote code. Then once they wrote all those libraries, 
> other people used them.
>
>>> I wonder how many of those folks are really serious about 
>>> using the language
>>
>> Are you telling me I'm not even serious about using the 
>> language? Then why I'm even writing here?
>>
>> My goal is not calling dlang is bad, but I think potential of 
>> dlang is being wasted, that's why I am writing here.
>
> What will help this language at this point is working on 
> libraries, documentation, tutorials, etc.

It's been +10 year and there's reasons why not many people wants 
to make libraries for Dlang. from GrimMaple's point:

> I would've lied if I said you can't use @nogc code in GC code. 
> But in a reasonably sized framework (eg UI framework) @nogc 
> will start bringing in too much issues eventually. Delegates is 
> just one of the things where @nogc issues are apparent. If you 
> want to have a @nogc control in a UI framework and have 
> callbacks/events in it, you are going to force the user of that 
> control to use @nogc code.
>
> The less apparent issue with @nogc are interfaces\subclasses. 
> If you have a @nogc in your interface, you're kind of forcing 
> @nogc onto all of the users of that interface:

GrimMaple is the author of dlangui, and talking about why writing 
libraries in D is not a good experience.

 From me: all languages haves something to offer, like python is 
beginner friendly, C was the master of it's time, Rust allows you 
to write good performant and safe code. But I can't really see 
whats D has to offer, D has many features of course, but when you 
using libraries, you may need to throw away half of the D.

Another comment by GrimMaple:

> And it's not like building tools/3rd party for D is a good idea 
> anyway. Since the language can't decide what it wants to be, 
> and you end up having to either overengineer your code, either 
> listen to a lot of complaints how your code is unsupported in 
> certain cases.

GrimMaple here again talks about why writing libraries in D is 
not a good experience.
If you want developers to use and write libraries for your 
language, you need to have something good and stable to offer 
them.