> Another common request is to “stop implementing features”.
Yes, it's a very common one shared by virtually all Scala 3 developers. Stop. At least for a couple of years.
Tooling and the community just can't keep up and the language is very good already that the focus should be on the ecosystem and not language.
But Scala devs are beyond deaf and that's what you get when a programming language is an ongoing research project on which many students and professors depend.
It's not enough to say "if we stop developing new features the language will die" when there's 0 evidence by it and a huge fatigue towards the relentless development coming from most of the community.
The tooling is IMO one of the leading causes of why the language has had a collapse in developer mind-share.
If we want to say it really doesn't matter what language we choose, because any solution can be cooked up regardless, it absolutely matters then what the tools around that language bring to the table.
Language geeks want language geeking, what Scala users want is a "faster horse". (Faster compiler, nicer project/package manager [sorry sbt], incremental compiler, LSP-compatible compiler, and so on. All good and nice and completely valid and important things!)
Unfortunately usually corporate backers can deliver these things not language researchers.
There's no need for the tooling and community to keep up. If Scala 2.12 is so good for the community stick with it.
The obvious problem is that Scala 3 delivers features (and whatever Odersky et al. cooks up will likely be useful for a lot of Scala users) that incentivizes attention fragmentation.
Yes, it's true that the community cannot keep up. (Yet the community is not a hivemind, it was able to churn out so many effect libs over the years I lost count.)
But it's an unforced error to put this responsibility on the researchers.
This is a fair characterization. Unfortunately Scala's corporate backing is weak compared to something like Java. So the people in the best position to give us a faster horse are in fact these researchers. :(
That might be so, and it's okay to kindly tell them that, but to me it seems the community is pretty abusive regarding the researchers sometimes. (Well, and ... in general, Scala drama was not unheard of over the years, powerful languages tend to attract people with their powerful vision. And of course said researchers' people skills tend to show some room for improvement from time to time.)
Anyway, squeezing water from stone might be easier than persuading certain folks :)
> > Another common request is to “stop implementing features”.
> Yes, it's a very common one shared by virtually all Scala 3 developers. Stop. At least for a couple of years.
I, for one, think Capture Catching can't arrive soon enough. It will allow us to write much simpler programs, getting an edge over modern Java & co. I'm very much looking forward to it.
Don't use experimental Scala features in production code. They may change or be removed. And they will likely lack support in IDEs. But that is a common sense.
1. Rust has had 10x better tooling right from the start. Cargo vs SBT, no joke.
2. Rust has improved its compiler performance by >3x in the last 5 years.
3. Rust hasn't gotten any major new language feature in the last 6 years. Most language improvement is improving orthogonality of existing features.
4. Rust has an excellent backwards compatibility story also right from the start. Code/libraries written in 2015 can be still compiled and used together with code from 2025.
5. Rust has a serious backing from all major IDE / editor providers.
6. Rust has integrates easily with other languages and ecosystems. It's easier to call Rust from Python than to call Scala from Python. It's easier and more performant to call C from Rust than to call C from Scala. Things like that. It's sad that Scala even struggled with interoperability with Java; which should theoretically be easy as it is the same platform.
Seriously, doesn't look to me like the same mistakes.
It's actually quite opposite.
> Rust hasn't gotten any major new language feature in the last 6 years. Most language improvement is improving orthogonality of existing features.
Rust also ships with a functioning epoch/edition system that makes it feasible to rework existing language features for improved generality, elegance etc. without losing backward compatibility. I'm not sure if Scala has anything like that.
Also, the nightly/stable split in Rust means that most new features don't reach the final adoption stage unless there's a very real consensus about their design. A lot of effort is made to get rid of incidental complexity wherever feasible, before the new features are actually stabilized.
Most language implementations that "haven't gotten any major new language feature in the last 6 years" would be described as broadly stagnant or stale, but Rust is quite different.
>Rust has had 10x better tooling right from the start. Cargo vs SBT, no joke.
Cargo is a really good tool, but I wouldn't say it is 10x better than SBT.On the other hand, Scala can be used with different build tools: Maven, Gradle, Mill. With Rust you have no choice(or I'm not aware of).
Rust-analyzer is better than metals, can't argue with that...
>Rust has improved its compiler performance by >3x in the last 5 years
Rust compiler is very slow. I can't imagine what compilation time was 5 years ago, but even now, it is incredibly slow, even compared to "slow" Scala compiler(which is no longer true). I'm working on a little project with bevy, and even on such small project compilation time sucks. You can't compare it with Scala, it's just completely different experience.
>Rust hasn't gotten any major new language feature in the last 6 years.
That's not true. Rust team handles these changes correctly. Rust has concept of "Editions", and every 3 years new edition introduces significant changes. I really like how editions work, it's a great way to maintain backwards compat.
>4 Mostly agree
>5 Fully agree
>It's easier and more performant to call C from Rust than to call C from Scala.
Yep, but it's not Scala but the JVM limitation. JNI sucks, but there is an effort to improve that (project Panama).
Overall, both Scala and Rust are great languages. Rust team has addressed many typical issues from the beginning. Scala had its mistakes, but moving in the right direction.
There is no sha-256 in the C or C++ standard library either. A cryptographic hashing algorithm like sha-256 is not something that necessarily has to be in a standard library.
There's plenty of old modules in the Python standard library that hardly any one uses. But removing them would break backwards compatibility guarantees. The Rust project has decided that they want to keep the standard library lean. And this works well in practise, because cargo is a really good package manager.
It is minimalist because it has to support many platforms and must be lightweight and easy to port. It also must be stable for a long time. Once something lands in the standard library, it is very hard to remove / modify / redesign. How many half-broken date time implementations Java ended up with?
But it makes up for the minimalist stdlib by making it a breeze to use third-party libraries.
Care to elaborate on which changes do you consider a mistake?
---------
To me the goals are sensible the flagship goals (for 2025H1 for example [1]) are all about DX and focus on downstream devs and their needs (all hands, Rust in the kernel).
The usual problem of "compile times" [2] (usually link times and LLVM throughput and so on) are things that are being worked on, but fundamentally they all can only be solved by caching, incremental compilation, and better developer tooling that are not language problems.
Yet it's Go that added big language features recently (generics, iterators, changing semantics of for loop) and not Rust. Rust hasn't gotten any new major features since adding async ~7 years ago. Rust is much more stable language-wise than Go, partly because it had much more features in 1.0, and Go has to gradually add them (what's next? enums?). It also has much more advanced mechanisms allowing to both evolve the language and not break existing code (editions). Things that neither Go nor Scala figured out yet.
Go has proven that people want cheap threads. If it didn't have it, it wouldn't get anywhere.
Now even Java has cheap threads (Loom).
And Go even has generics. Just 20-ish years later than Java. And it's likely that more features that now Java has will trickle into Go. If Go wants to survive.
All this to say that there is no space in the market for another language which is a stupid simple Algol. Go already occupies that space. And even Go will have to add features developers want/need, if it doesn't want to get cornered out of the market.
Go has proven that we still need the backing of large corporations for success in the tech world despite the fact that open-source powers most major tech companies today
- I want sbt+scalatest (the blessed build tool/test framework) to not leak memory constantly (https://olegych.github.io/blog/sbt-fork.html this is an issue I specifically run into)
- I want useful documentation when I ctrlclick into settingKeys in build.sbt
- I want Intellij to not bug out when you pass explicitly the implicit arguments required by a function that uses both context bounds and implicits
- I want intellij to always agree with the scala compiler
Scala has been very enjoyable and productive for me and the teams I've worked on. The first couple years of v2 -> v3 transition were a bit rough as the tooling and ecosystem was catching up, but now we happily use Scala 3 with no looking back. The language and ecosystem are evolving in a good direction, and I'm happy to play a small part in that with my open source libraries for Scala.js (which is the entire reason I got into Scala in the first place – so much simpler and safer than Typescript).
Scala is perhaps not going to replace Java in every old enterprise, but in my personal experience working for startups, it's been an awesome force multiplier for small teams who need to productively pump out safe and ergonomic code. Finance, health systems, etc. And yet it's also ergonomic and pleasant enough for me to eagerly use it in my non-mission-critical personal projects as well.
> it's been an awesome force multiplier for small teams who need to productively pump out safe and ergonomic code.
How much of this would be due to actual language features, and how much due to selection bias induced by talented and ambitious software developers looking into functional programming languages as a means to satisfy their intellectual appetite?
I've worked both at a startup that used functional programming libraries pretty heavily, and a startup that is using as plain of a Scala as you can imagine (no cats / zios / kyos / etc. in sight), and both benefited greatly from Scala language itself. The rich, safe and sound type system, combined with ergonomic syntax and well thought out features make it very easy to both read and write code – and most importantly – to make massive changes with very high confidence – which is an absolute necessity in a fast moving startup where the business requirements evolve all the time, features are shipped urgently with some tech debt that needs to be effectively addressed later, etc.
In terms of talent there is definitely some self-selection as with any non-default tech stack. Scala is a sharp tool and there are both people who are attracted to it for the pragmatic utility of its sharpness, and people who are attracted to it for wanting to play with sharp things. Both types are smart but the latter group have given Scala a bad rep in the past for being too smart and thus writing code that was too clever for others to understand. But nowadays the general vibe in the talent pool is a lot more pragmatic.
> I've worked both at a startup that used functional programming libraries pretty heavily, and a startup that is using as plain of a Scala as you can imagine (no cats / zios / kyos / etc. in sight), and both benefited greatly from Scala language itself.
Wouldn't you want to use Kotlin for the latter these days? It seems to have broadly wider adoption than any "plain" variety of Scala.
I don't know, kotlin has its pros, and is absolutely here to stay due to Android alone, but I always felt it being more or less just syntactic sugar for Java 8, to the point that now even Java has some more advanced/elegant features, like proper pattern matching with algebraic data types, while Kotlin is stuck with dumb sugar for instanceof checks.
Scala was always much more elegant and actually going the extra mile.
Kotlin's adoption is not that much bigger than Scala, and it's no good to me, as it's heavily concentrated in the Android world, which is irrelevant to me. Among other things, that means that Kotlin.js is not as good as Scala.js, both itself and in terms of the ecosystem – and the quality of Scala.js is half the reason I'm using Scala in the first place.
Kotlin as a language is also closer to Java on the Haskell <---> Scala <---> Java spectrum. We just don't want to move in either direction on that spectrum, Scala sits perfectly where it makes sense to us.
It's interesting that some people here are saying that Java's recent improvements will eat into Scala's market, when actually, it seems that it will eat into Kotlin first.
I've had a (relatively) bad time with Scala codebases. The last one I was involved in was like a 6-minute wait between making a code-change and being able to run or test it. But I still wanna work with Scala devs.
I'd rather work with Scala devs on a Java codebase than Java devs on a Scala codebase.
It's not about intellectual appetite though. It's about not re-litigating the same crap at every new work place. Avoid mutability and nulls where possible, etc.
The problem is that it is easy to write code that is not easy to read/understand afterwards. Especially if the code has a lot of operator soup and implicits.
Do people still do that? I thought that the whole "you can just google goobedygook" meme died already! ZIO for this reason has sane normal proper names for things for example.
Scala is not just a good functional programming language. It's also possibly the best OOP language around. The magic happens when these two aspects are combined.
This has been my personal discovery as well. I inherited a bunch of old Scala code and, having had no experience with Scala, it took a while to get up to speed.
We built full stack web applications: Scala on the JVM on the backend, and Scala.js on the frontend. For the frontend, used React.js (via Scala.js bindings) at one company, and my own Scala.js UI library Laminar at another. Mobile was implemented as a responsive web app. I've read that you can even use React Native from Scala.js, but we haven't needed that, so I haven't tried. The older React.js bindings were somewhat cumbersome, but the newer ones (slinky.dev) were great. The rest worked very well.
Working in a single language across frontend and backend is amazing, especially when the language is so nice. Sharing models, codecs, validations, etc. And again – all of that in a very friendly language. Scala's expressive yet safe type system is very good at describing the business domain, encoding constraints, etc.
The only weakness of Scala.js I would say is it takes a bit more effort to integrate with JS libs. The mechanism is the same as with Typescript – just need the type definitions, but in practice it needs a bit of manual work. It's not a big deal though because with Scala.js you don't really do the 200-npm-dependencies thing that so many JS projects are cursed with. Lots of stuff comes with the language or from nice Scala libraries, including immutable data structures, powerful collections, validations, state management, etc.
Scala has somewhat of a reputation for being complex, but the language itself is ecstatic in its simplicity and elegance. The problem historically lied in certain functional programming libraries that require a certain formal / academic mindset to work with. They did become more ergonomic and better documented with time, but those are still very advanced concepts for most devs. I did work with such a codebase, and I have to admit it was not the easiest. But that was before AI – nowadays it's a lot easier for me to figure out these things. But I don't need to, at my current job we don't use them. So I would advise to learn Scala the language before going off the deep end into hardcore FP libraries. That's a completely optional destination that you don't need to force onto yourself if that kind of style doesn't jive with you.
Speaking of AI, I've been asking both ChatGPT and more recently Claude about Scala 3 and about functional programming libraries, and they're pretty good. I don't "vibe code" so don't know about that, just asking for code snippets or for explanations.
I think a lot of criticism of Scala comes from the functional paradigm. More specifically it’s trying to be a mainstream language when the concepts it represents are not quite mainstream concepts for most software. The language designers, in an attempt to make it more mainstream, allow devs to use Scala in the more mainstream way (object oriented). This flexibility, ultimately, perhaps strangely, appears to hurt its adoption because of the learning curve of dealing with a language that mixes the two concepts.
Also for me, subjectively, it honestly feels too abstract at times. You can almost feel the academic joy of the beautiful, unintelligible concepts where you can express things so succinctly, but requires a small mountain of concepts to understand how to write that nice code. It’s quite frustrating to do battle with the compiler when you don’t fully understand the type system and that initial hurdle is kind of tough to get over if you’re also trying to switch into a functional paradigm from an objected oriented one.
The problem with overly abstract concepts is a problem of specific Scala functional programming libraries, and not of the Scala language itself, or of other, simpler Scala libraries (e.g. com-lihaoyi stuff, Play, my own Laminar on the frontend, etc.)
If you need to know category theory concepts like Monad / Semigroup / etc. in order to understand your code, you're not doing regular Scala, you're doing Haskell-style FP in Scala. Which is a popular choice that many people swear by, but is entirely optional. Personally I don't think the complexity of that approach is worth it, and we don't use any of that stuff at work, and still reap the benefits of Scala.
Scala is a true multi-paradigm language, it does not have a monoculture. Lots of people who use Scala don't use highly abstract FP libraries. I very much don't think that the OOP side of Scala is the language designers' concession for the sake of broad appeal. Seamless fusion of FP and OOP is the essence of Scala, and it works great for that without any third party libraries. The designers' attitude is evidenced by the libraries created by their companies (e.g. Play, Akka) and by the learning materials, both of which lean heavily on plain Scala without going off the deep end with FP libs.
> If you need to know category theory concepts like Monad / Semigroup / etc. in order to understand your code, you're not doing regular Scala, you're doing Haskell-style FP in Scala
FWIW, "Semigroup" is not a "Haskell concept" either. Equally, it's a facet of specific Haskell functional programming libraries, and not Haskell itself. Granted, Monad is baked into the language (as do notation).
> I think a lot of criticism of Scala comes from the functional paradigm.
Which functional paradigm. There are at least two in common usage in the Scala community. Odersky's vision was an ML style FP. And now ML patterns are common in modern PLs.
Java will never "catch up" to Scala (for example, the type system / generics will not evolve in the foreseeable future).
But once Valhalla lands, with some additional JEPs, Java will be very close to the core of what Scala offers. Where there are gaps, some of these can be filled via libraries (think immutables.org, or others providing persistent data structures).
As a matter of fact, these days at most companies that I see the typical deployment model is "micro"services, which you can quickly develop via Spring Boot or the alternatives. No need for ultra complex code or asbtractions, Java does it just fine. And you have all the tooling you need for the enterprise world.
I think Scala is an excellent language for teaching ML-style programming. I would still recommend it for that purpose. But there is no longer a killer app or need for Scala, that would convince most people to use it for new projects.
Just like Scala by virtue of being a guest language on the JVM ecosystem, never will replace Java on the minds of JVM architects.
Kotlin has an advantage here, because ART nowadays is effectly KVM from Google's point of view, where they grudgingly update Java support to keep up with Maven central.
Scala has nothing like this, and the update on Python alongside native libraries, kind of stole its demand in big data, hence why this kind of scenarios is described on the article.
They're not in the same playground. Scala has a far more advanced type system - more close in power to Typescript or Rust than Java - and capabilities like compile time metaprogramming which aren't on the Java roadmap. Or more mundane things like immutable collections or a copy method for "record" classes.
Whether that's an advantage in day to day business development is a different question.
Yes, Java has been getting a lot of features Scala has had since (more or less) always. But it's a continuing process, and not all such features are yet fully fleshed out and polished in Java.
Also, Java will probably never get many of important features Scala has (or will have). It may not be some esoteric things, like higher-kinded types. But things like meta-programming/macros. Or features which may be advanced from theoretical point of view, but are actually easy from user point of view (because they lead to a simpler code), like Capture Catching.
If capabilities (Capture Catching) proves to be very useful (and really solves the problems it claims to be able to solve) then it's likely that Java will also implement it, no? So... in about 8-15 years?
I doubt it. For Capture Catching of Capabilities to work, you need some of the unique sauce practically only Scala has. E.g. Contextual functions or path-dependent types. Java almost certainly won't adopt these.
Back in the days using Java was mind-numbing boring and boilerplate-galore. Scala offered vastly more productivity and fun. These days Java is... fine. Scala is still amazing but Java doesn't cause active pain anymore. It becomes harder to justify using a niche language.
Scala will still live. It is an amazing language with a great combination of functional and OO programming. I just don't see a big breakthrough in popularity.
Java has certainly improved. Kudos to its stewards.
But I think it still has many rough edges -- things that are awkward (or outright impossible) to do in Java and Scala is great. It doesn't have to be advanced features, like meta-programmig/macros. Here are some example that I think are not anything esoteric:
* Just the mere fact that Scala has immutable/persistent collections improves how and what programs people write.
* Scala also has good infrastructure to deal with "modifying" data model graphs in a persistent/immutable way. Think deeply nested case classes and sealed traits. You have the copy method, lens libraries, etc. Java does have records and sealed interfaces, but all the rest of the machinery to work with them is still missing.
* To generalize the points above, Scala is immutable-first language, with all the positives that come with it. Java, still not so much (even though they are moving in that direction, e.g. `record`s).
* Another weird thing in Java is how it deals with variance. In Scala, I find it easy to comprehend, in comparison.
* Scala is expression oriented. Ifs, trys, etc -- all of them are expression. You can bound the result of these expressions to a variable. Not the case in Java, which makes it annoying to work with. You have to fist make the variable null or something and then make sure it gets assigned within of the body of the if/try/... Just a bad experience :(
Than there is a matter of culture:
* Java libraries like to return (and expect to be passed) a `null`. Scala culture embraces `Option` from its standard library.
* While Java does have support for checked exceptions, which I think is a very good idea in theory, in practice its implementation is underwhelming (e.g. not possible to abstract over) and so libraries don't use it as much. With Scala you can return an `Either`. Or with new Scala 3, we may soon have powerful capability system to, among others, allow throwing "checked" exceptions. That's the Capture Checking https://docs.scala-lang.org/scala3/reference/experimental/cc... research.
* This may be even more personal opinion that others, but I find Java libraries more difficult to use that Scala ones. With Scala, you just follow the types and you create and work with the objects that the library gives you in an intuitive way. With Java, the types don't help you as much. You have to read the documentation thoroughly, to make sure you're calling the right methods on the right objects, in the right order. Because the types don't help you, you can't be sure you doing it correctly, because every other way compiles too.
Kotlin may be more popular, but not much. It's nowhere near the mainstream languages like Java, Python, JavaScript, C# or PHP. Not even close to TypeScript.
Kotlin's popularity plummets once you leave out android development, though. Same with Obj-c/Swift for Mac/iOS development.
5-8 years ago Scala had a large boost in data science/big data work as it was either it or Python for a lot of frameworks like Spark. We used Scala because we wanted static typing and threading (among other things) for our workloads.
Huh, fair enough. Maybe my spheres are much more Kotlin-focused and I was projecting too much.
That said, probably "number of Github projects" and/or "number of StackOverflow tags" doesn't encapsulate the sheer amount of code written in Kotlin for Android apps, which is where my head was probably at.
Java has now pattern matching, ADTs, case classes, even lazy vals are coming ("Stable values" previewed in JDK 25). Java is still much more verbose than Scala, but if you use it considerately, it looks more and more like an ML-like language, and not an imperative one.
"if" not being an expression is my main personal pain point for the time being. It would make simple code so much more readable.
Great post. There is no need to hide the fact that Scala is not the most popular language or that it ever will be.
And Kudos to VirtusLabs for maintenance.
Huge Kudos to Daniel for his courses. If you think Scala is difficult, check his course, these will change your mind.
When building Wide Angle Analytics backend I chose Scala. Sometimes I miss the convenience of Spring Boot of having all integrations at the fingertips. But then I implement same thing in Scala and it is much leaner, boils down to couple of functions and it just fits nicely.
My only personal pet peeve with Scala is painful upgrade path between libraries (Cats 2 -> Cats 3). Oh well.
I wonder to what extent the use of Scala at an organization is a "red flag". No disrespect to the language. I've used it a couple times and if you're all in on FP then it's probably the way to go.
But say you're interviewing for a job - what does it say about an organization if they've picked a somewhat obscure, academic tool to build their product? They are probably exceedingly clever, but are you in for long technical debates about arcane minutiae? Are they stubborn and uncompromising? Do they make impractical technical decisions?
You can ask them a single question to know the answer: do they have any cats/scalaz in their production code? Without their ilk Scala 10 years ago was the language Kotlin and Java are still trying to be.
But from what I have observed in the last few years Scala is either used in legacy projects or you're talking to a hard-core FP shop. The saddest fact that it's true even in Data Engineering with Spark :(
We eventually migrated the vast majority of our Scala code over to Kotlin (and a bit of PySpark).
I found Kotlin to be great for writing very performant concurrent code. It was actually easier to write faster code in Kotlin, and even though the pattern matching isn't quite as powerful, it was good enough. The code was also much easier to grok.
> I've used it a couple times and if you're all in on FP then it's probably the way to go.
It's a hybrid paradigm language and back when I used it (v2), it was perfectly possible -- and common -- to write code without using more FP idioms than is now common in most languages, Javascript, Python and Java included. A lot of people used Scala as "a better Java" back then.
I don't know what's the situation with Scala 3 nowadays, but judging from TFA it remains a hybrid language.
It is also important to keep in mind that there are two very different styles of FP one sees with Scala. Odersky et al envisioned ML on the JVM. And there is also a strong population of Haskell style FP.
Probably just means the decision to use Scala was taken back when it looked like it could really be the next big thing. These days it's clear that Scala has lost all momentum. Scala 3 was an attempt to fix that by appealing to Pythonistas, but I doubt it'll work. It may stick around as the Spark language, but it's hard to believe in a bright future for it.
If an employer uses Scalaz or Cats, on the other hand, run for the hills.
An experienced Scala programmer told me that something he's found important is to restrict a Scala codebase to only some subset of Scala features (or approaches). That's because in Scala you have an extreme variety of ways you can tackle most problems, and everyone has a different favorite way, thus, if that is left unchecked, the codebase can quickly become a zoo of many many different language features and techniques. I think of Go as the opposite, for example.
I can see how that can be a real challenge, but I, for one, am excited by this aspect of Scala more than any other.
- Apache Spark picked Scala in 2014 as a language with lambdas and pattern matching on the JVM.
- Akka picked Scala because it was a concise, performant language with support for lightweight concurrency with Futures or Actors.
- Scalaz and Cats picked Scala as a concise language with a rich type system.
This chronological list perfectly captures how its mental share has shrunk over time...
True, but also worth pointing out that Akka kind of footgunned themselves by trying a too-obvious moneygrab - not just all Scala’s fault there. Although it is also worth pointing out that Lightbend is Odersky’s company so maybe it is kind of Scala’s fault here
Scala is hands down the most wonderful language I have ever worked with. Some simple paradigms it offers e.g. case matching has changed the way I see and write code in every other language.
Would the kotlin equivalent just be:
val dateRegex = Regex("""(\d{4})-(\d{2})-(\d{2})""")
val (year, _, _) = dateRegex.matchEntire("2004-01-20")!!.destructured
println("$year was a good year for PLs.")
?
The Scala snippet works for all inputs, it's something you would see on a real codebase. It also scopes the regex captures within the match expression. The code also scales better for more complex cases where a string is tested against multiple regexes, or against specific captured values.
I assume this Kotlin snippet would, at minimum, need to do null-checking on "matchEntire" before it finds its way to a production codebase.
This is my problem with Scala. Too many fancy things hidden behind text with no meaning. Why the hell is this ‘r’ instead of something with a name that has meaning like toRegex?
It's a convenience method for a specific case where the result is already obvious, because it's called on a string literal that already looks like a regex. Any competent Scala dev reviewer would reject code that uses the "r" method on a variable.
If you want a more verbose option, you can import the Regex type and write:
val date = Regex(raw"(\d{4})-(\d{2})-(\d{2})")
And of course, explicit type declarations can further document the code.
Scala was the first language I learned to program in. I technically started with Java and some Javascript, but I hardly knew what I was doing. Scala accelerated my learning via better expressiveness, better abstractions for iteration, and for asynchrony. It thought me a lot of valuable lessons, and I miss it.
Sadly, I just don't find a spot for Scala in my toolkit these days: it's either Python for the numpy-et-al ecosystem, Clojurescript for frontend, Rust for portability, and something frontend-ish (probably just Javascript) for serverless backends. The long-lived JVM just doesn't have a place.
And if you want both frontend and portability everywhere, Scala will soon have a support for compiling to WASM (with WASI, etc) https://github.com/scala-wasm/scala-wasm/ (to be integrated into Scala.js after developed)
> And if you want portability, you can compile a Scala program with GraalVM's native-image and statically link everything with musl libc
Getting the musl stuff to work can be tricky, mostly-static (only libc dynamically linked) is an easier option.
I've built a CLI diagnostics app with Scala & NativeImage and I've embedded the Graal Python interpreter inside it to allow extension scripts to be written. The result is a zero-install executable that provides an n entire Python environment. I think that's a good showcase for one of Scala's strengths, it's interoperability with the Java ecosystem.
> If anyone care to share their experience with GraalVM's native-image, I'd be interested in hearing that.
The main issue is if you are using reflection, which needs metadata adding to describe it so the necessary metadata is included in the image. Some libraries already have it built in, and there are tools to help.
My main complaint is the poor IDE support. Shapeless breaks everything so casually.
> We acknowledge that there is still work to do. The IntelliJ team is working hard on bringing the best support for Scala 3, and you can expect more improvements in the following months.
Good to hear. I thought Jetbrains had completely abandoned Scala for Kotlin, so I'm glad they're still willing to support Scala.
Thank goodness that Shapeless is not needed in Scala 3. The good parts have been integrated into the language itself and so it's reliable and faster.
> Jetbrains had completely abandoned Scala
Thankfully not at all. Gets regular releases, Scala 3 support is improving with each. They're also welcoming to PRs, if you have spotted a bug that needs fixing. (The codebase of the Scala plugin is in Scala, so that makes it easy for the community to contribute.)
My company still sticks to Scala2 so I may be misinformed, but I heard Scala3 tuples cannot completely replace Shapeless, like missing LabelledGeneric equivalent?
I liked Scala and was excited about learning and using it when it was picking up steam many years back. Unfortunately, it felt like there wasn't as much traction, and Scala has been siloed into some niche domains like Spark. It's a bummer since it's so nice to write with.
I think Scala had a big momentum 10 to 5 years ago. Many people were choosing Scala for new apps and many were rewriting existing apps in Scala. But something happened, Scala lost its momentum and nobody is interested in Scala anymore.
All these languages may work very well for many people for the described use cases.
But one of Scala's strength is versatility. You could use it quite well for all the listed use cases too. With just one language. (Maybe with the exception of system programming -- Scala Native still requires a tracing GC.)
Also, it's worth noting that Scala is more popular/mainstream/supported/has bigger community than Julia, Zig and Elixir / gleam. And if Red Monk is to be trusted, even more than Rust
https://redmonk.com/sogrady/2024/09/12/language-rankings-6-2... That comes with many benefits.
> if you don’t need JVM / Java interop
OpenJDK is also very good, even if it's not a strict requirement to use it. Battle-tested, easily debugable, etc... AOT compilation is possible via GaalVM's native-image.
Or you can try Scala.js or Scala Native (which don't have anything to do with JVM).
>All these languages may work very well for many people for the described use cases.
But one of Scala's strength is versatility. You could use it quite well for all the listed use cases too.
I think that the jack of all trades space is already occupied by C#.
There was a brief moment when Scala seemed like the new Holy Grail. Gawker (the big 2004-2016 online tabloid/blog media group, before FB and Instagram/TikTok fueled by recommendation systems ate everything) transitioned from PHP to Scala!
Scala meetups were full with newcomers! Hadoop and Spark and Big Data[TM] was the thing! Distributed systems, were all the rage! Everyone and their dog was waiting patiently for the next HighScalability post about something even more crazier and bigger than before. People were writing homage posts to The Log post. Kafka was the thing you had to have in your system for it to be worth the napkin it was sketched on! Netflix and Twitter were talking about microservices and releasing all the amazing libraries to handle the load! (Circuit breakers, service discovery, etc.)
And then.
...
AWS and k8s and Go (and later Rust) and just an ungodly amount of hardware and deep learning progress happened.
People slowly realized that the JVM and Hadoop is a mess. (Ultra-low latency GCs like Shenandoah arrived too late.) That kind of Big Data is actually just irrelevant unfiltered shit (and implicit feedback is all you need for recommendation systems) and slowly but surely people started to move to S3 from Hadoop (and in general into the cloud).
And scientists - bless their little non-programmer hearts - did their best and moved from R ... to Python. (And there was already a ton of bindings to low-level linear algebra and tensor libs in Python, and calling into C/C++ was standard from Python - Cython is great - even if technically it's exactly as easy from Scala/JVM.
...
Fundamentally the lack of corporate sponsorship and the main contributors' lack of DX obsession led to the natural consequence of the industry leaving that Scala behind.
(Even though both Rust and Scala are research-heavy just compare how much attention Rust as a project spent on improving DX, including backward compatibility, trying very very hard to avoid py2-3 and scala2.11-2.12-2.13 upgrade speed bumps, and so on.)
I used Scala about a decade ago extensively and I’m still waiting for features I loved in it to be available in languages I have to use on a daily basis now.
* Immutable/persistent collections in standard library
* Machinery to "modify" immutable deeply nested case classes/sealed traits. You have the copy method, you have lens libraries. Very easy and comfortable to use.
* Expression oriented. if/try/etc expression can be bound to a variable
* less characters to write the same idea/program, while not losing readability
* better tooling: Scalafmt is ubiquitously used, supported in IntelliJ and is very good. Scalafix (a linter which can also fix some issues automatically) is used a little bit less, but is also good.
* build tools: while I don't like sbt, Mill is a so much better build tool than Maven or, even worse, Gradle. Then there is also scala-cli, which is not a build tool, but can work like it, if you have a simple, single-module project (i.e. no sub-projects/sub-modules).
Thank you, this captures most of these. I’d also add the excellent libraries from Twitter like Algebird and ability to do a lot of data processing with types at scale using Spark.
For me, the killer features were the metaprogramming abilities (both type and macro based). Not so much because I used them directly but because they allowed library authors to create extremely expressive libraries.
i like scala and have used it as my primary language for the majority of my career.
It is waning as other languages catch up, but to some extent perhaps having the self styled elitists move on to rust will mean that a more pragmatic and less dramatic user base is left behind and the intellectual one upmanship that has made scala toxic can find a home somewhere else.
If I was starting out today I'd lean more towards python, typescript and go depending on use case. (I still think rust is over engineered, over used and over prescribed with very few people getting paid to write it)
Anyway I am hoping it turns into somewhat of a COBOL where I can charge outlandish rates for fixing banks technical debt issues.
Good positive direction for Scala. I have written a lot of Scala and made my living almost 100% from it for 7 years.
However, three major head winds pushed me away from commercial use:
1. Culture war. The so called culture war came for the Scala community in a bug way. Cancellations and constant arguments threw out a lot of noise and put outsiders off. Employers, technical and community leaders had to put political concerns ahead of technical ones. Ultimately the community split and became silo’d.
2. Lightbend licensing. Not to blame Lightbend for wanting to have a commercial license for Akka but for many the retroactive commercialization was untenable. Akka is a great library for distributed computation and has many use cases so this caused more uncertainty for companies using it.
3. Scala 3. A consistent theme of Scala being part research, part production language means trade offs. The language ecosystem causes non stop maintenance of libraries. Personally I love the rapid pace of new features at language level but for library maintainers and companies it is too fast.
None of these issues should kill the language and I think it still has a potentially bright future.
That's not a big offense to Scala, honestly. It's easy to be worse than Rust.
Rustc in my experience is an extremely well optimized compiler, only second to Go. It beats pure Java with Maven / Gradle as well. It gets bad reputation because Rust projects are compiled fully from source, so Rustc has usually like 100x more code to compile than in languages which use binary dependencies.
fclones is ~500k LOC gross with all dependencies.
Takes 9 seconds to cold compile with linking on my machine.
I haven't used Scala for a while but last time we used it (Scala 2.12 + gradle) the compile times were just abysmal. A project containing just about 20k lines of Scala + some Java took over 5 minutes to build, and incremental compilation didn't work at all (probably due to Gradle not understanding Scala dependencies).
According to this, javac itself can compile up to 100k lines per second, while Maven/Gradle is an order of magnitude slower.
The only info I found for Rust mentions something along the 5k lines/second mark (on a different computer), but it is at most roughly the same, if not slower than a java build tool.
If pure javac can also do 100k LOC/s (which is definitely something I believe is possible) but then "Maven/Gradle is an order of magnitude slower" then my point stands. No-one uses pure javac to compile big projects.
There’s another reason for the decline of Scala - much less people are writing Spark code in Scala. At peak I think Spark accounted for a large portion of Scala’s growth
this is a good thing for scala actually, a lot of people have said 'wow scala is horrible' and later i find out they were doing black magic spark codebases
It takes a lot of humility to admit that the language just isn't as popular as it once was anymore, so kudos for that. The turn towards making the language more approachable to beginners is an interesting one for Scala, and I think it could have a positive impact on the language.
Between Java and Python getting better year by year and the uptick of Go, Rust, Kotlin, and Swift, at this point in 2025, Scala is pretty much dead, right?
> Heavy use of symbolic operators has thankfully fallen out of style.
I assume this refers to operator overloading.
I think `a + b - c` looks way more readable than `a.add(b).sub(c)` and I'm happy when a language lets me define my own operators for vectors/matrices but I also have a side-curiosity: do they ever have a good use case outside of a math context? I never heard anyone praise `<<` `>>` in C++ for ex.
The majority of code is not math. I prefer if languages have a math dsl, only in which, the math operators become available.
I actually do like symbols as opposed to words (+ instead of append, : instead of as, < instead of extends, -> instead of function etc). They just need to have stable meaning, which conflicts with operator overloading/math.
I was half way through a project when the licensing change happened, I had to abandon Akka as a result. Fortunately my requirements for an Actor System are low-end, basically just message passing in a multithreaded single process, so I wrote my own simple Actor system library. Scala made that relatively easy.
It became less popular a long time ago as the hype of actors as a programming paradigm died down, and then eventually akka adopted non-OSS BSL license which made many users including us switch to Pekko (a community fork) which is still developed and maintained, but again, this branch of Scala evolution is quite past its prime. Scala offers more and arguably better libraries for working with concurrency now, and even cooler stuff is on the horizon with kyo / ox / caprese.
I have been working on adding Pekko-based data pipeline into my side project, and it's an incredibly powerful system. The "bare" actors are rarely used. With streams, you can control parallelism, backpressure, add batching, retries, and so on. This is why this is so popular with systems ingesting massive amounts of data - log processing, IoT telemetry.
Which libraries are you referring to that do the same? Just curious.
I meant FP libraries like Cats Effect / FS2 / ZIO et al. – they don't really do the things that Akka / Pekko is very good at, such as multi-machine parallelism, but the conventional wisdom nowadays seems to be that it's easier to start with those libraries and progress to Pekko if you ever need that, rather than architect the system with Pekko from the start when you don't need its power.
I don't know if I personally agree with that, I've had a better experience with Akka (even raw actors) than with FP libraries, but what I mentioned is definitely the general vibe in the publicly active part of the community that's I'm observing. We gotta keep in mind that there are lots of companies and devs that never talk about what they're doing in public, so of course my perception is biased by that.
My own expertise is shifting more and more to the frontend / Scala.js these days, so please forgive/correct any inaccuracies.
The assumption that Cats Effect / FS2 / ZIO is easier than Akka / Pekko is questionable. There's the assumption that the Akka ecosystem requires the entire system to be built using the various features the ecosystem offers, when in reality it easily scales down to simple microservices just as well, if that's the only option or the overall preference.
One reason to reach for the pure functional libraries is a desire to avoid some of the many footguns Akka / Pekko has. For a long time, using Akka meant not being able to rely on the Scala type system for checking messages sent between actors, and for the people attracted to Scala due to the advanced type system, this was a deal-breaking drawback.
All in all, the FP libraries and the actor system libraries are almost direct opposite approaches to problem solving.
Well, Akka/Pekko is typed now. There is a learning curve to Akka, but it took me 3-4 weeks to get my system working. I can't imagine doing it with pure FP, it would break my brains.
As someone said - these are very cool but niche capabilities that companies do not talk about. It's almost like a secret weapon in the sea of over-engineering and hype.
Scala is an amazing language that I've been using professionally for a decade. But it has three major problems:
1) The language is too unstable - something that might seems as a great boon is actually a big problem if you want to use the language for greater periods of time.
2) The tooling around it is not the best - problem with syntax support in IDEs, sbt is still a mess. Compared to modern offerings like Rust or Go it doesn't look that great.
3) Competition is quickly catching up - this isn't 2010-2015, Scala's competitors have been evolving quickly and picking up a lot of FP features (pattern matching HOFs, etc.) that made it stand out but at the same time offering a much bigger developer base, more mature frameworks, etc.
A great example of this is modern Java but also Kotlin. Scala is still great but the gap isn't as big as it was a decade ago when Scala's popularity peaked.
And of course it is still hard to find and recruit competent people, especially if you go FP-heavy using Cats/ZIO and not Java+ style. Guess that's why we see less and less new projects written in it (and most of those probably are Spark) and in many companies it's becoming a legacy language waiting for a rewrite to e.g. Java.
"Scala will continue to evolve until morale improves"
Thankfully not anymore. They got their act together and have been maintaining compatibility since Scala 3.0.0 has been released in May 2021, which is almost 4 years and counting.
In my opinion the tooling like sbt, scalafmt, ... is actually semi decent, but the LSP is a pain to use.
The only way I'm productive on scala is on Intellij, as soon as I have to even glance at the metals LSP implementation my productivity skydives
This is compounded by the fact that most good AI editors are based on VSCode, which means I either have to suffer through it, or alt-tab to intellij any time I want to edit code
Scala serves a useful purpose: if you are thinking of taking a job somewhere and it turns out they use Scala, and aren't migrating off it, then you know not to take that job.
Yes, it's a very common one shared by virtually all Scala 3 developers. Stop. At least for a couple of years.
Tooling and the community just can't keep up and the language is very good already that the focus should be on the ecosystem and not language.
But Scala devs are beyond deaf and that's what you get when a programming language is an ongoing research project on which many students and professors depend.
It's not enough to say "if we stop developing new features the language will die" when there's 0 evidence by it and a huge fatigue towards the relentless development coming from most of the community.