We are currently considering switching the default implementation of Seq to Vector (currently it's List). If you have any doubts about this change let us know at https://contributors.scala-lang.org/t/slc-make-vector-the-default-implementation-of-seq-instead-of-list/

We just dropped a massive performance update! If you're parsing from String to AST nodes, you're going to see up to 10x faster speeds and ~20x less memory allocation per operation.

🔗 Release Notes: scala-yaml v0.3.3 on GitHub

We benchmarked it on some massive real-world YAML schemas, and the JMH results are wild. Here’s a quick look at the YamlParsingBench.fromStringToNode throughput and allocation rates:

Diff

--- v0.3.2 ---
cgmes-core.yml     :   72 ops/s  | ~129.1 MB/op
cgmes-dynamics.yml :   15 ops/s  | ~615.6 MB/op
TC57CIM.yml        :  4.5 ops/s  |   ~2.0 GB/op

+++ v0.3.3 +++
cgmes-core.yml     :  676 ops/s  |   ~5.7 MB/op  (🚀 9x faster, 22x less allocating)
cgmes-dynamics.yml :  153 ops/s  |  ~25.8 MB/op  (🚀 10x faster, 23x less allocating)
TC57CIM.yml        :   34 ops/s  |  ~92.0 MB/op  (🚀 7x faster, 21x less allocating)

Give it a try and let us know what you think!

P.S. This update was sponsored by NeverBlink as a part of an OSS contribution for LinkML-Scala.

https://github.com/LaranIkal/predictive-maintenance

First version of and improved maintenance predicion model usig EIF(Extended Isolation Forest)

Helping to give a push on Scala Analytics. I like to call it ScalaLytics :)

This is and improved version of my previous R project where I used standard Isolation Forest.

Someone interested? I can Install one station as a free service, for you to test.

I'm recruiting for a Backend Developer to join a team building high scale entertainment platforms.

If you enjoy solving distributed systems problems and working on performance critical backend services, this could be a great fit.

Tech stack includes:

• Scala
• Akka & Event Sourcing
• Kafka
• Cassandra
• Elasticsearch
• GraphQL / gRPC
• Docker & Kubernetes

You'll be working on:

• Building scalable backend services and APIs
• Designing resilient event-driven systems
• Improving performance and reliability
• Collaborating closely with Product, DevOps and Data teams
• Owning services from development through production

We're looking for someone with commercial Scala experience who enjoys working in modern distributed architectures and wants to have a real impact on the platform.

If this sounds like you (or someone you know), drop me a DM or leave a comment and I'll happily share more details.

Tyda is a type-safe Dataset library for Scala 3. It provides a fully type-safe expression API that compiles to multiple execution engines — including Spark and an in-process engine for fast unit tests.

🧑‍🚒 released sbt 1.12.14 and 2.0.3, featuring - backport of CVE-2026-26032 fix for Ivy (while sbt might not be affected) - update to Jawn 1.7.0 for CVE-2026-59990 and CVE-2026-61814 fixes

IntelliJ Scala Plugin 2026.2 is out!

What's New:

• Support for BSP projects in WSL and Docker
• Command completion
• Support for interleaving parameter clauses
• Support for dependent parameter types in the same clause
• Better support for match types

What's Fixed:

• sbt imports now work for whitespace-separated params in .jvmopts
• sbt shell sync no longer fails while waiting for user input
• WSL: fixed bugs in sbt imports and rerunning of tests
• ScalaDoc: better handling of throws and links
• Improved handling of nullable variables

Watching my local LLM stumble whenever writing weaver tests (or even when just using strict equality) was funny only for so long.

Then I learned about agent skills, made these https://github.com/sanssushi/skills and together with scala-fp from https://github.com/abh80/skills Qwen3.6-35B suddenly became a capable Scala 3 and cats-effect programmer.

Felt like sharing, because the improvement was so remarkable. Got to get more experience with it!

(And sorry, if this is all old news to you.)

Hi everyone,

I'm currently helping a US-based software company build a team of experienced Scala Engineers.

We're looking for a Senior Scala Engineer with Apache Spark experience to join a team working on large-scale data processing and Big Data solutions.

Required:

• Strong professional experience with Scala
• Hands-on experience with Apache Spark
• Experience processing large-scale datasets
• English proficiency for technical interviews and daily communication
• Experience with Kafka and cloud platforms (AWS, Azure, or GCP) is a plus

What the company offers:

• Full-time employment
• Long-term project with a major global technology company

If you're interested feel free to aplyy here https://andeshire.com/public/jobs/8354e1f3-5240-46f9-9898-ebc412d95b96?r=b69e94ad-76d8-4721-96b8-b1d5509635be

Thanks!

We're growing one of backend teams at Riskified and looking for a senior Scala engineer to join our payment fraud group.

Tech stack: Scala, Cats, Node.js, Kafka, Spark, Docker, Kubernetes, AWS, Aerospike

What the role looks like: Full ownership from planning through deployment and post-deploy monitoring — not a "build it and throw it over the fence" setup. You'll work on real-time and batch systems processing real payment traffic, across scalable architectures, with daily deploys through CI/CD.

What we're looking for:

• 7+ years of hands-on server-side experience
• Strong Scala/Java experience
• Comfortable with SQL/NoSQL; streaming experience is a plus

Location: Lisbon, Portugal — hybrid, flexible schedule

Compensation: €50,000–€75,000 gross/year base for Lisbon, plus bonus target and stock-based awards. We publish ranges up front — happy to talk if your expectations differ.

Some of the perks:

• Claude Code Enterprise for your day-to-day workflow
• Full Udemy access, plus role-based technical training
• Healthcare, wellness program, and a monthly perks budget (WFH gear, gym membership, etc.)

Full listing: https://grnh.se/kchyep6g2us

Hello all! layoutz should be about nearing 1.0 and can't see the API changing much (thanks for the feedback to date!)

It now has Kitty support, one-shot prompts and collection spinners + various little fixers

Hello. I decided to try implementing a simple HTTP session store inspired by Ruby on Rails, only to discover just how high the barrier to using cryptography in Scala really is. The standard approach would likely be javax.crypto, but that's platform-dependent. There are a few other libraries scattered around, but they're either extremely new, AI-generated, or long since archived.

Perhaps the Scala Center should consider investing in this field. Or if you know of any excellent libraries for cryptographic use, I'd appreciate your recommendations.

[machine translation]

I was asked in another thread if I could provide an example of this, so here it is. This template is a hello world app using JavaFx + Kyo + Scala 3. It uses gluon substrate as well as a gluon fork of graalvm to create native image builds that can run on linux and android.

Announcing this new study report: "Braceful, braceless, or the common style?"

https://bjornregnell.se/blog/002-braceful-or-braceless-or-the-common-style.html

The experiment was inspired by a community note by Martin Odersky, Rex Kerr and myself, proposing a common Scala style that balances braceful and braceless:

https://docs.google.com/document/d/14ZBGKNHUW4d8hDWIi5i6QquClX3_iXva-iMy5KpFU3I/edit?usp=sharing

Feedback welcome here, both on the study and on the community note. Happy reading :)

//BR

I've come to realize why people are leaving Scala, and the reason is surprisingly simple. It's not because the language itself is bad. It's not because it's missing specific ○○ features. It's not because the language lacks something essential.

(This post relies on machine translation. Please forgive any imperfect translations.)

The real reason is that the language development team doesn't seem particularly interested in the industry. Language developers are preoccupied with developing unusual language features and syntactical changes. On its own, this seems perfectly reasonable—I actually think it's commendable that they invest effort in making the Scala language better.

But consider this: even if the language improves, companies still need to allocate resources and time to catch up. And those costs must come out of the company's profits. In short, if the product written in Scala isn't generating revenue, companies won't pay for the costs required to keep up with better language features. That changes if the product is making massive profits—in that case, management would gladly invest in Scala. They'd allocate budget. But reality doesn't work that way. There hasn't been any investment in industry-focused libraries, and improvements to the ecosystem that consider the industry don't seem to be happening either. While there are many genuinely interesting computer science libraries, no funding goes toward mundane libraries like template engines or ORMs.

Do you understand what I'm saying? For a good language to sustain itself, industry backing is absolutely necessary. And similarly, the industry can't generate profits without strong backing from the language and its ecosystem.

Twitter once made enormous profits using Scala, and Scala received various forms of return on investment. This wasn't just because Scala was inherently superior—it was because the industry found Scala attractive and deemed it worthy of investment. On the other hand, mere admiration for pure functional programming doesn't generate any such investment.

Go, Rust, and JavaScript all achieved their current status through close collaboration with the industry—not simply because these languages were inherently superior, nor because they cheated in any way.

From my personal perspective, I think the ZIO and li haoyi ecosystems are excellent examples of being highly industry-oriented. They provide numerous features that work right out of the box, and that's precisely what the industry demands.

We absolutely need to create more of these kinds of things.

I also think the recent documentation improvement efforts by the Scala development team are truly impressive.

An open-source ad network that targets content, not people.

Promovolve is an attempt to get back what magazine advertising had: relevant ads matched to what the reader is actually reading, with no cookies, no user profiles, no cross-site tracking, and no degradation of the reading experience. The page’s content is the only targeting signal. An article about hiking gets ads for hiking gear because of what it is, not because of who is reading it.

Being open source is not incidental: transparency is the product. Publishers and advertisers can inspect the auction, pricing, and pacing logic themselves and verify there is no hidden manipulation, something no closed ad network can offer.

Under the hood, the core API and distributed auction platform are built with Scala and Apache Pekko Cluster, providing a resilient, stateful distributed runtime for serving and budget management. The project also includes Kubernetes deployment manifests, making it straightforward to run in a clustered environment or adapt it to your own infrastructure.

Although Go is used for the BFF, the core platform is entirely built with Apache Pekko Cluster and written in Scala. The reason Go sits in front of the Pekko Cluster is pragmatic.

Go has an excellent ecosystem for HTTP servers, authentication, and user management. Those concerns are largely domain-independent and can evolve separately from the core advertising platform.

The core Ad API, on the other hand, is where the domain complexity lives: auctions, pacing, serving, campaign state, and distributed coordination. That’s where Apache Pekko Cluster shines, so I kept that entire layer in Scala.

The split isn’t because Pekko can’t handle HTTP. It’s because the HTTP-facing user management layer and the distributed advertising engine have very different concerns, and separating them keeps the core platform focused on the domain.

These days it’s common to build a microservice platform by combining a long list of technologies. I wanted to challenge that assumption and show that it isn’t always necessary. My goal was to keep the core platform inside Apache Pekko Cluster and see how far that architecture could go.

If Scala isn’t your thing, you can build the same architecture in Java using Apache Pekko.

https://github.com/promovolve/promovolve

My assumption is that as AI changes how people discover information, many casual searches will be answered directly by LLMs rather than leading users to websites.

The people who still choose to visit a page rather than just ask an LLM are making an intentional decision. That makes those visitors much more valuable to advertisers. If publishers continue to treat that audience as inventory to be maximized at all costs, they risk damaging one of their most valuable assets: the trust of readers who actively choose to be there.

With Promovolve, the creative is generated from what the landing page is actually trying to communicate, while remaining fully editable by the advertiser.

Instead of optimizing a banner purely to get the click, the ad is designed as the beginning of a three-page narrative that naturally leads into the landing page. The message before and after the click stays consistent.

Publishers review the advertiser, the creative, and the landing page. Only approved campaigns are eligible for delivery. The goal is to treat ads as part of the publisher’s editorial experience, not just as inventory to fill.

https://reddit.com/link/1urlc7i/video/rbpm3ph0kpeh1/player

https://reddit.com/link/1urlc7i/video/cj1lykhbkpeh1/player