Scala was the second programming language I learned (the first was Java). I think I'm quite lucky to have picked up a language like Scala so early in my programming journey. It made it very easy for me to learn new programming languages, since it made it easy to support wildly different paradigms (which is also what makes it hard to use in an enterprise environment).
yeah, you get everything and the kitchen sink with Scala. Which is actually IMO its biggest weakness. It wants to be everything, and it isn't amazing at anything as a result.
That is why I actually like Scala. I want every tool to be available at my disposal, and I can choose what to use or not use. I want it to be reasonably succinct and type safe.
I don't want the language to dictate how I use it. I'd prefer the language not to look out for me. There might be some, but a lot of languages look out way too much. Golang for example doesn't allow you to compile if there is an unused var. Java with private as the default.
It is great that there is a production-ready language that differs from other languages.
Python is multi paradigm, but does several things really well that other ecosystems do not. Javascript as well. Java as well. What claim to fame does Scala have in this regard, aside from being the best supported language for Spark for several years before PySpark overtook it? Perhaps Akka before the boneheaded decision to paywall that ecosystem?
"Among the clients of the Spark runtime architecture, Scala is the most popular language, followed by Python and Java. According to a recent survey by Databricks, the company behind Apache Spark, 71% of respondents reported using Scala for Spark development, while Python was used by 24% and Java by 5%.
Another survey by Typesafe on the Spark ecosystem revealed that 88% of respondents used Scala, 44% used Java, and 22% used Python, with the percentages reflecting multiple language usage.
Scala is considered the most optimized language for Spark due to its integration with the JVM and its role as the language in which Spark was internally implemented, offering better performance and access to the latest features."
I think the info is even more outdated than that. The article is from August 2024 but it cites "a recent survey by Databricks" that from what I can tell isn't linked to, so who knows what data they're referring to.
I was deep into the big data ecosystem in the 2010s. Those numbers feel like they're from 2017 or so. Scala has been on a slide every since.
>> Every significant language became multi-paradigm these days, but you can do it intentionally, like Scala, or you can do it badly.
> Python is multi paradigm, but does several things really well that other ecosystems do not.
Both Perl and Ruby can be, and often are, used instead of Python to great success for similar concerns. IOW, the three are often Liskov substitutable[0].
> Javascript as well.
You're kidding, right?
> What claim to fame does Scala have in this regard ...
Scala supports declarative, generative, imperative, meta, and object-oriented paradigms. All of which are supported by at least, but not limited to, the JVM and JavaScript runtimes.
These capabilities transcend libraries (such as Akka) and/or frameworks (such as Spark).
It's interesting that Odersky started with Modula-2 (implementing a Z80 compiler), did a PhD with Wirth, but there discovered that functional programming offered a level of theoretical rigor and mathematical elegance he missed in Wirth's imperative languages. Wirth was generally critical of the complexity and abstraction often associated with functional languages. Rather than rejecting Wirth's pragmatism, he carried it forward by attempting to make functional programming "industry-ready".
I can relate to Odersky, similar to him, while I appreciate Niklaus Wirth's work, I don't appreciate the quest to minimalism that he went down after Oberon.
For me the right path is Oberon => Oberon-2 and Component Pascal => Zonnon and Active Oberon.
Yes, I know he wasn't directly evolved with those ones.
I see the several revisions of Oberon-07 as an entertaining exercise in minimalism, which fails to understand the industry.
Something that Niklaus Wirth complained about in his rant about Software Engineering, not understanding why Java and C++ and not Oberon won the hearts of companies.
I was fortunate to attend his Oberon session on Oberon Day at CERN, 20 years ago, while a genius programming language designer, expecting software engineers to recognise great design and naturally embracing it, was expecting too much.
Minimalism is indeed the correct term (usually framed as simplicity) when looking at both, language and documentation. But at least it helped that there was always a working compiler and system, not a mere theory.
> I see the several revisions of Oberon-07 as an entertaining exercise in minimalism, which fails to understand the industry.
His main motivation was to minimize the amount of work porting his original system to his own, FPGA based processor board. His fans interpreted the “new” language more as a new prophetic proclamation, but in reality it was only about the feasibility of his post-retirement hobby project. This became clear at the latest when people wanted to run a benchmark on the system and discovered that the compiler couldn’t generate such large binaries. There was simply a fixed maximum size, but for many years no one noticed this.
He has always positioned his languages for education and limited himself to the systems that can be realized with them. If his goal had been to meet the needs of industry, he would have acted differently. After a very brief foray to an industrial job in the sixties, he immediately returned to academia and hardly looked back.
One could argue that Modula-2 was an attempt to fix Pascal for the industry, after all the dialects that sprung out of it, which he wasn't keen on, with the influence from Mesa, after his sabbatical at Xerox.
Also that the way it failed to be embraced by the industry, too busy with UNIX, C and C++, also had an effect on his point of view going forward.
> One could argue that Modula-2 was an attempt to fix Pascal for the industry
There is no evidence that Wirth e.g. ever directly or specifically rebutted Kernighan's famous paper, nor that Modula-2 was a response to it. Modula-2 was a child of the ivory tower (PARC), not industry. Wirth was rather an "escapist" who built his own worlds rather than fixing the real one. He saw Parnas' concepts "in action" during his sabbatical at Xerox. He didn't create Modula-2 to help industry; he created it because he wanted to replicate the Alto workstation experience (which became the Lilith) for his own use and for his students at ETH. Wirth was a brilliant "synthesizer" of academic ideas (Parnas, Hoare, Mesa) who built beautiful, self-contained gardens for himself and his students. He was never the "industrial repairman" that later apologists tried to paint him as.
That paper was only relevant among UNIX people, and largely ignored by anyone doing 8 and 16 bit home computing with Pascal and Modula-2.
It is no accident that to this day, it is the UNIX accolades that keep bringing it back every couple of months, most of whom never used a single Pascal compiler in their lifes, or aware that Modula-2 was already around.
Modula-2 relevance as systems language is quite easy to find out in some of his essays, and the companies selling compilers for Acorn, Amiga and PC.
You said that "One could argue that Modula-2 was an attempt to fix Pascal for the industry". By 1981, the C/Unix team was no longer a "rogue research group" in a closet; they were the architects of the dominant industrial paradigm shift (with Apollo Computer, Sun Microsystems, Silicon Graphics, and even Microsoft all using Unix and C). That's why I mentioned it. Wirth didn't care because his concern wasn't industry. Pascal users helped themselves: e.g. Lisa Pascal essentially included all features from C, which according to Kernighan (who referred to Wirth's original Pascal, not the derivatives) were missing, and even a module and separate compilation concept (four years before Turbo Pascal); they could have used Modula-2, which was around at the time. While Modula-2 was hypothetically a "systems language", it lacked the pragmatic "dirty" features that C, Lisa Pascal, and Turbo Pascal embraced to actually build operating systems and drivers on commodity hardware (unless, again, they were added as an extension by the compiler vendors). E.g. Topspeed Modula supported inline assembly, Acorn Modula included extensions to call software interrupts directly with register mapping; almost all commercial vendors added extensions to bypass strict typing, or direct pointer increment/decrement to support C-style array traversal.
It is irritating that apparently C is fine having endless compiler extensions without which ISO C is equally unusable to implement an operating system[0], a sign of greatness, while the same argument is used to point out as design flaws when it isn't C we are talking about.
[0] - Unless helped by an external assembler, just like on the UNIX rewrite, when K&R C was initially created.
I'm not advocating for C (I wouldn't implement an Oberon/Pascal/Modula inspired C replacement otherwise). C was mostly adopted by industry because it came with Unix and had to be used by the many Unix-based workstation vendors to adapt and extend the OS for their specific need/brand. That a significant OS can be written in C without extensions is demonstrated by the many Unix versions themselves. There is always a remainder which has to be implemented in assembler (e.g. to achieve the system state required to run C functions at all). I can also confirm from my own long-time experience implementing embedded (microcontroller) systems in C that it is possible with standard C. But that's not the point. We were discussing about Wirt's minimalism and his focus on his own and the need of his students (vs. the need of industry). I think Wirth's role and influence are generally romanticized. He was innovative, but he did his own thing. The impact of his work on the industry is almost exclusively in a significantly modified/extended form. These extensions/modifications never came from Wirth himself, and only in exceptional cases did they have “his blessing” (e.g., Object Pascal or Modula-3). It was precisely his aforementioned minimalism that led him to focus on the things that were important to him, rather than on the needs of the industry, whether justified or not.
Sure, if we ignore the Assembly buddy code used alongside C.
IBM's OS/400 made use of Modula-2 for some parts, for example.
Back to Niklaus Wirth, as mentioned initially, I think his ideas were great, until he went into minimalism, the first Oberon edition was the turning point, that other researchers luckily improved upon.
Ironically to his point of view, some of them, like Hanspeter Mössenböck, changed his focus into Java and .NET, and has contributions to MaximeVM and GraalVM, via his students thesis.
I'm not sure what you're getting at with this recurring assembler argument. The Oberon system and also AOS/Bluebottle are full of inline assembler and SYSTEM tricks with pointer arithmetic, etc.; the Lisa OS is also full of assembler. Even Wirth himself wrote parts of the Ceres system in assembler.
Indeed they are, however when it is C, it is an advantage, gladly ignored that ISO C on its own requires an external Assembly tool to do its job, when it is something else, it is thrown around as proof they aren't as good as C for systems programming, the irony of two weighs, two measures.
"You need Assembly to do XYZ that C can do", yeah right.
> when it is something else, it is thrown around as proof they aren't as good as C for systems programming
That's not my position, and not my argument in this thread. My argument was, that Wirth created his own world and never cared about industry requirements, so industry cared for themselves.
But let me address your concerns. C is an ugly language with a silly syntax (e.g. for arrays, or function types), and the preprocessor is a nightmare, and the weak type checking overlooks a lot of errors (but at least we get warnings, and weak types are very useful when I use C as an IR). But the standard version (ANSI) lets me do all things I need for system development; I don't use inline assembler.
So let's look at Modula-2 (since you seem to see it as Wirth's response to industry needs). First, we have to differ between Wirth's Modula-2, and ISO Modula-2, which is a completely different language (more industry friendly, containing things Wirth was strictly against, and he even refused to participate). So let's stick with Wirth's Modula-2. The first thing that annoys me is the requirement of the original 1982 specification to capitalize all keywords. The second thing is the removal of any type checking for all operations essential for low-level system programming (a pattern Wirth continued in Oberon). ADDRESS is declared as POINTER TO WORD, and the specification doesn't define whether pointer arithmetics has byte or WORD resolution. Type casting is very limited (i.e. restricted to SYSTEM.TRANSFER or variant records without tag, but not in expressions). There is no conditional compilation and only limited compile-time evaluation. There is no explicit "extern" declaration; the use of definition without implementation modules is inofficial and compiler dependent. Some of these issues were "fixed" in ISO Modula. But if I compare Modula-2 e.g. with Ada, which is indeed a true system language explicitly designed for critical industry needs, even ISO Modula is still very limited.
It is, of course, well known – or at the very least frequently and enthusiastically repeated – that a suitably drunk Odersky devised Scala whilst watching a Reese’s Peanut Butter Cup ad[0].
I’m very happy that I learned Scala back in 2018(thanks to my colleague). I quickly realized that this is the language I want to use for work, and after some time, I joined my first Scala project. Five years later Scala is still my favorite language, along with Rust.
Martin Odersky did a fantastic job with Scala then, and also with Scala 3 IMO from a language design perspective. When I first got into Scala, I was blown away by the language features and the type system. It was the reason I got back into the JVM and the reason for getting into functional programming (not pure FP).
Scala is a great language, and functional programming (not pure functional) made me a much better programmer. And functional error handling is a fantastic way to model success and failure, whether you’re using Either or the newer Result type.
I have to both agree and disagree with some of the commenters here regarding why scala declined in usage. There are several reasons.
1. People just got fed up with the push toward pure FP and the complexity. Pure FP and category theory, and effect libraries are just not for the average audience.
2. Android support for Kotlin drastically reduced the momentum as well
3. Spark usage was pretty heavy driver for using Scala and I’m not sure about it’s used as much.
4. Scala became more and more niche as a result of item 1 above.
This being said, I switched to Kotlin for all server side work. I think a language and in particular the ecosystem, needs the vision/stewardship that can offer more practicality and balance in the language design, programming style, tooling, and frameworks. Kotlin just became a simpler language with better support for all of the above.
I can’t think of a better company to drive the development than Jetbrains. I don’t agree with all the choices, but Kotlin overall is a beautiful, simpler language, with all the practicality, and support needed to keep it going.
However, now that Java is making strides in the language features, as compared to historical improvements at the VM level, I’m curious to see how the market share for Kotlin outside of android is going to be affected.
Personally, I still prefer Kotlin for the practical FP support, Ktor as an HTTP server, and pretty good compatibility with Java. And lastly, I think there is enormous potential in multiplatform, as a strong alternative to typescript/react native for mobile.
Disclosure: I am biased as I’m developing some libraries and soon to be made (more) public server framework.
> However, now that Java is making strides in the language features, as compared to historical improvements at the VM level, I’m curious to see how the market share for Kotlin outside of android is going to be affected.
My employer has decided to abandon Scala, and they proposed Java as the language to head toward. I don't think Java's strides are fast enough to provide modern table stakes. In 2025, the big ones to me are:
1. null handling at the cultural and language level
2. abstractions over concurrency
For null handling, Java has Option, but you're just going to have to deal with the fact that basically any API or caller can give you null. This is not good enough in 2025.
For concurrency, Java has an excellent java.util.concurrent package (and the JVM is very good at concurrency in general). However, I've come to believe that it's a losing proposition to expect the average programmer to use concurrency primitives correctly, even at that level of abstraction. Every Java PR I review I have to add 20-30 comments about thread interruption, memory barriers, etc.
Structured Concurrency helps, but is new/in preview, and hardly helps with actually providing safer concurrency operations.
I think Java is doing the right things and the glacial pace of innovation at the language level is correct for protecting their users (contrast this with Scala 3...), but on the flipside I just think that it is hard to recommend Java vs C#/Kotlin.
Kotlin will always be a second language on the JVM, it isn't what Oracle, IBM, and others think about when designing runtime features, and eventually like all guest languages will face the problem to either exposed the platform features, or have multiple ways, with different semantics, to achive the same.
Virtual threads, versus co-routines, structured concurrency, SIMD/Vector, value class/records,....
It frankly doesn't matter in which markets C# isn't an option - if you're in one of those, well... then obviously don't consider C#. That doesn't somehow indict C# as a language which better makes it possible to write concurrent code. For a very large proportion of the population, you're picking a language and running some services on a cloud provider or machine you control.
The problem I'm citing in Java is not the performance, it's the semantics and having to explain what an InterruptedException is to every generation of programmers, including those who came before me. If you think virtual threads somehow do anything about what's difficult about concurrency on the JVM, we're talking on different wavelengths. Structured Concurrency is the TINIEST of baby steps and doesn't really do anything to change the experience, and it's only just now in preview, in the most recent LTS JVM? Hardly a solution.
It doesn't matter whether the JVM is developed with Kotlin in mind, as long as Kotlin continues to offer a better way to leverage what the JVM does have to offer. It's not some killer argument that Kotlin somehow can't be useful if the host platform isn't specifically developing their roadmap (especially because you can... just write Java, if you need it?).
Scala's demise likewise has nothing to do with whether the JVM is supporting Scala, and any suggestion that Java's language features have eliminated Scala's value proposition are similarly misplaced.
It matters, because these arguments are always done as if programming languages exist in a vacuum.
Any guest language on the JVM will trip on the InterruptedException just as well, it is called leaky abstractions for a reason.
People reach out to guest languages, as they think they don't have to learn the underlying platform, then they discover the hard reality to master two ecosystems.
Improvements on the platfrom language eventually always drive the guest languages away, because all guest languages either lose their value proposition, or use the platform to bootstrap their own ecosystem.
Turns out when they take second option, they open the door to having libraries that only work in one platform, and the usual #ifdef like complexity.
Kotlin has a better future than Scala, beyond the JVM, because papa Google has ensured it happens, at least as long as they care about Android.
No, it doesn't matter. You are advocating for the special case, not the average case, and it has no bearing on C#'s _general_ aptness that it can't be deployed somewhere. The same is true of Java! This is nitpicking with no justification.
> Any guest language on the JVM will trip on the InterruptedException just as well, it is called leaky abstractions for a reason.
They can (and do) reduce how often and where you have to interact with it. I at this point am not sure whether you are intentionally arguing from a position of ignorance or whether this is actual bad faith. Are you suggesting that abstraction is not useful or impossible? Yes _obviously_ InterruptedException is still on the classpath and in implementation code; that doesn't mean we should throw in the towel and interact with APIs that constantly throw it.
> Improvements on the platfrom language eventually always drive the guest languages away, because all guest languages either lose their value proposition, or use the platform to bootstrap their own ecosystem.
You have done nothing to address the issue that Java adopts new features extremely conservatively and slowly. I already used the perfect example that you gave of Structured Concurrency, which is not only not enough, but not even available, and ten years late. It is simply false that Java has done anything significant to compete with its guest languages. Javascript, yes! C#... debatable, but certainly better at it than Java.
> Turns out when they take second option, they open the door to having libraries that only work in one platform, and the usual #ifdef like complexity.
This is why I'm skeptical of multiplatform approaches such as Kotlin's, but that my suggestion that Kotlin is useful is not based on any degree of multiplatform support. Even at the end of the day if I thought Kotlin didn't have a future, my point is that that is table stakes level of abstraction in 2025 and Java ain't it.
1. There was never a push. Functional ecosystems are simply the ones that survived. You can't blame communities that keep the language alive for doing what they want, and not what you want. Without Typelevel and ZIO where would be Scala 3's adoption today?
2. Android has never been even remotely relevant to the space where Scala exists. And no, this was not a missed opportunity for the language. People who think Scala had a shot are completely delusional.
3. I'm personally convinced Spark was the worst thing that happened to the ecosystem as it brought a lot of attention, and indeed, drove adoption, only to result in an incredible amount of shitty code plagued by the worst annoyances in the JVM and big data space. Spark is the biggest open source project in Scala, yet Databricks doesn't seem to give a damn about the language and couldn't even be bothered shipping a Scala 2.13 runtime for years after its release. I sincerely hope Spark moves away from the JVM entirely.
Kotlin is really not any simpler especially with the constant feature creep that results in copying Scala features, only halfbaked. It's even less principled which is the biggest gripe against Scala having too many ways to do the same thing. There's nothing beautiful or practical about a language where people regularly write expression oriented code next to early returns.
Given that Scala-Android efforts predate Kotlin, Scala could have had a shot at Android if EPFL resources were allocated to it, like to Scala.js.
Kotlin is not simple at all, it has a lot of keywords for strange and very specific features and corner cases, it's hard to remember them all. Moreover, the Intellij Kotlin plugin is somehow slower than Scala's despite being a 1st party language and not having implicits, how they managed to achieve that is a mystery.
Right and if you know the first thing about Scala, Kotlin, Google and JetBrains, it should be clear Scala on Android was simply never going to happen, even if Typesafe somehow managed to find extra millions in funding and could allocate dozens of people behind it.
It certainly would, had Google decided that would happen, and support the ongoing existing efforts from the community.
If you know anything about Google politics, you would know Kotlin only took off because of a couple of folks on the Android Tools team doing free advocacy for JetBrains.
In an alternative reality, if those same persons had been Scala heads, Jetpack Compose would be a Scala DSL today.
Scala was a bad fit for the Android runtime and the SDK. On a $200 Android phone with 2015 specs the performance aspect was definitely not a trivial argument against Scala; Kotlin has perfect interop with very little overhead, no conversions between collections (often slow and immutable in Scala), a nullability story that doesn't box everything in Option, ...
And most Googlers do not like clever languages with bad tooling, especially the ones working to productize languages and toolchains for Blaze and other internal tools.
You will never get me to say anything positive about the Kotlin advocates on Android team.
It isn't only Scala, it is using Java 7 samples to sell Kotlin, the original language for Android, still used for the large majority of Android tooling, where your argument fails flat.
They have begrudgingly being updating Java support, up to Java 17, when Java 25 is the latest LTS, because that great Kotlin interop with Java is useless when Android loses access to the Java ecosystem that keeps moving forward regardless of Android.
Some of them even don't have any ideas how out of date their Kotlin "improvements" over Java are out of date.
I'm not defending JetBrains or Google's decisions. But I don't see why anyone should try to rewrite history.
Scala had a decade head start. Many people at Google are aware of Scala, some being former LAMP students or staff. Google doesn't simply add a language to their small list of sanctioned toolchains.
Kotlin was specifically designed to win the politics argument, using technical merits: full interop, gradual adoption, low overhead, ability to target outdated Java bytecode efficiently (Kotlin used to inline lambdas for Java 6 bytecode for instance, while Scala boxed everything before invokedynamic). It doesn't matter whether one approach is objectively right or wrong, Kotlin fitted the bill and Scala did not. More importantly, Kotlin fitted the bill on Google's server side too!
Then of course JetBrains was tasked to replace the IDE with Android Studio, they could put dozens people backing Kotlin as a first-class Android language, until Google adopted it officially.
But even if Typesafe had somehow stumbled upon $100M in funding to do the same thing, it doesn't change the fact that Scala never had a chance.
Kotlin won Android on internal Google politics, zero technical merit.
Feel free to write another long reply on how Kotlin is somehow special, going to replace Java, while the first iteration of Kotlin Native was a failure with a broken design on its reference counting memory approach, and there is still no KVM to replace the JVM in sight, despite such greatness as pointed out in Android circles.
I haven't defended Kotlin's approach in any way, I don't know why you want to put words in my mouth.
However if you don't see why Kotlin was well positioned, while Scala was not, then you clearly don't know much about either language.
Technical merit is subjective, but different design decisions can precisely be made to win politics or not, and JetBrains made the right ones, first to convince people internally (who knew about Scala, you know), then Google, as they were fairly well aligned.
I know enough about Google politics, and JVM ecosystem is part of my toolbox since 1996, starting with JDK 1.0.1, I have lived through all hype cycles of JVM guest languages since Beanshell was introduced.
> People just got fed up with the push toward pure FP and the complexity. Pure FP and category theory
Amen. My eyes start to glaze over whenever I read about covariance.
It's one thing if a feature works because of category theory, but if you just "feel like arrays should be covariant", and then the actual category theorists come along and can't work with its limitations, maybe give it a miss.
Wanted to get into enterprise-level back-end development in 2025 and was really drawn to Scala, but ultimately learning C# or Kotlin seemed way more practical.
Have error messages improved? I remember trying it few years back but the error messages made it hard to debug. Is it due to use of JVM? Sorry for my lack of knowledge since I rarely program in JVM based languages.
Compiler error messages improved significantly with Scala 3. IIRC there was a dedicated effort with Scala 3 to improve error messages and make them more actionable. Scala 2 error messages improved somewhat over time, but can still be obtuse.
It was before this: It was never a huge community, but from very early on it was split thanks to some rather unfriendly, competitive personalities and very different goals. You didn't just use scala: you either ran scala with a Twitter stack, or a typesafe(now lightbend) stack, or a scalaz stack, or a cats stack, or a zip stack. And a lot of the people developing each stack didn't like each other. I've gotten to work with core contributors of multiple of those, and knowing that I wasn't a devotee of any stack led to hearing way to much complaining in pairing sessions about how The Others (TM) were slowing down the adoption of the language.
A language that is really popular can manage having 5 ways to do things, but a small community is just going to lose steam. And the fact is, all the ways work just fine in a vacuum, but you can't just get really mature tooling when everything is just so split.
Yeah, I think with a community as small as Scala's, you can't really afford:
a. fragmentation of the ecosystem
b. repeated shuttering/abandonment of some of the most popular options (Lift, Play, Akka)
c. splitting the language in two
The perception within and without my own employer (which heavily invests in Scala) swapped from "acceptable" to "this ecosystem is a dead-end and we need to get out" with the launch of Scala 3. It's possible they would have reached the same conclusion, but I don't think breaking every industry engineer's development tools for years is a good strategy.
I don't think it is a problem with Scala 3 itself. Scala 3 brought a lot of improvements, one of them is using semantic versioning. People used to complain a log about binary compatibility between versions in 2.x. Now it's here.
I think that the slow adoption of Scala 3 is mainly due to one of its most successful projects: Apache Spark. To this day, Spark only supports Scala 2.13 although Scala 3 has been around for years now. This is both disappointing and frustrating because a lot of people were introduced to Scala thanks to Apache Spark.
The language is actually really nice. The "we won't ship dotty as the next version of Scala, just kidding, here it is", the breakage of editors and IDEs that lasted for years, etc (aka, the WAY they did it) make migrating a poor value prop. If I have to suffer worse tools and pay the tax of fixing them/updating them, then for each system when I think it's time to migrate to Scala 3 I might think it's time to migrate off Scala entirely.
It's possible that nothing could have reversed their existing trend, but I think it's fair to say that smaller communities (as another poster mentioned) can't afford this level of friction. Have we not seen Perl->Raku? Python2-3?
Additionally, while almost all of Scala 3 is an improvement over 2, whitespace significance seems like an awful hill to die on. Most people who value that sort of syntax in domains where Scala has made any inroads are already on Python, and we're going to alienate many existing developers in the (vain) hope of increasing marketability?
What really obliterated Scala’s momentum was PySpark overtaking Scala Spark coming from Python’s foothold in Data Science, columnar data warehouses carving out a big chunk of the batch processing pie as well, and then the Akka licensing change.
The Enterprise ecosystem quickly withered away, and now only type level programming diehards remain.
Akka's demise started before the license change. It's an incredible piece of software but as it turns out, not so many people need stateful cluster sharding. Modern cloud architecture and simpler streaming libraries have made the Akka toolkit irrelevant to many use cases.
You're right about Spark and the next logical step will be removing the JVM from the equation entirely, which is already ongoing (see Photon or Comet).
I think realistically we're looking at a lot of causes (which is not surprising; it's rarely a singular thing). Scala 3's momentum may have already been negative but how Scala 3 landed represented a nail in the coffin for a lot of individuals, teams, and organizations.
Scala 3 really landed at a bad time as the hype behind Spark, Akka, Play had already weaned off. Typesafe was struggling financially, and didn't back Scala 3 then (that went to VirtusLab).
Typelevel and ZIO really put a lot of effort to release many libraries on day 1 despite the hurdles with the 3.0 release, because these communities are alive and healthy. Yet Odersky is on a small crusade against monadic effect systems, which discouraged a lot of good people. On top of that there are neverending feuds and US politics...
Why is that? I think they did a lot of things right. Offer automatic conversions, backwards and forwards compatibility from a sufficiently recent 12.x version.
I think mostly Kotlin being simpler and Java gaining features ate the lunch. Also, software like Akka and Spark becoming less prevalent hurt because they were big reasons for devs to learn the language. Not to mention the community drama.
The only bad thing was that it took quite long for Scala3 to become available leading to a lot of stagnation.
From my perspective the two biggest challenges of the Scala 3 migration were macros and poor tooling support.
Macros were an experimental Scala 2 feature, but were used all over the Scala ecosystem. Because they were considered experimental a good migration story for them was never developed. That lack of support stopped migration efforts dead in their tracks at our company for a long while. It just wasn't worth contributing simultaneous support for Scala 3 and Scala 2 macros to every third party dependency who used Scala 2 macros. That said, we did it for some and lived on a fork for others.
IDE support for Scala 3 was really rough when it first released. We checked in on it with every IntelliJ release for roughly 3 years before we decided it was far enough along. Prior to that it was rough enough that we froze migration efforts in order to keep the tooling usable enough for engineers to be productive.
> IDE support for Scala 3 was really rough when it first released. We checked in on it with every IntelliJ release for roughly 3 years before we decided it was far enough along. Prior to that it was rough enough that we froze migration efforts in order to keep the tooling usable enough for engineers to be productive.
Same story for us - about 3 years before Intellij was usable, even then not up to what it had been on Scala 2. We still only have 2 Scala 3 repos, out of about 30, for my team, and we're actually MORE adventurous than most other teams at the company!
Well, IJ experience for Scala 3 is still noticeably worse than for Scala 2. We're still cross-compiling our work projects, waiting until Scala 3 support in Intellij is good enough to switch.
As other posters mentioned, a lot of it is about lacking critical mass in the first place. Making such a dramatic change is a high-risk thing, and Scala didn't have enough of a lead at all to justify it.
> The only bad thing was that it took quite long for Scala3 to become available leading to a lot of stagnation.
Unfortunately this isn't the only bad thing. The language overall is definitely a nicer language (though I complain about the whitespace change elsewhere). The tooling was broken for years, which actually stalled our team's migration. How could I advocate for moving to Scala 3, just to send everybody's editors and IDEs back to the stone age?
I'm not arguing that they built bad technology, I'm arguing that they ignored the reality: the value prop of moving to Scala 3 vs... moving to something else, at that point, isn't that compelling.
I remember being a big fan of Scala, and before Scala 3 it was looking to me that Kotlin was becoming a big competitor. Could that be, or do I have my timeline wrong?
It competes in some ways and not in others. It does a pretty good job of providing similar benefits as many Scala ecosystems, but providing approachability over purity.
Kotlin becoming The Official Android Language helps it quite a bit, though the future gets interesting if Google successfully abandons the JVM entirely to rid themselves of Oracle. I'm skeptical that Kotlin targeting multiple runtimes is a winning proposition, but it certainly seems to be doing a better job than Scala Native (also Rust is probably the better choice than Scala Native for that kind of code anyway).
> I'm skeptical that Kotlin targeting multiple runtimes is a winning proposition
Kotlin multiplatform being adopted by Google for huge projects like Google workspace makes it sound like it may actually be a winning proposition, if you ask me. Kotlin is replacing the more-than-a-decade old, battle tested, Java-to-ObjC translation at Google. I find that very impressive.
> also Rust is probably the better choice than Scala Native for that kind of code anyway
For sharing code between e.g. Android and iOS, Kotlin multiplatform seems to become the better solution. If you use Rust, you still have to call it from Swift and you just introduced a 3rd language.
I have always hated multiplatform frameworks, but Kotlin multiplatform is actually something that I find interesting (and flexible enough that you can choose where it makes sense to use it instead of committing to a whole framework).
> Kotlin multiplatform being adopted by Google for huge projects like Google workspace makes it sound like it may actually be a winning proposition, if you ask me. Kotlin is replacing the more-than-a-decade old, battle tested, Java-to-ObjC translation at Google. I find that very impressive.
When it comes to Google, I'll believe it when I see it. How's Fucshia?
> For sharing code between e.g. Android and iOS, Kotlin multiplatform seems to become the better solution. If you use Rust, you still have to call it from Swift and you just introduced a 3rd language.
I'm not positing Rust for this or any multiplatform thing, I was suggesting that Scala Native is eclipsed by Rust in its relatively narrow niche (and actually in addition to Rust, graal native-image).
I was first a big fan of Scala, and while I still like it, I am now really into Kotlin.
I don't find it disappointing: I tend to consider that Scala was an inspiration for Kotlin. Maybe Kotlin won by being simpler, and definitely because of the tooling and community: being backed by JetBrains and Google helps.
For a long time, the tooling was very limited with Scala, which must have slowed its adoption, right?
Kotlin is pretty nice. I think the build tool in Scala being so esoteric didn't help with adoption; I remember avoiding Scala for a few years because dealing with sbt left a horrible taste in my mouth.
Scala CLI should have happened 5 years before, but honestly sbt has improved a lot, the DX is mostly fine since the 1.0 release and it's maintained plugin compatibility for 8+ years.
Gradle is worse on several dimensions, which didn't really hurt Kotlin's adoption, nor seems to fundamentally bother Android developers (ok, they have little choice here).
Gradle is only still around thanks to Android, thankfully I have moved away from Android projects.
No need to read about how Kotlin is going to take over the world, while comparing it to samples written in Java 8, or the whole tooling infrastructure mess that needs to be changed, sorry improved, for each Google I/O, or stable Android Studio releases that crash on first use after upgrade, while "fixing" Gradle DSL changes.
I'm not advocating for Gradle either, but you already pointed out why the build tool being bad is relevant for Scala and not for Kotlin - Android developers have enough other reasons that they're going to use Kotlin, even though Gradle sucks. Scala developers... don't, and so just another straw stacked on a camel's back, so to speak.
I'm not saying it played no role, but I think sbt's negative impact is overblown.
Maven is old and the DX isn't particularly stellar either. User friendly build tools are a relatively recent development in the programming language landscape. Hell, until uv, Python managed to be much worse than anything on the JVM.
I work at a company that used to do a lot in Scala, and I've seen the decline first hand. Lack of investment in basic upkeep and maintenance is the real killer. Bitrot hurts in Scala more than in Java. And sbt is not the biggest offender there.
I also work at a company that used to do a lot in Scala, and have seen the decline firsthand. Who's anecdata is better?
I think a lot of posters make the mistake of saying "$otherLanguage has it worse." That's irrelevant! If otherLanguage is an incumbent, they can afford to have it worse. I don't think it's debatable that sbt harmed adoption in the first place and continued to represent a barrier to Scala's adoption for years, and it doesn't matter how good maven is or isn't.
The degree to which is certainly always going to be up for debate; as mentioned before, there are many factors, but sbt was not a nonfactor.
My point is that the decline is multi-factorial, as usual.
Scala needs some investment and commitment, you need a least one person who knows what they're doing: enforce a reasonable coding style, keep dependencies aligned and up to date, enable all the automated checks and linting, ...
Usually, when this is in place, then sbt is mostly a non-issue. You onboard a junior, they follow established practices, that includes the build. Sbt plugins are in fact a good way to standardize builds in a corporate setting.
Scala CLI was made for students and people who come from the outside. Sure, sbt is scary to them. But in the grand scheme of things, that's not what matters. Industry adoption doesn't really depend that much on the "zero to hello world" experience.
Case in point: several big Scala shops use Bazel. Bazel is 100x scarier than sbt and requires a bigger upfront investment.
Bazel being used by some companies is not vindication that sbt wasn't a significant source of friction, just another arena where sbt was considered less fit for the job (whether one could argue sbt should have been able to do the job would certainly be context-dependent).
If you work on internal libraries and apps, on a team with established practices, sbt shouldn't be a regular source of friction. It's really not that hard to define re-usable templates (you can even use Giter8!) for the typical multi-module build in a work setting. 99% of my projects either publish libraries to an internal Maven mirror, or packages apps with the native packager plugin, often OCI images nowadays. Sbt can be easily bootstrapped behind a Maven Central mirror entirely, you just need a single bash script. Sure the Maven and Gradle integrations in IntelliJ IDEA are more polished, but I'd pick sbt over these two without thinking, even for pure Java projects. Nowadays Mill is even better in many cases.
And the fact Bazel rules exist for a language doesn't say much about its native toolchain really. Large scale polyglot codebases and especially monorepos don't play nice with common tooling. But anyway you're missing my point. Developer friendly toolchains are the exception, not the norm. There's some impact on industry adoption, but not a huge one all things considered. Otherwise nobody would have touched Python before 2024.
I think we're simply going to have to agree to disagree.
Your position presupposes quite a bit of "systems already in motion" to make the point that there isn't friction. Except... there is, and _somebody_ has to maintain your builds, and handle all those fun deprecations like when the integration test project gets removed and the syntax gets updated. These things aren't stable, untouched pieces of your services over time, and I want everybody on my team, not just some experienced Scala developer who has already performed the rituals required to understand and establish practices for sbt, to contribute.
And what about the onramp to Scala? I'm certainly not relying on a team of established practitioners to pave the way when I'm learning a new language. We're talking about a dying language, I think it's silly to dismiss this.
> But anyway you're missing my point. Developer friendly toolchains are the exception, not the norm. There's some impact on industry adoption, but not a huge one all things considered. Otherwise nobody would have touched Python before 2024.
And you continue to miss mine - incumbent languages can afford more friction than niche languages. Python or Java's ability to have mediocre dev experiences do not have much bearing on how impactful Scala's is (though frankly, Java is not really worse than Scala in my opinion, and trendwise I think we see sbt displaced by java tools or mill more than maven or gradle in the reverse, so the industry tends to agree).
And again, if there's nobody that can maintain sbt builds you're screwed anyway. This is precisely what I said earlier: bitrot and lack of upkeep are the real killer. Sbt is the least of your worries in such scenario. There's no way a team of inexperienced Scala developers can bootstrap a greenfield project unsupervised, unless they're committed to a slow and painful onramp period. Sbt is just one small variable here.
For the sake of argument, imagine Scala had had the best build tool of the entire programming landscape in the past two decades. This would change nearly nothing to the current situation and Scala 3's adoption.
Can you elaborate on what you're referring to? I can see performance becoming a problem if you repeatedly chain non-optimisable (in bytecode) as excluding the in place operations I believe all ops re-allocate the collection.
Scala was the second programming language I learned (the first was Java). I think I'm quite lucky to have picked up a language like Scala so early in my programming journey. It made it very easy for me to learn new programming languages, since it made it easy to support wildly different paradigms (which is also what makes it hard to use in an enterprise environment).
yeah, you get everything and the kitchen sink with Scala. Which is actually IMO its biggest weakness. It wants to be everything, and it isn't amazing at anything as a result.
That is why I actually like Scala. I want every tool to be available at my disposal, and I can choose what to use or not use. I want it to be reasonably succinct and type safe.
I don't want the language to dictate how I use it. I'd prefer the language not to look out for me. There might be some, but a lot of languages look out way too much. Golang for example doesn't allow you to compile if there is an unused var. Java with private as the default.
It is great that there is a production-ready language that differs from other languages.
Every significant language became multi-paradigm these days, but you can do it intentionally, like Scala, or you can do it badly.
Python is multi paradigm, but does several things really well that other ecosystems do not. Javascript as well. Java as well. What claim to fame does Scala have in this regard, aside from being the best supported language for Spark for several years before PySpark overtook it? Perhaps Akka before the boneheaded decision to paywall that ecosystem?
"Among the clients of the Spark runtime architecture, Scala is the most popular language, followed by Python and Java. According to a recent survey by Databricks, the company behind Apache Spark, 71% of respondents reported using Scala for Spark development, while Python was used by 24% and Java by 5%. Another survey by Typesafe on the Spark ecosystem revealed that 88% of respondents used Scala, 44% used Java, and 22% used Python, with the percentages reflecting multiple language usage. Scala is considered the most optimized language for Spark due to its integration with the JVM and its role as the language in which Spark was internally implemented, offering better performance and access to the latest features."
When is this from? I would be shocked if in 2025 most Spark was being written in Scala
August 2024 -- so, dated.. mea culpa https://moldstud.com/articles/p-what-programming-languages-a...
I think the info is even more outdated than that. The article is from August 2024 but it cites "a recent survey by Databricks" that from what I can tell isn't linked to, so who knows what data they're referring to.
I was deep into the big data ecosystem in the 2010s. Those numbers feel like they're from 2017 or so. Scala has been on a slide every since.
One thing it clearly doesn't do well is performance.
>> Every significant language became multi-paradigm these days, but you can do it intentionally, like Scala, or you can do it badly.
> Python is multi paradigm, but does several things really well that other ecosystems do not.
Both Perl and Ruby can be, and often are, used instead of Python to great success for similar concerns. IOW, the three are often Liskov substitutable[0].
> Javascript as well.
You're kidding, right?
> What claim to fame does Scala have in this regard ...
Scala supports declarative, generative, imperative, meta, and object-oriented paradigms. All of which are supported by at least, but not limited to, the JVM and JavaScript runtimes.
These capabilities transcend libraries (such as Akka) and/or frameworks (such as Spark).
0 - https://en.wikipedia.org/wiki/Liskov_substitution_principle
It's interesting that Odersky started with Modula-2 (implementing a Z80 compiler), did a PhD with Wirth, but there discovered that functional programming offered a level of theoretical rigor and mathematical elegance he missed in Wirth's imperative languages. Wirth was generally critical of the complexity and abstraction often associated with functional languages. Rather than rejecting Wirth's pragmatism, he carried it forward by attempting to make functional programming "industry-ready".
I can relate to Odersky, similar to him, while I appreciate Niklaus Wirth's work, I don't appreciate the quest to minimalism that he went down after Oberon.
For me the right path is Oberon => Oberon-2 and Component Pascal => Zonnon and Active Oberon.
Yes, I know he wasn't directly evolved with those ones.
I see the several revisions of Oberon-07 as an entertaining exercise in minimalism, which fails to understand the industry.
Something that Niklaus Wirth complained about in his rant about Software Engineering, not understanding why Java and C++ and not Oberon won the hearts of companies.
I was fortunate to attend his Oberon session on Oberon Day at CERN, 20 years ago, while a genius programming language designer, expecting software engineers to recognise great design and naturally embracing it, was expecting too much.
Minimalism is indeed the correct term (usually framed as simplicity) when looking at both, language and documentation. But at least it helped that there was always a working compiler and system, not a mere theory.
> I see the several revisions of Oberon-07 as an entertaining exercise in minimalism, which fails to understand the industry.
His main motivation was to minimize the amount of work porting his original system to his own, FPGA based processor board. His fans interpreted the “new” language more as a new prophetic proclamation, but in reality it was only about the feasibility of his post-retirement hobby project. This became clear at the latest when people wanted to run a benchmark on the system and discovered that the compiler couldn’t generate such large binaries. There was simply a fixed maximum size, but for many years no one noticed this.
He has always positioned his languages for education and limited himself to the systems that can be realized with them. If his goal had been to meet the needs of industry, he would have acted differently. After a very brief foray to an industrial job in the sixties, he immediately returned to academia and hardly looked back.
One could argue that Modula-2 was an attempt to fix Pascal for the industry, after all the dialects that sprung out of it, which he wasn't keen on, with the influence from Mesa, after his sabbatical at Xerox.
Also that the way it failed to be embraced by the industry, too busy with UNIX, C and C++, also had an effect on his point of view going forward.
> One could argue that Modula-2 was an attempt to fix Pascal for the industry
There is no evidence that Wirth e.g. ever directly or specifically rebutted Kernighan's famous paper, nor that Modula-2 was a response to it. Modula-2 was a child of the ivory tower (PARC), not industry. Wirth was rather an "escapist" who built his own worlds rather than fixing the real one. He saw Parnas' concepts "in action" during his sabbatical at Xerox. He didn't create Modula-2 to help industry; he created it because he wanted to replicate the Alto workstation experience (which became the Lilith) for his own use and for his students at ETH. Wirth was a brilliant "synthesizer" of academic ideas (Parnas, Hoare, Mesa) who built beautiful, self-contained gardens for himself and his students. He was never the "industrial repairman" that later apologists tried to paint him as.
Why should he?
That paper was only relevant among UNIX people, and largely ignored by anyone doing 8 and 16 bit home computing with Pascal and Modula-2.
It is no accident that to this day, it is the UNIX accolades that keep bringing it back every couple of months, most of whom never used a single Pascal compiler in their lifes, or aware that Modula-2 was already around.
Modula-2 relevance as systems language is quite easy to find out in some of his essays, and the companies selling compilers for Acorn, Amiga and PC.
You said that "One could argue that Modula-2 was an attempt to fix Pascal for the industry". By 1981, the C/Unix team was no longer a "rogue research group" in a closet; they were the architects of the dominant industrial paradigm shift (with Apollo Computer, Sun Microsystems, Silicon Graphics, and even Microsoft all using Unix and C). That's why I mentioned it. Wirth didn't care because his concern wasn't industry. Pascal users helped themselves: e.g. Lisa Pascal essentially included all features from C, which according to Kernighan (who referred to Wirth's original Pascal, not the derivatives) were missing, and even a module and separate compilation concept (four years before Turbo Pascal); they could have used Modula-2, which was around at the time. While Modula-2 was hypothetically a "systems language", it lacked the pragmatic "dirty" features that C, Lisa Pascal, and Turbo Pascal embraced to actually build operating systems and drivers on commodity hardware (unless, again, they were added as an extension by the compiler vendors). E.g. Topspeed Modula supported inline assembly, Acorn Modula included extensions to call software interrupts directly with register mapping; almost all commercial vendors added extensions to bypass strict typing, or direct pointer increment/decrement to support C-style array traversal.
It is irritating that apparently C is fine having endless compiler extensions without which ISO C is equally unusable to implement an operating system[0], a sign of greatness, while the same argument is used to point out as design flaws when it isn't C we are talking about.
[0] - Unless helped by an external assembler, just like on the UNIX rewrite, when K&R C was initially created.
I'm not advocating for C (I wouldn't implement an Oberon/Pascal/Modula inspired C replacement otherwise). C was mostly adopted by industry because it came with Unix and had to be used by the many Unix-based workstation vendors to adapt and extend the OS for their specific need/brand. That a significant OS can be written in C without extensions is demonstrated by the many Unix versions themselves. There is always a remainder which has to be implemented in assembler (e.g. to achieve the system state required to run C functions at all). I can also confirm from my own long-time experience implementing embedded (microcontroller) systems in C that it is possible with standard C. But that's not the point. We were discussing about Wirt's minimalism and his focus on his own and the need of his students (vs. the need of industry). I think Wirth's role and influence are generally romanticized. He was innovative, but he did his own thing. The impact of his work on the industry is almost exclusively in a significantly modified/extended form. These extensions/modifications never came from Wirth himself, and only in exceptional cases did they have “his blessing” (e.g., Object Pascal or Modula-3). It was precisely his aforementioned minimalism that led him to focus on the things that were important to him, rather than on the needs of the industry, whether justified or not.
Sure, if we ignore the Assembly buddy code used alongside C.
IBM's OS/400 made use of Modula-2 for some parts, for example.
Back to Niklaus Wirth, as mentioned initially, I think his ideas were great, until he went into minimalism, the first Oberon edition was the turning point, that other researchers luckily improved upon.
Ironically to his point of view, some of them, like Hanspeter Mössenböck, changed his focus into Java and .NET, and has contributions to MaximeVM and GraalVM, via his students thesis.
I'm not sure what you're getting at with this recurring assembler argument. The Oberon system and also AOS/Bluebottle are full of inline assembler and SYSTEM tricks with pointer arithmetic, etc.; the Lisa OS is also full of assembler. Even Wirth himself wrote parts of the Ceres system in assembler.
Indeed they are, however when it is C, it is an advantage, gladly ignored that ISO C on its own requires an external Assembly tool to do its job, when it is something else, it is thrown around as proof they aren't as good as C for systems programming, the irony of two weighs, two measures.
"You need Assembly to do XYZ that C can do", yeah right.
> when it is something else, it is thrown around as proof they aren't as good as C for systems programming
That's not my position, and not my argument in this thread. My argument was, that Wirth created his own world and never cared about industry requirements, so industry cared for themselves.
But let me address your concerns. C is an ugly language with a silly syntax (e.g. for arrays, or function types), and the preprocessor is a nightmare, and the weak type checking overlooks a lot of errors (but at least we get warnings, and weak types are very useful when I use C as an IR). But the standard version (ANSI) lets me do all things I need for system development; I don't use inline assembler.
So let's look at Modula-2 (since you seem to see it as Wirth's response to industry needs). First, we have to differ between Wirth's Modula-2, and ISO Modula-2, which is a completely different language (more industry friendly, containing things Wirth was strictly against, and he even refused to participate). So let's stick with Wirth's Modula-2. The first thing that annoys me is the requirement of the original 1982 specification to capitalize all keywords. The second thing is the removal of any type checking for all operations essential for low-level system programming (a pattern Wirth continued in Oberon). ADDRESS is declared as POINTER TO WORD, and the specification doesn't define whether pointer arithmetics has byte or WORD resolution. Type casting is very limited (i.e. restricted to SYSTEM.TRANSFER or variant records without tag, but not in expressions). There is no conditional compilation and only limited compile-time evaluation. There is no explicit "extern" declaration; the use of definition without implementation modules is inofficial and compiler dependent. Some of these issues were "fixed" in ISO Modula. But if I compare Modula-2 e.g. with Ada, which is indeed a true system language explicitly designed for critical industry needs, even ISO Modula is still very limited.
It is, of course, well known – or at the very least frequently and enthusiastically repeated – that a suitably drunk Odersky devised Scala whilst watching a Reese’s Peanut Butter Cup ad[0].
[0] http://www.nerdware.org/doc/abriefhistory.html
I’m very happy that I learned Scala back in 2018(thanks to my colleague). I quickly realized that this is the language I want to use for work, and after some time, I joined my first Scala project. Five years later Scala is still my favorite language, along with Rust.
Martin Odersky did a fantastic job with Scala then, and also with Scala 3 IMO from a language design perspective. When I first got into Scala, I was blown away by the language features and the type system. It was the reason I got back into the JVM and the reason for getting into functional programming (not pure FP).
Scala is a great language, and functional programming (not pure functional) made me a much better programmer. And functional error handling is a fantastic way to model success and failure, whether you’re using Either or the newer Result type.
I have to both agree and disagree with some of the commenters here regarding why scala declined in usage. There are several reasons.
1. People just got fed up with the push toward pure FP and the complexity. Pure FP and category theory, and effect libraries are just not for the average audience.
2. Android support for Kotlin drastically reduced the momentum as well
3. Spark usage was pretty heavy driver for using Scala and I’m not sure about it’s used as much.
4. Scala became more and more niche as a result of item 1 above.
This being said, I switched to Kotlin for all server side work. I think a language and in particular the ecosystem, needs the vision/stewardship that can offer more practicality and balance in the language design, programming style, tooling, and frameworks. Kotlin just became a simpler language with better support for all of the above.
I can’t think of a better company to drive the development than Jetbrains. I don’t agree with all the choices, but Kotlin overall is a beautiful, simpler language, with all the practicality, and support needed to keep it going.
However, now that Java is making strides in the language features, as compared to historical improvements at the VM level, I’m curious to see how the market share for Kotlin outside of android is going to be affected.
Personally, I still prefer Kotlin for the practical FP support, Ktor as an HTTP server, and pretty good compatibility with Java. And lastly, I think there is enormous potential in multiplatform, as a strong alternative to typescript/react native for mobile.
Disclosure: I am biased as I’m developing some libraries and soon to be made (more) public server framework.
> However, now that Java is making strides in the language features, as compared to historical improvements at the VM level, I’m curious to see how the market share for Kotlin outside of android is going to be affected.
My employer has decided to abandon Scala, and they proposed Java as the language to head toward. I don't think Java's strides are fast enough to provide modern table stakes. In 2025, the big ones to me are:
1. null handling at the cultural and language level
2. abstractions over concurrency
For null handling, Java has Option, but you're just going to have to deal with the fact that basically any API or caller can give you null. This is not good enough in 2025.
For concurrency, Java has an excellent java.util.concurrent package (and the JVM is very good at concurrency in general). However, I've come to believe that it's a losing proposition to expect the average programmer to use concurrency primitives correctly, even at that level of abstraction. Every Java PR I review I have to add 20-30 comments about thread interruption, memory barriers, etc.
Structured Concurrency helps, but is new/in preview, and hardly helps with actually providing safer concurrency operations.
I think Java is doing the right things and the glacial pace of innovation at the language level is correct for protecting their users (contrast this with Scala 3...), but on the flipside I just think that it is hard to recommend Java vs C#/Kotlin.
Depending on the market, C# isn't always an option.
One example out of many, https://www.aicas.com
This isn't like Meadows, this is a real-time VM with AOT compilation and soft-realtime deadlines, there are others.
Or stuff like https://www.azul.com/products/prime/cloud-native-compiler, again there are others offering the same.
Kotlin will always be a second language on the JVM, it isn't what Oracle, IBM, and others think about when designing runtime features, and eventually like all guest languages will face the problem to either exposed the platform features, or have multiple ways, with different semantics, to achive the same.
Virtual threads, versus co-routines, structured concurrency, SIMD/Vector, value class/records,....
It frankly doesn't matter in which markets C# isn't an option - if you're in one of those, well... then obviously don't consider C#. That doesn't somehow indict C# as a language which better makes it possible to write concurrent code. For a very large proportion of the population, you're picking a language and running some services on a cloud provider or machine you control.
The problem I'm citing in Java is not the performance, it's the semantics and having to explain what an InterruptedException is to every generation of programmers, including those who came before me. If you think virtual threads somehow do anything about what's difficult about concurrency on the JVM, we're talking on different wavelengths. Structured Concurrency is the TINIEST of baby steps and doesn't really do anything to change the experience, and it's only just now in preview, in the most recent LTS JVM? Hardly a solution.
It doesn't matter whether the JVM is developed with Kotlin in mind, as long as Kotlin continues to offer a better way to leverage what the JVM does have to offer. It's not some killer argument that Kotlin somehow can't be useful if the host platform isn't specifically developing their roadmap (especially because you can... just write Java, if you need it?).
Scala's demise likewise has nothing to do with whether the JVM is supporting Scala, and any suggestion that Java's language features have eliminated Scala's value proposition are similarly misplaced.
It matters, because these arguments are always done as if programming languages exist in a vacuum.
Any guest language on the JVM will trip on the InterruptedException just as well, it is called leaky abstractions for a reason.
People reach out to guest languages, as they think they don't have to learn the underlying platform, then they discover the hard reality to master two ecosystems.
Improvements on the platfrom language eventually always drive the guest languages away, because all guest languages either lose their value proposition, or use the platform to bootstrap their own ecosystem.
Turns out when they take second option, they open the door to having libraries that only work in one platform, and the usual #ifdef like complexity.
Kotlin has a better future than Scala, beyond the JVM, because papa Google has ensured it happens, at least as long as they care about Android.
No, it doesn't matter. You are advocating for the special case, not the average case, and it has no bearing on C#'s _general_ aptness that it can't be deployed somewhere. The same is true of Java! This is nitpicking with no justification.
> Any guest language on the JVM will trip on the InterruptedException just as well, it is called leaky abstractions for a reason.
They can (and do) reduce how often and where you have to interact with it. I at this point am not sure whether you are intentionally arguing from a position of ignorance or whether this is actual bad faith. Are you suggesting that abstraction is not useful or impossible? Yes _obviously_ InterruptedException is still on the classpath and in implementation code; that doesn't mean we should throw in the towel and interact with APIs that constantly throw it.
> Improvements on the platfrom language eventually always drive the guest languages away, because all guest languages either lose their value proposition, or use the platform to bootstrap their own ecosystem.
You have done nothing to address the issue that Java adopts new features extremely conservatively and slowly. I already used the perfect example that you gave of Structured Concurrency, which is not only not enough, but not even available, and ten years late. It is simply false that Java has done anything significant to compete with its guest languages. Javascript, yes! C#... debatable, but certainly better at it than Java.
> Turns out when they take second option, they open the door to having libraries that only work in one platform, and the usual #ifdef like complexity.
This is why I'm skeptical of multiplatform approaches such as Kotlin's, but that my suggestion that Kotlin is useful is not based on any degree of multiplatform support. Even at the end of the day if I thought Kotlin didn't have a future, my point is that that is table stakes level of abstraction in 2025 and Java ain't it.
1. There was never a push. Functional ecosystems are simply the ones that survived. You can't blame communities that keep the language alive for doing what they want, and not what you want. Without Typelevel and ZIO where would be Scala 3's adoption today?
2. Android has never been even remotely relevant to the space where Scala exists. And no, this was not a missed opportunity for the language. People who think Scala had a shot are completely delusional.
3. I'm personally convinced Spark was the worst thing that happened to the ecosystem as it brought a lot of attention, and indeed, drove adoption, only to result in an incredible amount of shitty code plagued by the worst annoyances in the JVM and big data space. Spark is the biggest open source project in Scala, yet Databricks doesn't seem to give a damn about the language and couldn't even be bothered shipping a Scala 2.13 runtime for years after its release. I sincerely hope Spark moves away from the JVM entirely.
Kotlin is really not any simpler especially with the constant feature creep that results in copying Scala features, only halfbaked. It's even less principled which is the biggest gripe against Scala having too many ways to do the same thing. There's nothing beautiful or practical about a language where people regularly write expression oriented code next to early returns.
Given that Scala-Android efforts predate Kotlin, Scala could have had a shot at Android if EPFL resources were allocated to it, like to Scala.js.
Kotlin is not simple at all, it has a lot of keywords for strange and very specific features and corner cases, it's hard to remember them all. Moreover, the Intellij Kotlin plugin is somehow slower than Scala's despite being a 1st party language and not having implicits, how they managed to achieve that is a mystery.
- The resources simply didn't exist, Typesafe couldn't even become profitable doing what Scala does best.
- Scala was a bad fit, especially on low-end and slow Android devices.
- Google doesn't like languages like Scala. They use it for Chisel but it's not a language allowed for backend services, while Kotlin is.
Any language pushed by Android overload has a shot at Android.
Kotlin would be irrelevant on the JVM space otherwise, only something being pushed by Jet Brains that some folks play with outside the company.
There would not exist a Kotlin Foundation which is basically Jet Brains in bed with Google.
I keep waiting for the announcement of Google's acquisition from Jet Brains.
Right and if you know the first thing about Scala, Kotlin, Google and JetBrains, it should be clear Scala on Android was simply never going to happen, even if Typesafe somehow managed to find extra millions in funding and could allocate dozens of people behind it.
It certainly would, had Google decided that would happen, and support the ongoing existing efforts from the community.
If you know anything about Google politics, you would know Kotlin only took off because of a couple of folks on the Android Tools team doing free advocacy for JetBrains.
In an alternative reality, if those same persons had been Scala heads, Jetpack Compose would be a Scala DSL today.
Scala was a bad fit for the Android runtime and the SDK. On a $200 Android phone with 2015 specs the performance aspect was definitely not a trivial argument against Scala; Kotlin has perfect interop with very little overhead, no conversions between collections (often slow and immutable in Scala), a nullability story that doesn't box everything in Option, ...
And most Googlers do not like clever languages with bad tooling, especially the ones working to productize languages and toolchains for Blaze and other internal tools.
All irrelevant when politics are involved.
You will never get me to say anything positive about the Kotlin advocates on Android team.
It isn't only Scala, it is using Java 7 samples to sell Kotlin, the original language for Android, still used for the large majority of Android tooling, where your argument fails flat.
They have begrudgingly being updating Java support, up to Java 17, when Java 25 is the latest LTS, because that great Kotlin interop with Java is useless when Android loses access to the Java ecosystem that keeps moving forward regardless of Android.
Some of them even don't have any ideas how out of date their Kotlin "improvements" over Java are out of date.
I'm not defending JetBrains or Google's decisions. But I don't see why anyone should try to rewrite history.
Scala had a decade head start. Many people at Google are aware of Scala, some being former LAMP students or staff. Google doesn't simply add a language to their small list of sanctioned toolchains.
Kotlin was specifically designed to win the politics argument, using technical merits: full interop, gradual adoption, low overhead, ability to target outdated Java bytecode efficiently (Kotlin used to inline lambdas for Java 6 bytecode for instance, while Scala boxed everything before invokedynamic). It doesn't matter whether one approach is objectively right or wrong, Kotlin fitted the bill and Scala did not. More importantly, Kotlin fitted the bill on Google's server side too!
Then of course JetBrains was tasked to replace the IDE with Android Studio, they could put dozens people backing Kotlin as a first-class Android language, until Google adopted it officially.
But even if Typesafe had somehow stumbled upon $100M in funding to do the same thing, it doesn't change the fact that Scala never had a chance.
Kotlin won Android on internal Google politics, zero technical merit.
Feel free to write another long reply on how Kotlin is somehow special, going to replace Java, while the first iteration of Kotlin Native was a failure with a broken design on its reference counting memory approach, and there is still no KVM to replace the JVM in sight, despite such greatness as pointed out in Android circles.
I haven't defended Kotlin's approach in any way, I don't know why you want to put words in my mouth.
However if you don't see why Kotlin was well positioned, while Scala was not, then you clearly don't know much about either language.
Technical merit is subjective, but different design decisions can precisely be made to win politics or not, and JetBrains made the right ones, first to convince people internally (who knew about Scala, you know), then Google, as they were fairly well aligned.
I know enough about Google politics, and JVM ecosystem is part of my toolbox since 1996, starting with JDK 1.0.1, I have lived through all hype cycles of JVM guest languages since Beanshell was introduced.
> People just got fed up with the push toward pure FP and the complexity. Pure FP and category theory
Amen. My eyes start to glaze over whenever I read about covariance.
It's one thing if a feature works because of category theory, but if you just "feel like arrays should be covariant", and then the actual category theorists come along and can't work with its limitations, maybe give it a miss.
Wanted to get into enterprise-level back-end development in 2025 and was really drawn to Scala, but ultimately learning C# or Kotlin seemed way more practical.
I love scala case classes and pattern matching. Too bad the compiler sucked (too slow) and it had some rather large footguns like implicits
Have error messages improved? I remember trying it few years back but the error messages made it hard to debug. Is it due to use of JVM? Sorry for my lack of knowledge since I rarely program in JVM based languages.
Compiler error messages improved significantly with Scala 3. IIRC there was a dedicated effort with Scala 3 to improve error messages and make them more actionable. Scala 2 error messages improved somewhat over time, but can still be obtuse.
Do you mean compiler errors or some other kind of error message?
Compiler errors got a lot better during the Scala 2.12 era.
Yes. It might have been errors when using Apache Spark with Apache Zeppelin notebooks. However, I must admit it was long time ago (2015-2016 era).
If you haven't checked Scala 3, give it a try. Its syntax is now Python-like (indentation based), although you can also use C style if you prefer.
And it's faster (or maybe my laptop is faster).
Scala is a great language. It's a little bit disappointing that Kotlin is the JVM language that's gained so much traction instead.
I've used both fairly extensively. Scala is just "too much". Kotlin is perhaps not enough, but that's better than too much.
They really obliterated their momentum with how they went about Scala 3, unfortunately.
It was before this: It was never a huge community, but from very early on it was split thanks to some rather unfriendly, competitive personalities and very different goals. You didn't just use scala: you either ran scala with a Twitter stack, or a typesafe(now lightbend) stack, or a scalaz stack, or a cats stack, or a zip stack. And a lot of the people developing each stack didn't like each other. I've gotten to work with core contributors of multiple of those, and knowing that I wasn't a devotee of any stack led to hearing way to much complaining in pairing sessions about how The Others (TM) were slowing down the adoption of the language.
A language that is really popular can manage having 5 ways to do things, but a small community is just going to lose steam. And the fact is, all the ways work just fine in a vacuum, but you can't just get really mature tooling when everything is just so split.
Yeah, I think with a community as small as Scala's, you can't really afford:
a. fragmentation of the ecosystem b. repeated shuttering/abandonment of some of the most popular options (Lift, Play, Akka) c. splitting the language in two
The perception within and without my own employer (which heavily invests in Scala) swapped from "acceptable" to "this ecosystem is a dead-end and we need to get out" with the launch of Scala 3. It's possible they would have reached the same conclusion, but I don't think breaking every industry engineer's development tools for years is a good strategy.
I don't think it is a problem with Scala 3 itself. Scala 3 brought a lot of improvements, one of them is using semantic versioning. People used to complain a log about binary compatibility between versions in 2.x. Now it's here. I think that the slow adoption of Scala 3 is mainly due to one of its most successful projects: Apache Spark. To this day, Spark only supports Scala 2.13 although Scala 3 has been around for years now. This is both disappointing and frustrating because a lot of people were introduced to Scala thanks to Apache Spark.
The language is actually really nice. The "we won't ship dotty as the next version of Scala, just kidding, here it is", the breakage of editors and IDEs that lasted for years, etc (aka, the WAY they did it) make migrating a poor value prop. If I have to suffer worse tools and pay the tax of fixing them/updating them, then for each system when I think it's time to migrate to Scala 3 I might think it's time to migrate off Scala entirely.
It's possible that nothing could have reversed their existing trend, but I think it's fair to say that smaller communities (as another poster mentioned) can't afford this level of friction. Have we not seen Perl->Raku? Python2-3?
Additionally, while almost all of Scala 3 is an improvement over 2, whitespace significance seems like an awful hill to die on. Most people who value that sort of syntax in domains where Scala has made any inroads are already on Python, and we're going to alienate many existing developers in the (vain) hope of increasing marketability?
I learned scala due to load testing with Gatling.
I’ve always hated Java but Scala was super fun.
What really obliterated Scala’s momentum was PySpark overtaking Scala Spark coming from Python’s foothold in Data Science, columnar data warehouses carving out a big chunk of the batch processing pie as well, and then the Akka licensing change.
The Enterprise ecosystem quickly withered away, and now only type level programming diehards remain.
Akka's demise started before the license change. It's an incredible piece of software but as it turns out, not so many people need stateful cluster sharding. Modern cloud architecture and simpler streaming libraries have made the Akka toolkit irrelevant to many use cases.
You're right about Spark and the next logical step will be removing the JVM from the equation entirely, which is already ongoing (see Photon or Comet).
I think realistically we're looking at a lot of causes (which is not surprising; it's rarely a singular thing). Scala 3's momentum may have already been negative but how Scala 3 landed represented a nail in the coffin for a lot of individuals, teams, and organizations.
Scala 3 really landed at a bad time as the hype behind Spark, Akka, Play had already weaned off. Typesafe was struggling financially, and didn't back Scala 3 then (that went to VirtusLab).
Typelevel and ZIO really put a lot of effort to release many libraries on day 1 despite the hurdles with the 3.0 release, because these communities are alive and healthy. Yet Odersky is on a small crusade against monadic effect systems, which discouraged a lot of good people. On top of that there are neverending feuds and US politics...
Why is that? I think they did a lot of things right. Offer automatic conversions, backwards and forwards compatibility from a sufficiently recent 12.x version.
I think mostly Kotlin being simpler and Java gaining features ate the lunch. Also, software like Akka and Spark becoming less prevalent hurt because they were big reasons for devs to learn the language. Not to mention the community drama.
The only bad thing was that it took quite long for Scala3 to become available leading to a lot of stagnation.
From my perspective the two biggest challenges of the Scala 3 migration were macros and poor tooling support.
Macros were an experimental Scala 2 feature, but were used all over the Scala ecosystem. Because they were considered experimental a good migration story for them was never developed. That lack of support stopped migration efforts dead in their tracks at our company for a long while. It just wasn't worth contributing simultaneous support for Scala 3 and Scala 2 macros to every third party dependency who used Scala 2 macros. That said, we did it for some and lived on a fork for others.
IDE support for Scala 3 was really rough when it first released. We checked in on it with every IntelliJ release for roughly 3 years before we decided it was far enough along. Prior to that it was rough enough that we froze migration efforts in order to keep the tooling usable enough for engineers to be productive.
> IDE support for Scala 3 was really rough when it first released. We checked in on it with every IntelliJ release for roughly 3 years before we decided it was far enough along. Prior to that it was rough enough that we froze migration efforts in order to keep the tooling usable enough for engineers to be productive.
Same story for us - about 3 years before Intellij was usable, even then not up to what it had been on Scala 2. We still only have 2 Scala 3 repos, out of about 30, for my team, and we're actually MORE adventurous than most other teams at the company!
Well, IJ experience for Scala 3 is still noticeably worse than for Scala 2. We're still cross-compiling our work projects, waiting until Scala 3 support in Intellij is good enough to switch.
As other posters mentioned, a lot of it is about lacking critical mass in the first place. Making such a dramatic change is a high-risk thing, and Scala didn't have enough of a lead at all to justify it.
> The only bad thing was that it took quite long for Scala3 to become available leading to a lot of stagnation.
Unfortunately this isn't the only bad thing. The language overall is definitely a nicer language (though I complain about the whitespace change elsewhere). The tooling was broken for years, which actually stalled our team's migration. How could I advocate for moving to Scala 3, just to send everybody's editors and IDEs back to the stone age?
I'm not arguing that they built bad technology, I'm arguing that they ignored the reality: the value prop of moving to Scala 3 vs... moving to something else, at that point, isn't that compelling.
I remember being a big fan of Scala, and before Scala 3 it was looking to me that Kotlin was becoming a big competitor. Could that be, or do I have my timeline wrong?
It competes in some ways and not in others. It does a pretty good job of providing similar benefits as many Scala ecosystems, but providing approachability over purity.
Kotlin becoming The Official Android Language helps it quite a bit, though the future gets interesting if Google successfully abandons the JVM entirely to rid themselves of Oracle. I'm skeptical that Kotlin targeting multiple runtimes is a winning proposition, but it certainly seems to be doing a better job than Scala Native (also Rust is probably the better choice than Scala Native for that kind of code anyway).
> I'm skeptical that Kotlin targeting multiple runtimes is a winning proposition
Kotlin multiplatform being adopted by Google for huge projects like Google workspace makes it sound like it may actually be a winning proposition, if you ask me. Kotlin is replacing the more-than-a-decade old, battle tested, Java-to-ObjC translation at Google. I find that very impressive.
> also Rust is probably the better choice than Scala Native for that kind of code anyway
For sharing code between e.g. Android and iOS, Kotlin multiplatform seems to become the better solution. If you use Rust, you still have to call it from Swift and you just introduced a 3rd language.
I have always hated multiplatform frameworks, but Kotlin multiplatform is actually something that I find interesting (and flexible enough that you can choose where it makes sense to use it instead of committing to a whole framework).
> Kotlin multiplatform being adopted by Google for huge projects like Google workspace makes it sound like it may actually be a winning proposition, if you ask me. Kotlin is replacing the more-than-a-decade old, battle tested, Java-to-ObjC translation at Google. I find that very impressive.
When it comes to Google, I'll believe it when I see it. How's Fucshia?
> For sharing code between e.g. Android and iOS, Kotlin multiplatform seems to become the better solution. If you use Rust, you still have to call it from Swift and you just introduced a 3rd language.
I'm not positing Rust for this or any multiplatform thing, I was suggesting that Scala Native is eclipsed by Rust in its relatively narrow niche (and actually in addition to Rust, graal native-image).
I was first a big fan of Scala, and while I still like it, I am now really into Kotlin.
I don't find it disappointing: I tend to consider that Scala was an inspiration for Kotlin. Maybe Kotlin won by being simpler, and definitely because of the tooling and community: being backed by JetBrains and Google helps.
For a long time, the tooling was very limited with Scala, which must have slowed its adoption, right?
Kotlin is pretty nice. I think the build tool in Scala being so esoteric didn't help with adoption; I remember avoiding Scala for a few years because dealing with sbt left a horrible taste in my mouth.
Scala CLI should have happened 5 years before, but honestly sbt has improved a lot, the DX is mostly fine since the 1.0 release and it's maintained plugin compatibility for 8+ years.
Gradle is worse on several dimensions, which didn't really hurt Kotlin's adoption, nor seems to fundamentally bother Android developers (ok, they have little choice here).
Gradle is only still around thanks to Android, thankfully I have moved away from Android projects.
No need to read about how Kotlin is going to take over the world, while comparing it to samples written in Java 8, or the whole tooling infrastructure mess that needs to be changed, sorry improved, for each Google I/O, or stable Android Studio releases that crash on first use after upgrade, while "fixing" Gradle DSL changes.
I'm not advocating for Gradle either, but you already pointed out why the build tool being bad is relevant for Scala and not for Kotlin - Android developers have enough other reasons that they're going to use Kotlin, even though Gradle sucks. Scala developers... don't, and so just another straw stacked on a camel's back, so to speak.
I'm not saying it played no role, but I think sbt's negative impact is overblown.
Maven is old and the DX isn't particularly stellar either. User friendly build tools are a relatively recent development in the programming language landscape. Hell, until uv, Python managed to be much worse than anything on the JVM.
I work at a company that used to do a lot in Scala, and I've seen the decline first hand. Lack of investment in basic upkeep and maintenance is the real killer. Bitrot hurts in Scala more than in Java. And sbt is not the biggest offender there.
I also work at a company that used to do a lot in Scala, and have seen the decline firsthand. Who's anecdata is better?
I think a lot of posters make the mistake of saying "$otherLanguage has it worse." That's irrelevant! If otherLanguage is an incumbent, they can afford to have it worse. I don't think it's debatable that sbt harmed adoption in the first place and continued to represent a barrier to Scala's adoption for years, and it doesn't matter how good maven is or isn't.
The degree to which is certainly always going to be up for debate; as mentioned before, there are many factors, but sbt was not a nonfactor.
My point is that the decline is multi-factorial, as usual.
Scala needs some investment and commitment, you need a least one person who knows what they're doing: enforce a reasonable coding style, keep dependencies aligned and up to date, enable all the automated checks and linting, ...
Usually, when this is in place, then sbt is mostly a non-issue. You onboard a junior, they follow established practices, that includes the build. Sbt plugins are in fact a good way to standardize builds in a corporate setting.
Scala CLI was made for students and people who come from the outside. Sure, sbt is scary to them. But in the grand scheme of things, that's not what matters. Industry adoption doesn't really depend that much on the "zero to hello world" experience.
Case in point: several big Scala shops use Bazel. Bazel is 100x scarier than sbt and requires a bigger upfront investment.
Bazel being used by some companies is not vindication that sbt wasn't a significant source of friction, just another arena where sbt was considered less fit for the job (whether one could argue sbt should have been able to do the job would certainly be context-dependent).
If you work on internal libraries and apps, on a team with established practices, sbt shouldn't be a regular source of friction. It's really not that hard to define re-usable templates (you can even use Giter8!) for the typical multi-module build in a work setting. 99% of my projects either publish libraries to an internal Maven mirror, or packages apps with the native packager plugin, often OCI images nowadays. Sbt can be easily bootstrapped behind a Maven Central mirror entirely, you just need a single bash script. Sure the Maven and Gradle integrations in IntelliJ IDEA are more polished, but I'd pick sbt over these two without thinking, even for pure Java projects. Nowadays Mill is even better in many cases.
And the fact Bazel rules exist for a language doesn't say much about its native toolchain really. Large scale polyglot codebases and especially monorepos don't play nice with common tooling. But anyway you're missing my point. Developer friendly toolchains are the exception, not the norm. There's some impact on industry adoption, but not a huge one all things considered. Otherwise nobody would have touched Python before 2024.
I think we're simply going to have to agree to disagree.
Your position presupposes quite a bit of "systems already in motion" to make the point that there isn't friction. Except... there is, and _somebody_ has to maintain your builds, and handle all those fun deprecations like when the integration test project gets removed and the syntax gets updated. These things aren't stable, untouched pieces of your services over time, and I want everybody on my team, not just some experienced Scala developer who has already performed the rituals required to understand and establish practices for sbt, to contribute.
And what about the onramp to Scala? I'm certainly not relying on a team of established practitioners to pave the way when I'm learning a new language. We're talking about a dying language, I think it's silly to dismiss this.
> But anyway you're missing my point. Developer friendly toolchains are the exception, not the norm. There's some impact on industry adoption, but not a huge one all things considered. Otherwise nobody would have touched Python before 2024.
And you continue to miss mine - incumbent languages can afford more friction than niche languages. Python or Java's ability to have mediocre dev experiences do not have much bearing on how impactful Scala's is (though frankly, Java is not really worse than Scala in my opinion, and trendwise I think we see sbt displaced by java tools or mill more than maven or gradle in the reverse, so the industry tends to agree).
And again, if there's nobody that can maintain sbt builds you're screwed anyway. This is precisely what I said earlier: bitrot and lack of upkeep are the real killer. Sbt is the least of your worries in such scenario. There's no way a team of inexperienced Scala developers can bootstrap a greenfield project unsupervised, unless they're committed to a slow and painful onramp period. Sbt is just one small variable here.
For the sake of argument, imagine Scala had had the best build tool of the entire programming landscape in the past two decades. This would change nearly nothing to the current situation and Scala 3's adoption.
Except when you chain many collection operations... then it breaks horribly.
Can you elaborate on what you're referring to? I can see performance becoming a problem if you repeatedly chain non-optimisable (in bytecode) as excluding the in place operations I believe all ops re-allocate the collection.
Just use `.iterator` before chaining and the final collection will only be allocated once.
Ignore that person they don’t know what they’re talking about lol
Answer: some PL prof used to do a lot of java back in his day
Disk partitioning labels: GPT, MBR, SUN, or BSD.
[dead]