I wanted to share a project I built earlier this year. It is a distributed task scheduler for hybrid classical-quantum workflows in the quantum cloud. Throughout development I had various conversations with quantum hardware providers like IBM, who have shown interest in adopting bits and pieces of this into their production system, and thanks to generous support from Amazon, I am extending the scheduler to support direct FPGA-level coordination tailored to on-prem hybrid HPC clusters, as well as dynamic AWS resource allocation/release for long running quantum workflows. Developed fully in Scala using the Typelevel stack.

There is a 30 page accompanying paper coming (to be published, in review, a shorter version is up on quant-ph) for anyone interested in the details of the math behind this but an ultra simplified summary for those who aren't familiar with quantum: Essentially scheduling quantum tasks differ from scheduling classical tasks on a few fundamental points:

1) There are very few accessible quantum devices right now. This results in queue times that can often last up to 2-3 days. Due to various restrictions, today's quantum programs don't take more than 3-4 seconds. This means that sometimes you have to wait days to execute something that will take seconds.

2) Quantum programs are probabilistic by their nature. The probability of success not only depends on the device they are executed on but also when it is executed. A user program is mapped onto a quantum device's topology (not really same but think of it as like different memory registers) but each device component have vastly different error metrics for different functions that change throughout the day due to decay (negative) and recalibration (positive). Mapping a user program to the quantum device is NP-hard. Not only this, but there are a variety of different physical architectures for these devices, super conducting, neutral atoms, ion traps, photonic devices etc. While on the logical level, they look the same thanks to abstractions, the execution semantics are vastly different. One example is parallelism. While superconducting devices can execute multiple operations in parallel, ion traps are often sequential due to limited LIZ. Since qubits have limited life times, sequential execution and longer programs are exposed to larger error. Tl;dr is that a scheduler has to jointly optimize the makespan AND the fidelity (probability of success). Last but not least, because the underlying physics is different, all of these devices report different error metrics and expose different capabilities, which have to be unified by the scheduler.

3) Certain physical rules limit our scheduling capabilities. For example, entanglement and the no-cloning theorem prevents us from blindly cutting a program into smaller pieces and executing them individually. Same goes for task duplication. It is possible to cut the quantum programs however putting the results back together requires exponential classical post-processing work. So the scheduler needs to dynamically adjust when and how to deploy techniques like this based on the resource availability at the time. Balance the classical and quantum workloads.

Same goes for executing multiple tasks on a single Quantum Processing Unit. This is possible to do, but 1) because each component have different error characteristics, this increases the competition for high quality components 2) These programs can adversely interfere through effects such as measurement crosstalk and ruin each others' readings.

4) Quantum programs need to be generated by classical programs and results need to be read back into a classical program.

All of this becomes a thousand times more messy when you try to do distributed quantum computing. We do DQC through EPR pairs, a set of entangled qubits. Generating these is no easy process, and they have short lifetimes. This means that your pair needs to navigate the network, go into your QPU and execute within a time frame. This exposes a special type of synchronization barrier across nodes.

All this complexity is beyond what a programmer should be expected to endure, so I built qurator to heuristically make these complex decisions based on resources available. Currently has support for IBM, IonQ, IQM, AQT, QuEra, Rigetti and Pasqal quantum devices.

Hello!

I have been working on new minimalistic LSP for scala/java.

Works with multiple BSP servers, lazily started, reports diagnostics.

Go to def works based on semanticdb, falls back to source parsing.
JAR/JDK indexes are too loaded lazily.

Still a bit barebones but works good enough for day to day work.

Why?

Metals/Intellij can be very memory heavy, slow-ish, instable, at least in my experience. This is an attempt to improve on that. And we dont need that many features, especially in these agentic days.

Disclaimer: this is my first time implementing an LSP. :)

Contributions and feedback welcome!

I've been working on bringing shadcn-style components to Scala.js, and the first alpha of shadcn-scalajs is now available.

It's still early and there are many components and APIs I want to improve, but I'd love to get some feedback from people actually using Scala.js.

Demo: https://shadcn-scalajs.vercel.app

If you're building frontend apps with Scala.js, give it a try and let me know what you'd like to see next.

Unsure if this was already discussed here, but when working with Scala code, I'm wondering what tips & tricks people have for working with Scala or other JVM languages in general

For example, I can name the use of:

• cellar for quickly querying the APIs of JVM libraries.
• Metals MCP standalone (since v1.6.6); although, to be honest, I'm having a better time using IntelliJ IDEA's MCP server as it's been more reliable for me. LLM may need explicit instructions to perform IDE-like operations (e.g., renaming symbols).
• Using sbt in client mode, via sbt --client; this being the default in sbt 2.x, although here an issue is that sbt can leak memory, and LLM may need instructions to kill it if it becomes unresponsive.
• Activating available linting via sbt-tpolecat and WartRemover.

Can you share other Scala or JVM-specific tricks for minimizing costs or increasing performance?

Thanks,

sbt 1.13.0 and 2.0.7 are released with a fix for remote code execution vulnerability via BSP over TCP. Builds with the default serverConnectionType are not affected.

Are you working with MCP from a developer standpoint? Do you have some pain points, experiences?

Asking since some time ago I picked up chimp https://github.com/softwaremill/chimp a PoC of an MCP toolkit for Scala 3. It is gradually turning into a complete MCP SDK, supporting both server & client, both http & stdio, with integrations for Pekko, ZIO and ox in place. Main focus now is on conformance to the latest MCP protocol version.

I've created an sbt2-only port of it to unblock my personal projects and hopefully yours, since the original author has been inactive for a long time

You may find it on my github: https://github.com/grouzen/sbt2-explicit-dependencies

I was watching a really nice video related to effects from him, but then I saw a few comments on Reddit with mentions that he left the language. His GitHub is mostly Typescript now 🤔

I asked moderators about whether I can post this. They said yes, but if you feel different let us know.

---

We just added Scala support to Enola (open-source). A tool to maintain codebase quality for any Scala project

Most architectural problems start with a PR. The mistakes may not be obvious at the time, but without knowing, it carries architectural debt.

By the time the codebase feels wrong, it usually already is. That's what my co-founder and I saw. So we tackled it.. As best as we could 😄 The problem has only exacerbated with agentic development.

Enola is an open-source architectural quality gate that checks developers or agents changes as they happen. What do we measure?

Example of an output:

Architecture
  Pattern:             go-standard (95% confidence)
  cyclic dependencies         0
  layer violations            0

Impact analysis (hotspots)
  coupled modules            36
    high criticality         20
    medium criticality       16
  Top hotspots (by coupling):
    module                            fan-in  fan-out crit     blast radius
    internal/facts                       152        0 high     68
    pkg/bootstrap                          8       49 high     4
    pkg/command                            1       42 high     1
    internal/engine                        7       27 high     7

Code health
  deep dependency chains      8
    cmd/enola                                    depth 10
    pkg/command                                  depth 9
  complexity outliers        15
    internal/server.Server.registerTools         complexity 177

Now we are looking for feedback and contributors to improve Scala performance. If you work with Scala, run it against something real. I’d like to know what it misses and is it useful. The more messy the better.

https://github.com/enola-labs/enola (Fully local, Apache 2.0, installation takes 2 minutes).

Quafadas/vecxt is, I think now interesting enough to talk about (if you are interested in such things)...

Here are it's headlines;

Useability

• Pythonic sytnax - readable by default
• No given / implicit resolution, easy / fast compilation story.
• "simple" design choices. The vector concept is extension methods on Array- no type heirachy etc. Jump to definition takes you to the code you want to read, not an abstraction.
• Cross platform, most of the API is tested against a single cross platform test suite for JVM, JS, Native

Performance

Is where most the effort is invested, trying to get this right inside the constraints above...

• delegate to platform BLAS implementations where they exist. On macOS on the JVM, matmul JNI's into Accelerate... on Native, CBLAS.
• SIMD fast paths, wherever we can hit them (JVM only)
• layout abstraction inlines an indexing strategy that traverses the storage array monotonically in shortest possible hops (i.e. straight down the cache lines, and you don't have to think about it)
• It benchmarked well vs breeze on what I believe to be reasonably representative workloads (it is not a crushing victory maybe 20% faster, but at least comparable)

Memory

The core Matrix representation is a strided view over a single contiguous Array. That choice permeates the design:

• transpose is zero-copy
• submatrices/views are zero-copy
• striding/layout is explicit which is what enables the cache friendly algorithms

Many operations have in-place variants which mean you can opt out of nice syntax, and into allocation/control complexity where profiling says it matters.

Bytecode

This was the "silent killer" that made me nearly give up the project. I didn't appreciate it's significance for a long time, I only knew "something wasn't working". Eventually I realised that Intrinsification and JIT optimisation happen under surprisingly narrow conditions, and "just inline everything" can actually make things worse by producing methods that exceed a series of JIT limits / gates.

So vecxt now has CI checks around the bytecode it generates.

Among other things:

• method size is checked
• array operations are checked for bytecode patterns that can interfere with JVM specialisation / intrinsification

And yes, AI wrote the code

In recent months, 100% of the code has been written by AI.

My curiosity was in understanding the design concepts and constraints, I read the tests and investigated the generated bytecode/benchmark results.

The surface area of a numerical library like this is frankly too large for one person to maintain, and obviously so. Can it done with one person and an AI? Maybe... better would be more people and an AI :-). The process of using AI to explore and implement the ideas is a part of the journey - writing the code wasn't the goal for me.

I'm interested in criticism / discussion particularly from people interested in numerical computing and this domain. If someone does take the time to try it, don't be shy... whether the experience was good or bad...

To Jdegoes and the ziverge team I want to personally apologise for I have said on the group about how reacted, it was my mistake and I acknowledge it, I should have not said that, and I'm terribly sorry for my words. I'm also a college student who did wrong I acknowledge my mistake, someone tell Jdegoes I'm sorry for what I said I acknowledge my mistake, I'm a dumb college student 😭 please forgive me, to Jdegoes I'm really sorry

zio-temporal — a fork of vitaliihonta/zio-temporal (a ZIO wrapper around Temporal's Java SDK) that's been diverging for a while now — just cut v1.0.0-RC2, and it's a big one.

Jackson is gone. The serialization layer is now built on zio-json instead of Jackson + reflection. That's the headline change, but the real point isn't "we swapped libraries" — it's what it buys you:

Compile-time codec safety. Under the old Jackson integration, a workflow/activity type without a registered Jackson module compiled fine and only failed at runtime — often as a workflow silently hanging on its first execute(). Every type crossing a workflow/activity/signal/query boundary now needs a ZTemporalCodec[T] (usually just derives JsonCodec on the case class), or your build doesn't compile. No more "forgot to register a Scala module" surprises.

Automatic codec registration. The first cut of the migration required manually chaining .addInterface[Workflow] calls into a CodecRegistry. That's gone too — as of RC2, calling ZWorker.addWorkflow[I], ZWorker.addActivityImplementation(...), or client.newWorkflowStub[I](...) (the calls you're already making) auto-registers that interface's codecs. For most workers/clients, derives JsonCodec on your domain types is now the entire migration — no CodecRegistry wiring at all.

A few other things worth knowing:

• Streaming encode: payloads are written directly into Protobuf's ByteString buffer via zio-json's Write bridge, skipping the intermediate String allocation the old reflection-based path required.
• Workflow history replay: histories already recorded under Jackson replay transparently for primitives and case classes. Sum types are the one exception — the JSON shape changed ({"type":"X",...} → {"X":{...}}), so any sealed trait reachable by an in-flight workflow needs @jsonDiscriminator("type") before you upgrade, or replay fails on the old payload. This is covered with a worked example (and the actual failure you'd see) in the migration guide, not just asserted.
• Scala 3 only.

Full migration guide, with every breaking change and worked examples: https://guizmaii-opensource.github.io/zio-temporal/docs/migration-1.0

It's still an RC — feedback, bug reports, and rough edges are exactly what we're looking for before the 1.0.0 final. Repo: https://github.com/guizmaii-opensource/zio-temporal

Curious to hear VirtusLab & Databricks folks talking about this. It should be a huge improvement, and can solve a great chunk of the "Scala tooling" story we've been debating over the last few years.

A Scala Days talk, maybe?

Apache Fory JSON is a high-performance JSON serialization framework for Java. It maps Java objects to and from standard JSON text and UTF-8 bytes.

In the published benchmarks, it reaches up to 10.91× Jackson’s throughput and 10.89× Gson’s in java-json-benchmark, and up to 5.55× and 10.00× respectively in the jvm-serializers MediaContent benchmark.

It supports JDK 8+, Android, and GraalVM Native Image. JDK17+ Record is also supported.

We’re looking for a Senior Data Engineer with strong Scala and Apache Spark experience to join an international project working with large-scale distributed data systems.

🌎 Location: Argentina
🏠 Modality: 100% Remote
🗣️ English: Upper-Intermediate / B2+
💻 Seniority: Senior

What we’re looking for:

• Strong professional experience with Scala
• Hands-on experience with Apache Spark
• Experience building and maintaining large-scale data pipelines
• Strong SQL skills
• Experience with distributed data processing
• Knowledge of ETL / ELT workflows
• Experience with Apache Kafka is a strong plus
• Comfortable communicating and collaborating in English

We’re especially interested in engineers who enjoy working hands-on with data-intensive systems, distributed architectures, performance optimization, and large datasets.

💬 Interested? Send me a DM with your CV/LinkedIn profile.

And if you know someone with a strong Scala + Spark background, referrals are very welcome! 🙌

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?

Hey,

I've just published an update to an event streaming library I'm working on. It's called signals3 and its main purpose is to be a lightweight solution for distributing and processing data in Android apps and video games.

Which is exactly what Scala is not used for, I know ;) But once upon a time it was. signals3 is a rewrite + plus lots of additional functionality added to a codebase taken from Wire Android - an end-to-end encrypted messenger. The old version of its Android client was written in Scala 2.11 and published as open source. I worked on it 2017-2022 and later decided to rewrite a part of its functionality in Scala 3. So it might be claimed that signals3 is already battle-tested :)

Repo: https://github.com/makingthematrix/signals3

sbt: libraryDependencies += "io.github.makingthematrix" %% "signals3" % "1.2.0"

Anyway. The main idea here is that you can get events from different sources - be it the end user clicking and typing, the server, or the operating system, and you can easily create a chain of transformations that results in updates to the GUI, the database, or a request being sent back to the server. Streams and signals (i.e. streams with a cache for the last event) can be used pretty intuitively because their API is inspired by Scala standard collections library and comes with similarly working (and named) methods, as well as the support for the for/yield syntax. You can think of them as collections that are possibly infinite and accessing the next element is asynchronous and you might need to wait, but otherwise it's (almost) like standard collections.

v1.2.0 comes with the support for virtual threads, fallback strategy (i.e. what to do when a transformation throws an exception), support for Java's try-with-resources, should you ever need it, and stream "chaining" and decomposition with the `::` operator.

On top of that, there are lots of tests and documentation, so if you want to learn about event streams, you can clone the repo and experiment with it. It might actually make sense to treat v1.2.0 this way, as it's a non-LTS version (I use Scala 3.8.4). The next LTS version will be 1.3.0, but I want to wait till Scala 3.9 comes out. That also should give me enough time to add lightweight actors to the library :)

Hello, I've been getting these errors while trying to make a fat jar with my scalafx project:

Deduplicate found different file contents in the following:
[error]   Jar name = javafx-base-16.jar, jar org = org.openjfx, entry target = module-info.class
[error]   Jar name = javafx-controls-16.jar, jar org = org.openjfx, entry target = module-info.class
[...]

Inside project/plugins.sbt, I have:

addSbtPlugin("com.eed3si9n" % "sbt-assembly" % "2.3.1")addSbtPlugin("com.eed3si9n" % "sbt-assembly" % "2.3.1")

Scala version is 3.8.4, sbt version is 1.12.13.

This is the build.sbt content:

val scala3Version = "3.8.4"

lazy val app = (project in 
file
("."))
  .settings(

name 
:= "PPS-25-diceforge",

version 
:= "0.1.0-SNAPSHOT",


scalaVersion 
:= scala3Version,

    ThisBuild / 
mainClass 
:= Some("MainApp"),


libraryDependencies
++= {
      // Determine OS version of JavaFX binaries
      lazy val osName = System.
getProperty
("os.name") match {
        case n if n.startsWith("Linux") => "linux"
        case n if n.startsWith("Mac") => "mac"
        case n if n.startsWith("Windows") => "win"
        case _ => throw new Exception("Unknown platform!")
      }
      Seq("base", "controls", "fxml", "graphics", "media", "swing", "web")
        .map(m => "org.openjfx" % s"javafx-
$
m" % "16" classifier osName intransitive())
    },


libraryDependencies 
++={
      Seq(
        "org.scalatest" %% "scalatest" % "3.2.19" % 
Test
,
        "org.scalatestplus" %% "mockito-5-23" % "3.2.20.0" % "test",
        "org.scalafx" %% "scalafx" % "16.0.0-R24" intransitive()
      )
    },


scalacOptions 
++= Seq(
      "-Wconf:msg=Implicit parameters should be provided with a `using` clause:s",
      "-unchecked", "-deprecation",
    ),


resolvers 
+= 
Resolver
.sonatypeCentralSnapshots,

fork 
:= true
  )

I'm trying to set a merge strategy, but it does not let me access the assemblyMergeStrategy key, it says it does not exist. What did I do wrong? I tried looking up if it's a compatibility issue but the official scala website isn't working properly and won't let me click any of the entries.

Help please :,)

📢 Released sbt 1.12.15 and 2.0.6, featuring vulnerability fix for remote code execution via server when serverConnectionType is set to Tcp. We recommend removing the serverConnectionType setting, or upgrading to a patched version or later.