My two cents on what D needs to be more successful...

[Jack Stouffer via Digitalmars-d]

On Sunday, 21 May 2017 at 05:52:11 UTC, Ecstatic Coder wrote:
> Since a few months, I'm using D for all my command-line tools.
>
> For that use case, the language and its standard libraries are 
> really perfect, making it the best scripting language I know, 
> completely exploding JavaScript, Python, Ruby, etc.

Glad to see you're happy with the language.

Let's break down each of these suggestions.

>   - std.database (connect/use MySQL/MongoDB/etc databases)

I while I don't agree that the connection facilities themselves 
should be included (shipping C libraries has been a huge pain), I 
agree that some form of either ORM or standardized format of DB 
API should be in Phobos. Like SQLAlchemy, let's leave the 
connection to other libraries.

>   - std.ui (draw 2D user interfaces)
>   - std.input (get mouse/touchscreen/etc events)

I would like to point out that users of the languages you 
mentioned almost never use the builtin versions of these types of 
libraries (and hasn't maintenance of Swing been a huge time 
burden on the Java devs, I remember reading this somewhere). 
Python users use either Qt or GTK, not Tk.

> * a soft-realtime garbage collector (like in Nim), which can 
> progressively recycle the memory of a thread without blocking 
> the whole application.

This is possible, just needs a champion.

>   - std.web (serve web data/files/pages)

There's a philosophical boundary here. There are many ways to 
make a web server, and there's no one right answer for every web 
problem. Standardizing one type of server seems improper.

Plus the below problem applies.

>   - std.audio (load/play/process/record sounds/musics)
>   - std.image (load/show/process/record images)
>   - std.video (load/show/process/record videos)
>   - std.graphic (draw 2D/3D graphics)
> * a dedicated IDE, allowing to effortlessly 
> open/compile/execute/debug a single ".d" file as well as an 
> entire project.

The problem with all of these suggestions is that the maintenance 
burden is so enormous that it would take a medium sized team of 
paid professionals. Let's take std.graphic as an example. To give 
a sense of the scale of the job, getting a cross platform 
graphics API is a task so large that it takes some of the largest 
corporations in the world (MS, Apple, etc.) to come together to 
make it happen. It's not so much a code problem as it is an 
organization problem. The result is OpenGL, an API that no one 
likes very much and literally no one understands.

So we would have to support OpenGL, because this has to work on 
Linux and OpenBSD. Next, you probably want to support DX 11, 
because that's what pretty much 99% of video games use, so that's 
another monolithic API that you have to incorporate into your 
agnostic API. Now how about DX 12? Because it's supposedly way 
faster, and if you're going after game devs, they tend to worry 
about speed. How about Vulkan? How about OpenGL 3 as well as 4 
because Apple abjectly refuses to upgrade for no apparent reason. 
Speaking of Apple, how about Metal? Oh, and we want to support 
mobile so don't forget about OpenGL ES, plus all its different 
versions that have to be supported for different phone platforms.

I cannot stress enough how difficult a task a cross platform 3D 
graphics library is.

It's the same thing for audio and video too. Just look at all of 
the different encodings and features ffmpeg supports.

No, best to leave graphics/audio/video to C libraries that 
already exist. Even if it's painful, it's more painful to copy 
their work.

> But with some efforts...

D is 100% community run and none of us get paid. Bringing 
something into Phobos doesn't mean that it gets more work (it can 
actually mean the opposite). It's gotten to the point where each 
module in Phobos ostensively has one or two owners who's 
responsible for its condition in order to spread the load.

> For the web servers, vibe.d is already there.
>
> For desktop applications, there is gtkd and dlangui.

In order to make the existing libraries standard would require

1. An API freeze. Not something that anyone in the community is 
willing to concede, not even Vibed.
2. Constant, time consuming review of every change, as is 
required by any standard library for QA. This is why ndslice is 
no longer in Phobos.
3. Tons of hours of work fixing the bugs that are present in the 
existing solutions before even considering merging them into 
Phobos.

> I agree that at the moment, all these developments can be 
> possible through several third-party libraries.

And that's the way it's going to have to stay TBH.