Your readme promises a lot, but your code doesn’t back it up. You need to be clearer in the readme that this is wildly alpha software.

Couple of points that raise some alarms:

• https://github.com/santosh79/remixdb/blob/master/lib/remixdb.ex doesn’t create an OTP application
• No supervisors. Not only is this bad practice, it goes against all general claims to fault tolerance in the Readme, as well as against explicit claims to use supervisors.
• No distributed functionality, despite claiming so in the readme.
• Your latest commit says “Using HashDicts for better hash performance” and the commit shows you’ve replaced a bunch of Maps with HashDicts. Not only is this false, Maps perform better in literally every case, but HashDicts are deprecated.
• you’re creating an escript, but a release would be more appropriate for a long running service.
• extensive use of spawn_link instead of using OTP behaviours.
• unlinked processes.
• You aren’t following elixir conventions for file organization

I’m not trying to discourage you, I think there’s a lot of value in thinking through how a key value store in Elixir might work. However, right now your readme is 100% aspirational, but written as if it reflects the current capabilities of your code. You do yourself and your users a disservice by not being clear on this point.

Having a Redis protocol compatible k-v, but with an Elixir implementation certainly sounds interesting!

However, I’d advise against hand building the distributed k-v part yourself, as it can become hard to get proper CP or AP guarantees in a clustered environment. Instead, I’d suggest looking for third party libraries which solve those problems. The first ones which come to mind are riak_core for eventual consistency, and riak_ensemble for strong consistency. I also wonder whether recent work on Phoenix presence (i.e. CRDT) could be used for a general purpose distributed k-v, and what are the trade-offs. I’ll ping @chrismccord to hear his thoughts on this

However, if you just want to practice and/or have fun, then it will probably be simpler to build from scratch, as long as you’re not optimistic about proper behaviour on netsplits. Getting that part right requires carefully applying some scientific papers and a good amount of testing. Otherwise various subtle errors might occur, and the storage might have unpredictable behaviour on netsplits.

I agree with other comments, especially those made by @benwilson512. An app should be OTP compliant, because strange bugs may occur, and it might not play nicely with the client’s project. If you’re still practicing, it’s fine to violate those principles and taking baby steps in whichever order suits your flow. However, the project Readme should clearly state that, because otherwise people may get false impression about the maturity of the library. Here’s an example of how we did it for our Phoenix socket client.

Best of luck!

Yes. This used to be the case, but in recent versions of Erlang (18+) this has been changed. Maps are now more performant than HashDicts. Also see http://www.theerlangelist.com/article/eia_elixir_12

Thanks for your suggestions. I’ve gone ahead and updated the README, to
reflect the same and appreciate your suggestions on that as well.

I hadn’t thought about riak_core/riak_ensemble. Will check it out. As for
CRDTs, isn’t that a little loose with it’s consistency guarantees? I was
considering those, but Redis is very strong with it’s consistency
guarantees, so I’d like to have RemixDB meet those as well.

Best,
Santosh

Appreciate your response as well. Misleading is definitely a bit of a stretch, since a whole slew of sections are TBD’ed. I’ve gone and thrown in a disclaimer now, so it should be more obvious now.

And yes, I’m in complete agreement, supervisors/other OTP constructs are definitely something that will be there when it’s usable and are a high priority. RIght now, as Sasa had picked up, it’s more of a playground than anything else. But should be usable real soon.

Best,
Santosh