r/scala

Possibly the most important Scala library that has been created. We can finally write code in a way that makes sense. The tests may be nonsense as I relied on comparing outputs to other "correct" implementations to ensure correctness.

Some of the terrible naming, and non-cow spec compliant naming comes from the issues with not case sensitive operating systems overwriting mOo and moo. Some of it is the rush to get this out as my gift to America for the big birthday. Starting on v1.0.13 as a combination of looking like a cow and tag issues.

The DSL implementation is my favorite, but you can also parse text with the interpreter or deal with the VM directly if you actually want to use the debugging.

cow {
  MoO
  MoO
  MoO
  OOM
}

is finally valid Scala code.

https://github.com/StephenRinn/Moo4S

Hey r/scala! 👋

We’ve just released v2.38.17 of jsoniter-scala, and it brings some serious performance upgrades under the hood.

This week, I've successfully integrated the full version of James Anhalt's amazing algorithm for serializing integers into text format. The results are fantastic - if you're running on Oracle GraalVM, you can expect up to a 1.5x speedup for Int and up to a 1.25x speedup for Long serialization!

The best part? Because of how the library leverages JSON serialization, this optimization cascades down to a bunch of other data types as well. You'll see performance bumps when serializing:

• small BigInt, and BigDecimal values
•  java.time.Period , java.time.Duration and other java.time.* values with nanos

Update your dependencies, let it fly, and let all us know how it impacts your applications.

Benchmark results incoming! 📊 I've just kicked off the massive benchmark suite across 10 different JVMs and 4 browsers. I'll publish the final, detailed results next week here as usually:

• JVM Benchmarks
• Scala.js / Browser Benchmarks

What's next? 👀 I'm looking into how to apply the same technique to make Float and Doubleserialization blazing fast.

Support the project! ⚡ Running these massive benchmarks is keeping my CPU running for several days and nights, and the air-conditioning needed to cool my room down is definitely spiking my electricity bill! 😅 ❄️ If you enjoy these speedups, consider supporting me and my over-worked equipment with a tip via GitHub Sponsors.

Happy Scala coding!

Professor just released this: https://github.com/bjornregnell/muntabot/releases/tag/v1.0.0

A single-page-serverless ScalaJS app live here: https://fileadmin.cs.lth.se/pgk/muntabot

Now translated to English from Swedish (use the language menu top left)

For your re-skilling in the agentic software engineering era :)

I am happy to announce that we now have translated our teaching material for Introductory Programming (in Scala) to English.

You can download the "ready for review" version here:

https://github.com/lunduniversity/introprog/releases/tag/v2026.4

(Some things remain, issues welcome, see repo readme)

The translation was done in an idempotent sbt build pipe line using this this Scala program:

https://github.com/lunduniversity/introprog/tree/master/autotranslate

License for the teaching material is CC-BY-SA

On Friday I've released a bunch of libraries that are based on meta programming:

• Hearth 0.4.0
• Kindlings 0.3.0
• Scala-Newtype-compat 0.1.1
• Refined-compat 0.2.0
• Pipez 0.6.0

What are they and what problem they solve?

Hearth is a library that was created to help you write robus macros without going insane. Why macros instread of Shapeless/Mirrors?

• faster compilation - you can get tighter feedback loop if your compiler returns result faster (because you don't treat typer as a naive Free monad)
• better runtime performance - it is much easier to generate the fast code when you control the result and not rely on cleverness of the compiler in handling intermediate structures
• better error messages - if you know how to provide good error messages to your users when you implement web services, you should be able to reuse that experience to users that call your macros

However, since juggling ASTs in even more of an ivory tower than the category theory, it helps if someone handled all the common cases with high-level utilities. Therefore Hearth.

(As a bonus, with Hearth, you can implement macros in a way that reuses code between Scala 2 and 3, so if your are still on 2.13 Hearth-based macros would not get in your way of migrating to Scala 3 eventually).

(I consider Hearth feature-complete at this point, so I am not planning the next release. It's not 1.0.0 only because I want to give some time to other people who could use it and give some feedback).

How can we tell if that would enable implementing macros in practice?

That's where Kindlings comes in. We reimplemented a lot of the existing Scala libraries (or their type class derivations) with Hearth:

• Avro (complete Avro4s reimplementation)
• Cats type class derivations (Kittens reimplementation, but with a few more types supported the last time I checked)
• Cats tagless derivations (cats-tagless derivation reimplementation)
• Circe sanely automatic derivation of codecs
• DI (dependency injection) (reimplementation of MacWire-like DI)
• DI Cats (reimplementation of MacWire-like DI but for Cats, but without assumption that F=cats.effect.IO)
• Diff (Diffx/Difficious-like reimplementation)
• Jsoniter (sanely automatic derivation of Jsoniter codecs)
• Mocking (ScalaMock-like mocking)
• Optics (MacWire-like optics)
• PureConfig and SConfig sanely-automatic derivation
• ScalaCheck sane automatic derivation
• Tapir Schema sanely-automatic derivation - uses the same config as Kindlings' Circe or Jsoniter, so less risk of mismatches!

Additionally, it adds:

• UBJson codecs with derivation
• Scala XML sanely-automatic derivation
• Scala YAML sanely-automatic derivation
• Jsoniter JSON that does NOT rely on Circe's JSON
• Tapir OpenAPI schema rendered that relies on Jsoniter without relying on Circe's JSON

As for the integrations it currently supports:

• Cats collections
• Iron
• Refined

without requiring you to import it in every file that needs it - macros can pick up the integrations automatically from the classpath!

And all of that while using the same API for both Scala 2 and Scala 3! (And supporting JVM, Scala.js and Native where possible).

What about the compat modules?

If you wrote DDD code with Scala Newtype and Refined, like Practical FP in Scala (the 2.13 version), you mighe be in trouble:

• Scala Newtype has no support for Scala 3, since Scala 3 has no support for macro annotations (at least the the scope that 2.13 supported them)
• Refined has support for Scala 3... but no support the macros to turn literals into Refined types during compilation (skipping runtime checks, where we see from the source code that predicate would be matched)

You could migrate by rewriting the code into one of dozen newtype libraries, but at this point you have to migrate at once: Scala version, newtype library and tests, which is not fun, especially if you have a few dozen repositories, that could not be easily cross-compiled during transition.

Scala Newtype compat solves the first problem by providing a compiler plugin that emulates the 2.13 macro annotations for Scala 3. You add it, and the plugin would rewrite the code on Scala 3, so that cross-compilation is possible again.

Refined compat solves the second problem, using Hearth - Scala 3 is missing eval which is like a REPL running in macros, but we can implement a weaker version of eval that treats AST as a recording of literals, and operations that we can re-play using runtime reflection. While not as powerful as eval, it's good enough for 80% of use cases.

With both of these, your Newtype/Refined-based codebase can cross-compile between Scala 2.13 and Scala 3 unblocking the migration. (And once you are migrated you can switch to some more modern library).

And Pipez?

It's more of a trivia, but if you ever missed using custom F[_] in Chimney, Pipez library is exactly about it. Actually, even more, it's about modelling transformations as Pipe[_, _], so in theory your Kleisli and ZIO should also work with it.

It came to be when I wondered if I'll be able to make Chimney cross-compilable between 2.13 and 3. Pipez spearheaded that effort of 1 codebase for 2 macro systems. Then Chimney refined it into chimney-macro-commons, so that Chimney maintainers could just work with higher-level abstraction and focus on the derivation logic. Finally, Hearth turned all of that research into a library that is not tied to any specific use case. And then Pipez was used again, to verify that Chimney can be ported to Hearth (Chimney 2.0.0 on Hearth confirmed!).

Hopefully, all of that would be enough to convince the community that macros have more potential for smooth developer experience than Shapeless/Mirrors, that writing macros can be engineered with as high standard any other Scala code, and that is not a hypothetical possibility, but something we can already have today.

(No ETA on tutorials, but I am thinking of writing some).

Hello,

I have recently published my POC of scala language binding implemented using scala-native and SBT plugin.

Repo: https://github.com/optical002/godot-scala-native

Features that it supports right now:

- A gitter8 template for quick 'Hello World' setup https://github.com/optical002/godot-scala-native-template.g8

- Integrated (inside sbt plugin) godot plugin, which manages sbt builds

- Generator for all of Godot node types and built-in types (e.g. Color, Vector2, Rect2, ...)

- Support building new nodes from case classes without additional annotations for example:

case class PlayerNode(var hp: Int) extends Node2D  

- Has some of the export annotations like '@export_range'

- Supports hot reloading even after changing Node properties.

- No 'Entry' class is needed like in other language bindings, just write Nodes and other logic directly.

- No extra .gdextension file creating yourself, auto-generates it from an sbt task.

What it is lacking at the moment:

- Build time isn't the best, first initlial build can take up to like 16 seconds (There are many places for improvements)

- After the .so library gets moved into gd project scala widget in godot says it has finished compiling, but new properties does not immediately appear in inspector, since there is a hidden godot reload mechanism in place (Need to expose it via godot plugin)

- And lost of polishing up, still a 0.1.0 version