We are looking for people to join our mission of building an event sourcing database engine. Event sourcing is a pattern in which, instead of storing the current state of the data and using it as a source of truth, one should immutably record the full series of actions taken and designate that log as a source of truth instead. This approach can simplify tasks in complex, changing domains by avoiding the need to synchronize data models and domain models. It also provides great auditing and transactional capabilities, as well as opportunities for lossless error correction.
The core ideas behind our project (PumpkinDB) stem from the so called lazy event sourcing approach which is based on storing and indexing events while delaying domain binding for as long as possible. The intention of this database is to be a building block for different kinds of event sourcing systems, ranging from the classic one (using it as an event store) all the way to the lazy one (using indices) and anywhere in between. It’s also possible to implement different approaches within a single database for different parts of the domain.
We’ve been previously nominated as a Crate of the Week and have grown our followers base significantly since the first announcement.
We are gearing up for the next release and have recently pushed out some exciting bits (like SPDK bindings for Rust for our future direct NVMe storage module). We are working on examples and articles to explain our ideas in more details to make the project more accessible in the short term.
I’m starting a recommender systems framework written in Rust and I’d love to work with people interested in this topic. There are a bunch of fairly easy issues here: https://github.com/z1mvader/quackin/issues that only requre some basic knowledge on recommender systems. The project itself is pretty new and young so I hope that it will be a good space to discuss recommender systems and machine learning topics as well.