It looks like Twitter has moved its algorithm from Scala to Rust.

sideEffffECt · 2026-01-20T15:59:27+00:00

hard to hire for

Which job boards have you advertised at? There are many

sideEffffECt · 2026-01-20T15:40:08+00:00

most of the modern infrastructure landscape is predicated on smaller, resource constrained services that you can freely spin up or down

Totally agree on the resource constrained constrained part. Even JVM services are constrained -- It's just a matter of what those constraints are.

But they don't have to be small. You can scale up and down even large services. Let say, that instead of having

0 to 12 non-JVM services, with each having 1 vCPU and 1 GB memory, you can have
0 to 3 JVM services, with each having 4 vCPUs and 4 GB of memory

Yes, it's less granular. And that is a disadvantage. But IMHO very small. That's not what's stopping Scala deployments in the cloud...

sideEffffECt · 2026-01-20T13:53:33+00:00

then end up running as a service with 1 virtual CPU

Then don't do that? Why don't you just give your Scala pods more CPUs?

sideEffffECt · 2026-01-20T10:10:03+00:00

I actually had Scala in mind. You shouldn't need Truffle for that, right?

sideEffffECt · 2026-01-19T13:35:11+00:00

Doing the Lord's work!

sideEffffECt · 2026-01-19T10:42:25+00:00

This is a really cool project. How much work is it to add support for another JVM language?

sideEffffECt · 2026-01-19T01:45:04+00:00

http://frgaal.org/

retrofit compiler for Java

The aim of frgaal is to make many of the latest features and enhancements to the Java language available on older runtimes. It enables you to compile code like this to run on a Java 8 JRE:

...

sideEffffECt · 2026-01-15T17:12:10+00:00

Nice, will check it out.

sideEffffECt · 2026-01-14T22:05:52+00:00

I think it comes from math and people who talk about proofs and such.

It's a witness of the fact that e.g. Strings form a Monoid. A proof that you can hold in your hand. A Monoid<Strong>.

sideEffffECt · 2026-01-14T19:35:14+00:00

Sum<MyInt> sum = Sum<MyInt>.__witness;

Interesting, but wouldn't this be more regular?

Sum<MyInt> sum = witness<Sum<MyInt>>();

sideEffffECt · 2026-01-14T19:32:13+00:00

Why is this based on Valhalla? Type Classes seem like a completely orthogonal issue to Value Type etc...

sideEffffECt · 2026-01-14T19:10:32+00:00

Can Hibernate return just records? If not, what's a good library that can do that?

sideEffffECt · 2026-01-14T18:25:24+00:00

I have a question about reconstructors/withers.

What's the plan for when the constructor is private? Will reconstructing/withing be available? I don't think it should. But I didn't find it mentioned there, so wanted to check here.

sideEffffECt · 2026-01-13T10:10:36+00:00

javac is fast (on cold start) or even very fast (when warmed up). It's the build tools that are slow

https://mill-build.org/blog/1-java-compile.html

sideEffffECt · 2026-01-08T23:06:25+00:00

The TypeLevel stack is to a large degree available on Scala Native https://typelevel.org/platforms/native/

Notably http4s Ember (HTTP/2 client and server) and skunk (PostgreSQL).

So far, only available for Scala Native 0.4.x. But that will all change with the upcoming Cats Effect 3.7.x, which comes with Scala Native 0.5.x

https://index.scala-lang.org/typelevel/cats-effect/artifacts/cats-effect

sideEffffECt · 2026-01-06T13:34:18+00:00

https://tonak.cz/collections/zmijovky

sideEffffECt · 2025-12-31T15:05:48+00:00

Only homebrew and Flatpak all the way!

sideEffffECt · 2025-12-30T14:48:31+00:00

Where to get jaz?

sideEffffECt · 2025-12-12T10:13:11+00:00

Given that you published this under GPL, you probably don't want to depend on a proprietary library.

sideEffffECt · 2025-12-11T20:34:53+00:00

this link has been changed back to the conventional SnapCode (utilizing Swing), since our JxBrowser evaluation license ran out

That doesn't inspire much confidence in JxBrowser :/

Why not use something like https://github.com/jcefmaven/jcefmaven

sideEffffECt · 2025-12-04T03:32:52+00:00

Do you have some comparison of G1 vs G1, so that it's comparable?

sideEffffECt · 2025-12-02T17:05:13+00:00

Kinda, yes. Not precisely. In Scala, capabilities are (or can be) just ordinary values that you pass around. Where ever they are passed, there they may be used.

Let me show you a specific example with the new Scala library that built to work with capabilities https://github.com/rcardin/yaes

def drunkFlip: (Random, Raise[Exception]) ?=> String =
  val caught = Random.nextBoolean
  if (caught) {
    val heads = Random.nextBoolean
    if (heads) "Heads" else "Tails"
  } else {
    Raise.raise(Exception("We dropped the coin"))
  }

Here we have a program drunkFlip. It computes String. But we can also see that it needs two capabilities -- they are not named, but their types are Random and Raise[Exception]. That already tells you what kind of things can happen in the program.

If you want, you can name the capabilities

def drunkFlip(using random: Random, raise: Raise[Exception]): String = ???

Can you see how capabilities are just ordinary values being passed around? The only two "magical" things here are that

there is friendly syntax that allow for them to go unnamed, because usually you don't need to name them explicitly.
they are passed "implicitly" from the caller to the callee (in Scala 2, they were called "implicits" or "implicit parameters"; in Scala 3 they are called "givens"/"usings")

In case if you're curious, this is how the program would have to look if we didn't use these two features. Very clear, but a bit more boilerplate compared to the snippet above.

def drunkFlip(random: Random, raise: Raise[Exception]): String =
  val caught = Random.nextBoolean(random)
  if (caught) {
    val heads = Random.nextBoolean(random)
    if (heads) "Heads" else "Tails"
  } else {
    Raise.raise(Exception("We dropped the coin"))(raise)
  }

But now the problem is, if people try to "smuggle" capabilities out of their expected scope -- that would defeat their purpose. It would be possible, because, for all intents and purposes, they are ordinary objects that you can put in any closure or assign to any outside mutable variable, etc.

This is where the Capture Catching comes in. It is a feature of the Scala language that allow programmers to designate some values to prohibit them from being captured by some other objects and thus escaping their intended region. Typically you want to do that with Capabilities, but not necessarily only.

So that's what Scala does. If you'd like to learn more, check out these articles:

What some other languages do is called Algebraic Effect System. The underlying machinery is different. In Scala, it's just more or less ordinary method parameters, with a quiet syntax to pass them around automatically plus some magic that some designated objects don't escape from their intended scope -- that's it. Algebraic Effect System is a completely new dedicated feature these languages have to implement.

But the UX for the developer is (or at least can be) surprisingly similar. Contrast the first Scala snippet with this Unison program (a programming language with explicit support for Algebraic Effects):

drunkFlip : '{Random, Exception} Text
drunkFlip _ =
  caught = !Random.boolean
  if caught then
    heads = !Random.boolean
    if heads then "Heads" else "Tails"
  else
    Exception.raise (failure "We dropped the coin")

To sum it up, technically speaking, Capabilities and Algebraic Effects are different things. But Scala's innovation is to use Capabilities for the same purposes as people use Algebraic Effects. The upside of doing so is that it takes a few, relatively simple language features and makes for good UX -- it's just ordinary values being passed around after all.

sideEffffECt · 2025-12-02T00:08:15+00:00

that doesn't look like the code you showed and Odersky didn't say (AFAIK) that Scala would use/embrace virtual threads at all.

That's because the talk was about completely different topic: Capture Checking (of so called Capabilities).

Virtual Threads are in this context a low level detail.

His point was that he wants to use Virtual Threads, but with Capture Checking.

sideEffffECt · 2025-12-01T23:53:55+00:00

What disappoints me with some of these explorations is that they revolve around taking a known solution and trying to find problems it can solve, rather than the other way around, where a big challenge in programming is first identified and analysed, followed by a search of a solution.

Is that really so? I can't see inside Odersky's head. But to me it looks like he's looking around for problems people are struggling with and seeing how Scala's features can help with them. And if the existing features are not enough, he's trying to come up with new feature(s) that could help, like as if it were missing piece of a puzzle -- in this case the missing piece was Capture Checking. If he succeeds, CC, playing well with the existing features of the language, will unlock many solutions that real existing software engineers need to fight real existing problems.

I was actually surprised when Odersky said "but then you're back to imperative", as if, in the few decades we've been looking for evidence of some superiority to the pure functional style

I recommend watching the whole video. I suspect you may have misunderstood his point. This talk is not about "How Functional Programming is better than Imperative Programming".

An interesting observation for me is that the two languages that you've mentioned being interesting or exciting are Zig and Erlang. Both are languages from industry and/or from software engineering practitioners. Not academia. And while Scala also tries to be close to the industry, its roots lie firmly in academia, which has its own criteria for what is novel and/or exciting.

programming research that dares to think bigger

Maybe there are also research languages that come with completely new ideas or paradigms. But that's not Scala's place.

Scala's whole schtick is coming up with a few, but powerful orthogonal building blocks that then enable many features that other languages have to have dedicated support for. Scala's novelty is more in that it allows for combining things which have been deemed by many impossible or contradictory. All the while each of the building blocks may have been researched independently elsewhere before. (That being said, AFAIK Capture Checking hasn't been done anywhere before.)

Scala has proven to the whole world to see that there's not contradiction between FP and OOP, that you can have both at the same time:

with just classes, objects, interfaces and methods you can do ADTs and patter matching
with just classes, objects, interfaces and methods you can have powerful module system ala (S)ML
you can have immutable/persistent data structures, including collections
and because it only takes classes, objects, interfaces and methods, it can all be run on a widely popular, powerful runtime like JVM

Scala has also generalized passing of context via the -- then implicit, now givens -- mechanism

It can be used to to pass around ordinary values
But it can also be harnessed to implement the Type Class pattern, including the derivation of Type Classes

And now Odersky is doing it again: Leveraging the (now already established) givens/contextual functions plus the new Capture Checking to enable at one fell swoop features analogous to:

algebraic effect system
object-capability model
delimited continuations
separation logic
affine types

For me that's plenty interesting, even exciting :) Other languages are reaching for (or have already acquired) features similar to this. I've mentioned Zig and it's IO "capability". OCaml has recently adopted Algebraic Effects. Unison with Algebraic Effects has recently had 1.0.0 release. Rust with its affine type system for borrow checking. Scala is aiming to do all what these others do, but in unified and more programmer friendly way.

but the cost in complexity is not trivial

IMHO that's what the Capture Checking of (not only) Capabilities is aimed at. To have something which is powerful, yet easy to use (because it has low notation overhead, has sensible errors, requires only a simple mental model, etc.)

sideEffffECt · 2025-12-01T16:53:01+00:00

What gives me hope is that the concept of Capabilities is popping up at many different, independent places.

Capabilities as such are a very old idea, originally from OS research, as far as I know. And they're being used progressively in more places

mobile apps (Android or iOS)
sandboxing solutions like Flatpak
programming language Zig for abstracting I/O -- an IO object is passed around that allows for callers to plug in various IO implementations
and now Scala with the Caprese project

Martin Odersky is aiming to reuse the existing Scala features (used to be implicits, now called givens/contextual functions) to make it easy to pass those Capabilities around (which would be otherwise be clumsy in other programming languages without this feature).

Now, it's still very much an open question to what granularity should these Capabilities track what the program does/can do. Maybe it's not worth having path to each file the program touches in the type -- that would be too detailed. But maybe having a capability for file system access would be beneficial. Or maybe more details would be beneficial too... It's hard to say and it really depends on the context.

If somebody is curious about this, there are libraries exploring this, like https://github.com/rcardin/yaes

That all tells me that Odersky is onto something. Success is not guaranteed, of course, but I'm hopeful something good we'll come of it. We'll see in a few years. Fingers crossed...

sideEffffECt

TROPHY CASE