3 ms·

We are definitely looking to improve the documentation. This is 0.1, after all. This project was started as a backend for a lazy event sourcing approach (https

by yrashk 10y ago

We are definitely looking to improve the documentation. This is 0.1, after all. This project was started as a backend for a lazy event sourcing approach (https://blog.eventsourcing.com/lazy-event-sourcing-ed7e59007e17 https://blog.eventsourcing.com/lazy-event-sourcing-ed7e59007... , https://m.youtube.com/watch?v=aqv8d1pjmU8 https://m.youtube.com/watch?v=aqv8d1pjmU8) and beyond. The idea behind it is that it provides primitives for building systems that are designed around immutable events, journals, indexing, etc. Hence the current positioning. We thought it would be useful to be targeting fairly narrowly early on. Either way, we will definitely need to expand on that in our materials

elcritch 10y ago
Amazing looking project! I've been daydreaming about using LMDB's memory mapping to provide a flexible low level db primitive for quite a while, figuring a combo of erlang like actors and flexible data scripting would be killer. Needless to say I love the design. Any thoughts on whether this could be used to implement a Q/kdb+ like computation system? Seems like PumpkinScript could be extended with a library of computational array primitives. (https://news.ycombinator.com/item?id=13481824 https://news.ycombinator.com/item?id=13481824) That being said, it'd be great to be able to read how the "actor" system is implemented. The documentation alludes to actors and pub/sub channels. Not sure I can help much at this time, but will keep an eye on it to see!