Evolving Scala
177 comments
·March 25, 2025epolanski
btreecat
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.
bishabosha
We have to be more specific about this “tooling” - what are you missing
dmos62
Not sure why this is being downvoted. It's hard to do something actionable based on abstract critique.
pas
It's a fundamental misreading of the situation.
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.
ATMLOTTOBEER
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. :(
pas
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 :)
sideeffffect
> > 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.
openplatypus
> Yes, it's a very common one shared by virtually all Scala 3 developers. Stop. At least for a couple of years.
Please avoid generalisation. Not "all".
xboxnolifes
Know it's generalization, you should also know generalizations aren't literal readings.
redcannon218
Unfortunately Rust is making the exact same mistake.
Edit: It focuses too much on the language instead of the ecosystem.
pkolaczk
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.
zozbot234
> 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.
redcannon218
I need to hash something, one way or another, in virtually 100% of my projects. Where is SHA-256 in the standard library?
pas
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.
[1] https://rust-lang.github.io/rust-project-goals/2025h1/goals....
[2] https://old.reddit.com/r/rust/comments/1if5wpm/high_hopes_fo...
redcannon218
Please see my edit
vaylian
> Edit: It focuses too much on the language instead of the ecosystem.
What do you mean by that? What is missing?
pas
They mentioned SHA-256 as an example, here -- https://news.ycombinator.com/item?id=43483313
packetlost
It... really isn't though?
culi
Rust is younger than Scala. It makes sense for it to still focus on features
redcannon218
But Go has proven that the ecosystem is way more important than the language.
It's time to shift priorities.
sieabahlpark
[dead]
bishabosha
What do you want from the ecosystem?
ATMLOTTOBEER
- faster compile times
- faster compile times
- faster compile times
- 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
sideeffffect
The first five points are fixed by using Mill
https://mill-build.org/mill/comparisons/why-mill.html#_perfo...
KajMagnus
I'd like better debugging of async call stacks. Seems that'll start working better, with Java 21 and virtual threads, so looking forward to that.
And support for Scala in [web frameworks for Java].
Still on Scala 2.13, so don't know what 3.* I'd want, more than what already exist
nikitaga
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.
smokel
> 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?
nikitaga
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.
zozbot234
> 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.
btreecat
Could you give an example of a massive change that was made easier by your choices?
mrkeen
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.
JackFr
> I'd rather work with Scala devs on a Java codebase than Java devs on a Scala codebase.
And Java devs on a Scala codebase is effectively the norm once your project enters BAU/maintenance phase.
threeseed
Type system makes a huge difference especially things like refined types:
https://github.com/Iltotore/iron
Shifts entire classes of errors to compile time.
beastman82
Most underrated library in the world
vvillena
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.
davidee
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.
But once it clicked, it's been a joy to work in.
amelius
What kind of applications have you built in it? GUIs, or web? Mobile perhaps? AI? Does Scala have strong/weak areas here?
threeseed
So I have built all sorts of applications using Scala:
- Desktop GUI app which used Tauri/Rust but heavy Scala.js on the frontend
- Cloudflare Workers using Scala.js
- Web apps using Slinky React [1] and Scala.js
- Highly concurrent, fiber-based backend apps using Scala and Ox [2]
- OpenAI model inference against ultra large datasets using Scala, Spark and MS Synapse
- CLIs using Scala Native
nikitaga
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.
SOLAR_FIELDS
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.
sgt
How far is Java 24 from catching up to Scala though?
haspok
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.
pjmlp
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.
dtech
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.
pas
Just as context for anyone curious:
Scala is even more "powerful" than TS or Rust as it has real HKT (higher-kinded types), and for example Effect.TS needs to emulate/simulate it.
https://github.com/Effect-TS/effect/blob/main/packages/effec...
sideeffffect
Probably never. It's very slow to move.
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.
pas
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?
null
cardanome
Other languages have caught up.
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.
brodo
And if that isn't good enough, Kotlin is also an option with first-class tool support. And a lot of Java developers are IntelliJ users.
sideeffffect
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.
fastball
Most of those things are improved upon by Kotlin as well, and seems like an easier upgrade path from Java anyway vs Scala.
Kotlin is also much more popular than Scala.
sideeffffect
> Kotlin is also much more popular than Scala.
That's not what (at least some) numbers say. Both Scala and Kotlin are 14th.
https://redmonk.com/sogrady/2024/09/12/language-rankings-6-2...
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.
zero-sharp
I haven't kept up. What changed about Java in the past 10 years?
pjmlp
Plenty,
Up to Java 21,
https://advancedweb.hu/a-categorized-list-of-all-java-and-jv...
Remaining ones until Java 24, released last week,
https://www.infoworld.com/article/2335077/jdk-22-the-new-fea...
https://www.infoworld.com/article/2336682/jdk-23-the-new-fea...
https://www.infoworld.com/article/3491404/jdk-24-the-new-fea...
Additionally, commercial AOT compilers have taken a big hit, as two great options are now freely available,
https://www.graalvm.org (Basically LLVM, but in Java)
https://eclipse.dev/openj9/docs/aot
With them there is also the rise of AOT friendly frameworks like Quarkus and Micronaut.
haspok
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.
dmos62
I'm surprised to hear someone say Scala is niche. To me it is to Java what Rust is to C. Subjective, I guess.
openplatypus
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.
bionsystem
> Huge Kudos to Daniel for his courses. If you think Scala is difficult, check his course, these will change your mind.
Daniel Ciocirlan I guess ?
ryandvm
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?
62951413
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 :(
pantsforbirds
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.
the_af
> 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.
jghn
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.
the_af
Yes. I remember Erik Meijer was frustrated back then [1], and advocated going all-in FP, but I don't think that was ever the norm for most developers.
[1] "`Mostly Functional` Programming Doesn't Work" https://queue.acm.org/detail.cfm?id=2611829
tormeh
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.
jghn
When did they choose it, and why? It was far from obscure 10 years ago.
dmos62
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.
flakiness
- 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.
SOLAR_FIELDS
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
yard2010
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.
vvillena
My favorite showcase of Scala to this day is pattern matching on regular expressions:
val date = raw"(\d{4})-(\d{2})-(\d{2})".r
"2004-01-20" match
case date(year, month, day) => s"$year was a good year for PLs."
pantsforbirds
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.") ?
vvillena
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.
dmos62
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.
sideeffffect
> Clojurescript for frontend, Rust for portability
If Clojure and Rust work well for you, more power to you. But at least in theory, you could very well use just Scala for these purposes
Scala can compile to JS https://www.scala-js.org/ if you target frontend.
And if you want portability, you can compile a Scala program with GraalVM's native-image and statically link everything with musl libc https://www.graalvm.org/latest/reference-manual/native-image...
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)
crustycoder
> 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.
dmos62
I've been meaning to try scala-js. If anyone care to share their experience with GraalVM's native-image, I'd be interested in hearing that.
crustycoder
> 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.
For building, https://github.com/sbt/sbt-assembly supports native Image.
znpy
What about GraalVM licensing?
According to https://www.graalvm.org/latest/introduction/#licensing-and-s... the community edition is free software (GPLv2 + classpath exception).
But it isn't really clear what the differences are between the free software version and the proprietary version.
There does not seem to be a page detailing the differences between the two (or at least I couldn't find it)
sideeffffect
I think the proprietary variant of GraalVM comes with more optimizations in the compiler.
But the AOT compilation (native-image) is available in the GPL community variant.
isjustintime
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.
manojlds
My favourite was always Akka Streams. I loved working with it so much.
drewhk
This warms my heart in an otherwise bland day :)
margorczynski
+1, it's an amazing library. Actors is also great along with the rest of the Akka stack. Shame what LB did to it.
sideeffffect
I think it's actually used more to develop more or less ordinary backends. Or some tools/frameworks like Spark or Akka/Pekko.
But you can (and people mostly do) use Spark from Python. And Akka/Pekko from Java (but I'm not sure how that is common).
And the job market is there:
https://functional.works-hub.com/jobs/?remote=true&tags=scal...
https://scalajobs.com/locations/remote/
https://remoteok.com/remote-scala-jobs
https://betterremotejobs.com/search?title=scala
https://readytotouch.com/organizers/scala/vacancies?remote=1
https://www.levels.fyi/jobs?searchText=Scala&workArrangement...
https://www.linkedin.com/mwlite/search/jobs?keyword=Scala&lo...
https://discord.com/channels/629491597070827530/629546253381...
https://discord.com/channels/632277896739946517/840255868096...
okr
Yeah, spark was for me the reason to learn spark, as the Java Api was annoying.
But i do not like to see switch between java and scala and these days also kotlin. Syntax model switches in my head drive me nuts. :))
DeathArrow
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.
sideeffffect
> But something happened
Oracle started heavily investing into Java. And Google picked Kotlin as the language for Android.
But Scala hasn't stagnated since. And as the blog post suggest, plans on moving further still. For example, https://docs.scala-lang.org/scala3/reference/experimental/cc... may be one of the most impactful developments in the language's history.
leetrout
There are better alternatives for almost every domain if you don’t need JVM / Java interop.
Julia for mathy stuff.
Python with pandas / polars.
Rust with polars / actor frameworks.
Go for simple systems tooling / api dev.
Zig and Rust for systems programming.
Elixir / gleam for functional webdev.
JS / TS for everything.
sideeffffect
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).
DeathArrow
>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#.
pas
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.)
minebreaker
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.
sideeffffect
> Shapeless breaks everything so casually.
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.)
minebreaker
My company still sticks to Scala2 so I may be misinformed, but I heard Scala3 tuples cannot completely replace Shapeless, like missing LabelledGeneric equivalent?
linotype
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.
I miss it a lot.
mpweiher
Which features would those be?
sideeffffect
* Immutable-first
* 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).
gf000
Also, the collections API is the best out of any language I have used!
linotype
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.
olivermuty
You can code the whole program with only types and no code?
Albeit that is possible in typescript these days too tho.
tossandthrow
Type systems expressive enough to write actual programs is widespread these days.
Typescript's typesystem is even Turing complete.
Regardless, it is not very practical to use a type checker as your runtime.
thinkharderdev
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.
> 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.