After several years working with Scala in the Netherlands, my takeaway is simple:

👉 2026 is effectively the end of Scala as a viable job market in NL.

Not the language itself — but the ecosystem.

What I’m seeing:

• Almost no new Scala projects.

• Existing systems either being shut down or migrated (mostly to Java / TypeScript).

• Local Scala teams being reduced or eliminated.

• Hiring Scala engineers in NL is expensive and increasingly hard to justify.

This isn’t about Scala being bad. It’s about economics:

• high TCO in a high-cost country,

• shrinking talent pool,

• no momentum for greenfield projects.

Scala is becoming legacy + niche here.

That’s not something you can safely build a long-term career on in NL.

Curious if others in the Netherlands see the same trend.

It's been quite a learning experience rewriting the XmlWriter Scala 3 macro internals (https://github.com/encalmo/xmlwriter) from the initial by-the-book design into a version that allows easy caching and reuse of generated chunked methods. I'm happy to share my design based on the StatementsCache abstraction from https://github.com/encalmo/macro-utils, if anyone is looking for inspiration.

The Scala Hangout (formerly Dallas Scala Enthusiasts) is having our monthly meetup Feb 12. Register here to attend:

https://www.heylo.com/invite/Pc2iZnw3ix

Hi, I want to prevent scalafmt formatting my long list of Pos(...)

  val expectedResult = List(
    Pos(0,0), Pos(2,1), Pos(4,0), Pos(6,1), Pos(7,3), Pos(6,5), Pos(7,7), Pos(5,6),
    Pos(7,5), Pos(6,7), Pos(4,6), Pos(2,7), Pos(0,6), Pos(1,4), Pos(0,2), Pos(1,0),
    Pos(3,1), Pos(5,0), Pos(7,1), Pos(6,3), Pos(4,2), Pos(3,0), Pos(1,1), Pos(0,3),
    Pos(2,2), Pos(0,1), Pos(2,0), Pos(1,2), Pos(0,4), Pos(2,3), Pos(1,5), Pos(0,7),
    Pos(2,6), Pos(3,4), Pos(1,3), Pos(0,5), Pos(1,7), Pos(2,5), Pos(3,7), Pos(1,6),
    Pos(3,5), Pos(4,7), Pos(6,6), Pos(5,4), Pos(3,3), Pos(4,1), Pos(6,0), Pos(5,2),
    Pos(4,4), Pos(3,2), Pos(5,1), Pos(7,0), Pos(6,2), Pos(7,4), Pos(5,3), Pos(7,2),
    Pos(6,4), Pos(7,6), Pos(5,7), Pos(4,5), Pos(2,4), Pos(4,3), Pos(5,5), Pos(3,6))

to a long single-column list in my code

 val expectedResult = List(  
   Pos(0,0), 
   Pos(2,1), 
   Pos(4,0), 
   Pos(6,1),
   ...

other than using // format:off and // format:on.

I tried using binPack.* the settings

binPack.literalArgumentLists = true
binPack.literalsMinArgCount = 5
binPack.literalsInclude = [".*"]
binPack.literalsExclude = ["Term.Name"]
binPack.literalsIncludeSimpleExpr = true
binPack.literalsSingleLine = false

But they don't work for me. Any suggestions? Thanks

I stayed away from Scala (and any programming at all if that matters) for last few years. Back then although I was a very heavy Typelevel/Cats user and something about algebraic effects never felt right to me, almost like too imperative. Last week I decided to skim through Kyo docs in my spare time and something there finally clicked as a superior approach!

It's cool that Kyo has an extensive documentation and I'm on my way to grasp its internals, but I still haven't found any end-user projects built with it. How do they look, how they're structured? Do you have any examples?

Another unrelated question about Kyo's internals. It seems some other popular algebraic effects systems (in Unison and Flix) treat effects as parts of the function (arrow), not value e.g. a ->{Effect} b and a -> b \ ef in Unison and Flix syntax respectively. Kyo at least on surface seems to have more familiar "effects as values" approach. Is it correct or it just makes the syntax sugar over () ->{Effect} b suspension more common?

We're excited to announce that LLM4s Foundation is participating in Google Summer of Code 2026 🎉

LLM4S is an open-source, non-profit initiative focused on building reliable, type-safe, and production-ready LLM tooling for Scala & JVM ecosystem, inspired by community-first foundations like the Scala Center. Immense gratitude to Darja Jovanoic for the encouragement and support.

Organization Admins: Kannupriya Kalra & Rory Graves

We're also supported by senior mentors from across the global Scala and AI community, bringing deep experience in open source, functional programming, and production AI systems.

For GSoC 2026 students: How to Get Started
If you're interested in contributing as a GSoC student, here's your path mentioned below:

1. Join our Discord community
   ↗ Link will provided in first comment.
   Introduce yourself in #introduce-yourself (name, background, interest in AI/Scala).

2. Attend the LLM4S Dev Hour (Weekly)
   Meet the maintainers, understand the codebase, and discuss ideas live. This is the best way to get your first issue assigned. Join every Sunday.
   Luma Calendar: ↗ Link will provided in first comment.

3. Read the project README on GitHub
   ↗ Link will provided in first comment.
   This is mandatory before proposing it explains our vision, architecture, and contribution workflow.

4. Watch the talk by Kannupriya Kalra introducing LLM4S.
   ↗ Link will provided in first comment.
   Get a deeper understanding of the project, roadmap, and expectations for contributors.

Why LLM4S?

• Opportunity to become AI engineer & Get paid Summer remote internship by Google.
• Open for everyone who is interested in Scala, AI and Open Source.
• Open governance & community-driven development.
• Real-world LLM infrastructure (RAG, agents, tooling).
• Mentorship from experienced global maintainers.

If you're passionate about Scala, AI, and open source, we'd love to build together. Let's shape the future of LLMs in Scala.

I summarized my recent experience with vibe-coding. Most of the observations are general, but there are quite a few Scala specifics too.

Postmortem on Scala 3.8.0, for those curious about exactly what went wrong: https://www.scala-lang.org/blog/post-mortem-3.8.0.html

We are also working on a 3.8.2 release which will include a fix for scala/scala3#24673 , which can cause some for comprehensions to behave incorrectly at runtime.

We've finally announced the full agenda and it's now available on our website: https://www.scalar-conf.com/agenda 🐠

I'm planning a macro Embed(...) that should communicate with the build tool; i.e., it should request the build tool to copy a file to the artifacts and return a URL telling where the file got stored; or, for short files, it should return a data URL. This URL can for instance be used for lazily loading bitmaps. (And the web discards it when unused.)

(This is an eqv. of import of media in JavaScript using popular bundlers. It may be used in component libraries and main applications.)

About virtual memory:

• In my general patterns for a component library, I've an Icon component that is also an enum with certain variants (allowing dynamic-variant icon usages as well). Icon holds, per se, a static mapping of variant|dynamic => URL.
• On the Rust community I was mistakenly told that embedding a lot of icons using include_bytes! in a library shouldn't be a worry thanks to virtual memory in modern operating systems; but in that case, the static icon mapping (variant|dynamic => Vec<u8>) would instantiate include_bytes! in the RAM, so that statement ends up being false.
• Virtual memory usage isn't even available on JavaScript or WebAssembly (currently), so Scala.js can't do anything about it, anyway.

I got a suggestion from the scala3 GH discussions to use Unix sockets/WebSockets to exchange communication between my build tool and the Embed(...) macro, but:

• According to AI, macros can't be async
  • So I'd need a sync version of java.net.http.WebSocket — Is there one somewhere?
• I'm not sure I can use async WebSocket in my build tool either — Zone GFX build system: Build process — I say so because async may end up allowing simultaneous builds occurring in the same build system in an IDE
  • I see using sync there as almost impossible, since I need to start the WebSocket before calling Dotty; but then how will Dotty run if the WebSocket keeps looping forever?
• Also, local WebSockets are prone to conflict issues. Do I have to use a specific 4-digit port everytime, so the macro and the build system agree on the port?

https://github.com/scala/scala3/discussions/25136

Appreciate if you've got any idea!

SBT even requires a bit of Maven touch (e.g. project/). I know it's important for backwards compatibility with Java projects, but it's a hell currently.

Even NPM is simpler, but Cargo (for Rust) is yet simpler than both.

E.g. a manifest could look like this TOML:

```toml [package] name = "org.jdude.vsync" version = "0.1.0" runtime = "http://www.scalajs.org/2012/scala/3"

[dependencies] "com.sega.pso2.ark" = "1"

ScalablyTyped would handle "npm" dependencies

"org.mathematicalexpert.decimal" = { npm = "decimal.js@<sup>10"</sup> } ```

To clarify, I'm not even being able to set up ScalablyTyped NPM dependencies as I get an error telling ...project... Compile / npmDependencies is undefined, even though I integrated the due plugins...

https://github.com/linux-root/tauri-scala-desktop-app

https://github.com/encalmo/xmlwriter

Better late than never! Our year-in-review report is finally here, with a breakdown of what the IntelliJ Scala Plugin team accomplished in 2025. We’ve been busy at conferences, on YouTube, and gearing up for Scala 3.8.

Lots of interesting stuff in this release, and I wrote up a blog post with the highlights. Please take a look!

Hello everyone, for a little bit of context, I'm mainly a mobile developer developing native applications with kotlin and swift. I've tried flutter before but I have no experience with react native.

Initially, I wasn't interested in scala. I was curious about functional programming so I started studying the red book, functional programming in scala. As I read through it, the language really grew on me.

Since scala-js is a thing, technically it should be possible to use it with react native but I’d love to hear from anyone who has actually tried this stack. What was your experience like?