Scala 3 slowed us down?

Performance testing & profiling on the JVM

• Many commenters say major language upgrades demand automated performance tests, flamegraphs, and tooling like JMH, async-profiler, JFR, and Java Mission Control.
• Some teams run continuous or nightly benchmarks comparing two versions side-by-side, analyzing CPU, GC metrics, allocation rate, and kernel-level counters.
• There is concern about noisy neighbors and VM variability; approaches include fixed hardware, concurrent version runs, hardware performance counters, and warm-up phases.

Root cause: Scala 3, inlining, and macros

• Several explain that in Scala 3 inline is part of the macro system and is mandatory, unlike Scala 2’s @inline hint.
• Blindly converting @inline to inline can generate huge expressions, overloading the JIT and causing pauses and slowdowns.
• Clarification: macros are compile-time; the problem is JIT cost on large generated expressions, not runtime codegen per se.

Dependencies and upgrades

• Strong agreement that when upgrading language major versions, libraries must be upgraded too; old transitive deps can hide subtle perf bugs.
• Some are puzzled that old libraries were still present, but others point out this is normal when version ranges are pinned or transitive.
• One camp insists “keep libraries updated” is best practice; another argues frequent updates introduce new bugs and risk, so change should be minimized and isolated.

Scala 3 syntax and tooling

• The optional indentation-based, brace-less syntax draws criticism: seen as unnecessary “Python envy” and a distraction that complicates tooling and learning.
• Others argue it’s optional, closer to ML/Haskell styles, and can be auto-rewritten by compiler/scalafmt; projects can standardize on either style.
• Tooling quality is contentious: some report Scala 3 IDE support (e.g., via LSP/Metals) as better than Scala 2, others say it’s still a downgrade from IntelliJ Scala 2 and some IDEs remain unreliable.

Scala vs Java vs Kotlin & ecosystem health

• One view: Scala missed its Spark-era window, is now an “academic curiosity,” and Kotlin/modern Java have taken over industry mindshare.
• Counterview: Scala is widely used at large companies, has powerful type systems and features still unmatched by Java/Kotlin, and remains very expressive and performant.
• Opinions diverge sharply on Scala’s governance: some say Scala 3 changes ignored real pain points (compile times, tooling) and fatigued users; others argue Scala 3 finally regularizes type inference and fixes deep design issues.
• Broader debate branches into Kotlin’s role (strong on Android, mixed adoption server-side), long-term maintainability, hiring costs, and Java’s evolving functional features.

High-level languages and predictable performance

• A few argue that high-level languages with aggressive optimizers (Scala, Haskell, etc.) make long-term performance predictability hard: small changes can cause opaque regressions.
• Others respond that JVM languages remain far faster than many other “high-level” languages and that this single bug is not evidence Scala is failing.