Hey! Congrats on shipping.

Just FYI - There's a pretty popular (in finance circles) JVM library called Chronicle[0], which also deals with high throughput event queues etc.

[0]: https://chronicle.software/

This is a lot of work to make the following work and it feels odd to force comments onto my structs to make your API able to look like the following:

    //sumtype:decl
    type AccountEvent interface {
     event.Any
     isAccountEvent()
    }
    //...
    return a.recordThat(&moneyDeposited{
      Amount: amount,
     })

This API requires that you know what you can pass into it - not a type, an interface. You know, by way of being familiar with the code base, you have moneyDeposited that matches. Do you have userSuspended wired up? Is that even an option? As your code base grows and as new developers onboard, more and more of the events available will become need to take up mental space.

I am in favor of discoverable APIs that leverage simple IDE features, like string completion. The API that I would design for recording events would be closer to:

    return a.event.AccountDeposit(amount)

What other events can you record? Just tab away and find out. AccountSuspend pops right up.

And when you do it this way, you no longer need to pull in the the non-standard sum types package that requires comment annotations and subsequent linting packages.

I suppose the goal here is a general framework so to make things general, you are adding indirection. I've not had to create new events in an event sourced architecture on a regular cadence. Usually, any particular team has N events they generate, where N is relatively small and almost never gets new events. And my events are usually historic or log-like in nature, spreading data out to other systems and the events themselves are not the source of truth, but the system that generated them is

May I ask, idiomatic by what standard?