What can make scala more popular?

Waw, I think you widely underestimate the popularity of Scala.js and the maintenance that goes into it.

Several estimates (StackOverflow, IntelliJ survey, Gitter rooms, download numbers, etc.) more or less converge to say that Scala.js represents about 10% of the Scala marketshare. It is far from being a majority, but you can’t dismiss it as easily as saying “it’s a side-project” and “it’s not popular”.

Also, you say it is maintained by a very small team. That’s true for the core, but also it only needs to be maintained by a very small team, because the scope of Scala.js core is very limited. Scala.js reuses the hard work done by the Scala core team on everything from language design to compiler implementation up to the back-end. Scala.js only reimplements the compiler back-end, with a strategy to emit JS code instead of JVM bytecode. If you want to compare apples with apples, you should compare the size of the team working on Scala.js with the set of people maintaining the Scala/JVM back-end (i.e., GenBCode). That team is as small or even smaller than the team maintaining Scala.js.


No, we don’t all agree that in order for scala to grow, companies must to convert to mostly using scala from a different language. Companies using scala on the side is a perfectly reasonable way to grow too, as is new companies using scala.

In general, I think your post is very black and white. We must convince companies to switch to scala in majority in order to grow, scala is a JVM language because scala.js is maintained by a smaller group of people, so we must focus on the JVM part of things only, so we must convince companies that predominantly use Java to start predominantly using Scala in order for scala to grow, which means we must start using the tools they use, because those companies will not switch when we don’t.

I don’t think any of those things are very true, and I don’t think that with such an unnuanced perspective, there is room for further discussion about that.


I’m sorry, but this just plain isn’t true. What matters isn’t the size of the team, what matters is the amount of support outside that team. And the reality is that a large fraction of the Scala library ecosystem supports Scala.js at this point – saying that it is “not popular” is seriously at odds with reality. It’s popular enough that much of the tooling (eg, ScalaTest, IntelliJ) was forced to support it because of popular demand from us users. Not to mention, there are plenty of us who run companies whose front ends are built in it.

Five years ago, I might have still agreed with your “side-project” characterization, but that long since stopped being true – at this point, you are simply incorrect in this assertion.

You keep asserting this, and I’m sorry, but that doesn’t match my experience. Like I said, I am training up Java engineers in Scala, and most of them do like most of the ecosystem. Not everything (almost nobody loves sbt), but I’ve found that, for example, most of them like ScalaTest quite a lot.


What an interesting topic!
Thanks for posting, and thanks to people who actually shared their solutions!


Most of my points are going to relate to this talk by Richard Feldman. I don’t agree on everything he’s stating, but that’s a great talk (and he’s a fantastic speaker).
(I’ll describe the points he’s making in a different order than the one in the presentation)

  1. Platform exclusivity
    Not sure it’s a path Scala can take.
    Obviously, the JVM is a huge fantastic platform shared by a lot of languages. So there’s no exclusivity there.
    Scala.js could possibly be a way to go? But the Front-End world finally has some great functional languages for building applications, namely Elm, ReasonML and probably Purescript.
    Webassembly maybe? not sure about that.
    For sure people have made a great work with Scala.js, but I’m not sure it’s a “platform exhaustivity” Scala could go for in the future.

  2. Quick upgrade
    This is both true and not true.
    Scala doesn’t have a “quick upgrade” path from Java as some of its competitor can have (Kotlin, Vavr, for instance).
    But they don’t bring as much.
    I once had to draw what Scala’s learning curve would look like to me, and inspired from a talk (I can’t find anymore, and Alvin Alexander’s writings):

  • it has a steep learning curve towards writing “better Java” (= less-verbose, better types, pattern matching, function composition). Mostly because:
    • syntax, different from most of the languages in the JVM-world,
    • concepts like eta-expansion and val/def
    • confusing stuff like “should I write ( or {? Oh, both work actually? So they’re the same? Oh, in fact no.” “Can I omit the . here? Or maybe I shouldn’t. Oh I guess it’s not working because I omitted the dot, so I’ll add one, and in the future, in a pure cargo-cult manner, I’ll add dots everywhere the compiler is giving me this error”
    • some concepts that are used everywhere in “Scala codebases you’re using” but that can mean really different things: namely: implicits.
  • then, it has a very smooth curve towards “Scala/FP beauty” (pure functions programming, function composition, immutability everywhere, extracting power from case classes / objects / traits, replacing clunky inheritance by mixin traits, using implicits correctly, etc.)
    • you start refactoring your own code, relying on the compiler, adding more types you’ve heard about, wrapping stuff in Options or Try
    • you start being quite good at using implicits only where they’re really useful, and not harmful
    • eta-expansion helps you write curried functions for better composability
    • you finally get to the point where you’re building powerful opaque-types that can be unapplyd properly, safely: so, easy to deal with for people using your code, while being easy to understand.
  • until naturally you start hearing, and getting more&more interest in “Advanced FP constructs” (Group, Monoids, Functors, Monads, etc.)
  • I think that’s where you’re hitting your second huge learning-curve barrier (that I didn’t manage to go over this one, yet).
    • Ok, I think I finally got the Functor/flatMap thingy
    • Ok, I understand effects can be harmful, I’ve seen it a lot of times already. If every other functional construct has the same kind of benefits (Lenses maybe?). I should start learning it. Moreover it’ll help me understand part of the docs where it’s taking Monoid or Semi-Group examples
    • So, Should I start using Cats? There’s probably a library I’ve been using that’s using Cats right? I’ll read its source code.
    • Oh… what the hell are these cabalistic symbols? Oh well, I’m lost, thought I had made progress but don’t understand anything… Well, I guess I’ll what some parts of the doc has to say about these constructs.
    • And from here you’re back to reading examples in the dotty doc, for instance, full of Semi-Groups etc. Without even understanding the problems it tries to solve.

I really hope dotty will help on flattening/softening this learning curve. And I really think that’s the most powerful lever we can act on. Functional Programming is already getting more and more popular. As an example: coming from a telecom/network academic background: FP wasn’t even taught for us in high-school (only Pascal, C, Java, and Matlab obviously), it was only in the pure “computer-science” cursus. It’s no longer an exclusivity now, both cursus are taught ML-family languages as first languages. (M. Feldman talks about this from Elm’s point of view in the presentation above).

The ultimate reward of learning Scala is a fantastic/powerful reward, I think it really should stay the same: from writing better Java towards using powerful FP constructs and types that will separate computation from effects, making the impossible stuff impossible to write, and modeling complex problems in the most safe way possible, while targeting a well-known, battle-tested, runtime.

But we can make efforts with the learning curve / path. From bridging with “now-common” Java language constructs (method references) to writing Scala/Vavr cross tutorials, by adding very simple, real-life examples where advanced constructs are used. (Example for HKT: “try to write the signature of a single Java method that takes a specialized collection, sorts it, and returns the exact same type of collection” i.e. not referring to the “most common ancestor”. It sounds pretty silly, but it shines at evidencing "Oh, right, if C is the type of the collection, and T the type of the elements in it, I simply can’t write C<T>, oh, and in Scala C[T] is possible, I think I get it now!).

For me, the major points on having a smoother leaning curve would be:

  • not having as many ways to write stuff, it’s so confusing. And as a beginner you tend to “lose confidence” (like "oh this is probably not compiling because I used { instead of (")
  • having a more tight relationship between keyword <=> functionality (just Google “what does implicit mean in Scala”, hopfully you’ll find one of the most useful answers in Stackoverflow for Scala beginners, going into every case, one by one). Distinction between loops and comprehensions is another (less “huge”) example. Typeclasses through implicits are adding complexity to this problem. I really think having a sound "where keyword => type class concept => another way of thinking what you’re calling inheritance" => just google “type class” and you’ll probably see the point" would help having a less steep learning curve.
  • still introducing advanced concepts in the docs, but probably in a less-generic, (maybe less-academic :frowning: ) more “real-life” oriented examples. This one is a really hard one, but some people managed to (most book writers do, example Nilanjan Raychaudhuri when explaining how to turn the strategy design pattern into functional programming in Scala in Action: it’s still helping me to this day, Alvin Alexander also does, in its “Simplified Functional Programming” book).
  • people love languages that “make them better programmers” (Haskell is probably the most known language to do so, lately, Elm started getting this reputation, too). I really really think that’s what will make Scala a popular language. For now, its reputation is too much “Scala is a language that makes you write incredibly clever code no-one else actually understands”. If we can move this to: “Scala makes you write battle-proof code easy to read, understand, and maintain, yet using powerful academic constructs”. That would be a guaranteed success
  1. Killer App

That’s a major point. The only “niche” I could find, would be: strongly-typed Machine Learning applications.

Scala had one niche (kindof) at some point with Apache Spark. And I saw a lot of people diving heads-down into Scala in order to build Spark applications. (Akka could be mentioned as a killer-app, too, but since you can use both in Java now…).

A lot of people are getting into ML, Python has been the default choice for a lot of them.
Python has great stuff built-in, but I think (sorry if I’m mistaking, that’s pure assumption) its massive adoption in the ML world has come from the fact:

  • it has very advanced “math-computation” libraries (SciKit, etc.)
  • it is quite single-function-friendly (Lambdas as in FAAS, not as in lambda-calculus)
  • it’s easy to experiment with (dynamic-typing, etc.)

But from my perspective, the ML-world starts turning from “experiment-oriented” (a bunch of scripts where these adoption arguments really matter) to “factory-oriented” (an application we have to maintain in the long-run, with business rules/logic in it) where other kind of features matter more.

And I really think that’s the field where both functional languages and an advanced type-system really shine: they make some stuff easier to conceptualize, describe, model, and maintain.
Every “bug” detected by the compiler (through the type-system for instance) is something we don’t need to check for or write a test for.

Advanced constructs like Opaque-types etc. can help “making impossible states actually impossible” (another great talk by M. Feldman, actually). We could even be harsher with nulls and Exceptions in Scala, that’d be for the best.

As a “baby-Scala” developer, Scala helps me A TON with this. Pattern matching exhaustivity, Option/Either/Future etc, composing pure functions, etc.
It’s a great tool for turning a bunch of “useful-but-dirty scripts” or “small prototypes” into in industrial application. (Vavr is another one, btw).

So I guess it could be a niche, a potential killer app for Scala. (things like Tensorflow-Scala, etc.). A goal could be: “Java developers leaning towards ML should be embracing Scala in the process instead of Python.”:

  • they (and their Ops teams) are already confident with the JVM, its debugging/monitoring tools, its optimizations, so they’re “safe”
  • since they’re coming from Java, they’re already relying on a compiler to “check stuff for them” (refactoring, for instance). Pushing this approach even more in a world where you’re not confident-enough (you just start creating ML-applications) is an obvious advantage
  • provide a Python alternative to either FP lovers, or people being used to deal with advanced type constructs
  • now that GraalVM can build native images, “functions” can be written in JVM languages. Using a functional language to write complex functions makes total sense.


Finally, lets look at Richard Feldman’s “Considerations” slide (the considerations people have in their mind, according to him, when looking at the language):

  1. Benefits
    Scala should emphasize its benefits, really.
    The first time I read about Scala I discovered a blog article writing about “Libra” that could basically make dimensional equations, and assert dividing a measure by time would end-up in velocity. Love at first-sight for me!
    Such great examples are not that frequent, although I think a lot of the community has examples to share about that. Scala helps modeling complex / advanced logic, has a powerful type system that helps designing programs that are not going to make absurd computations. Starting learning Scala is starting a journey towards academic functional programming. A very hard/long journey, but that’s a huge benefit.

  2. Familiarity
    It’s bad, I’m sorry to say it like that, because I like Scala, but “familiarity” for Java/Javascript/Kotlin/Groovy/C programmers is not good. It’s really hard (even for me who is a baby Scala programmer) to remember the “unfamiliar” stuff because Scala tends to be a language with one of the most important survivor bias. (because of the benefits). But things like someKeyValue.map(_+_) even though extremely useful and noise-reducing are terrible for beginners. (I’ve seen people go absolutely crazy with this very example). Brackets for generics have been hard to figure out for me during the first month (hopefully I wrote it at the time, because survivor bias erased this from my memory). def/val and eta-expansion where other JVM languages tend to use method references for the same needs. “Should I write val? def?”
    Not sure how this can be worked on without restarting from scratch though. Sorry I don’t have any real solution here apart from working with experienced Java/Javascript/Kotlin/Groovy/C++ developers wanting to learn Scala, and asking them all-day-long how they feel about the code they’re reading.
    Cabalistic symbols in libraries don’t help with “familiarity” or “first-impression”, too. “What the hell is ~>, is this a language construct?” “Oh, so |@| is an operator? Nice! Oh actually not, it’s a method defined by cats”.

  3. Learning Curve
    I went into way too much details already

  4. Ecosystem access
    Keep it as it is! It’s really rich, can deal with Java libraries, has great Scala libraries (scalatest), integrable with other build tools than sbt so that it’s not “all-brand-new”. IntelliJ support is quite good. Compiler could be faster but… It’s fine for me to be honest.

Thanks for the topic, and the opportunity to express these.
Hoping this can be useful to the community.


2 things I’d like to address:


I don’t think that the fact that a strong alternative language already exists on other platforms too (Java/Kotlin, JS/TS) is a counterargument to what I said. My argument wasn’t that Scala should be a better JS or Python instead of a better Java, my argument was that Scala should be its own thing and as good at that as possible.


You argue for a top-down approach (convincing companies) for adoption in the industry while I argue for a bottom-to-top one (convincing devs, both with experience and devs-in-the-making, i.e. students before they get… for lack of better word, indoctrinated to imperative/OOP).

I still think that I’m right on this one. Unless there is a limitation imposed by regulators or other businesses a company interacts with, they don’t care too much about programming languages. They care about their product, about their code earning them money. As far as languages go, they care about the ecosystem and about whether there is enough talent to hire (probably incomplete list, but things along these lines). The latter already shows why a bottom-to-top approach would e more successful. A company won’t introduce a non-mainstream language to a bunch of devs moaning about it. Why would it? And vice-versa. You dismiss the thought as one betting its success on singular curious individuals, and a curious individual indeed won’t make a change if the rest of the team resists it. What I have in mind though is 2 thirds of the team having the same preference. I think the management tends to listen to both the attraction and aversion of their devs to tech, if it is present in sufficient numbers and there aren’t other issues (e.g. what I said above, or the company already having invested in 7-8 langs for god knows why). Why would a company want to use Scala? Other than what I said above, I don’t think they care. The one thing you have to make sure of in that regard that there isn’t an aversion from tech managers towards it.

Edit: Steve Balmer’s “Developers, developers, developers” comes to mind…


On StackOverflow, scala.js has less than 1K questions in comparison to Scala as a whole which has around 90K. That’s more like 1%. Google trends shows Scala.js barely scratches 1% of the interest in Scala as a whole, which looks very close to the overall interest in Typescript (Scala.js’s direct competition?). JetBrain’s Survey’s may show higher usage percentage, but take in mind that this survey might very well introduce a selection bias (I for once didn’t even hear about it). I suspect this sort of selection bias was hurting Scala’s own survey, as I’ve noted in the past.

Fair enough, I admit not to know this project all that well.

Regardless, even if Scala.js does constitute 10% of Scala’s market-share, that’s not a strong enough reason in my opinion for pivoting the focus on JS developers, especially when Scala is heavily rooted in the Java world. And again, trying to cater for both JS and Java will prevent Scala from gaining popularity, as focusing on a single segment is of the essence.

Just a point of clarification: Mill runs Scala JUnit tests.

Also, the bugfix shouldn’t be terribly hard, so I’m not sure why you’re making a fuss about it. Yes, it’s a young project; so yes, there are bugs and missing features. Any top-quality gradle support will have the same growing pains (i.e. stuff that it gets wrong at first that sbt and/or mill nail).

1 Like

Fixme but I can imagine that’s because most of the questions that come up while using Scala.js are not specific to Scala.js?

I don’t think anyone is arguing for this. Pivoting to a different primary runtime(s), maybe, moving away from the mindset of being a better XXX, maybe, but these are different questions


Yes, my approach is very much like that. Reality is obviously a lot more complex, but trying to control all of the different aspects is impossible. I believe focusing on key solutions is the only way to go, as it is for most startups. One cannot do everything at once, and cannot appease to all of the stakeholders. One has to draw a line and build a strategy based on that.

Also, “converting” companies doesn’t necessarily mean converting their entire code-base; actually, with Java it means slowly introducing Scala code into the repository. Other than that, even the smallest of companies usually have more than one repository, and potentially more than one team, with different languages involved. Scala isn’t meant to replace everything, so when I say “convert companies” I’m talking about converting the particular parts in the company that utilize a certain language (say, Java).

Correct – Scala.js is exactly the same language as Scala-JVM, and the libraries are mostly the same libraries that you use in JavaScript or Scala-JVM. So the only questions that are specific to Scala.js, in principle, are about the integration of Scala in that ecosystem – in practice, a fairly small subset of the topic.


I beg to differ. See my earlier reply to @sjrd with references to some numbers.

Having all the current core tools support Scala.js does not prove its popularity. It only means that the particular teams that maintain these tools either believe it is necessary or are being pressured to support it, and that might be due to a case of echo chamber.

Popularity should be assessed based on actual uses – especially inside of stable commercial companies – which is extremely hard to do.

Of course it isn’t a counterargument, since you brought it up in the first place. You argued that Scala shouldn’t try to compete with Kotlin on being a “better Java”, while I merely stated that if we’re talking about competitions, this isn’t different than how it is with other languages (JS/TS for example).

It seems you have misinterpreted my approach. It’s not about being top-down or bottom-up. It’s about convincing key roles in an organization – be it a large corporate or a small startup – to try and use Scala inside the organization. It could be an early stage startup that decides to base its code-base on Scala, or it could be a small team in a large organization that decides to introduce Scala into one of their projects.

Students are not a target at all in my opinion. It will take them years to gain enough authority and responsibility in order to introduce a new language into an organization, and by that time they will be forgetting the language they were taught in the first place.

That may very well be the case, but then it is quite inaccurate to state that StackOverflow shows that Scala.js has about 10% of Scala’s market-share.

What is the alternative mindset you are seeking? Where do you hope to gain popularity from? Which developers to you hope to attract?

I think some video tutorials on linked in might help, just to get people started. Since Linkedin bought lynda.com and added a training section some people might search for ‘Scala’ and move on due to no results.

I’m not talking about core tools, I’m talking about the Scala ecosystem as a whole – probably hundreds of libraries, from large numbers of creators, many of whom are really enthused about the cross-platform-ness of Scala. You’re making it out like somebody is forcing everyone to support Scala.js, and that’s nonsense: this was a broad-based, ground-up effort.

Seriously – you seem to be very invested in an argument that is plainly wrong, on a topic that you admit that you don’t know very well. It’s not helping your overall case here.

Okay – I work at a company like that, where a couple of key players, early on, made the decision to focus on Scala. (After having started in PHP and realized that that was a mistake.) We’re now a much larger, Scala-centric company. We care about the Java library ecosystem, and compatibility with it – we have to. But that’s not an easy win: the Java libraries tend to cause us more problems than the Scala ones, because of the different idioms. (Especially null usage.) And we’ve continuing to move slowly towards more Scala-centric tooling, because it works better for us.

So I’m not finding the overall point persuasive. We care about the JVM a lot, yes, and we use many bits of its ecosystem. But we’re not using Scala-focused tools because somebody is holding a gun to our heads, we’re doing so because we find that it works better to get our jobs done, which is the only thing that really matters from a corporate POV.

And ultimately, that’s why I think your point doesn’t hold up. This isn’t like Go or Java or C#, where there is a big company with significant power to dictate how one should use the tools. The Scala community votes with its feet, and tools succeed only if the people in the community make use of them. You seem to be arguing that we should push everyone to use the Java stack instead, as if we’re all ignorant and missing the blessings of that stack. We aren’t – we understand the tradeoffs, we’ve made very conscious choices about what to support in terms of ecosystem, and we’re using what we have found to work best…


I think you might have misunderstood what I was trying to say here, which was that Typescript’s success in the JS world does not say anything about Scala’s chance to beat Kotlin as a better Java, rendering it an irrrelevant fact.

I don’t think I misinterpreted you, based on what you say here it seems like I understood you exactly the way you intended. My argument is that people in key roles don’t care about the choice of language safe for personal success or failure stories and factors external to the language’s nature such as availability of talent or regulatory concerns. If anything, introducing a new language is a slight risk that has to be justified. Java not able to make lambdas working with checked exceptions is shambolic but unfortunately not a justification in business’ eyes. What is though is devs preferring a different language because of things like this. And this is what my argument stands on:

Convince the devs, and they will convince the otherwise understandably indifferent decision makers. Don’t convince the devs and decision makers will have one more reason to not move from the mainstream coming from these devs preferences.

The students argument falls nicely into this line of thinking. But since it’s brought up again, it is a nice opportunity to emphasise how much imperative code wrapped in OOP IS software development for a graduate. The equivalence can hardly be overstated wrt most graduates.

It’s @sjrd 's statement, I don’t feel the need to defend it, he might if he’s around.

I don’t think targeting Java devs work as well as it did in the mid-2000’s, the landscape is much more fragmented than it used to be (and also Kotlin is better at that, but we appear to agree on that so I’ll not elaborate). If anything, catering for Java devs might alienate Python ones and vice versa (just examples) while you also can’t cater for everyone. Doing so also imposes otherwise unwanted limitations on the language. That’s why I think Scala should be its own thing instead and be convincing as an absolute rather than in relation to any other language.

Sure familiarity arising from similarity might suffer somewhat and it’s an important drawback. It’s more evenly distributed between devs using different stacks though and that counterbalances it quite a bit I think. That’s also why I’m suggesting other sources of familiarity, I actually believe quite a bit in teaching it to undergrads (big corps are paying $$$ to get their tech taught for a reason, AFAIK). The other way to gain popularity is… to utilize the gains in language design coming from e.g. moving away from the mindset of being a better XXX and make Scala good enough so that it is an appealing alternative.

For context: Scala is never going to be mainstream, and that’s OK. It just needs to be popular enough. If 10% of companies would be using it I’d be happy. All I’m saying is in the context of that. If you want a language to take over another mainstream one, you need Typescript’s approach. But that’s very far from Scala’s way of evolving as is, that would be something completely different.

I was merely suggesting that it might be the reason why it got that amount of support from the ecosystem, but you’re right – I don’t know this topic very well. But I believe that this is not a good proxy for popularity; again, that should be based on actual usages – say, appearance on job boards. But let’s not go down that rabbit hole since this is getting irrelevant to the discussion, as I believe we can agree that the majority of Scala is still very JVM centered.

I believe this type of companies – the ones starting off with Scala early on – are quite the minority. Finding employees nowadays is becoming harder and harder it seems, and therefore small startups usually start with technologies that have many developers on the market; meaning, the more popular languages become even more popular, and less popular ones become less popular. Unless, of course, transitions are made in bigger companies that are willing to take a risk or do an experiment.

I’m not saying that the current Scala community mostly came to Scala from Java, I’m saying that if Scala wants to become vastly more popular, it needs to draw developers from other languages, and I believe that with the current state of affairs it’s easier to achieve that by catering for developers of one very similar language rather than trying to cater for developers of all languages.

Being the best language and ecosystem we can be according to our own vision leading to people adopting the language sounds like a more appealing strategy than changing what we value because that may appeal to some specific subgroup of companies because we believe that’s where we can unlock the most growth. I don’t believe growth lies in that direction, and I certainly don’t think we can all agree on that.


It must be called Scala.js because it’s a jouet de Séb.

(Edit: my French ami says you never spell the short form with the accent, sorry about that.)

1 Like

I’ll put the catering for a specific (and quite large) subgroup argument aside because I believe we have exhausted that discussion.

What is, though, this vision that we have? How is Scala going to be best language? How does it compare to other languages and being better?

And who’s “we”? Ever since I came into the Scala world 4 years ago, I had the notion that the community is somewhat divided on how to approach the language and its design. Many best practices vary drastically from camp to camp. There are of course a lot of concepts that differ from many other languages and that most of the Scala world agree on (immutability, for instance), but I’ve seen so many other cases where a specific group is very opinionated about a certain concept, advocating it as if it is the idiomatic way to go about, when in fact many others disagree on that.

1 Like

I think it is right direction.
Nevertheless there are some difficulties.
Martin has written :
I see this difference of approaches as a big opportunity. There are so many great ideas to debate and opportunities to learn from each other! Lots of these ideas feed into the design of Scala 3, with the overall goal to make Scala’s integration of paradigms even tighter than it is now, as well as making it simpler and safer.

Scala is integration of paradigms. It is great. But it can make almost everything kitchen syndrome.

I can see it in these topic. It creates the high wall between scala community and other world. It seems it is a communication problem :slight_smile: I think it can be overcome by good business task oriented documentation. IMHO scala has a lack of such documentation. The current documentation is too philosophical in high level(scala for business).