Event Store VS eventsourcing

I've been doing some research and found this: https://github.com/EventStore/EventStore

C#: In Europe, Java is still strong but many trading firms use C# because of the strong Microsoft culture in Europe, as well as because of strongly supported C# libraries like say EventStore, which tends to be used for the matchmaking engines for stock exchanges (especially that exchange matchmaking problem is basically SMR). And skimming over the code, it has Paxos implemented too, making it good for dealing with partial failures (failover), essential for any HFT/trading firm. C#'s also the biggest ecosystem that many of the breakthrough java tech mentioned earlier was first ported to.

Support for eventstore.com eventstore. esdb

Where's the catch, then? Well, there's a couple of catches, in fact. First of all, in a distributed setting, appending data to a log isn't that easy. First, you need to make your log distributed. Again, Kafka/Cassandra/EventStore make this possible, however, whenever you start dealing with distributed data, you‘re introducing new operational and implementation complexity.

Support for eventstore.com eventstore. esdb

I have a package where I try to tackle event sourcing with DDD in mind. https://github.com/hallgren/eventsourcing

Its been a year since I posted https://www.reddit.com/r/golang/comments/drdyqm/eventsourcing_in_go/ and asked for feedback for my eventsourcing pkg.

A friend of mine has been working on an ES project with idiomatic Go using zero dependencies: hallgren/eventsourcing. If you want something lightweight with an open and flexible API I recommend you check it out. It uses submodules to support different persistance methods, e.g. in-memory or SQL.