www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - What makes a language popular - and how to manufacture D popularity

reply Jakob Jenkov <jjd duniverse.code> writes:
I have followed parts of the thread "Why is D unpopular, redux" 
here on these forums,
and decided to contribute my 5 cents on the matter.

I am a 20+ year Java developer and have seen Java's rise in 
popularity, then fall, and recently a resurgency in popularity 
again. The same with JavaFX. I have seen languages
such as JavaScript and Python creep into spaces where Java used 
to be the language of
choice, and wondered why that happened.

I first encountered D about 5-7 years ago, and started reading 
the book "The D Progamming Language". I was sold almost 
immediately! At almost every feature I felt "Yes! That is exactly 
how I would like a language to work and look (syntax)".

So - why did I not end up becoming a D developer? And why has D 
not become more popular?

Here is what my interpretation of what attracts developers to a 
language - aside from the language features themselves:


Language Popularity Factors:
============================

Ease of Use:
------------
Lots of developers learn JavaScript and Python because they are 
really easy to get started
with. Just install Python or Node.js, and you can start making 
small programs. Also, they allow for easy scripting - no need for 
classes, main methods or even IDEs to get started.

Other languages are reasonably easy to get started with too.

Maybe D needs to emphasize what is needed to get started with D 
easily?
Maybe also what is required to get a full development environment 
up, incl. an IDE with syntax highlighting, a compiler etc. ?
I know that info is available on the D website, but it could be a 
bit more "visible". Maybe a "Get Started" section somewhere?


Use Case:
---------
Developers often choose a language because they need it
for some specific use case.

- I need to do data science, therefore I choose Python (lots of 
data science libs).

Unity)
- I need to make an iOS app, therefore I choose Swift.
- I need to make an Android app, therefore I choose Java / Kotlin.
- I need to make a web app, therefore I choose JavaScript (+ 

- Etc.

What is the use case where D shines? If there isn't one - should 
the D community maybe
pick one, and provide excellent tooling, libraries and products 
for that?


Ecosystem:
----------
It is not enough to have a cool language. You need a cool 
ecosystem of open source APIs
addressing a wide variety of problems. And - these APIs must be 
well documented.

The D ecosystem was the primary reason I did not start developing 
in D. I simply could
not find the APIs I needed at the time, for the project I was 
working on. So, I stuck
with Java - which was not perfect - but good enough.


Jobs:
---------
Developers often learn a specific language because they need it 
for their job, or because the hope to be able to get a job 
working with that language.

Jobs are of course reasonably tightly correlated with use cases 
and ecosystem.

Should the D website have a jobs section?


Popularity:
-----------
Humans are social animals to some degree. If we do not feel 
confident making a choice ourselves, e.g. because we lack the 
knowledge to make a proper judgment, we tend
to look at what others have chosen.

Unfortunately we cannot magically make D more popular overnight.
There are other ways to gain popularity though, some of which I 
list below.



Social Gravity and Manufactured Momentum:
=========================================
No human being has complete knowledge of every product - e.g. 
every programming language
out there. Therefore, no human being can make a fully calculated 
decision about what product to choose.

Instead, humans tend to gravitate towards products (and 
organisations, movements etc.)
they perceive as having momentum. This is also known as "social 
validation".


Perceived Momentum Signals:
---------------------------
Momentum is typically perceived via the following primary signals:

A) How often does a person hear / read about X ?
B) How many people does the person know talking about X?
C) How often does X have new releases, new features etc?

All of these signals can be artificially manufactured. I give 
some examples of how a bit later.


Perceived Momentum vs. Other Language Popularity Factors:
---------------------------------------------------------
Perceived momentum is a strong gravitational force. Perceived 
momentum tend to translate into both validation and anticipation. 
You feel validated in your choice and anticipate all the exciting 
develoments in the future - because X has a strong perceived 
momentum.

Developers can forgive a language for many issues, if the 
perceived momentum of that language is high. The perceived 
momentum makes them anticipate that it will certainly
be better in the future.

Some complain that D has bugs - but all languages have some level 
of bugs. Developers
can forgive that if the most serious bugs are fixed fast, and 
others soon.

Some complain that D is not always backwards compatible, but many 

non-backwards compatible releases. Python broke backwards 
compatibility between the 2.X and 3.X version series. Even Java 
which has focused a lot on backwards compatibility is now slowly 
removing features and APIs, and making subtle syntax changes.


breaking backwards compatibility - because developers anticipate 
that the result, and the future, will be better all in all.

Some complain that D doesn't have all the latest, cool features 
of language X, Y and Z.

features. Java does not

features. Neither does
Python, JavaScript, Rust, Ruby, R etc.

Once a language has "enough" features to make a developer 
reasonably productive,
other factors start to play a bigger role, such as use cases, 
ecosystem, jobs -
and perceived momentum.

Here are some examples of how Java increased its popularity again
(that D could perhaps learn from):


Java's Resurgency:
------------------
Java was for several years considered "dead" - even if lots of 
enterprise software was
still written in Java, and there were lots of Java jobs. Why was 
Java perceived as "dead" then?

The primary reason was, that Java evolved too slowly. Languages 
such as Scala and later Kotlin had more advanced features and 


To fix that, Java started adding some of the more popular 
features from Scala. But that still wasn't quite enough. Java was 
still evolving too slowly and unpredictably. You did not know 
when the next Java release was out, nor what features it would 
end up containing.

To fix the perceived slow evolution, from Java 10 and forward, 
Java changed to a 6 month
fixed release cadence. New major version of Java drops every 6 
months, quite precisely.
Whatever features are ready at that time, make it into the 
release.

The 6 month fixed release cadence made Java feel like it is very 
much alive.
You *know* new features will drop soon. Maybe not your favourite 
feature - but some feature will be added. This addresses momentum 
signal C) in the list above.

The new release cadence also has the side effect of creating 
anticipation and excitement.
What will be included in the next release? Luckily, you won't 
have to wait too long to
find out - and to be able to play with it.

The new release cadence of Java also has a related side effect. 
Every 6 months there is
a lot of buzz around Java - because of the new release. Articles 
are written and shared
on social media about the new features in the latest / coming 
Java release.
This addresses momentum signal A).

And - to be fair: The new features added to Java these days are 
quite advanced - often
addressing performance, multi-core development, polyglot 
development etc. These are features that are useful where Java is 
often used - in server side development, and
big data engineering. It's not all just manufactured buzz.

Lately Java has started to focus on compiling to native 
executables. This is useful
for targeting smaller devices, and to reduce cold start on AWS 
Lambdas (Function as a Service).


JavaFX Growing Popularity:
--------------------------
JavaFX is the newest of the Java GUI toolkits available. First, 
it lived outside
of Java. Then from Java 8 it was included as part of the Java 
SDK. Then from Java 11
it was removed again. The removal made Java developers think that 
JavaFX was dead.
However, JavaFX was primarily removed to make the core Java SDK 
smaller.

JavaFX is still very much alive today, and its popularity seems 
to be growing,
based on number of SDK downloads at least. Here is why (in my 
perception):

JavaFX adopted the same 6 month release cadence as Java. This has 
brought JavaFX
the same signal advantages as Java. JavaFX feels alive, buzz is 
generated regularly, and people start anticipating new releases 
with excitement.

Additionally, the JavaFX community has honed in on a specific use 
case: Cross platform GUI app development. More specifically:


- Cross platform desktop apps.
- Cross platform mobile apps.
- Browser execution of JavaFX.

That means, that JavaFX can run on Windows, Linux, MacOS, iOS, 
Android and Raspberry Pi (Linux) - and in the browser. This makes 
JavaFX one of the most cross-platform GUI toolkits available out 
there - apart from game engines such as Unity.


GraalVM:
---------
GraalVM is a virtual machine from Oracle that is capable of 
running Java, JavaScript, Python, Ruby, R, LLVM and WebAssembly. 
Being able to run Java, GraalVM can also run Scala, Kotlin, 
Groovy and Clojure.

GraalVM can run these languages either separately, or inside the 
same application.
This way, GraalVM is trying to solve the language fragmentation 
problem of polyglot organisations. Use Python, JavaScript, Java 
etc. when that is convenient - call into LLVM when you need 
performance or need to call a C library.

GraalVM can also compile your polyglot app to native executables 
and many other things.

GraalVM has added greatly to the Java ecosystem buzz - and make 
developers feel less
"captured" in the Java ecosystem.



What can D learn from this?
===========================
I did not write this post to promote Java. I wrote it to explore 
how D could learn
something from Java's resurgence in popularity.

A) If D does not have a fixed and regular release cadence, D 
might be able to benefit
from adopting that.


B) If D has one or more core use cases where it is really strong 
- emphasize them.

If not, perhaps the D community could choose one or more to 
emphasize?

Preferrably use cases that organisations with deep pockets care 
about. Financial
institutions don't care about Python. They care about data 
science - and Python
addresses that need.


C) Manufacture buzz. Write blog posts. Submit talks to 
conferences.
Solve interesting problems and talk about it.


D) D won't make everyone happy. There will always be some that 
complain about
something, or prefer some other language.


A Possible Trend Toward Low Level Coding - For D to "Latch on To":
----------------------------------
For a while, the trend in development (as I perceive it) has been 
towards increased
developer convenience. Use easier, interpreted languages such as 
JavaScript, Python or Ruby.
Use game engines such as Unreal Engine or Unity instead of coding 
your own.

However, the last few years some developers have been raising 
some alarm bells
about this development. Fewer and fewer developers know how 
computers and languages
work at the lower levels. The result is slow, bloated software. 
But more importantly:

Who will write the next generation of Node.js, the Python 
interpreter, the Java VM,
the game engines, device drivers etc. , if fewer and fewer people 
know how to
develop low level code?

Not many developers yet talk about this, but the concern has been 
raised by Casey Muratori
in his video "The Thirty-Million Line Problem" :

https://www.youtube.com/watch?v=kZRE7HIO3vk

Also other people and videos address this problem, although it is 
still just a few people making noise about it.

Could D jump on to that trend, and start marketing itself (among 
other things)
as the "high level low level" language of choice for the future?



Why I am looking at D - again:
==============================
There are two primary reasons why I am looking at D again, 5-7 
years after leaving it:

1) Enticed by the concern about fewer people knowing low level 
coding, I have started
looking into it again. This time mostly out of general interest - 
not because I need
D to solve a specific problem. The choice was between C, C++, 
Rust and D (so far).


2) I am working on a hobby / art / research project attempting to 
create a "smart media platform".
This project involves:

- A smart media player (desktop / mobile app).
- A smart media fabric node (infrastructure to connect media 
player apps).
- A P2P topology designed for media distribution.

- A custom binary data format
- A custom binary network protocol for RPC and Subscribe-Notify
- A custom VM + script language (for simple scripting of the 
platform)
- A custom stream storage engine
- A custom stream processing API
- Possibly some RSync implementation

- Compression algorithms.
- Encryption algorithms.

- Possibly a "remote desktop" type protocol too.
- 2D graphics - and possibly 3D graphics in the future.

I will develop the prototype in Java, because I know I can get 
most of it done with Java + JavaFX combined. Over time I would 
like to replace parts of it with a more low level (higher 
performing) language. Here I am hoping D could be that language.

I am the kind of developer that appreciates convenience, but 
prefers control - if I have to choose between control and 
convenience. In Java I get at decent tradeoff between the two, 
but would like the control I could get in D.
May 28 2022
next sibling parent reply zjh <fqbqrr 163.com> writes:
On Saturday, 28 May 2022 at 08:41:57 UTC, Jakob Jenkov wrote:

 I have followed parts of the thread "Why is D unpopular, redux" 
 here on these forums,
 and decided to contribute my 5 cents on the matter.



what `D` lacks is `organization`. everyone fight for his own 
`battle`.

We should `organize` the power of the `'community'` and make the 
best use of `D programmers's free time` .
Even a `'loose'` organization is better than a `'completely 
discrete'` organization.

We can `distribute` tasks to community members according to their 
`abilities and priority`, and then they can obtain `material or 
spiritual rewards`.
It is not necessary to limit the time to finish. However, 
`implementor` should make a `progressbar` so that others can see 
your progress.
In addition, D need to `investigate` the community and `'to-do'` 
items, and then distribute `various tasks` to serve for the 
existing `d programmers` first, and then try to make them bigger .
At least keep the existing community.
`D` community `members` should understand that `d` and `d 
programmers are on the same boat`. Only `d` are getting better , 
can `d programmers` getting better , if `d` gets worse, and `d` 
programmers can not get better.
  `'D'` must rely on the `community` and `trust` the community,And 
we should give `great freedom` to `D` contributor.
And `D officials` only need to keep reviewing whether the 
direction of `d` conforms to the principle of `'d'`.
If there are no `material rewards`, `spiritual rewards` can be 
offered.
`Organization` is the `key factor` that determines the `success 
or failure` of things.
This is especially true for the `language and ecology`.
In addition, Establish a good `'reward'` mechanism and `'dip'` 
improvement mechanism, and how to judge the `'to do'` priority 
mechanism,etc.
May 28 2022
parent reply IGotD- <nise nise.com> writes:
On Saturday, 28 May 2022 at 09:15:58 UTC, zjh wrote:

 what `D` lacks is `organization`. everyone fight for his own 
 `battle`.

 We should `organize` the power of the `'community'` and make 
 the best use of `D programmers's free time` .
 Even a `'loose'` organization is better than a `'completely 
 discrete'` organization.

 We can `distribute` tasks to community members according to 
 their `abilities and priority`, and then they can obtain 
 `material or spiritual rewards`.
 It is not necessary to limit the time to finish. However, 
 `implementor` should make a `progressbar` so that others can 
 see your progress.
 In addition, D need to `investigate` the community and 
 `'to-do'` items, and then distribute `various tasks` to serve 
 for the existing `d programmers` first, and then try to make 
 them bigger .
 At least keep the existing community.
 `D` community `members` should understand that `d` and `d 
 programmers are on the same boat`. Only `d` are getting better 
 , can `d programmers` getting better , if `d` gets worse, and 
 `d` programmers can not get better.
  `'D'` must rely on the `community` and `trust` the 
 community,And we should give `great freedom` to `D` contributor.
 And `D officials` only need to keep reviewing whether the 
 direction of `d` conforms to the principle of `'d'`.
 If there are no `material rewards`, `spiritual rewards` can be 
 offered.
 `Organization` is the `key factor` that determines the `success 
 or failure` of things.
 This is especially true for the `language and ecology`.
 In addition, Establish a good `'reward'` mechanism and `'dip'` 
 improvement mechanism, and how to judge the `'to do'` priority 
 mechanism,etc.


Exactly, this THE reason why the D project doesn't gain much 
traction. The is no leadership, no vision, no work orders in 
order to make people know what to do, no design document 
describing to people what to do. In fact much of SW engineering 
is documenting the design, at least a comprehensive overview is a 
good start.

Right now the D project is like a bunch of headless chickens. 
It's a text book case of diffusion of responsibility.

The more you look into to project you realize that there are tons 
of things to do because many parts of the D projects is starting 
to show its age or essential features are missing. This doesn't 
have to be in core language but even more in druntime/Phobos, 
which means that the claim the we need super elite 
compiler/language engineers isn't really true. The heavy lifting 
is more in the standard libraries and infrastructure and 
documentation. Simple things like this archaic news group forum 
needs to be updated to something modern.
May 28 2022
next sibling parent reply zjh <fqbqrr 163.com> writes:
On Saturday, 28 May 2022 at 09:35:10 UTC, IGotD- wrote:
  The is no leadership, no vision, no work orders in

 order to make people know what to do, no design document 
 describing to people what to do. In fact much of SW engineering 
 is documenting the design, at least a comprehensive overview is 
 a good start.

 Right now the D project is like a bunch of headless chickens. 
 It's a text book case of diffusion of responsibility.


It's better now. There's a `monthly meeting` .
We should make it bigger .
Make a `three circle pattern` .
The first `circle` is the `core` .
The second is the `middle` and the third is the `outer circle`.
There should have a `'three cicle's'` flow mechanism.

In fact, most `'d'` programmers are willing to `contribute`. 
Otherwise, they will not discuss `'d' issues` and `participate 
in` 'dip' discussions.
They just don't know where to get the `task`.

Therefore, `d's` core circle should focus on the `future 
development` of `'d'`, the `core implementation` , the `task 
prioritization` , and such. the `middle` is responsible for the 
implemention of `key features` and `bug fix` etc.The third 
receives `various tasks` as required.

We should let these `"members"` of the `participating 
communities` enjoy full respect .
We can continuously increase the `'voice(weight)'` of 
participants according to their `'contributions'` .
`Labors` must be rewarded. Only in this way can we achieve a 
`'positive cycle'`.
Of course, it would be better if there were appropriate 
`'material'` rewards.
May 28 2022
parent Sergey <kornburn yandex.ru> writes:
On Saturday, 28 May 2022 at 10:19:44 UTC, zjh wrote:

 On Saturday, 28 May 2022 at 09:35:10 UTC, IGotD- wrote:

 In fact, most `'d'` programmers are willing to `contribute`. 
 Otherwise, they will not discuss `'d' issues` and `participate 
 in` 'dip' discussions.
 They just don't know where to get the `task`.


It looks like it is not really the case..
For example, one of the most successful (at least based on stars 
of GitHub) project could not find a maintainer more than 2 years..

https://github.com/gnunn1/tilix/issues/1700

And it is highly tied on:
* Linux
* GNOME VTE
* GTK3

And now on the one of the most popular issue page someone 
suggested just move to Rust competitor, which supports a billion 
features (like GPU rendering) and runs on Linux, macOS, Windows 
10 and FreeBSD…

Some users already left Tilix because of lack of maintaining..
Now “let’s write in Rust” solution promoted on D solution’s page…
Nobody care
May 29 2022
prev sibling parent reply Mike Parker <aldacron gmail.com> writes:
On Saturday, 28 May 2022 at 09:35:10 UTC, IGotD- wrote:


 Right now the D project is like a bunch of headless chickens.


I'm starting to feel like a broken record! The vision document is 
coming before DConf. Probably by the end of June. We're also 
working on migrating critical ecosystem services to the control 
of the foundation.

Those two steps are foundational to the next steps. The first of 
those will be to establish a team to oversee the ecosystem (call 
it the Ecosystem Team/Committee or whatever). They will be 
responsible for setting up ecosystem roadmaps based on the vision 
document, and coordinating contributions. The full details 
haven't been worked out yet, but it will be derived from a 
proposal Mathias Lang brought to a meeting a few months back.

This is a two-way street, though. Once the team is in place, 
we'll be asking for people to sign up as volunteers, letting us 
know the kinds of project they're interested in working on, how 
many hours per week or month they can be available, etc. The team 
will make use of them. We'll put out contract work now and again 
as well, when funding allows, but as always we'll be relying on 
people willing to volunteer their time. Even the ecosystem team 
will be all volunteer (though we already have a few people 
tentatively willing to participate).

I've mentioned most of this in meeting summaries here in the 
forums, particularly in the summaries of our monthly meetings. 
Please keep up with those if you want to stay abreast of what's 
going on before any announcements are made. This is the sort of 
stuff we discuss.

In short, we know there's a need for more management and 
guidance, and we are working to address it. It's going slowly 
because there are always a gazillion other things that need to be 
done, but it is going. You can expect the vision document before 
DConf, the services will hopefully be migrated by the end of the 
year, and the ecosystem team should be in place sometime early 
next year if not sooner.

In the meantime, there is nothing stopping anyone who wants to 
contribute to reach out to Razvan and Dennis to be on call for 
fixing bugs. Let then know which repositories you're willing to 
work on and your skill level, and they will throw things at you 
now and again.

You can also reach out to me (aldacron gmail.com or 
social dlang.org) and ask how best to contribute in other ways. 
Let me know where your interests lie and I'll link you up with 
whomever can best direct you where to go. You don't need to 
contribute blindly or randomly in the absence of a vision 
document or a roadmap. Just ask!
May 28 2022
parent reply IGotD- <nise nise.com> writes:
On Saturday, 28 May 2022 at 10:51:57 UTC, Mike Parker wrote:

 We're also working on migrating critical ecosystem services to 
 the control of the foundation.


New information to me. What does that mean in practice and how 
does it differ from
how it is today?



 I've mentioned most of this in meeting summaries here in the 
 forums, particularly in the summaries of our monthly meetings. 
 Please keep up with those if you want to stay abreast of what's 
 going on before any announcements are made. This is the sort of 
 stuff we discuss.


The summary of the monthly meetings is certainly an improvement 
in order to communicate the status of the project.


 In short, we know there's a need for more management and 
 guidance, and we are working to address it. It's going slowly 
 because there are always a gazillion other things that need to 
 be done, but it is going. You can expect the vision document 
 before DConf, the services will hopefully be migrated by the 
 end of the year, and the ecosystem team should be in place 
 sometime early next year if not sooner.


One thing that people often, also in companies is to instate some 
kind of system where people can work within. This is especially 
important when you have a bunch of loosely connected people based 
on voluntary work. In practice this means that you have a defined 
number actions needed to be done for a certain task. For common 
tasks these needs to be defined and communicated/documented.
May 28 2022
parent reply Mike Parker <aldacron gmail.com> writes:
On Saturday, 28 May 2022 at 11:25:06 UTC, IGotD- wrote:


 We're also working on migrating critical ecosystem services to 
 the control of the foundation.


 New information to me. What does that mean in practice and how 
 does it differ from
 how it is today?


Currently services like code.dlang.org, forum.dlang.org, 
run.dlang.io, etc., are managed independently by one or maybe two 
people. Bringing them under foundation control means the 
foundation pays for them and we have multiple admins available 
for all of the services, more easily managed under one roof.
May 28 2022
parent Jakob Jenkov <jjd duniverse.code> writes:
It sounds like there are some improvements to the process coming 
- via the foundation. That is cool :-) ... and it makes me more 
motivated to play with D in the future :-)
May 28 2022
prev sibling next sibling parent zjh <fqbqrr 163.com> writes:
On Saturday, 28 May 2022 at 08:41:57 UTC, Jakob Jenkov wrote:


 but it could be a bit more "visible".



Because I am a beginner, I have collected `some links`, but I 
don't know where to `put them`.
May 28 2022
prev sibling parent zjh <fqbqrr 163.com> writes:
On Saturday, 28 May 2022 at 08:41:57 UTC, Jakob Jenkov wrote:


 What is the use case where D shines? If there isn't one - 
 should the D community maybe
 pick one, and provide excellent tooling, libraries and products 
 for that?




In fact, I think there is a good `direction` .
You can focus on the `compiler` domain. Many programmers like to 
build their own `compilers`
However, they all lack a 'foundation', but `d` doesn't. Many 
programmers build compilers based on `'d'`. We can serve for 
these programmers, but we should `unite` them around D.

Also, tools. In my opinion, D `'lacks'` `vim/vscode` tools or 
tutorials.
In addition, `d` should make use of all `'d'` community members. 
It is better to set up a `'website'` to specifically collect 
`'d'` community members' relevant `excellent articles`. Of 
course, they are encouraged to distribute the articles to the 
`'big'` community, and let them `actively` participate in 
`community affairs and reward them`.
May 28 2022