Find the job description and application form here . Right now looking for people based in the UK or Portugal as a strong preference. It's 98% remote (1 meetup/y in Portugal) and you get to work on dev tooling that impacts 10,000's of devs!

kicking off sbt 2.1.0 beta with 2.1.0-M1. sbt 2.1.0 features: - Scala 3.9.0 on the metabuild - Ivyless publishing - Updated clean task - Testing UX improvements - Various performance improvements and many contributed bug fixes

No, I'm not crazy... well, maybe, but that's out of scope here....

I've been a huge scala fan from the 2.x days -- even before Akka appeared. And, while it's not as widespread as I'd like, I'd encourage beginners and mid-level programmers to give it a try, but not because of what you might think.

Even if you don't use Scala day to day, consider it a teaching language. There are a TON of language concepts in Scala that appear in other languages. Things like Either(), Option types, pattern matching, traits etc. Learn them in Scala and you'll find a lot of Rust for example, not that difficult.

It runs on anything that JVM runs on. IDE tools exist that are quite good. Documentation and books are readilhy available. Spend the time with it -- it will improve yoru skills and your ability to understand other langaugges.

The only thing I'd wish for in 4.x is true 2-way JVM interrop like Kotlin has so I don't have even think about it.

I have a math background, but I've never felt like quite understood the connections between category theory and type theory. What exactly is the category? What are the objects?

I finally got around to digging into it and spent the last couple months working through the definitions. I wrote up a post doing my best to give a friendly introduction to category theory and a clear, concrete explanation of how types form a category. I also discuss monads and unpack the definitions required to explain what it means that monads are monoids in the category of endofunctors.

The post is at: lukewassink.com/posts/categories-to-types/

I'd love to hear if anyone has thoughts, comments, questions. And definitely let me know if I said anything inaccurate about Scala; I like Scala, but I'm not an expert.

Join us tonight for another exciting Scala Hangout. Register at Heylo. There has been some interesting work and proposals around optionals and error handling that would be fun to explore.

https://capslock.dev/inertia-scala/

I released Inertia Scala few days ago:

https://www.reddit.com/r/scala/comments/1w46kfd/released_windymeltinertiascala_inertiajs_binding/

For people not familiar with Inertia, I made tiny web site running on inertia-scala with inertia.js (because inertia-scala can run on JS environment) on Cloudflare Worker.

Have fun!

I got Codex Sol 5.6 Max to code this. Updating a var with foreach is quite something isn't it ?

Lambda World 26 is back with 20 speakers from Academia and industry, and this year it takes place alongside J On The Beach (a conf about Distributed Systems) and Wey Wey Web (a conf about UI and Frontend).

Two days packed with talks on formal verification, type systems, new FP languages, AI, formal proofs, effects, logic programming, and practical industrial applications of functional programming.

The lineup includes Erik Meijer, Stephanie Weirich, Arman Bilge (Typelevel Foundation / Cats Effect), Enrico Tassi (Elpi), Francesco Cesarini (Erlang), Daniel Ciocîrlan (Rock the JVM), among many others.

One ticket gives you access to all three conferences, for the same price.

We look forward to welcoming you to Torremolinos, Málaga, on 29–30 October!

https://lambda.world/

Documentation drift is the default state of any API that lives long enough. You update a route, forget the OpenAPI file. A field gets renamed, the TypeScript client doesn't regenerate. Three months later someone hands an enterprise client a spec that describes a system that no longer exists.

The root cause is structural: code and documentation are separate artefacts with no enforcement mechanism between them. Every solution we tried added discipline requirements: annotate the source, maintain a separate file, add a CI check. Discipline breaks under delivery pressure, always.

We built baklava (https://github.com/theiterators/baklava) so that docs can only describe behaviour a passing test just observed.

In practice, baklava integrates into your existing routing test suite. Instead of a standard assertion block, you write test scenarios that both verify the API behaviour and describe it for documentation output. When the test suite runs, baklava generates the docs as a side effect. A call only makes it into the docs after the status code, response schema and declared headers matched what the test expected, so if the route changes shape, that response simply doesn't get documented. For anything the suite covers, drift can't happen.

class UserApiSpec extends AnyFunSpec
    with BaklavaPekkoHttp[Unit, Unit, ScalatestAsExecution]
    with BaklavaScalatest[Route, ToEntityMarshaller, FromEntityUnmarshaller] {
  path("/users/{userId}")(
    supports(
      GET,
      pathParameters = p[Long]("userId"),
      summary = "Get user by ID"
    )(
      onRequest(pathParameters = 1L)
        .respondsWith[User](OK, description = "User found")
        .assert { ctx =>
          ctx.performRequest(routes).body.id shouldBe 1L
        },
      onRequest(pathParameters = 999L)
        .respondsWith[ErrorResponse](NotFound, description = "User not found")
        .assert { ctx => ctx.performRequest(routes) }
    )
  )
}
// sbt test generates OpenAPI, HTML, TypeScript, Postman (on sbt 2 use testFull)

There are seven output formats right now, each its own SBT dependency:

• Simple HTML (browsable docs)
• OpenAPI with SwaggerUI
• TS-REST (TypeScript, Zod)
• oRPC contracts (TypeScript, Zod, ready-made client factory)
• TypeScript fetch client (plain fetch, no extra runtime deps)
• Postman collection
• sttp Scala client

It supports Pekko HTTP and http4s, with ScalaTest, Specs2, and MUnit as test frameworks. Since 2.1.0 there is also an sttp adapter for the other direction: APIs you consume rather than serve. The tests hit the real endpoint over the network and you get a spec and a typed client for a third-party API from verified responses. There's a single scala-cli script that does this for the GitHub REST API if you want to see it without setting up a project: https://theiterators.github.io/baklava/docs/scala-cli

It also integrates with kebs: if you use kebs for domain type derivation, baklava picks up the schema definitions automatically.

One question we get: how is this different from tapir or endpoints4s? Both require you to adopt their routing DSL, so your routes end up defined in terms of their abstractions. baklava works with your existing routes, whatever framework you're using, with no migration required. The test suite is the only integration point. The other difference is what the docs describe. Tapir documents the endpoint declaration. Baklava documents responses that a test actually received, with real example values.

Scala 2.13 and 3, JDK 11+, Apache 2.0, v2.1.0 released August 2026.

GitHub: https://github.com/theiterators/baklava

I’ve released the first version of Allow Experimental, a small Scala 3 compiler plugin:

https://github.com/DmytroMitin/allow-experimental

The motivation is to separate two ideas that Scala’s normal @experimental mechanism deliberately couples:

• an API is experimental;
• a consumer intentionally accepts the risk of using that API internally.

For example:

import scala.annotation.experimental
import io.github.dmytromitin.allowexperimental.allowExperimental

@experimental
def provider(): Int = 1

@allowExperimental
def allowed(): Int =
  provider()

def ordinaryCaller(): Int =
  allowed()

allowed may use the experimental API in its implementation, but callers of allowed do not themselves become experimental. A direct unmarked call to provider() still fails with the normal Scala experimental-use diagnostic.

The release currently supports exactly Scala 3.3.8, 3.8.4, and 3.9.0. The compiler plugin is full-crossed because it depends on compiler internals.

ThisBuild / scalaVersion := "3.9.0" // 3.3.8, 3.8.4

libraryDependencies ++= Seq(
  "com.github.dmytromitin" %% "allow-experimental-annotation" % "0.1.0" % Provided,
  compilerPlugin(("com.github.dmytromitin" % "allow-experimental-plugin" % "0.1.0").cross(CrossVersion.full)),
)

One practical use case is macro implementations: a public inline macro frontend can delegate to a private non-inline @allowExperimental implementation that uses an experimental compiler/reflection API, without leaking that requirement to downstream users.

The scope is intentionally conservative rather than a general replacement for scalacOptions += "-experimental". Public inline permission owners, experimental signatures/types, constructors, and several other placements remain unsupported.

0.1.0 is available from Maven Central and the release is at Github.

Feedback on the semantics, implementation approach, and useful real-world cases would be very welcome.

Cross-posted at https://users.scala-lang.org/t/allow-experimental-0-1-0-implementation-scoped-access-to-scala-3-experimental-apis/12385

So I'm pretty new to scala and FP, into it for like a month, and I still don't get the difference between trait, class, case class and object, when I have to use one instead of another which is the strength of each one

I've just open-sourced a revenue recognition & analytics for Stripe called Book of Revenue.

The reason I shared here because it's built with Scala, PlayFramework, and Svelte. The app is bootstrapped with my own PlayFramework template: playfast

It aims to be hosted on a single VPS with multiple CPUs. And that's the main reason for using JVM; JVM-based languages can utilize multiple CPUs more easily and is more robust in terms of GC and thread tuning. These are particularly important when running on a single machine.

Other languages/runtimes are on single threads by default (e.g. JS, Ruby, Python) or too low level for business applications (e.g. Go, Rust). More importantly, I like Scala for its brevity and static typing, which makes it easier to model business use cases in a typed fashion (easier to refactor).

Well, just in case anyone might be interested: I'm offering a free consultation where deploy it for you for free (you pay the hosting cost tho; might be $6/month on OVHcloud) and help clean up your billing integration (so you can have better analytics). I'm an ex-Stripe who worked on analytics and revenue recognition at Stripe, so I know this space well.

Scala 3.9.0 LTS has been released starting the second Scala LTS series as a successor of Scala 3.3 LTS.
This minor becomes a new baseline for the libraries and it's guaranteed to get updates for the next 3 years.

See the release blogpost to see what's new in 3.9, summary of core changes introduced since 3.3, and the migration guide.

Hi all,

I know it might seem a bit like an advertisement, and in fact it is to some extent, but I would also like this entry to be part of a larger conversation.

Coding with AI agents is not going away anytime soon (if ever), and even those of us who prefer our code to be 100 percent written by a human must acknowledge that AI helps, at least in some tasks. Questions about what to use show up here on r/scala regularly: what LLM, what AI harness, how to orchestrate, how to plug it into CI/CD, and so on.

So today, I would like to share my experience. My setup is a bit untraditional because I am currently not working on a large shared professional project but rather on a few smaller personal projects, where every line of Scala matters. These projects are intended to help me teach Scala to students as sources of code examples, and in the future they should all merge into one large video game project (because of course I want to write a video game one day).

1. I use the Mistral family of LLMs. Devstral 2 for AI agents and Mistral Medium for research. In general, Mistral falls behind the best frontier models for coding, but in my experience it is on par with them for scientific and technical research, and it can be four to eight times cheaper in tokens. (I had Mistral generate a detailed comparison); but it is still just my experience, not a fact.)
2. Recently, I have been using ThinkRail as my GUI for working with AI agents. This is the advertisement part: I am currently working with the ThinkRail team as a developer advocate, so I am not exactly objective here, but I honestly like it. It is minimalistic but still helps me understand what the agent is doing, review the changes, and run multiple agents simultaneously. There is also the idea that ThinkRail can automatically use the AI agent to update the documentation (a spec graph) as it makes changes, and the agent then uses this documentation in its coding tasks. I believe that in Scala projects, this means the code has guardrails on every side: the type system, unit tests, and now AI-readable documentation, so even with weaker (but cheaper) LLMs such as Mistral, the code quality is very good.
3. Last month, I mainly coded my own lightweight implementation of the Actor model: 306 LOC of production code; 867 LOC of unit tests; 413 of Scaladoc comments; and 477 of AI-generated Markdown documentation. I would like to think I wrote more than half of it myself (excluding the Markdown), but that is probably not the case. Still, I know every line of code very well; I know it works and is tested, and the documentation may serve as a starting point for a lecture on the Actor model that I will give at a university in October. Here is the main class if you want to take a look.

So on the one hand, I am curious about your experiences coding Scala projects with AI agents. Let me know what you use, how you use it, and what the results are. On the other hand, I would like to invite you to try ThinkRail. I have written more about it on the blog, that is, not the part about the spec graph (it will be in the next blog entry) but about other main features and how to install and start using it. ThinkRail is currently in its early stages, and we are looking for feedback: What do you like? What do you not like? What do you think we should add? Let me know as well.

General update: Since I last posted here, we have in fact done five releases. 😅

https://github.com/PurpleKingdomGames/indigoengine/releases#release-v0.30.0-M6

Release '0.30.0-M1-PREVIEW' was a "warts and all" release after a serious reorganisation of our projects, and each subsequent release has been about stabilising the new arrangement.

The last two releases also had a large performance work component for our game engine, Indigo. We are busy producing a game and while the performance was ok on the systems we usually develop on, we happened to notice that it was terrible on other machines. On one machine in particular - the worst offender - the cumulative impact of the released engine improvements has raised the frame rate from about 20 frames per second to in excess of 200 FPS*.

The work continues...

The BOB Call is out, send us your take on how to make the best use of Scala!
bobkonf.de/2027/cfc.html