On Tuesday, 1 May 2018 at 12:26:25 UTC, Joakim wrote:
> I realize it's right before the conference, but I'd like to put out a request for Walter and Andrei to spend five minutes during your talks laying out some overarching strategy for how you see D evolving. It could be during the keynotes or leading off the Q&A panel, but I think it's worth laying a broad strategy out there.
>
> Specifically, what uses do you see D being put to for the next five years and how do we make it better in those directions.  For example, in what way you'd like to see D get better as a language for writing apps, or what particular niches you see D as a systems language doing well in first.
>
> For another example, here's what I'd say, ie my strategic vision: the pendulum is about to swing hard back towards the client, towards the billion and a half mobile devices sold each year, and D is ideally positioned with its native efficiency to do well there. However, since it's not the blessed language for any mobile platform, like Kotlin or Swift, it will take much work on libraries to pull that off.
>
> Some caveats: since D is not controlled by a company with W&A as co-CEOs, they cannot obviously order people to follow their vision. However, that should leave you free to really share your unexpurgated thoughts, after all, we're all free to ignore it. ;)
>
> Another is that perhaps D has chosen to evolve tactically as opposed to strategically, carefully picking off wins with a new feature or mode of programming but not following any grand strategy, similar to how Linus Torvalds claims he didn't have any grand vision for linux either. However, a strategic vision can inspire people to work towards that goal, if there is one to be shared.

My 2 cents. I have been following D for a long time and started using it in a very small project. I am a very long term C++ user.

Many people say that D does not offer anything over C++, improvements-wise. Or people tell you that there is Go and Rust. Because D does not have these fancy algebraic data types, or that borrow checker... no, no and NO. I think we do not need to enter that game. I have tried all 3. Here is my opinion.

1. Go --> excellent...!!! For what it does: namely, intensive communication client/server. It falls short of abstraction power in some areas, has no compile-time evaluation, no metaprogramming... though I must recognize it works pretty smooth for its simplicity.

2. Rust --> the borrow checker... excellent, in theory: in practice, as Andrei Alexandrescu once mentioned: you spend a lot of effort on something that in reality is not a problem most of the time. It is a problem, yes, but these problems can be avoided with much more lightweight solutions or simply, as D does, being able to avoid GC where it is needed. A much more practical solution. Rust has other things of value, such as Algebraic data types and Traits, but the borrow checker has a big impact for several reasons: it takes time to get used to, socially, people cannot use Rust from day one, so... you need added training for teams. But also remember... an "alien" type system makes it more difficult for integration with previous systems.

How should be D advertised? Well, I think that Ali Çehreli did a good job explaining in one of his keynotes the conveniencies of D, but this will not make people migrate. Why I am myself starting to take a look into D? I am a person that if I publish a project as open source, I want people to be able to contribute. Coding is, above all, a social activity, so:

- Come from Java, C#, want faster alternative? D will take little effort.
- Come from C, abstractions are too low level? D will take the same effort as alternatives with native performance, but you can start coding today.
- Come from C++ (like myself)? D is way cleaner and more convenient: modules, better metaprogramming, pervasive CTFE, *much better introspection* and also easy to learn.

Those are all good reasons, but, for me, what sets D apart is its level of integration with C/C++. If I come for D in the first place is because I can reuse my old code. This is true for most businesses: they have older code to integrate.

So my opinion is that D is a very pragmatic language that has this real, also management-perceivable advantages over all these nice algebraic data types integrated into the language and so on:

- if I pick up D in a team, it is very likely that D will be easier to pick up because many, many people know C++/Java/C# or similar things. This is a very important social factor and usually not mentioned or underestimated.
- if I have some C/C++ code to integrate, I can do it *way smoother* than with other languages to do it: please guys keep working on this.
- if I want safety, there are mechanisms that take you 90% there. Why would you pick up an alien like Rust where you have to relearn all, but not only that, you have to train full teams? This has a cost that is never analyzed seriously, but, on top of that, with an alternative mechanism such as GC + ability to disable it you can easily get there at a very low cost, because you skip a lot of the training for things such as the borrow checker.
- and last but not least, because of its insanely powerful metaprogramming: opening files at compile time + CTFE + metaprogramming, you can reach a level of integration with language bindings like Python or others that it is simply not possible with other languages, all at compile-time.

So, all in all, if I had to advertise D in a strategic way, it would be:

- the language for which migration for your team is going to work much smoother than the alternatives. I mean *much better*. Especially C/C++
- it does not feel alien -> another practical reason for saving training and moving things faster. Java/C#/C/C++ people can pick it up easily. And with native performance.
- powerful metaprogramming -> integration with other systems has an edge.
- native performance: fast code, but not only fast, you can avoid also the GC if you want and use it @safe ly.

What this means overall is that this language is the most practical of the pack for many reasons, compared to picking up the (in my opinion) almost academic Rust or the very specialized Go.

Some kind of slogans for D I could think of:

D: familiar, native and with a superior integration story: start being productive from day 1.
D: the pragmatic language, for people that need to get things done.

Or something similar. This is very true. We do not leave in a void, we have code, we have libraries from other languages, we need to integrate. D has an edge here, besides the learning curve, compared to any other native language.

On Saturday, 5 May 2018 at 04:59:58 UTC, germandiago wrote:
> On Tuesday, 1 May 2018 at 12:26:25 UTC, Joakim wrote:
>> [...]
>
> My 2 cents. I have been following D for a long time and started using it in a very small project. I am a very long term C++ user.
>
> [...]

Interesting analysis.  These are pretty much the points of technical and marketing emphasis today, so it appears the current message resonated with you.

However, I was talking about more from the point of which markets D would target first, ie the types of end users who'd use D, whether game programmers or compiled GUI apps. So far D's gained some traction at startups that need performance.

One issue with the current approach is that they seem to implicitly assume that D needs to match or surpass C and C++. Can't disagree with the betterC approach as that's really needed, but I'm not sure if D should want to be a better C++. Certainly app devs don't really care about @nogc and the current systems programming emphasis aimed at C++ devs like you.

My point is that whatever that strategy is should be clearly articulated, or you may even undermine yourself by not thinking through carefully what your goals are.

On Monday, 7 May 2018 at 10:27:32 UTC, Joakim wrote:
> On Saturday, 5 May 2018 at 04:59:58 UTC, germandiago wrote:
>> On Tuesday, 1 May 2018 at 12:26:25 UTC, Joakim wrote:
>>> [...]
>>
>> My 2 cents. I have been following D for a long time and started using it in a very small project. I am a very long term C++ user.
>>
>> [...]
>
> Interesting analysis.  These are pretty much the points of technical and marketing emphasis today, so it appears the current message resonated with you.
>
> However, I was talking about more from the point of which markets D would target first, ie the types of end users who'd use D, whether game programmers or compiled GUI apps. So far D's gained some traction at startups that need performance.
>
> One issue with the current approach is that they seem to implicitly assume that D needs to match or surpass C and C++. Can't disagree with the betterC approach as that's really needed, but I'm not sure if D should want to be a better C++. Certainly app devs don't really care about @nogc and the current systems programming emphasis aimed at C++ devs like you.
>
> My point is that whatever that strategy is should be clearly articulated, or you may even undermine yourself by not thinking through carefully what your goals are.

Great marketing beats great tech (sadly), but we are creatures subject to social influence and that which is shiny.

Who actually runs marketing for Dlang?  Is it the foundation, collective cooperation, or ?  Does Dlang have what it needs to be successful in this category in terms of financial resources, expertise, and focus?

As an aside, this was the original marketing for Node.js, in the years before it was acquired by Joyent: http://tinyclouds.org/ .  In a single year, it caught fire (that is, it became wildly successful) because it had a strong BDFL (who was not a dictator, and who stepped down as soon as it made sense to do so, and he took on some messianic stature as a result), strong technical merits, a clear focused message of where it fit in the market, and it met a need.  In fact, it met many more needs than intended, widely used in both cloud and embedded type applications.  8 years on from moving the project into the hands of a corporate sponsor, through much controversy over governance and some community strife, forks, etc., it's doing well in the hands of a foundation: https://foundation.nodejs.org/ .

From a market focused perspective there is the technology itself in one bucket, and then there is the adoption by enterprise.  Certain things have to happen for enterprise adoption to actually take place.  If we follow the pattern of what happened for Go or Node.js, we can boil those down to execution of certain tangibles:

- Project is well documented
- Project is available under favorable OSS license (I won't get into what favorable means, but for corporations, they have their preferences)
- Project has a good toolchain and tools support
- Project has a good IDE integration
- Project has good sample applications built, lots of good examples
- Project has a strong and active community of developers with the appropriate mix of core contributors, external contributors, experts, casual users, and people evaluating possible use
- Project has strong technical merits
- Project has strong market differentiators (this may require real marketing to get this down on paper and promote this)
- Project has commercial support available (training, bug fixing, development)
- Project has an academic community (this often helps seed use in Universities), and students eventually grow up to work for enterprise corporations
- Project has corporate sponsors (or foundation sponsors ... they are really representing corporations)
- Project has a sustainable model (legal, financial) to maintain its community, engineering, and marketing.
- Project has multiple big projects that rely upon it

Grade Go, Rust, and Node.js on this list above.  Where are they at on each item?  Grade Dlang on this.  We still have some work to do.  What companies offer commercial support in D?  Are there any Dlang focused agencies out there?  How many projects are using Dlang commercially?  Who are the corporate sponsors of Dlang?  Again, I think much of this comes back to that marketing message.  What is the unique selling proposition.  Define that.  Then conquer the world.

On Wednesday, 2 May 2018 at 04:48:46 UTC, Joakim wrote:
> On Wednesday, 2 May 2018 at 03:44:37 UTC, Nick Sabalausky (Abscissa) wrote:
>> On 05/01/2018 10:27 PM, Joakim wrote:

> Yes, but how is it decided what the "most important things" are? There is a strategy at work for any prioritization, even if it's implicit and never even articulated in their own minds. If unarticulated, you can gain a lot by spending time to articulate it, as you may find unwanted contradictions in the way you had been prioritizing.

I'm sure Walter and Andrei would love to have the newsgroup micromanaging their decision making process.

On Monday, 7 May 2018 at 21:55:28 UTC, Dave Jones wrote
> I'm sure Walter and Andrei would love to have the newsgroup micromanaging their decision making process.

i dont think anyone is trying to micromanage anyone

i think D's strategic positioning, is a very interesting question
and it is normal for some, especially for new comers or anyway who is not already very invested in D to be interested in an answer

and in D's case i think it is hard to find a satisfying answer

D have two leaders and you mention Andrei and Walter, and the way I see, I dont think they both fully agree on an answer for this question

Going back to D's 2018 vision document and comparing whats in it to both Andrei and Walter comments and youtube videos
I would argue Walter is all in on the -betterC feature (for now), while Andrei is more into improving D overall and doubling down on introspection

Both are really good and unique features

On Monday, 7 May 2018 at 15:52:38 UTC, David J Kordsmeier wrote:
> On Monday, 7 May 2018 at 10:27:32 UTC, Joakim wrote:
>> [...]
>
> Great marketing beats great tech (sadly), but we are creatures subject to social influence and that which is shiny.
>
> Who actually runs marketing for Dlang?  Is it the foundation, collective cooperation, or ?  Does Dlang have what it needs to be successful in this category in terms of financial resources, expertise, and focus?
>
> As an aside, this was the original marketing for Node.js, in the years before it was acquired by Joyent: http://tinyclouds.org/ .  In a single year, it caught fire (that is, it became wildly successful) because it had a strong BDFL (who was not a dictator, and who stepped down as soon as it made sense to do so, and he took on some messianic stature as a result), strong technical merits, a clear focused message of where it fit in the market, and it met a need.  In fact, it met many more needs than intended, widely used in both cloud and embedded type applications.  8 years on from moving the project into the hands of a corporate sponsor, through much controversy over governance and some community strife, forks, etc., it's doing well in the hands of a foundation: https://foundation.nodejs.org/ .
>
> From a market focused perspective there is the technology itself in one bucket, and then there is the adoption by enterprise.  Certain things have to happen for enterprise adoption to actually take place.  If we follow the pattern of what happened for Go or Node.js, we can boil those down to execution of certain tangibles:
>
> - Project is well documented
> - Project is available under favorable OSS license (I won't get into what favorable means, but for corporations, they have their preferences)
> - Project has a good toolchain and tools support
> - Project has a good IDE integration
> - Project has good sample applications built, lots of good examples
> - Project has a strong and active community of developers with the appropriate mix of core contributors, external contributors, experts, casual users, and people evaluating possible use
> - Project has strong technical merits
> - Project has strong market differentiators (this may require real marketing to get this down on paper and promote this)
> - Project has commercial support available (training, bug fixing, development)
> - Project has an academic community (this often helps seed use in Universities), and students eventually grow up to work for enterprise corporations
> - Project has corporate sponsors (or foundation sponsors ... they are really representing corporations)
> - Project has a sustainable model (legal, financial) to maintain its community, engineering, and marketing.
> - Project has multiple big projects that rely upon it
>
> Grade Go, Rust, and Node.js on this list above.  Where are they at on each item?  Grade Dlang on this.  We still have some work to do.  What companies offer commercial support in D?  Are there any Dlang focused agencies out there?  How many projects are using Dlang commercially?  Who are the corporate sponsors of Dlang?  Again, I think much of this comes back to that marketing message.  What is the unique selling proposition.  Define that.  Then conquer the world.

Those are mostly things that have to be done collectively in a community project like this. Much has already been done: the front page of the website has a slogan, "Fast code, fast," and a list of companies using D.

D is never going to have a completely structured process like a well-organized company, where it defines those objectives and then pays to get them done. As a community project, it's much more decentralized, which has its pros and cons, but more positives for me than being backed by a single company.

However, what the community leaders can do is put out a strategic vision, for the community to gather around if they accept it. The vision document is a great example of this, where anyone can pick items off that list and go work on them.

However, an overall strategy is broader than that, which someone could further by working on something _not on that list_, that they think up themselves.