Let’s continue.

Did you know this signature is valid?

type Func func() Func

A function type that refers to itself.

How do you use that in real code? Is it useful?

Yes, if you don’t like if-else spaghetti.

In the previous post, I mentioned PBEM (Play-by-Email) games
and noticed that each step had no World. Let’s fix that.

First, the world and a step over it:

type World struct {
  TurnID     int
  HasWinner  bool
  NextPlayer string
}

type StepFn func(*World) StepFn

Then, a few steps:

// waiting for the email move
func waitForEmailStep(w *World) StepFn {
  fmt.Printf("[Turn %d]: Waiting for %s's email move...\n", w.TurnID, w.NextPlayer)
  return processMoveStep
}

func processMoveStep(w *World) StepFn {
  fmt.Println("[Engine]: Calculating ... etc.")

  if w.TurnID >= 3 {
    w.HasWinner = true
    return endGameStep
  }

  w.TurnID++
  if w.NextPlayer == "Player #1" {
    w.NextPlayer = "Player #2"
  } else {
    w.NextPlayer = "Player #1"
  }
  return sendNotificationsStep
}

// jump back to waiting
func sendNotificationsStep(w *World) StepFn {
  fmt.Printf("[Email]: Sending new save game file to %s ...\n", w.NextPlayer)
  return waitForEmailStep
}

// base case: nil breaks the loop
func endGameStep(w *World) StepFn {
  fmt.Println("[Game Over]: FINAL RESULTS.")
  return nil
}

Nothing magic here. These are just the actions the game needs in order to progress.

And the driver:

func main() {
  world := &World{TurnID: 1, NextPlayer: "Player #1"}

  state := waitForEmailStep

  for state != nil {
    state = state(world)
  }
}

The useful part is isolation, and how small the control flow stays.
There is no package-level state. The only shared state is the World itself.
You can easily recombine the functions or insert a new step. New game release!

Full code is here.

This is a more or less real example.
For the same idea in the standard library,
see text/template/parse/lex.go where Rob Pike uses type stateFn func(*lexer) stateFn to build a clean state machine for the template lexer.

Happy coding!

Recursive types are also a fit for nested JSON, but the type needs a place for a leaf value. This works:

A recursive type is a type that refers to itself. That is useful for data structures:

type Node struct {
    Next *Node
}

This shape is a list. A tree is the same idea with more than one link, for example Left and Right.

type Node struct {
    Value any
    Kids  []Node
}

A map or a slice can be recursive too:

type M map[string]M
type S []S

Those compile, and every element is another map or slice.

There is no field for a string or a number, so they are not enough to parse real JSON on their own.

The same recursion is legal for a channel:

type Ch chan Ch

A value of type Ch carries only another Ch.

I can see how to use the map and slice forms. I still do not see a use for the channel.

The only ideas I can come up with are actors and games.

Here is my toy example:

package main

import "fmt"

type Step chan Step

const maxJumps = 3

func play(self Step, next Step, done Step) {
 for range maxJumps {
  self <- self
 }

 next <- self
 done <- next
}

func main() {
 step := make(Step)
 next := make(Step)
 done := make(Step)

 named := map[Step]string{step: "step", next: "next", done: "done"}

 go play(step, next, done)

 for {
  select {
  case from := <-step:
   fmt.Println(named[from], "->", "step")
  case from := <-next:
   fmt.Println(named[from], "->", "next")
  case from := <-done:
   fmt.Println(named[from], "->", "done")
   return
  }
 }
}

Output:

step -> step
step -> step
step -> step
step -> next
next -> done

Each channel is a stone. Sending on a channel means landing on that stone, and the value sent is the stone you jumped from.

After a few jumps on the same stone (3 here), the player jumps to next and then to done.

I could use this in a PBEM game (have you ever played one?) or for a small FSM. One caveat: a PBEM turn carries the whole state of the world, and here there is no world at all, only the addresses of stones.

Still, I don’t think it’s for everyday programming: the same thing can be written in a more ordinary style.

Recursive maps, slices, and structs describe data. A recursive channel describes communication: what you pass is not data but an address to talk to next.

This is the core idea of the π-calculus, where processes send channel names over channels.

P.S. It’s also a great topic to bring up in interviews.

I didn’t plan to write here, but today I learned something xD At least I remembered bash!

More than 12 years ago I wrote some bash scripts for deployments, checks, and other little things.

Look at the tricks I picked up: `”$@”` gets the arguments of a function. You pass something in, and `$@` holds all of it. You can also take arguments one by one with `$1`, `$2`. You’ve seen that syntax somewhere, right? ;)

Also `head -n X`. One of the first commands you learn on Linux, right? (`cd` is probably the first.)

But the coolest part is copying to the clipboard. It looks like real magic. What do we have here? `wl-copy`, `xclip`, `xsel`. Oh My Zsh already has an abstraction for that: `clipcopy`. Use it!

And `grep`! I haven’t written a regular expression since 2018, or earlier. Really.

So I joined copy + grep + head + git + zsh. Did you know that git writes to stderr? (`2>&1` sends stderr to stdout.)

You probably think I made it up.

I wrote a function that copies the MR link when I push. So instead of copying it with the mouse, I just open the browser and hit `Ctrl+V`. Voylla.

This post has more text than the function itself :)
If you use Oh My Zsh, install it and use it. It’s free!

Oh, and also: not all Git hosts send the link. Keep that in mind!

Use it.

One everyday, battle-tested pattern is the outbox.

Why do we need it?

Because a DB transaction does not cover producing the message to the bus.

How to do it? Decompose the insert from the produce.

What does that mean?

First of all we need to store our outbox messages in a separate event table. I won’t write a full

table DDL here, but in my practice the important fields are

- obj_id — ref to the original object (convenient for searching if you want to look things up or have an admin panel/backoffice)
- topic — where the event needs to be sent
- payload — bytes/text, it depends on your taste
- status — here we want to see pending, processing, published, or error

Of course in real life there are a lot of extra fields for metadata: headers, correlation_id, retry_count, error_text, and so on.

Here I see one mistake: do not make obj_id UNIQUE in the outbox. Want only one order? UNIQUE on orders, not on outbox — they share the same transaction anyway. And one object often means many events, so UNIQUE on obj_id is the wrong constraint even when the main row is unique.

Another very important part: do the business work in the same transaction as storing the outbox event:

// good
begin_tx
store_order
store_outbox_event
commit_tx

// bad
store_order
store_outbox_event

In the `bad` part we lose the A — atomicity — from ACID, because the two writes are not one transaction. Otherwise you know — that does not work at all.

Then the main and complicated part: how to read new rows for parallel processing, without a long-running transaction.

So the base code is something like this:

begin_tx
rows = `select * from outbox_events where status = 'pending' order by created_at ASC limit :limit`

for row in rows {
    err = send_to_bus(row)
    if err != nil {
        mark_as_error(row)
    } else {
        mark_as_published(row)
    }
}

commit_tx

See the troubles here?

I count them:

- one long-running transaction with bus-involved code (Kafka, Rabbit, …); in case of a network glitch you need to wait 2–5 seconds to complete all events
- this SELECT has no lock: two workers fetch the same pending rows and both publish — that is duplicate delivery, not parallelism

How to solve it?

I prefer to have state-machine processing in three steps.

Step 1 — claim. One short transaction: lock a batch, mark processing, commit. No bus I/O inside.

begin_tx

rows = update outbox_events SET status = 'processing', updated_at = NOW()
where id in (
    select id from outbox_events
        where status = 'pending'
        order by created_at ASC limit :limit
        FOR UPDATE SKIP LOCKED -- <----------- see here
    )
returning *

commit_tx

`FOR UPDATE SKIP LOCKED` prevents two workers from fetching the same IDs at the same time.

Step 2 — send. Outside any DB transaction.

Step 3 — final status. A separate micro-transaction per row. The DB still has to open a short TX for that UPDATE; it is just not wrapped around the bus send.

// after commit_tx of step 1
for row in rows {
    // step 2 - no DB transaction
    err = send_to_bus(row)  // Kafka key = obj_id

    // step 3 - micro-transaction, status only
    if err != nil {
        db.execute("UPDATE outbox_events SET status = 'error' WHERE id = :id")
    } else {
        db.execute("UPDATE outbox_events SET status = 'published' WHERE id = :id")
 }

One more nuance from “do not make obj_id UNIQUE”: one order can emit CREATED, then a second later PAID. Worker 1 SKIP LOCKED a batch that has CREATED; worker 2 in the same millisecond takes the next batch with PAID for the same order. They send in parallel, and because of the network PAID can land in Kafka before CREATED.

Fix: when producing, use obj_id (order_id) as the Kafka message key. Kafka then puts both messages on the same partition and keeps order inside that partition even if they arrived with a microsecond skew.

If a worker dies, a scheduler resets status back to pending. One catch: pick the interval carefully — if the main sender runs every 1 second, run the scheduler on something like 30 seconds, and only reset rows whose updated_at is old enough that you do not overlap a live worker.

The same for error: increment retry_count and retry after some interval.

Here I highlight the issue I want to solve with this code: the long-running transaction, nothing more.

SKIP LOCKED also stops two workers from grabbing the same row at the same time — that duplicate we do want to kill (network load, event races).

It does not make delivery exactly-once. If the worker dies after send_to_bus and before published, the scheduler retries and the bus sees the message twice. Inbox is still needed. Unique/integrity stays on the main table, not on this read path.

Using the outbox is not a hard pattern, but it is useful in a world of events.

I tried before and dropped it (life got busy). This time it’s done.

What’s in this release:

• Scala 3 alongside 2.13 — same DSL
• Netty 4.1.137, refreshed play-json / circe / jsoniter modules
• Maven Central (omhs-dsl + JSON support)
• CI on both Scala versions

The hard part was the routing macros. On Scala 2, ~> expanded into an anonymous ExecutableRule subclass. Scala 3 quoted macros don’t generate that cleanly, so ExecutableRule now takes a runner: List[ParamDef[_]] => AsyncResult, and the macro only builds that function. Same DSL, different codegen.

Artefacts are here.

How to use:

// scala
import com.github.fntz.omhs._
import com.github.fntz.omhs.playjson.JsonSupport
import RoutingDSL._
import play.api.libs.json.{Format, Json}
import scala.concurrent.Future

case class Person(id: Int, name: String)

@main def main(): Unit = {
  implicit val personJson: Format[Person] = Json.format[Person]
  implicit val personBodyReader: BodyReader[Person] = JsonSupport.reader[Person]()
  implicit val personBodyWriter: BodyWriter[Person] = JsonSupport.writer[Person]()

  import AsyncResult.Implicits._
  import scala.concurrent.ExecutionContext.Implicits.global

  val simpleGetRoute = get("ping") ~> { () =>
    "pong"
  }

  val getWithParamsRoute = get("bar" / string) ~> { (x: String) =>
    s"given: $x"
  }

  val postPersonRoute = post("person" <<< body[Person]) ~> { (p: Person) =>
    val x = p.copy(name = "new")
    Future(x)
  }

  val route1 = new Route().addRules(
    simpleGetRoute,
    getWithParamsRoute,
    postPersonRoute
  )

  val server = OMHSServer.init(9000, route1.toHandler(Setup.default), None)

  server.start()

  sys.addShutdownHook(server.stop())
  new java.util.concurrent.CountDownLatch(1).await()
}

All my examples were related to slices, without a real application in production code.

Let’s fix it!

Do you use Kafka or another message broker? Almost everyone does now.

So, let’s look at an example from confluent-lib:

consumer, err := kafka.NewConsumer(ToConsumerConfig(cfg, "earliest"))
if err != nil {
    log.Fatalf("Failed to create consumer: %v", err)
}

defer consumer.Close()

err = consumer.SubscribeTopics([]string{topic}, nil)
if err != nil {
    log.Fatalf("Failed to subscribe to topics: %v", err)
}

for {
    msg, err := consumer.ReadMessage(1 * time.Second)
    if err == nil {
        fmt.Println("Received message: ", string(msg.Value))
    } else if !err.(kafka.Error).IsTimeout() { 
        log.Fatalf("Consumer error: %v", err)
    }
}

What do we see here? Standard setup around the topic and then an infinite loop

(in real systems, of course, it is usually controlled by shutdown logic).

If we transform this example into an iter-style version:

for msg, readErr := range consumeMessagesIter(consumer, 1*time.Second) {
  if readErr != nil {
   log.Fatalf("Consumer error: %v", readErr)
  }
  fmt.Println("Received message: ", string(msg.Value))
 }


func consumeMessagesIter(consumer *kafka.Consumer, timeout time.Duration) iter.Seq2[*kafka.Message, error] {
  return func(yield func(*kafka.Message, error) bool) {
   for {
     msg, err := consumer.ReadMessage(timeout)
     if err != nil {
       var kafkaErr kafka.Error
       if errors.As(err, &kafkaErr) && kafkaErr.IsTimeout() {
         continue
       }
       if !yield(nil, err) {
         return
       }
       return
     }

     if !yield(msg, nil) {
      return
     }
    }
  }
}

What is the difference? In this Kafka case, there is no memory win from iter, because the original version is already streaming and does not build large intermediate slices either.

So one classic iter advantage does not apply here. Still, iter helps with composition, reuse, and cleaner separation between reading and processing.

For example, composition here means we can build a pipeline like:

`consumeMessagesIter -> parse JSON -> filter by event type -> handle business logic`

Each step can be a small reusable function, and we can chain them without rewriting the Kafka read loop every time.

Full example here.

1. What we have now

// Generic function
func foo[T any](x T) {
 fmt.Println(x)
}

// Generic type with a method that uses the type parameter
type Printable[T any] struct{}

func (f Printable[T]) Print(x T) {
   fmt.Println(x)
}

2. What we will have in Go 1.27

type Printable struct{}

func (f Printable) Print[T any](x T) {
   fmt.Println(x)
}

3. What we still want

// Not valid in Go today
type Printable[T any] interface {
   Print[R any](x T) R
}

In the first example, even if the struct itself does not need `T`, you still have to put `T` on the type declaration to make method APIs generic.

In the second example (Go 1.27), you can keep the struct non-generic and put type parameters directly on the method.

The third example is what I still want: generic interface methods.

Why is this still hard?

The Go proposal says generic concrete methods are manageable, but generic interface methods are much harder to implement efficiently because interface dispatch is dynamic, and the compiler/runtime cannot know in advance which method instantiations will be needed.

So is Go 1.27 bad, or does it add nothing?

Of course not. It is a useful step forward, especially for cleaner chained APIs.

Example:
type Option[T any] struct {
 v  T
 ok bool
}

func (o Option[T]) Map[R any](f func(T) R) Option[R] {
 if !o.ok {
  return Option[R]{}
 }
 return Option[R]{v: f(o.v), ok: true}
}

// Signature here is simplified just to show the chaining idea.
func (o Option[T]) Transform[R any](f func(T) R) Option[R] {
 if !o.ok {
  return Option[R]{}
 }
 return Option[R]{v: f(o.v), ok: true}
}

// chaining:
// out := someInt.
//  Map(toString).
//  Transform(SomeFunc)
//
// current style (list :))
// out := Transform(Map(someInt, toString), SomeFunc)

What is still missing for full monad-style abstractions:

// Not valid today:
// generic method inside an interface.
type Functor[T any] interface {
   Map[R any](func(T) R) Functor[R]
}

Read spec here

Microservices don’t live in isolation. Every service:
- talks to a database
- publishes or consumes messages (queues, topics)
- depends on infrastructure: health checks, lifecycle management, metrics, tracing

And these integrations are rarely unique. Across services, you keep solving the same problems:
- DB and queue clients
- configuration and bootstrap
- health endpoints
- logging, metrics, tracing

That’s why teams inevitably end up with shared building blocks.

So what are the options?

In practice, it’s usually a mix of:
- copy-paste
- service templates (boilerplate)
- shared/platform libraries

Copy-paste works — until it doesn’t. Rolling out changes across dozens of services quickly turns into a mess.

That’s why I usually lean toward a platform library.

A typical structure might look like (here golang):

builder/  common/   consts/  health/  logging/  redis/     tracing/
bus/      configs/  grpc/    kafka/   metrics/  security/

This approach makes it easier to:
- reuse integrations
- test things once
- evolve infrastructure consistently

It also pairs well with service templates, so developers can focus on business logic instead of wiring.

But there’s a trade-off.

Without strict versioning and compatibility rules, a platform library easily turns into a “god library” — tightly coupled, hard to upgrade, and slowing everyone down.

Rule of thumb:

If you have more than a handful of services, start with shared building blocks — but treat them like a product, not a dump of utilities.

P.S. Multi-language environments break this model in interesting ways — but that’s a separate headache.

The iter package gives us a DSL-like style: we can build a small, readable pipeline instead of combining a few for loops. It can also be memory-friendly because it streams values instead of materializing intermediate slices.

Let’s benchmark something closer to a “production-ish” scenario. (I also don’t want to compare a single one-liner.)

We will use these small helper functions:

func square(x int) int {
  return x * x
}

func filter(x int) bool {
  return x%2 == 0
}

func sum(acc int, x int) int {
  return acc + x
}

And these iterator helpers: Generate, Map, Filter, Reduce.

The flow is:
- generate numbers from `0..max-1`
- square each number
- keep only values that pass `filter` (in this case: keep even values)
- reduce (sum) them into a single number

func Pipeline(max int) int {
  result := Reduce(
    Filter(
      Map(
        Generate(max), square),
      filter), 0,
    sum)

  return result
}

And compare it with a direct loop:

func ForLoopPipeline(max int) int {
  acc := 0
  for x := range max {
    tmp := square(x)
    if !filter(tmp) {
      continue
    }
    acc = sum(acc, tmp)
  }

  return acc
}

If we run go test -bench=. I get:

BenchmarkPipeline-4              1364      887367 ns/op
BenchmarkForLoopPipeline-4         924     1213157 ns/op

So, on my machine, the iterator pipeline is faster than ForLoopPipeline by about ~1.37 times.
If we run with -benchmem, we can also see that both versions can run with **0 allocations**.

For an experiment, I preallocate a slice and compare again:

func ForLoopWithArrayPipeline(xs []int) int {
  acc := 0
  for _, x := range xs {
    tmp := square(x)
    if !filter(tmp) {
      continue
    }
    acc = sum(acc, tmp)
  }

  return acc
}

Results:

BenchmarkPipeline-4                         1274      956065 ns/op
BenchmarkForLoopPipeline-4                   967     1225687 ns/op
BenchmarkForLoopWithArrayPipeline-4          328     3807070 ns/op

Here the iterator pipeline is ~4x faster than the slice-based loop.

This is expected: the slice-based version must load 1_000_000 ints from memory. Generate(max) produces numbers without reading a large array, so it puts less pressure on caches and memory bandwidth.

What else?

You may ask why not write the pipeline in a step-by-step style (with intermediate variables), like this:

func PipelineEscape(max int) int {
  xs := Generate(max)
  xs = Map(xs, square)
  xs = Filter(xs, filter)
  result := Reduce(xs, 0, sum)
  return result
}

Here is the answer:

BenchmarkPipelineEscape-4                    100    10368198 ns/op       192 B/op        6 allocs/op
BenchmarkPipeline-4                         1270      929701 ns/op         0 B/op        0 allocs/op
BenchmarkForLoopPipeline-4                  1094     1506114 ns/op         0 B/op        0 allocs/op
BenchmarkForLoopWithArrayPipeline-4          289     3900064 ns/op         0 B/op        0 allocs/op

PipelineEscape does 6 allocations and is ~12x slower than the “nested” Pipeline.

If we run escape analysis:

go test -run=none -gcflags=all='-m -m' 2>&1 | rg 'PipelineEscape'

we will see, for example:

cannot inline PipelineEscape: function too complex: cost 144 exceeds budget 80

More importantly, we will see messages like func literal escapes to heap and parameter yield leaks. That means the compiler must allocate closure-related state on the heap (instead of keeping it on the stack), which adds allocations and typically slows the benchmark down.

In the end: iter can be competitive (and sometimes faster than a direct loop), but performance depends on the exact code shape and what optimizations the compiler can apply. If you want to adopt the new iterator style, do it — but benchmark your code before and after.

Takeaway

- The iterator style can be fast, but performance depends on code shape, not just on the abstraction.

- A “step-by-step” pipeline with intermediate variables may trigger escape to heap, causing allocs/op and a big slowdown.

- A “nested” pipeline expression may allow better inlining and stack allocation, resulting in 0 allocs/op.

- A loop over a prebuilt slice often loses due to memory/cache pressure (reading a large array), not because iterators are inherently slow.

- Always look at -benchmem and confirm hypotheses with escape analysis (-gcflags=all=’-m -m’).

Do you still remember from the previous post that iter.Seq is a type alias for a function?
So, I might repeat myself:

type Seq[T] = func(yield func(T) bool)

IT’S A FUNCTION!!!

If it’s a function, you can do many interesting things with it, such as writing your own Map:

func Map[T any](xs iter.Seq[T], mapper func(T) T) iter.Seq[T] {
    return func(yield func(T) bool) {
        for x := range xs {
            tmp := mapper(x)
            if !yield(tmp) {
                return
            }
        }
    }
}

Or even add Filter:

func Filter[T any](xs iter.Seq[T], filter func(T) bool) iter.Seq[T] {
    return func(yield func(T) bool) {
        for x := range xs {
            if !filter(x) {
                continue
            }
            if !yield(x) {
                return
            }
        }
    }
}

It’s that simple. What we have here are higher-order functions -Map and Filter.
With these, we could even recreate our own version of lo!

But let’s get back to the main point: what’s the best thing you can do with functions?

Function composition (pipelining):

xs := []int{1, 2, 3, 4, 5, 6}

// Square each element
ms := Map(slices.Values(xs), func(x int) int { return x * x })

// Keep only even numbers
fs := Filter(ms, func(x int) bool { return x%2 == 0 })

Here we chain Map and Filter together - the output of one becomes the input to the next. This is the essence of functional composition: building complex transformations by combining simple building blocks.

And for dessert - terminators (functions that consume the sequence):

func Reduce[T any](xs iter.Seq[T], zero T, acc func(T, T) T) T {
    for x := range xs {
        zero = acc(zero, x)
    }
    return zero
}

The Takeaway

type Seq[T] = func(yield func(T) bool)

It’s just a function. But because it’s a function, we get:

• Lazy evaluation — compute only what you need
• Composability — build complex pipelines from simple pieces
• Zero allocations — no intermediate slices, no memory overhead
• Infinite sequences — generate values on the fly
• First-class citizenship — pass them around, return them, store them