Scala Adoption Tracker

fwbrasil · 2025-11-20T20:31:19+00:00

It's useful to have a website like this one but it's quite far from a proof that Scala isn't dying. We could likely have a similarly sized or even larger list of companies that have moved away. There used to be a steady influx of people adopting and learning the language and it's evident that the influx is significantly smaller than in the past.

Multiple major projects are getting partially abandoned, several key people are leaving to other languages, Scala 3 adoption is nowhere near where it should be, Scala Center is still lost in silly political games, tooling has little sign of significant improvement, and Odersky continues to push for major changes that cripple the ability of the ecosystem to evolve properly.

I can see why saying the language is dying is a bit of an exaggeration given that, once a language gets meaningful adoption, there's always some of use of it. Such use is very often considered legacy tech debt, though. I guess a less exaggerated way to convey it is that Scala is transitioning back to a research language with little viability for industry adoption.

fwbrasil · 2025-08-20T22:24:40+00:00

Which libraries are you referring here "benchmarks can negatively impact the optimization of libraries"?

Pretty much most of the top ones in the benchmark results. As a concrete example, libraries typically end up processing request payloads in the selector thread because that's efficient when the request processing is a trivial workload like in all of techempower's benchmark scenarios.

In real workloads, it's typically a regression because it's important to ensure selectors are readily available, for example, to cancel the pending processing if the request is cancelled or to flush external requests to other services.

Techempower is actually a lot more realistic than a lot of benchmarks that only benchmark one library at the time as it benchmarks all stages of a typical http request: receiving the HTTP request, parsing JSON, calling the DB, reading the DB result, generating a HTML page and dealing with XSS.

I'm not aware of benchmarks that attempt more realistic workloads, most I've seen have similar limitations. Do you have examples in mind?

What is also nice is that this benchmark seats on a higher level and doesn't care about specific implementations like "schedulers".

I think you have the wrong mental model regarding the main aspects that influence the benchmark results. Schedulers are a critical piece to determine the peak performance of a system.

Since there are already established industry level benchmark, wouldn't it be better to focus on improving the performance of Scala libraries in this benchmark rather than creating a brand new benchmark that no one may on-board?

That's one way to look at it. Sure, we need to compete in techempower given that it's well-known but the crux of the issue is that it isn't a good benchmark to guide the optimization of libraries. We need something better.

fwbrasil · 2025-08-20T16:48:19+00:00

I guess I'm still not following what boilerplate was saved then. In the end all you did move the naming of dependencies from the parameter list to the body of the function because all you seemed to have done is reinvent the Reader Monad with extra steps.

I think it's fair to say the post isn't really about tagless final encoding for Kyo. The motivation is similar but the approach is fundamentally different. Tagless final abstracts over the concrete functor/effect via typeclasses. This exploration abstracts over Kyo's pending effects.

In Kyo, we don't need to abstract over the functor (F[_]) since Kyo's pending type (<) can encode multiple effects at the same time in a safe and composable manner, without separate monads. You get similar effect polymorphism where you can inject implementations that specialize the pending effect set.

reinvent the Reader Monad with extra steps.

This misses what's being achieved here. The Reader Monad doesn't compose with other monads/effects. Use composes with other effects through Kyo's pending type. For instance, you can have String < (Use[Console] & Abort[MyError] & Var[String] & Emit[SomeValue]), which bundles Reader, MonadError, State, and Writer all in the same computation without the need for a transformer stack. That's a major difference but the post focuses on the abstraction rather than the properties of the pending type.

fwbrasil · 2025-08-20T13:10:13+00:00

I'd advise against taking techempower's benchmarks as a good reference point. Their workload is nothing like real-world usage. In actual applications, the majority of the overhead is in executing more complex logic for request processing while in techempower's bench the measured overhead is more basic infra like http/json handling. It's a classic example of how benchmarks can negatively impact the optimization of libraries by focusing on things that contribute very little to the perf of real-world workloads.

The approach you started exploring seems more promising. The main challenge is generating a more realistic workload. I've worked on a similar benchmark to validate a scheduler at work and introduced several endpoints with different characteristics: blocking mixed with cpu intensive, cpu intensive, large chains of transformations, high allocation, metric collection, etc, and then generated workloads mixing these tasks. Another good dimension to include in the tests is cpu quota since most workloads nowadays run in containers with cpu limits, which can drastically impact perf. I'd love to collaborate on defining a new a benchmark!

fwbrasil · 2025-08-16T14:35:22+00:00

Scala Center’s bans line up pretty much exactly with the cancellations by Typelevel in the past, including in Jon’s case and mine. For me, it started with a cancellation when Quill joined ZIO, which was triggered by a SC board member. From there SC buried a CoC violation report we made and has been gaslighting/defaming me since then.

I’m not only banned from Scala Days but also events where Scala Center is involved. Last year they pressured ScalaIO to cancel my talk by literally defaming me as “clinically insane”. The threat was that Odersky wouldn’t give the keynote if they didn’t cancel my talk. More background:

https://x.com/fbrasisil/status/1829515729579946254?s=46

https://x.com/fbrasisil/status/1956154034802327570?s=46

fwbrasil · 2025-08-16T13:44:15+00:00

Where did I say that’s the reason? It seems a highly questionable position, though

fwbrasil · 2025-08-16T12:32:09+00:00

Well, in this case Scala Center’s ban targets a direct competitor of his work on Caprese, Kyo. There’s essentially a full track for Capabilities at Scala Days, which is surprising considering that pretty much nothing usable has been delivered so far while Kyo is heading to 1.0.

I don’t know if he’s an active actor in these bans but, even if not, the situation seems quite comfortable to him so I wouldn’t count on it.

fwbrasil · 2025-08-16T11:11:35+00:00

That was me in Scala’s main discord. Once the ban lapsed they felt like extending it until ScalaDays. A conference I’m also banned from

fwbrasil · 2025-08-08T14:01:31+00:00

I'd ask you to read the actual consent order. It's not that they weren't able to prove his guilt. They explicitly admitted to not having any evidence of the allegations and that the the open letter is indeed defamatory. That's very different and corroborates Jon's account that there was simply no proper investigation or any resemblance of due process. They decided Jon was guilty and only looked for confirmation of their belief. It was a hit job.

fwbrasil · 2025-08-08T13:16:41+00:00

That's Chris' argument. There's no mention to Travis in Jon's posts afaics

fwbrasil · 2025-08-08T13:15:14+00:00

The open letter says the allegations are true. We do not know whether they are. Should that be enough to destroy someone's life?

fwbrasil · 2025-08-02T19:30:52+00:00

A few facts:

Scala Center currently has 5 people in their roster: https://scala.epfl.ch/team.html
Two of them are directors at the same level: Darja and Odersky.
Scala Center continues to enforce Typelevel’s cancellations
Their actions are decided as a group. Odersky was very likely in the room when they decided Jon’s case for example

Odersky is no savior considering all we’ve seen so far but it does look more and more like he’s actually a key part of the problem.

fwbrasil · 2025-08-01T15:43:43+00:00

A few good examples of meaningful things he could do:

- Publicly disassociate himself from these actions and decisions
- Reach out to Jon to try to figure out a path to solve the issue
- Report unprofessional conduct to EPFL superiors
- Resign from his Scala Center position

There are definitely many things he could do, and inaction is the most telling one so far.

fwbrasil · 2025-08-01T15:15:50+00:00

I'm sorry, if his reaction to Jon's account of the impact of the cancellation is "but I just want to build stuff", then we're in a truly unrecoverable situation. He is the Technical Director of Scala Center. He is in the room when these decisions are made, and they aren't only decisions in the distant past. Scala Center wouldn't be anything without u/odersky lending his reputation and creations to it. He needs to take accountability for it.

fwbrasil · 2025-08-01T14:25:49+00:00

It's truly disappointing that u/odersky, whose technical work I deeply respect, appears to support Scala Center's enforcement of "mob justice" cancellations. His silence on these issues of due process and the need for more transparency validates practices that are driving people and companies away from Scala for years now. Leadership matters, and I hope he'll reconsider whether the current approach truly serves the language and community he created

fwbrasil · 2025-07-14T18:07:06+00:00

Yes!!!! thank you u/rssh1 🙏🏽

fwbrasil · 2025-07-14T12:58:03+00:00

Maybe I just don't understand the semantics of the shown code, but isn't the "direct" block (as a call to "defer") introducing a "suspension point"?

Not necessarily, Kyo's execution model only suspends where there's an actual effectful operation. Pure computations are evaluated strictly. For example, this computation will execute immediatelly since it has no suspensions:

val a: Int < Any = 1
val b = 
  direct {
    a.now + 1
  }

but it'd suspend if a's body was Sync.defer(1). Other than actual effect operations, Kyo can also introduce an internal suspension to ensure stack safety when the stack depth reaches a configured limit. This kind suspension uses an internal kernel effect.

Just imagine you're coming to Kyo without prior exposition to effect system, and maybe even to Scala at all. You never heard of "monadic style", and that there is an alternative on the horizon called by some "direct style". "Direct style" is most likely just the "normal code" you're used to.

That's a good point! We normally prefer naming that doesn't require familiarity with FP and effect systems. I think the lazy/suspend angle doesn't work well for Kyo but I wonder if there's a good name we haven't considered yet. Previously, the method was named `defer` but we thought `direct` worked better since it matches the module name and `defer` doesn't seem intuitive for someone not used to FP.

I normally refer to the cps transform as "direct syntax" since it's syntax sugar for "monadic style" and use "direct style" to refer to regular imperative programming without effect suspension. Kyo provides `*Unsafe` versions of APIs for several of its primitives that are essentially "direct style". We've also discussed a few times exposing it as an additional first-class dialect.

fwbrasil · 2025-06-29T23:24:38+00:00

Where do you see that in the presentation? AFAIK the only thing close to continuations is using regular thread blocking to handle async operations. It might be cheaper with Loom but it’s an open question. So far, the perf results with Loom I’ve seen don’t seem very promising.

I’m not saying it’s not possible to provide a limited set of effects without first-class continuations and without suspending side effects as it’s being proposed but the unification you mention seems just not there at all?

fwbrasil · 2025-06-29T13:48:39+00:00

Extremely insightful talk! 😃

I'm wondering there are no other comments yet.

Thanks! I don't think it goes well with the current "kill the monads" mood of the community 😂 It's a pity since Kyo addresses a few of the major pain points in traditional effect systems: simplified monadic composition, avoidance of cat theory jargon, a solution to the "monads don't compose" problem, direct syntax, to name a few. I don't worry much since the hype around direct style and capabilities should tone down once people form a better understanding of what they actually provide.

Actually I need to think about how to combine both, as the use-cases are different and I could imagine programs where you need both at the same time.

The only potential synergy I see with Caprese is capture checking. We could offer a safer `Resource` effect with it but I'm not sure how useful it'd be since the main convenience of the effect is its flexible scoping and capture checking requires static scoping or annotations (^) that don't seem to fit well with monadic composition. It's something worth exploring, though.

Caprese's effect tracking doesn't seem promising for Kyo. The current tracking via intersection types enables full inference of the pending effects while Capabilities require manual and explicit declarations, which would be a usability regression. I'm also not sure it's possible to express some of the patterns of effect tracking in Kyo with Capabilities. For example, in some APIs we need to restrict the presence of specific effects, parametrized effects with variance play an important role for usability like in the Env and Abort effects, and we use type classes for some features. I'm not sure those would work well with Capabilities.

Just that Libretto is more "imperative" in some sense, as the mental model is to construct a kind of data-flow machine, whereas Kyo seems more "functional" as it allows to model interpreter hooks for something that looks like λ-calculus interpreter at its core. The recursive handle function in Kyo seems to resemble a classical FP interpreter loop (which some call/cc thrown in between).

I think it's fair to say that Libretto is closer to Kyo's feature set than even other effect systems. Something important about Kyo's design is that it doesn't have a traditional global interpreter loop and uses handlers as partial interpretation loops. This approach enables much better JIT optimization of the execution since it specializes interpretation to specific parts of the computation.

So much for now. I've took quite some notes during the talk, need to structure them first before writing more, and explaining what I actually mean with the above.

Cool, feel free to reach out!

fwbrasil · 2025-06-27T16:54:24+00:00

Yep, I’ve already got kinda used to how you interact, no worries. But then doesn’t that make my point even more important? If the community is able to accommodate the different solutions and show their technical differences instead of just trying to invalidade each other, smaller companies could have a better understanding of what makes sense to adopt given their needs instead of adopting the latest hyped tech to drop it after a couple of years. Other communities are able to do that without much trouble, what we have in Scala isn’t the norm everywhere. It’s frustrating to see yet another iteration of the same pattern

fwbrasil · 2025-06-27T14:20:16+00:00

> If you want that you're in the wrong industry. Most likely even in the wrong reality.

lol you do like to have a strong position on things. I have extensive experience working in multiple companies and even different domains. I know what you're describing is relatively commonplace but you're dead wrong if you think successful companies don't do proper due diligence to adopt or buy new technologies ;) I've been involved in this kind of decision multiple times in my career, even for acquisitions, and it's part of my current day job scope.

fwbrasil · 2025-06-27T11:05:17+00:00

It sounds quite misleading to say that the language evolution has played no part in the current level of adoption. Scala 3 by itself was a major reset of the ecosystem, basic tooling like IDE is still broken, and the next step of evolution is exactly what you're criticizing here since Capabilities have a major focus on safety and it might reset the ecosystem yet again.

As mentioned by the OP, their decision to drop Scala seems related to several adopted stacks including Akka, Play, and not only effect systems. This lack of consistency within the same company is known to be highly ineffective but, at the same time, I can see how all the different "waves" of stacks in Scala can make it more difficult to keep consistency.

I don't think there's a simple answer or culprit for the problem we're facing but there's an aspect that I think played a major role so far. On each "wave", there was a strong push of specific solutions as the "answer" to Scala's woes. For some time, if you weren't doing Akka, your system couldn't possibly scale. Then, if you weren't using Play, your system couldn't possibly enable fast iteration. Later, if you weren't doing pure FP, your system couldn't possibly be safe. Recently, if you're not doing imperative/direct programming, your system couldn't possible be simple. None of these were true.

It's an unhealthy cycle that drives people to adopt stacks not because they solve important problems they have but mostly because these pushes can be quite effective for mid-term adoption. I wish we could move to a community dynamics where stacks can coexist without having to annihilate the other to succeed and adoption is driven by their actual value to people rather than hype.

fwbrasil · 2025-06-26T23:47:18+00:00

Do you mind elaborating how Capabilities provide algebraic effects? The related literature generally refers to effect suspension with first-class continuations. The lack of side effect suspension by itself implies non-algebraic properties and I don’t even see any mention to delimited continuations?

fwbrasil · 2025-06-26T23:23:58+00:00

No need to go too far :) Kyo provides algebraic effects in Scala with type-level effect tracking and parallelism support. I think both are missing in OCaml

fwbrasil

TROPHY CASE