One of the most complicated systems I worked on was based around event sourcing with a bunch if AWS DynamoDB tables and Kinesis streams. The original designers thought the inherent auditing capabilities and ability to generate view tables of anything would be a great for data durability and performance. In reality, nobody really understood how to effectively use it and ended up with events that were giant entity blobs so you couldn't understand changes, expensive AWS bills, numerous view tables that were impossible to know if they were in sync and correct, and difficult to evolve systems.
Event sourcing is a cool system, but friends don't let friends build systems they don't understand. There's a lot to event sourcing and I agree with the gist of this article of not modifying events. Though you can end up with a lot of events in a complex data model.








Now you have two package managers. The problem is that Nix needs to create a folder structure that matches what your language package manager wants to see.
Even if the language package manager goes away, languages have slight differences that can't be totally abstracted away. C/C++ have .h and .c files. JS has its own thing, C# has a .dll. Each language has difference opinions on how symbols get resolved.