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

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

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 :)