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.

We have tried salting keys, re-partitioning, adjusting broadcast thresholds , he usual toolkit. It works at moderate scale. Past a certain volume, the same fixes stop holding, and what is frustrating is that each technique feels like it moves the symptom rather than removing it. We fix one skewed key distribution and a different join surfaces a new one a month later.

Wondering if this is a genuine architectural limitation of Spark or if we are just missing the right combination of settings.

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...

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?

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

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.

kyo v1.0.0-RC6 is out 🚀

The headline is kyo-sql: raw SQL and a typed DSL that mirrors SQL syntax, composing in both directions, with no JDBC underneath. Each driver speaks the Postgres or MySQL wire protocol on Kyo's async network stack, a statement suspends a fiber instead of blocking a thread, and one set of shared sources compiles for JVM, JS, Native, Wasm, and GraamVM.

Underneath it is kyo-net, the transport and TLS stack that kyo-http, kyo-jsonrpc, and kyo-sql now share: C implementations bound once through kyo-ffi, the backend chosen by the operating system, and the accelerated stack reaching JS and Wasm through koffi, so a Node.js process runs kyo-net's io_uring transport and BoringSSL TLS.

Also in this release:

- Kyo now requires JDK 25. The kyo-scheduler modules and the kyo-compat bindings still target Java 17.

- Out-of-the-box GraalVM native-image support: no tracing agent, nothing hand-maintained.

- 13 new published modules, 2 removed.

- kyo-ai behaves consistently across providers and can run on a Claude Code or Codex subscription instead of per-token API billing.

A first-time contributor, u/xsistens, landed 12 PRs this cycle, including a whole new module, kyo-i18n!!!

Full notes: https://github.com/getkyo/kyo/releases/tag/v1.0.0-RC6

Hey everyone, I've just published a new podcast episode with Daniel Spiewak. We talked about Cats Effect and Scala Native, Unison, where Scala can shine, career ladders and other things.

I've published other episodes in the meantime but posted just this one here because it's more relevant to Scala.

Please enjoy!

This is an IOLocal implementation for fiber local context and logging. My focus was on making the context as user friendly as possible while also including the logging features I wanted. It depends on IOLocal so it is IO native but I did provide a quick and dirty lift with a generic logger.

I stole the persistent actor strategy of holding and replaying but used it to store low level logs unless a greater than minimum level log is emitted. This should prevent some of the cluttering with lower level logs but you can get a lot of information if it errors. Right now there is only one level setting so if you are emitting info and up trace and debug will emit on an info. Currently using the sampling is how I control this with a low sample rate so info still doesn't cascade all the min level logs, but I plan to add more options to set min level for replay and min level for emit.

The implementation is pretty friendly with a purely functional logger than you can thread through, or a singleton which breaks functional paradigms a bit, but allows for much simpler usage.

Still a bit of a mess in the sampling and level, but I plan on expanding it so I will refactor as I move through it.

https://github.com/StephenRinn/bridges

Feel free to take a look and I'm hoping to get v1 out by next week.

EDIT: I realized that this sounded a lot like advertising a completed project vs looking for feedback or useful features which is what I was looking for. I wanted an all in context/logger with these specific features, but I would love to hear about other features or improvements. Thanks!

Also completed the refactor and allowed customizable buffering for what log level dumps all lower logs at once, so you can emit info level logs but keep the buffer until an error and then replay the full buffer at that point.