Lots of good points made already within this thread.
A fair part of this discussion takes a marketing approach to the topic. For marketing, you need to (1) have (know, understand) a target group, (2) address and reach that target group, (3) convince people and last but not least (4) keep them invested.
However, while marketing is certainly a valid approach, it tends to overlook other aspects, which likewise matter for a programming language ecosystem to be alive and thrive.
Programming is a craft, and as programmers, we spend a huge fraction of our live in exerting our craft. The programming language ecosystem defines the space, the place where this happens. And as such this needs to be a good place to stay.
- there must be a reason in doing the craft this way
- things need to be at hand
- you need to be empowered to perform your work
- and matters need to be at ease.
Just take a look at various programming language ecosystems which succeed in becoming and staying relevant. Also consider some examples which fail and fall into obsolescence, where most people start to put “getting away from here” on their agenda.
Consider Perl. Perl made doing simple things simple, and allowed you to do the complicated ones. And this was not just marketing speech, rather, this was a truth. Everyone who used Perl in depth can confirm that. IMHO this is a very important point: the inner reason why you choose a tool needs to be constantly reconfirmed. Every day you work.
But unfortunately Perl failed to resolve some of its long-standing quirkiness. It was unable to support the growth of a code base, structuring, modularisation, building abstractions other parts can rely upon, without the need to “open the box”. And, lastly, a very late attempt to address some of these points caused a state of fear, uncertainty and doubt.
Have a look at Java. Without doubt, the language itself is dull and deaf. Yet still, working e.g. as java backend developer on mission critical enterprise services is an enjoyable experience. The language is quite opinionated; there is a clear-cut “java way” of doing things, with some marginal flavours to choose from. “Holy style wars” are mostly non-existent. There is a standard way of naming things, which is clear and explicit, albeit somewhat verbose. Which is not much of a problem, because the java ecosystem offers the most complete, mature and powerful tooling you can imagine. And you are highly empowered to do your actual work. The readily available free standard tooling supports even the more advanced operations problems, like monitoring, profiling, versioning, CI and deployment. And up to now, Java successfully managed to move ahead and incorporated some pragmatically chosen moderately modern concepts.
In the late 90ies, the C++ language was a sinking ship. At that time, you found yourselves “forced to code something in C++”. Then something astounding happened. The people on the bridge set a course towards future and maintained that, without a wiggle, for more than 10 years to come. They really embraced the state-of-affairs instead of abandoning it. Most notably, they embraced template metaprogramming, and turned it from an exotic, curious after-the-fact discovery, from a quirky workaround into a core pillar of the envisioned smaller, cleaner more modern language struggling to get out. And even more fascinating, the vision of the modern language turns out to be the old one: building zero-overhead high level abstractions. Thus, modern C++ empowers the developer to build large-scale, demanding and mission-critical systems, while reliably controlling and encapsulating a lot of intricate low-level details and warts. After the last language standard iterations, working with C++ is an enjoyable experience. Not so much writing C++, which tends to be tedious. But, after all, 90% of the time you read and maybe adapt existing code. And with that, the ability of modern C++ pays off to express the solution for some given problem cleanly and concise, yet still without compromise.
- what is the reason to solve something in Scala?
- we need to be able to answer that in a single sentence!
- this single sentence must be understandable and obvious
- and it must correspond to the inner truth of matters
- and this must be reconfirmed every day when writing Scala code solving everyday mundane problems.
- what is the Scala way?
- can we show what is a typical Scala approach?
- “we have a problem here”. The Haskell-like extreme FP-style can not be it, because it covers only a narrow scope of problems and appeals only to a very limited group of developers with explicitly mathematical background.
- yet such a sub-style is not a problem in itself. Also people promoting such a specific advanced style are just fine, and can be inspiring to the community as a whole.
- what is problematic is that the Scala mainstream is fuzzy. We are not opinionated enough in that respect. It is still somewhat hard to grasp what idiomatic Scala looks like. “Everything goes” is not enough to keep a language relevant. We need to decide what is good, what is bad and what is ugly.
- what is at the heart of Scala? Where does it really shine?
- can we define a small coherent set of ideas/concepts/constructs which suffice to grasp “this is Scala”
- and how do precisely those ideas help solving problems in an unique and empowering way?
I personally think, we should not foremost aim at “popularity”. Others are better with that. And, last but not least, popularity comes as a side-effect after you did your homework. Sure, it does not come for free, but first things first.
It is not enough when a programming language is interesting.
Rather, a programming language must be convincing in order to stay.