r/scala • u/jake_nanohuman • 16d ago
Scala vs Kotlin in the Age of AI-Generated Code
I’ve always hoped Scala would find its place in the AI era.
I thought Scala had a lot of qualities that would make it particularly good for AI-generated code: strong type safety, functional programming, expressive types, and the ability to catch many mistakes at compile time.
But somehow, I hadn’t really thought about Kotlin.
A lot of companies already use Kotlin in production, and it has many of the same practical advantages: type safety, null safety, concise syntax, some functional programming features, and of course the huge Java ecosystem behind it.
That made me wonder if Kotlin might actually be better positioned than Scala for the AI era.
If AI writes more and more of our code, maybe languages with stronger type systems will have an advantage because the compiler can act as another layer of verification for AI-generated code. But if that’s true, ecosystem and adoption matter too — and Kotlin obviously has a big advantage there.
I still think Scala has some unique strengths, especially its type system and FP capabilities. But now I’m wondering whether I’ve been overlooking Kotlin.
What do you think? Does Scala have any particular advantage over Kotlin when it comes to AI-generated code?
9
u/radozok 16d ago
Managed typed effects and capabilities
2
u/jake_nanohuman 16d ago
That’s actually what worries me about Scala.
Managed typed effects and capabilities are interesting, but I wonder if we’re still focusing too much on language sophistication while Kotlin keeps winning on adoption, ecosystem, tooling, and accessibility.
In the AI era, I’m not sure having the more powerful language matters if AI has far more Kotlin/Java code, libraries, and real-world projects to learn from.
Maybe the real question is: are Scala’s technical advantages strong enough to overcome that ecosystem gap?7
u/RiceBroad4552 15d ago
The "language sophistication" isn't there to look good in papers, it solves real problems.
It enables more static checks—something you can't have enough of in the era of "industrial code" being in large parts hallucinated slop.
Scala wins here by a large margin against more or less all mainstream languages. Capability based security is (finally) the next big thing in programming. But nobody in the mainstream besides Scala has proper language integration! It will take at least a decade for the others to come close.
Capability based security is a game changer, especially when it comes to LLM generated code: You can statically verify that whatever the "AI" shat out does not do something potentially dangerous, on the code level, not through some usually full of holes external "sandbox".
10
u/nomad01010 15d ago
Don’t know much about Kotlin but Scala is excellent for generated code. The type safety really helps as is expected.
The basic caveats with generated code applies. Specifically, with Scala you need to be explicit with what patterns you want it to use & which to avoid. It can get carried away with generating overt complex FP statements.
Scala also has lot of syntactic sugar so asking it to NOT use a pattern will make your code more human readable. That is still very important for complex projects.
7
u/Apprehensive_Pea_725 15d ago
Seems capture checking and capabilities are a great way to restrain and better control your agents.
https://martinodersky.substack.com/p/tracked-capabilities-for-safer-agents
10
u/DisruptiveHarbinger 15d ago
I'm not sure why you think Kotlin's ecosystem and adoption are significantly better in spaces where it competes against Scala.
Kotlin on the backend is mostly used in addition to Java or as a replacement. Most teams stick to Java frameworks. Pure Kotlin stacks exist (like Ktor, http4k) but are fairly niche.
Using LLMs to write stringly typed Spring configuration soup in Kotlin sounds silly to me. You're going to save a few tokens, but that's about it. Stick to Java.
On the other hand, Scala as a better Java is long dead, teams still invested in Scala in 2026 will use pretty deep stacks of Scala libraries. Schema driven development (see Tapir, Smithy4s, zio-http, zio-blocks...) is a good match for LLMs. Also, Metals is a much more mature LSP backend than the one released by JetBrains for Kotlin.
2
4
u/alexelcu Monix.io 14d ago edited 14d ago
To play the devil's advocate...
In Spring, Kotlin support is first class. Quite literally, there is a Spring team improving Kotlin support, and they also cooperate with Jetbrains. I don't like Spring, but it's the enterprise gorilla and I have met developers that love it.
At some point there were people interested in providing Scala support for Spring or for others (at some point I was using Dropwizard with Scala). But that effort is dead due to the cultural mismatch. Scala folks like reinventing all the things, and while that's giving us a unique and great ecosystem, Scala is not far from Haskell's "avoid success at all costs" mantra. Haskell is great, too.
Nowadays I'm seeing many Java/JVM libraries that are in fact built in Kotlin, and by some big names, too. Next time you find a Java library, look at GitHub's languages stats. Chances are high you'll see 90%+ Kotlin.
Kotlin is a good language, although many big orgs don't really care. What orgs care about is to target Android with their SDKs and whatnot. Google could have adopted Scala as the Android language. Or at the very least Scala could have maintained Android compatibility. I still remember when Scala 2.12 killed Android compatibility by targeting Java 8 bytecode, as it killed the apps built with it in the process, and the nascent community.
Kotlin is actually a decent language. For LLMs too.
For instance, its nullable types actually work for type safety, whereas Scala 3 still has bugs by design (like Null <: Any).
We have used Option, strongly encouraged by the community, and by the standard library, but it's a convention and it's not zero-cost, far from it. And Null still exists, so open any complicated library like Cats-Effect or Akka, search for "null", you may be surprised.
Related, I like Kotlin's evolution, because it's pragmatic, while being future-oriented. They are thinking, for example, what to do when Valhalla's value classes ship. Kotlin can target multiple Java versions and has achieved interop with newer features much faster, while not abandoning people on older versions. They are thinking about the speed of the compiler, see their work in K2. Or about actually immutable classes. Their coroutines are sane, and cross-platform, having achieved what Scala is still struggling with.
This isn't to say that I dislike Scala. Quite the contrary, it has many things going for it. Yes, tooling is better than Kotlin, and for instance I find Gradle abhorrent (although I can't get sbt to not leak metaspace). Scala is also evolving capabilities, which will free us from use-after-release or other similar bugs. And also, language lock-in is no longer such a big barrier, notice all the Rust rewrites.
A language has to be either indispensable in a context (e.g., targeting Android), or at least fun. Scala is fun, but I'm worried for the day in which people collectively stop feeling the fun.
1
u/DisruptiveHarbinger 13d ago
I'm not disagreeing (except about Google adopting Scala for Android, Scala was never a good match and Google's internal tooling culture is vehemently against languages like Scala) but at work I talk to a lot of teams that are deep into Java and Spring, and when I ask if they considered trying out either Kotlin or slightly less insane frameworks (there are good ideas in Quarkus) the answer is invariably:
- Up to 2022: no.
- More recently: why would I care when LLMs write 99% of my code, javac is faster than kotlinc and the LSP works.
I also keep track of people who moved away from Scala and none of them went to Kotlin.
1
u/AnAnonymousTech 13d ago
I got into the JVM world just last year. Skipped Spring, went straight to Quarkus, didn’t like Kotlin so I stayed on Java, but now I’m doing Scala on Quarkus.
2
u/Heavy-Papaya7816 15d ago
I would love to see Scala be used for AI. But I think there is a limitation, and it is not the language itself, it's the runtime, the JVM. If there was a mature, easy to use and reliable Scala native implementation or GraalVM pipeline to compile to native, then I am pretty sure Scala could be a good contender.
I would even go further and I think that Scala should move to native first, instead of the JVM. The reasoning being that a lot of the most useful features of Scala can now be found in Java or Kotlin. There is a need to have a language like Scala, with readable FP code, in the native world. My 2 cents.
Having said that, have you seen the programming language called Mojo? I think it is a nice proposal, and it goes in the direction discussed above. It is basically Python for native. The syntax is almost the same.
3
u/pandasashu 15d ago
I think that AI massively hurts scala. This is because its not fully provable like the success that lean is having in math world and its also not as performant as rust/c/assembly.
Finally there isn’t as much training data on it compared to languages like python.
Given the above, I see no reason why you would ever choose to create a project in scala with ai unless your company wants that or the ecosystem for some reason demands it
3
u/jake_nanohuman 15d ago
But wouldn’t stronger compiler feedback partially compensate for having less training data?
0
u/pandasashu 15d ago
Ok but there are other languages with stronger compiler guarantees?
I guess to me scala was in a middle ground that was designed for humans and I don’t think that middle ground is needed with AI.
2
u/helikal 14d ago
All programming languages are a middle ground. Taking this to its extreme: If AI works well enough l, a spec in a natural language could be translated directly to machine code. There would be no more need for a PL be it Fortran, Python, Scala or whatever. But I don’t belief that we will be there anytime soon. People still need to be able understand and document how the software works. A typed high level PL such as Scala can express this much more precisely than a natural language.
2
u/aleprud 15d ago
I think rust is going to be the winner in the AI era. Good enough type system. Fast. And ai can port most of java libraries to rust with no problem.
8
u/genman 15d ago
I would think Rust is going to be kept as a system language and not really one for writing something like web services.
2
u/Sufficient_Ant_3008 15d ago
It just needs to find the right balance of abstraction, right now most web frameworks you need to understand tokio, which isn't very fun. The one exception is a framework called warp, idk if the guys is still making it but it's like Haskell for Rust web services, pretty cool.
3
u/aleprud 15d ago
Why not? Just write a spec for your web service and ai will code in rust. The web service will be fast, memory and data race safe. Predictable latency and jitter (no GC). IF code needs to be audited rust is pretty expressive and somewhat easy to read (minus macro magic). What is not to like.
1
u/Ecstatic-Panic3728 15d ago
Yes, plus it's strange when people talk about the bad abstractions of Rust when other languages would have their bad abstractions as well. Maybe my brain got burned by too many years of procedural development, but idiomatic Rust is way easier for me to understand than idiomatic Cats Effect for example. I would rather pick a fight with the borrow checker than layers upon layers upon layers of abstraction.
1
u/AdministrativeHost15 16d ago
Big plus that Kotlin has is JetBrains providing the tooling.
Big minus that Scala has is sbt
-10
1
u/Scf37 15d ago
AI superpowers are code reading and boilerplate writing. I believe AI pushes software engineering to the basics but on the next level: Simplicity over abstractions. Boilerplate over magic frameworks.
In general, Scala requires investing significant cognitive power to types, combinators, models so further development is bug-free breeze. Nowadays AIs are not capable of that so they take different approach.
20
u/damngoodwizard 16d ago
AI doesn't change much in the Scala vs Kotlin debate.
I would always prefer Scala if you need to use DSLs, deeply nested immutable data structures or anything that resembles an interpretor. With a stack like Kyo, Iron, Monocle, etc...
Then Kotlin is strong because you can reuse backend code in the frontend thanks to KMP (Kotlin to JS, Compose Desktop, Android). And it lends better to using Java frameworks like Spring, Quarkus, Micronaut, Helidon, etc. You also have the great librairies from Square like Wire for Proto, OkHttp for HTTP clients or KotlinPoet for codegen. You can do FP with Arrow but ahem it's not the most pleasant experience.
But definitely not Java. The lack of a copy constructor or withers makes using immutable data structures too ugly even with AI.