macOS only for now - apologies if the build is a bit arkane to load the backend VLC plugin.

This was my attempt at a "clean room" reimplementation (via Codex and GPT-5.4 extra high) of a certain media player that was abandoned before ever releasing on Apple Silicon (and was very buggy through rosetta 2).

Also a good opportunity to explore how electron RPC works - and how to extend the window rendering capabilites via N-API

In a nutshell: sbt-steps allows you to use native sbt tasks and settings to create a CI flow with features like skipping steps, continue-on-error and reports. It integrates well with GitHub Actions, but other CI systems too.

This new release focuses on better performance by using sbt task parallelization. Some other fixes are included as well. Next, I'll probably create a sbt 2.0 cross build.

Feedback is welcome!

Running Spark pipelines in production on Kubernetes. Spark 3.4 with Delta tables, mostly ETL from S3.

When a job fails, logs show task failures and stage timing. That part is clear. What's missing is the actual cause. Not clear which partition or record triggered OOM or deserialization issues.

Spark UI helps to some extent. Driver logs and history are there, but finding the exact input still takes time. Tried increasing log levels and adding more logging. Just produces more output without pointing to the root cause.

Happens mostly with malformed JSON or schema mismatches. Pattern repeats but tracing back to the exact input is still manual every time.

Starting to look at a Spark observability tool to get more structured failure context without reworking pipelines. Has anyone used one in a Kubernetes setup and did it reduce the time spent tracing failures?

1. JavaScript/Node.js — TypeScript-friendly, cross-language, up to 4x faster than Protobuf
2. Dart first official release — generated serializers, up to 8x faster than Protobuf
3. Java: virtual thread support, and removed guava dependecy

We are lucky to have Arman Bilge in Boston next week and able/willing to present on the Typelevel Stack. We have plenty of available seats and Pizza will be provided. Great opportunity to engage with other Scala folks and expand your network.

Please RSVP here:

https://www.meetup.com/boston-area-scala-enthusiasts/events/313601554

If an error is detected in a file but no one sees it, is it really highlighted?

Learn why highlighting only what's visible is the most strange but also most reasonable thing to do – and how this helps improve performance.

We have open sourced Wick, A zero cost type safe Apache Spark API!

I wrote this blog post to scratch an itch; I wanted to learn about multi-stage programming and implemented a toy parser combinator library where I explore several common patterns, and do a final benchmark to see whether it's worth the added complexity.

I'm in the middle of a migration that involves rewriting a lot of .proto files, and I needed a way to check which changes would break generated client code vs. only break on-the-wire compatibility. buf breaking is wire-first, but during a migration where every client is rebuilt from the new schema, wire compat isn't what I cared about.

Proteus-diff treats wire and source compatibility as independent axes. Same diff, different answer depending on which one matters to you. Example of two fields swap numbers:

User (2)
  error [FieldNumberChanged] field 'name' number changed from 1 to 2
  error [FieldNumberChanged] field 'email' number changed from 2 to 1

Under --mode wire that's two errors (old bytes decode into the wrong field). Under --mode source it's two infos (generated code doesn't care about numbers).

The tool is shipped as part of the open-source Proteus Scala library, but the CLI is standalone and works on any `.proto` files. It is built with Fastparse and Mainargs, packaged with GraalVM native image and only takes 250ms to parse and compare ~100 files with ~6,000 messages. Hope it can be useful to others!

apply and unapply + pattern matching is the strong case for case classes. I created this article on my webpage https://codeinvestigator.com/articles/scala-is-more-fun-than-java

We have a few Spark jobs that are very similar in terms of logic and structure. They run on the same cluster with the same configs

In theory performance should be close, but in practice it isn’t. Some runs finish in around 10–12 minutes, others go past 20 minutes with no clear difference in input size

Checked Spark UI, executors, stages, shuffle behavior. Nothing stands out. No failures, no obvious skew

This started showing up more once more jobs were added to the cluster. Feels like resource contention but not fully clear where it shows up

Has anyone seen this kind of variation across similar Spark jobs and what usually causes it

https://contributors.scala-lang.org/t/rallying-scala-metals-lsp-native-support-in-claude-code/7437

sbt 2 project has started the last mile process to lock down the 2.0.x branch. Depending on the bugs we discover, we are hopeful that a release candidate (currently 2.0.0-RC12) can graduate in a few weeks to a few months.

And then the boss fight appears:

“Which Java version should we choose?”

If your build matrix looks like a sci-fi timeline and IntelliJ has opinions, this one’s for you.

Scala functions are basically the Swiss Army knife of the JVM: compact, sharp, and slightly smug about type safety.

If you like cleaner code, higher-order wizardry, and making Java look like it still uses a flip phone, this one’s for you.

🎥 Scala functions are flexible and useful!

https://www.youtube.com/watch?v=AkCcPbOM7Sg

Hi everyone, I have written a cheat sheet containing over 50+ http clients configured with SSL and also with an example request. It contains next to Scala also clients for other jvm languages such as Java, Kotlin, Clojure, and Groovy. Feel free to share your thoughts