Chronicle – Idiomatic, Type Safe Event Sourcing Framework for Go
Key topics
The Go community is abuzz about Chronicle, a new event sourcing framework that's sparking both curiosity and skepticism. Some commenters are drawing parallels with an existing JVM library called Chronicle, while others are questioning the framework's idiomatic design choices and the need for specific struct annotations. The author clarifies that users aren't forced to use certain annotations, and that the framework offers flexibility in handling events. As one commenter is eager to explore real-world use cases, the discussion highlights the ongoing interest in event sourcing and the trade-offs involved in designing a robust framework.
Snapshot generated from the HN discussion
Discussion Activity
Moderate engagementFirst comment
4d
Peak period
6
90-96h
Avg / period
3.5
Key moments
- 01Story posted
Aug 28, 2025 at 12:37 PM EDT
4 months ago
Step 01 - 02First comment
Sep 1, 2025 at 8:00 AM EDT
4d after posting
Step 02 - 03Peak activity
6 comments in 90-96h
Hottest window of the conversation
Step 03 - 04Latest activity
Sep 1, 2025 at 12:40 PM EDT
4 months ago
Step 04
Generating AI Summary...
Analyzing up to 500 comments to identify key contributors and discussion patterns
Want the full context?
Jump to the original sources
Read the primary article or dive into the live Hacker News thread when you're ready.
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/
I wasn't aware of this library, I did check for name collisions with other Go repos though
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:
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
You're not forced to use that comment, you can pass the event however you like, if you satisfy the event.Any interface (by having the method EventName() string).
I prefer that comment because Go doesn't have native sum types, and I believe that by using the framework in combination with the gochecksumtype linter, you get the best developer experience and type safety (you DO have tab autocomplete with the events for recordThat - the type system helps because of the sealed interface).
But again, if you don't want to use the linter, no problem. You can create constructors for the events however you like, just like in your example.