[HN Gopher] Scala 3 slowed us down?
___________________________________________________________________
Scala 3 slowed us down?
Author : kmaliszewski
Score : 152 points
Date : 2025-12-07 15:08 UTC (7 hours ago)
(HTM) web link (kmaliszewski9.github.io)
(TXT) w3m dump (kmaliszewski9.github.io)
| spockz wrote:
| For me the main takeaway of this is that you want to have
| automated performance tests in place combined with insights into
| flamegraphs by default. And especially for these kind of major
| language upgrade changes.
| esafak wrote:
| What are folks using for perf testing on JVM these days?
| noelwelsh wrote:
| jmh is what I've always used for small benchmarks.
| cogman10 wrote:
| For production systems I use flight recordings (jfrs). To
| analyze I use java mission control.
|
| For OOME problems I use a heap dump and eclipse memory
| analysis tool.
|
| For microbenchmarks, I use JMH. But I tend to try and avoid
| doing those.
| gavinray wrote:
| async-profiler
| spockz wrote:
| I use jmh for micro benchmarks on any code we know is
| sensitive and to highlight performance differences between
| different implementations. (Usually keep them around but not
| run on CI as an archive of what we tried.)
|
| Then we do benchmarking of the whole Java app in the
| container running async-profiler into pyroscope. We created a
| test harness for this that spins up and mocks any
| dependencies based on api subscription data and contracts and
| simulates performance.
|
| This whole mechanism is generalised and only requires teams
| that create individual apps to work with contract driven
| testing for the test harness to function. During and after a
| benchmark we also verify whether other non functionals still
| work as required, i.e. whether tracing is still linked to the
| right requests etc. This works for almost any language that
| we use.
| malkia wrote:
| Benchmarking requires a bit of different setup than the rest of
| the testing, especially if you want down to the ms timings.
|
| We have continous benchmarking of one of our tools, it's
| written in C++, and to get "same" results everytime we launch
| it on the same machine. This is far from ideal, but otherwise
| there be either noisy neighbours, pesky host (if it's vm), etc.
| etc.
|
| One idea that we thought was what if we can run the same test
| on the same machine several times, and check older/newer code
| (or ideally through switches), and this could work for some
| codepaths, but not for really continous checkins.
|
| Just wondering what folks do. I can assume what, but there is
| always something hidden, not well known.
| spockz wrote:
| I agree for measuring latency differences you want similar
| setups. However, by running two versions of the app
| concurrently on the same machine they both get impacted more
| or less the same by noisy neighbours. Moreover, by inspecting
| the flamegraph you can, manually, see these large shifts of
| time allocation quickly. For automatic comparison you can of
| course use the raw data.
|
| In addition you can look at total cpu seconds used, memory
| allocation on kernel level, and specifically for the jvm at
| the GC metrics and allocation rate. If these numbers change
| significantly then you know you need to have a look.
|
| We do run this benchmark comparison in most nightly builds
| and find regressions this way.
| atbpaca wrote:
| Thank you for sharing. Interesting insight on dep libraries.
| game_the0ry wrote:
| I am not a scala fan and do not care for it, but I upvote for the
| thorough thought process, breakdown, and debugging of the
| problem. This is how technical blogs should be written. AI aint
| got shit on this.
| sema4hacker wrote:
| > I was refreshing one of our services. Part of this process
| was to migrate codebase from Scala 2.13 to Scala 3.
|
| My first question was: why?
| pxc wrote:
| [delayed]
| pjmlp wrote:
| The only issue I have with Scala 3 is Python envy, they should
| not have come up with a second syntax, and pushing it as the
| future.
|
| If anything is slowly down Scala 3 is that, including the tooling
| ecosystem that needs to be updated to deal with it.
| gedy wrote:
| As a former Scala fan, wow you aren't kidding, wth
| val month = i match case 1 => "January"
| case 2 => "February" // more months here ...
| case 11 => "November" case 12 => "December"
| case _ => "Invalid month" // the default, catch-all
| // used for a side effect: i match case 1 |
| 3 | 5 | 7 | 9 => println("odd") case 2 | 4 | 6 | 8
| | 10 => println("even") // a function written
| with 'match': def isTrueInPerl(a: Matchable): Boolean =
| a match case false | 0 | "" => false
| case _ => true
| bdangubic wrote:
| madness :)
| a24j wrote:
| Can you eli5 the madness? And how that relates to
| python/java?
| jfim wrote:
| It's been a while since I touched Scala but wasn't that a
| thing in previous versions, minus the braces not being
| present?
| weego wrote:
| Yes, that's all just as it was, and in places braces were
| not required / interchangeable so this is more of an
| optional compiler choice than a real change
| malkia wrote:
| Sorry, I'm coming from C++-ish background - can anyone
| explain what's going on :)
| hocuspocus wrote:
| Scala 2's syntax is mostly Java/C-style with a few
| peculiarities.
|
| Scala 3's _optionally_ allows indentation based, brace-less
| syntax. Much closer to the ML family or Python, depending
| on how you look at it. It does indeed look better, but
| brings its share of issues.[1] Worse, a lot of people in
| the community, whether they like it or not, think this was
| an unnecessary distraction on top of the challenges for the
| entire ecosystem (libraries, tooling, ...) after Scala 3.0
| was released.
|
| - [1] https://alexn.org/blog/2025/10/26/scala-3-no-indent/
| esafak wrote:
| You could also have compared it, more attractively, to Haskell.
| pjmlp wrote:
| Except the reason behind the syntax change is the losing
| mindshare from Scala into Python, after its relevance in the
| big data wave that predated the current AI wave.
|
| Nothing to do with Haskell, even if it is also white space
| significant.
| noelwelsh wrote:
| Everything is up to date with the new syntax as far as I'm
| aware. Also, the compiler and scalafmt can rewrite one to the
| other. A project can pick whatever style it wants and have CI
| reformat code to that style.
| pjmlp wrote:
| When I checked a year ago, the IDE tooling still wasn't quite
| there.
| spockz wrote:
| What I don't get because there is LSP and BSP support. What
| else is needed to get support for scala 3 from an IDE?
| Obviously, Kotlin coming from Jetbrains will make it
| receive a lot more love and first class support.
| pjmlp wrote:
| Parity with Scala 2 development experience, which was
| lacking a year ago.
| dmix wrote:
| > After upgrading the library, performance and CPU
| characteristics on Scala 3 became indistinguishable from Scala
| 2.13.
|
| We had a similar experience moving Ruby 2->3, which has a ton of
| performance improvements. It was in fact faster in many ways but
| we had issues with RAM spiking in production where it didn't in
| the past. It turned out simply upgrading a couple old
| dependencies (gems) to latest versions fixed most of the issues
| as people spotted similar issues as OP.
|
| It's never good enough just to get it running with old
| code/dependencies, always lots of small things that can turn into
| bigger issues. You'll always be upgrading the system, not just
| the language.
| derriz wrote:
| I was involved in a Scala point version migration (2.x) migration
| a few years ago. I remember it being painful. Although I recall
| most of the pain was around having lots of dependencies and
| waiting for libraries to become available.
|
| At the time Scala was on upswing because it had Spark as its
| killer app. It would have been a good time for the Scala
| maintainers to switch modes - from using Scala as a testbed for
| interesting programming-language theories and extensions to
| providing a usable platform as a general commercially usable
| programming language.
|
| It missed the boat I feel. The window has passed (Spark moved to
| Python and Kotlin took over as the "modern" JVM language) and
| Scala is back to being an academic curiosity. But maybe the
| language curators never saw expanding mainstream usage as a goal.
| hylaride wrote:
| Outside of Android work, has Kotlin really taken over? My
| understanding is that Java added a lot of functional
| programming and that took a lot of wind out of Scala's sails
| (though Scala's poor tooling certainly never helped anything).
| esafak wrote:
| Java's new features are always going to be on paper. The
| ecosystem, with all its legacy code, is always going to be a
| decade behind. And if you are starting a new project, why
| would you pick Java over Kotlin?
| hylaride wrote:
| That's kind of what I'm asking. I did have a former co-
| worker write a micro service in Kotlin around 2018. He said
| that as nice as the language is, the ecosystem was (at the
| time, not sure how it is today) so utterly dominated by
| Android development, that he said he wouldn't recommend
| using it again - half the time he was calling out Java
| anyways.
| esafak wrote:
| I use kotlin and I do not feel oppressed by Android in
| any way. And I'd rather call Java libraries from Kotlin
| than Java. Many have Kotlin wrappers.
| dtech wrote:
| That's a weird take. Even if true, kotlin has perfect
| interop with calling Java libs so there's not really a
| downside to keep using Java libs. There's not that much
| demand for kotlin-specific libs outside multiplatform
| which includes Android.
|
| For what it's worth, Spring has first tier Kotlin
| support, I haven't noticed this bias.
| gavinray wrote:
| Kotlins "ecosystem" is all of Java, and then all of
| Kotlin.
|
| Put another way: Java only has access to a subset of the
| ecosystem
|
| Almost all of the backend libraries I use are Java libs.
| Some of them have additional Kotlin extension libs that
| add syntax sugar for more idiomatic code.
| adrianN wrote:
| It's a lot cheaper to hire for Java than for ,,modern"
| languages.
| frje1400 wrote:
| > And if you are starting a new project, why would you pick
| Java over Kotlin?
|
| Because in 5-10 years you'll have a Java project that
| people can still maintain as if it's any other Java
| project. If you pick Kotlin, that might at that point no
| longer be a popular language in whatever niche you are in.
| What used to be the cool Kotlin project is now seen as a
| burden. See: Groovy, Clojure, Scala. Of course, I recognize
| that not all projects work on these kinds of timelines, but
| many do, including most things that I work on.
| wrathofmonads wrote:
| Clojure has never been a popular language, nor has it
| aimed to be mainstream. That is the Lisp curse. It has
| never positioned itself as a "better Java". It shines in
| applications where immutable, consistent, and queryable
| data is crucial, and it has found another niche in UIs
| through ClojureScript.
| pjmlp wrote:
| Because the Java Virtual Machine is designed for Java, and
| that is what all vendors care about.
|
| Kotlin is Google's C#, with Android being Google's .NET,
| after Google being sued by coming up with Google's J++,
| Android Java dialect.
|
| Since Google wasn't able to come up with a replacement
| themselves, Fuchsia/Dart lost the internal politics, they
| adopted the language of the JetBrains, thanks to internal
| JetBrains advocates.
| aarroyoc wrote:
| At least where I work, writing new Java code is discouraged
| and you should instead use Kotlin for backend services.
| Spring Boot which is the framework we use, supports Kotlin
| just fine, at the same level as Java. And if you use
| Jetbrains tools, Kotlin tooling is also pretty good (outside
| Jetbrains I will admit it is worse than Java). Now, even in
| new Java projects you can still be using Kotlin because it is
| the default language for Gradle (previously it was Groovy).
| dtech wrote:
| Sort of true, but I often hear this take from Java
| programmers and it feels like "Blub" [1]/Stockholm syndrome
| to me.
|
| Personally, I'm extremely glad to not have had to write
| .toStream().map(...).collect(Collectors.list()) or whatever
| in years for what could be a map. Similar with async code and
| exception handling.
|
| For me one of the main advantages of Kotlin is that is
| decreases verbosity so much that the interesting business
| logic is actually much easier to follow. Even if you
| disregard all the things it has Java doesn't the syntax is
| just so much better.
|
| [1] https://paulgraham.com/avg.html
| mystifyingpoi wrote:
| > My understanding is that Java added a lot of functional
| programming
|
| This is true, but needs more context. Java 8 added Stream
| API, which (at this time) was a fantastic breath of fresh
| air. However, the whole thing felt overengineered at many
| points, aka - it made complex things possible (collector
| chaining is admittedly cool, parallel streams are useful for
| quick-and-dirty data processing), but simple everyday things
| cumbersome. I cannot emphasize how tiring it was to have to
| write this useless bolierplate
| customers.stream().map(c ->
| c.getName()).collect(Collectors.joining(", "))
|
| for 1000th time, knowing that customers.map(c
| -> c.getName()).join(", ")
|
| is what users need 99.99999% of the time.
| gavinray wrote:
| My org had to write a pivotal backend service on the JVM, due
| to JDBC having the largest number of data source adapters.
|
| The choice was Kotlin. Scala is too "powerful" and can be
| written in a style that is difficult for others, and Java too
| verbose.
|
| Kotlin is instantly familiar to modern TypeScript/Swift/Rust
| etc devs.
|
| The only negative in my mind has been IntelliJ being the only
| decent IDE, but even this has changed recently with Jetbrains
| releasing `kotlin-lsp` for VS Code
|
| https://github.com/Kotlin/kotlin-lsp
| pjmlp wrote:
| Kotlin is an Android language, because Google says so, and they
| stiffle Java support on purpose (Java 17 LTS subset currently).
|
| Outside Android, I don't even care it exists.
|
| If I remember correctly, latest InfoQ survey had it about 10%
| market share of JVM projects.
| wrathofmonads wrote:
| Kotlin hasn't made much of an impact in server-side development
| on the JVM. I'm not sure where this perception comes from, but
| in my experience, it's virtually nonexistent in the local job
| market.
| izacus wrote:
| Why is your personal experience relevant to the wider market?
| How many companies and locations did you survey for that?
| _old_dude_ wrote:
| In Scala 3, the inline keyword is part of the macro system.
|
| When inline is used on a parameter, it instructs the compiler to
| inline the expression at the call site. If the expression is
| substantial, this creates considerable work for the JIT compiler.
|
| Requesting inlining at the compiler level (as opposed to letting
| the JIT handle it) is risky unless you can guarantee that a later
| compiler phase will simplify the inlined code.
|
| There's an important behavioral difference between Scala 2 and 3:
| in 2, @inline was merely a suggestion to the compiler, whereas in
| 3, the compiler unconditionally applies the inline keyword.
| Consequently, directly replacing @inline with inline when
| migrating from 2 to 3 is a mistake.
| dtech wrote:
| Kotlin _heavily_ uses the inline keyword basically everywhere,
| to get rid of lamdba overhead for functions like map. Basically
| every stdlib and 3rd part library function that takes a lamdba
| is inlined.
|
| In general it's a performance benefit and I never heard of
| performance problems like this. I wonder if combined with
| Scala's infamous macro system and libraries like quicklens it
| can generate huge expressions which create this problem.
| gavinray wrote:
| The killer is specifically the inlining of macros -- which
| Kotlin lacks.
|
| And not all macros, but just the ones which expand to massive
| expressions
|
| Think template expressions in C++ or proc macros in Rust
| pjmlp wrote:
| This is one example why being a guest language isn't optimal.
|
| They should have made use of JVM bytecodes that allow to
| optimize lambdas away and make JIT aware of them, via
| invokedynamic and MethodHandle optimizations.
|
| Naturally they cannot rely on them being there, because
| Kotlin also needs to target ART, JS runtimes, WebAssembly and
| its own native version.
| dtech wrote:
| Kotlin existed before Java 7 and kept support JVM 1.6 for a
| long time (mainly because of Android)
|
| Even then, they benchmarked it, and inlining was still
| faster* than invokedynamic and friends, so they aren't
| changing it now JVM 1.8+ is a requirement.
|
| * at the expense of expanded bytecode size
| pjmlp wrote:
| Java 7 to Java 25 is a world apart, and then on which
| JVM?
|
| Naturally it is a requirement, JetBrains and Google only
| care about the JVM as means to launch their Kotlin
| platform, pity that they aren't into making a KVM to show
| Kotlin greatness.
|
| If it feels salty, I would have appreciated if Android
| team was honest about Java vs Kotlin, but they weren't
| and still aren't.
|
| If they were, both languages would be supported and
| compete on merit, instead of sniffling one to push their
| own horse.
|
| Even on their Podcast they reveal complete lack of
| knowledge where Java stands.
| hunterpayne wrote:
| Maybe the JVM team should listen to the market then and
| disable the jigsaw encapsulation that keeps devs on 1.8.
| Forcing a questionable security framework on everyone is
| why 1.8 is still used. Again, this is a problem because
| the PMs (and some devs) refuse to listen to what the
| market wants. So they are stuck keeping a 20 year old
| version of the code working. Serves them right to have to
| do this. It is their penance for being too arrogant to
| listen to the market.
|
| PS Yes, I know, there is some weird way to disable it.
| Somehow that way changes every version and is about as
| non-intuitive as possible. And trying to actually support
| the encapsulation is by a wide margin more work than it
| is worth.
| imtringued wrote:
| What you're asking for is essentially commercial support
| from Oracle.
| pjmlp wrote:
| I have not done a Java 8 project in years, other than
| Android because the reasons we all know.
|
| Maybe Google could finally support latest Java versions
| on Android, instead of begrudgingly update when Kotlin
| lags behind Maven Central most used versions.
|
| Which by the way is a Java 17 subset, not Java 8, when
| supporting Android versions below Android 12 isn't
| required.
| gavinray wrote:
| There are Kotlin compiler flags to default to "indy"
| optimization, and which may be enabled by default for some
| time now?
|
| Also not all Kotlin inlines are lambdas or even include
| method calls
| Kwpolska wrote:
| The takeaway of upgrading your libraries when upgrading major
| language and framework versions applies beyond Scala. Especially
| when the libraries abuse magic language features (and far too
| many Scala libraries do) or otherwise integrate deep into the
| framework/language.
| munchler wrote:
| I'm not familiar with Scala's macro system, but it seems like a
| big takeaway here is: Be careful with code that invokes the
| compiler (JIT) at runtime. That seems like it's asking for
| trouble.
| dtech wrote:
| Macro's are compile time, there is no runtime codegen.
|
| The problem was overly-frequent inlining generating enormous
| expressions, causing a lot JIT phase and slow execution.
| munchler wrote:
| Thank you for the clarification. If I understand correctly,
| these large expressions are created at compile-time, but the
| impact isn't felt until JIT occurs in the runtime
| environment. In that scenario, shouldn't the JIT just run
| once at startup, though? I'm still not quite understanding
| how JIT can take so much time in a production environment.
| hunterpayne wrote:
| Because the jit will let the unoptimized code run a few
| (hundred) times to take measurements to know what needs to
| be optimized and how it needs to be optimized. This is a
| good solution and makes hotspot very effective. The problem
| is that it happens randomly a few minutes/seconds into the
| operation of the service. So you randomly have a big pause
| with the performance hit everytime you run the service. The
| upside is that this only happens once. But you have to plan
| for a big performance hit to requests which are unlucky
| enough to be called at the wrong time.
| pretzellogician wrote:
| And this can generally be avoided as well, by doing
| "warmup" when starting your service (effectively, mock
| some calls), but before accepting requests.
| hunterpayne wrote:
| Of course, but then you have to actually do this. It is
| just another complexity to add. Also, I was answering a
| question about the hows and whys of the jit. I wasn't
| saying it was impossible to work around.
| gavinray wrote:
| That's not true, Spark's entire query engine relies on use of
| runtime codegen via macros/quasi quotes
|
| Look up the architecture of Catalyst + Tungsten
|
| https://www.databricks.com/glossary/catalyst-optimizer
| phendrenad2 wrote:
| Controversial opinion: Scala should have gone into maintenance
| mode a decade ago. They got the language right at the beginning,
| and a decade of tinkering has just fatigued everyone and
| destroyed any momentum the language once had.
| instig007 wrote:
| > and a decade of tinkering has just fatigued everyone and
| destroyed any momentum the language once had.
|
| it's hard to buy it, considering that many of those "fatigued"
| moved on Kotlin, led by their managers' bs talking points.
| hunterpayne wrote:
| Many of the Scala projects got people fired. Something the
| Scala devs largely ignore. Plus Scala support is truly awful
| even by the low standards of an OpenSource project. Then
| there is the fact that the Scala specific libraries are
| largely dead.
|
| Scala had/has a lot of promise. But how the language is
| marketed/managed/maintained really let a lot of people down
| and caused a lot of saltiness about it. And that is before we
| talk about the church of type-safety.
|
| Scala is a more powerful language than Kotlin. But which do
| you want? A language with decent support that all your devs
| can use, or a language with more power but terrible support
| and only your very best devs can really take advantage of.
| And I say this as someone writing a compiler in Scala right
| now. Scala has its uses. But trying to get physicists used to
| Python to use it isn't one of them. Although that probably
| says more about the data science folks than Scala.
|
| PS The GP is right, they should have focused on support and
| fixing the problems with the Scala compiler instead of
| changing the language. The original language spec is the best
| thing the Scala devs ever made.
| jiehong wrote:
| > After upgrading the library, performance and CPU
| characteristics on Scala 3 became indistinguishable from Scala
| 2.13.
|
| Checking the bug mentioned, it was fixed in 2022.
|
| So, I'm wondering how one would upgrade to scala 3, while keeping
| old version of libraries?
|
| Keeping updated libraries is a good practice (even mandatory if
| you get audits like PCI-DSS).
|
| That part puzzled me more than the rest.
| fn-mote wrote:
| > Checking the bug mentioned, it was fixed in 2022.
|
| I was considerably less impressed by the reporting when I
| finally found out the culprit.
|
| Sure it was "Scala 3" ... but not really.
|
| It was an interaction of factors and I don't think it would
| take away from the story to acknowledge that up front.
| mystifyingpoi wrote:
| I'm confused as well, because he wrote
|
| > I did it as usual - updating dependencies
|
| but later
|
| > After upgrading the library, performance and CPU
| characteristics on Scala 3 became indistinguishable from Scala
| 2.13.
|
| So... he didn't upgrade everything at first? Which IMO makes
| sense, generally you'd want to upgrade as little as possible
| with small steps. He just got unlucky.
| gavinray wrote:
| It would have been a transitive dependency based on the
| comments about the library being "transparent" and the author
| unaware it was even used.
|
| Pinning specific versions of transitive deps is fairly common
| in large JVM projects due to either security reasons or ABI
| compatibility or bugs
| gavinray wrote:
| If your Maven/Gradle/SBT build specifies a version constraint
| for a third party lib, updating your Scala or Kotlin version
| doesn't affect this
|
| (For scala-specific libs, there is a bit more nuance, because
| lib versions contain scala version + lib version, e.g.
| foolib:2.12_1.0.2 where 2.12 = scala version)
| tasuki wrote:
| > Keeping updated libraries is a good practice
|
| First, the "good practice" argument is just an attempt to shut
| down the discussion. God wanted it so.
|
| Second, I rather keep my dependencies outdated. New features,
| new bugs. Why update, unless there's a specific reason to do
| so? By upgrading, you're opening yourself up to:
|
| - Accidental new bugs that didn't have the time to be spotted
| yet.
|
| - Subtly different runtime characteristics (see the original
| post).
|
| - Maintainer going rogue or the dependency getting hijacked and
| introducing security issues, unless you audit the full code
| whenever upgrading (which you don't).
| groundzeros2015 wrote:
| I know this topic has been beat to death but this is another
| example of why high level language with super optimizing compiler
| has had less industry success.
|
| If performance is a feature it needs to be written in the code.
| Otherwise it implicitly regresses when you reorder a symbol and
| you have no recourse to fix it, other than fiddling to see if it
| likes another pattern.
| alberth wrote:
| To be fair, it's misleading to group Scala (or any JVM
| language), with other "high-level languages."
|
| The JVM is extremely mature and performant, and JVM-based
| languages often run 5x (or more) than non-JVM high-level
| languages like Python or Ruby.
| groundzeros2015 wrote:
| That doesn't follow. Scala is a high level language and
| compiler above the JVM. The bug here is a high level one:
|
| > Turns out there was indeed a subtle bug making chained
| evaluations inefficient in Scala 3
|
| I'm comparing with Haskell, Scheme, or even SQl which all
| promise to compile efficient code from high level
| descriptions.
| esarbe wrote:
| Awesome language, nice to see others using it.
|
| I can thoroughly recommend it. Once of the best languages out
| there in terms of expressive power.
| xolve wrote:
| The bug reports linked on softwaremill and scala GitHub's are
| precise and surprisingly small fixes! It does show Scala's power
| in expressiveness.
|
| Scala is a great language and I really prefer its typesafe and
| easy way to write powerful programs:
| https://www.lihaoyi.com/post/comlihaoyiScalaExecutablePseudo...
| Its a great Python replacement, especially if your project is not
| tied to ML libraries where Python is defacto, like JS on web.
| hunterpayne wrote:
| The problem with Scala 3 is that nobody asked for it. The problem
| with Scala 2 is that the type inference part of the compiler is
| still broken. Nobody worked on that. Instead they changed the
| language in ways that don't address complaints. Completely ignore
| the market and deliver a product nobody wants. That's what
| happened here.
|
| PS Perhaps they should make an actual unit test suite for their
| compiler. Instead they have a couple of dozen tests and have to
| guess if their compiler PR will break things.
| thefaux wrote:
| It's sad but I generally agree. Scala was in my view pretty
| well positioned for an up and coming language ~2010-15. Not
| only did the scala 3 rewrite fail to address many of the most
| common pain points -- compile times and tooling immediately
| come to mind -- the rewrite took many years and completely
| stalled the momentum of the project. I have to wonder at this
| point who is actually starting a new project in scala in 2025.
|
| It's really a shame because in many ways I do think it is a
| better language than anything else that is widely used in
| industry but it seems the world has moved on.
| oelang wrote:
| And I wish you read the article, you're comments are completely
| off topic.
| voidfunc wrote:
| Scala has deep roots in the Ivory Towers of Academia, its not
| shocking they think they know better than their users what the
| problems with the language are and didn't do any kind of real
| product management to figure out the actual problems before
| embarking on a rebuild.
| lispisok wrote:
| I tried getting into Scala several times and kept going back to
| Clojure. Unless you are into type system minigames Clojure has
| many of the things Scala advertises but without the dumptruck
| of Scala overhead and complexity. Another commenter briefly
| touched on this but it's a language made by academics for
| academics to play with language design. It was a little weird
| it blew up in industry for a while.
| scotty79 wrote:
| It's quite impressive that you can swap out major version from
| under running application and have just one subtle issue.
___________________________________________________________________
(page generated 2025-12-07 23:00 UTC)