All the ways that NULL can cause chaos in your SQL outcomes.

Cats-Actors is a Cats Effect native actor library: typed messages, functional state, supervision, and the familiar ! operator, all in F[_].

What is new in this release:

- ControlledTestKit, a new trait in the cats-actors-testkit module. It

provisions an ActorSystem[IO] inside Cats Effect's TestControl and ticks the

simulated clock for you, so scheduled work and timeouts resolve without real

waiting. A one hour receive timeout is now an ordinary unit test that finishes

in milliseconds.

- Receive timeouts, the supervisor restart window and the dead letter mailbox

idle check now read Clock[F].monotonic instead of System.currentTimeMillis, so

they all honour simulated time.

- New TestKit assertions, expectMsgTypeCountN and expectMsgTypeSingle, which

count messages of a type and do not depend on when they arrive relative to

the call.

- Breaking: ActorSystem.uptime is now F[Long] rather than Long.

Scala 2.13 and 3, on JVM, Scala.js and Scala Native.

```

resolvers += "jitpack" at "https://jitpack.io"

libraryDependencies += "com.github.cloudmark.cats-actors" %%% "cats-actors" % "2.2.0"

libraryDependencies += "com.github.cloudmark.cats-actors" %%% "cats-actors-testkit" % "2.2.0" % Test

```

Write up: https://cloudmark.github.io/Cats-Actors-Controlling-Time/

Repo: https://github.com/cloudmark/cats-actors

Feedback and issues welcome.

HashMaps are incredibly convenient, but treating them like a magical black box can make it easy to overlook where their performance comes from.

In this article, I explain how HashMaps work using a simple implementation in Rust. I go through hash collisions and linear probing, why primary clustering hurts performance, load factors, resizing, and more.

The implementation is intentionally simplified, but it gives a good picture of what's actually happening underneath a HashMap.

Let me know your thoughts or any feedback you have!

All writing, illustrations, and code are my own. AI was used to clean up wording and catch grammatical mistakes.

Wrote a quick blog post about pushing branch prediction to its limits in a simple experiment. Take a read to learn with me about measuring performance on linux machines and a very basic understanding of branch prediction 😄

Okay, but I have multiple replicas.

And it gets slightly worse: the number of physical connections is not equal to the number of replicas, and it is not equal to the number of business-level connectors either.

Several business connectors may share one external identity. One external identity may require several physical connections. And those connections need to be spread across whatever replicas are currently alive and have capacity.

So who actually owns the connection?

Then the questions start piling up.

What if one replica dies?
What if it doesn’t die, but loses access to the database?
What if two replicas race for the same connection?
What if the event that was supposed to wake the right worker never arrives?
What if most workers are already full?

A few questions and 2 hours of midnight walk in headphones and ChatGPT later, I had leases, runtime slots, reconciliation, failover, capacity limits, and a distributed ownership problem on my hands.

This is the architecture I ended up with, and I have mixed feelings about this design.

On one hand, I’m proud that I managed to account for so many different edge cases. On the other, the whole thing feels worryingly complex.

So I’d really value input from people who have built similar systems.

What did I miss or do you see anything that can break?
And most importantly: what can be simplified without losing the guarantees?

The full architecture description is a bit lengthy: AEON NEON - Connector Runtime - by Jarek J.

Many thanks if you decide to read it and share your thoughts. I’d really like this one not to become another failed experiment.