Vision for the first semester of 2016

[Rikki Cattermole via Digitalmars-d-announce]

On 26/01/16 5:49 AM, Russel Winder via Digitalmars-d-announce wrote:
> On Mon, 2016-01-25 at 20:34 +1300, Rikki Cattermole via Digitalmars-d-
> announce wrote:
>>
> […]
>> I had a long post replying to Russel and to put it bluntly, its just
>> wrong.
>> We are most definitely losing people simply because they expect
>> certain
>> code in the standard library. Like windowing and image.
>> Things like sockets are lower on their priority list.
>
> It sounds like we will just have to disagree. Either than or agree that
> you are wrong. ;-)
>
> Most languages benefit from libraries that wrap and abstract OS APIs,
> everything else can be handled by libraries (many of them) as long as
> there is a single central resource that enables people to find and
> trivially use. This message comes from Rust, Ceylon, other JDK
> languages, and Python. Go is weird. The counter example is C++. D just
> needs to get it's Dub act together properly.
>
>> In their mind we are not even a 'programming language'.
>
> Actually I think the core problem is that there is fashion and hype
> around D. By simple observation Go and Rust got huge impetus via hype.
> This led to a huge amount of activity most of which died a death, but
> left a huge acceleration of real traction. Whilst usage figures are
> dwarfed by Java, C, C++, and Python, Go and Rust have huge distributed
> activity bases. By sheer volume of activity some good stuff appears.
> Especially the stuff that gets funded, because some company is taking a
> punt.
>
> Consider the one obvious case of Cloudflare. Originally a PHP company,
> Go was introduced by guerilla processes, and now Go is central to their
> operation. Such they they fund meetings and conferences. There are many
> other companies using Go who put money into meetings, conferences,
> general marketing, etc. because they want the best programmers. I
> suspect the same will happen with Rust in a couple of years. It is
> already the case with Python.
>
> This is the core of the issue with D for me: there isn't enough
> corporate activity and will to put money into the D milieu.
>
>> Phobos does need to be bigger, but not fully inclusive.
>> If most people won't use something, don't add it.
>
> Wouldn't it be better to be explicit about what has to be in Phobos and
> what can be separate? Let me start a list:
>
> Data structures that are not in the language. Phobos more or less has
> most of the core ones. The job here is to define an architecture, which
> is has in ranges.
>
> OS APIs. The point here is to abstract away from Windows, OSX, Linux,
> UNIX,… I am not sure Linux DVB API should be in here, it is more
> threads, input/output, networking, memory management. Phobos host most
> stuff here already doesn't it?

So windowing, image library and audio handling.
They are core to any modern OS.

It wasn't until very recently that Windows Server ripped out all of the 
GUI aspects of its sdk for core edition.

> Signals and slots systems so as to be able to write asynchronous
> systems.
>
> Concurrency and Parallelism libraries.
>
> Not a lot else.
>
>> Sure there is arguments against this, but there is a certain amount
>> we
>> must standardize and agree upon as a community. Phobos most certainly
>> is
>> the place to do this. Otherwise we will be going round in circles for
>> a
>> much longer period then we should and not growing much.
>
> What needs to be standardized? Data structure architecture. Already in
> Phobos. Cross platform Input/Output. Already in Phobos.
>
> Why isn't Dub the way forward on this? Why a centralized massive
> library that is hard to change and evolve, why not a far more
> lightweight management of contributions via a centralized mechanism,
> i.e. Dub.
>
> In so many ways vibe.d shows what can be right about D, and graphics
> all that is wrong.
>
> Of course in the end D just does not have the corporate backing that
> Go, Rust, Python, Java, etc. are getting. Until that happens plus ça
> change, plus c'est la même chose.
>