So, there's another project – called kvrocks https://github.com/apache/kvrocks , which is for people which don't need in-memory perf of redis but would like to use its protocol and be still very performant. However, its devs never packaged a release in deb and other formats.
So, if you were to implement something similar ^ which will implement the protocol, have ability to grow on disk, and be available in distro repos (ideally) – would definitely hold a niche of many little projects which benefit from redis-like thing I've done.
another major drawbacks of Redis is that It is single threaded and sync. you need expensive high frequency CPU if you need more performance. something that could benefit from multi core system and if you would want to use disk cache async is a must. single threading also affects scripts running on Redis side, when they execute whole Redis is waiting and is unable to fulfil other requests.
another place for improvement would be proper easier to use HA, and maybe also auto scaling.
Redis-compatible protocol guarantees that you can think about the things you've mentioned later. If project is successful – you'll find money to pay for RAM and move to pure Redis. If it's CPU-bound – you'll find multi-threaded alternatives.
So this is a pretty nice niche IMO actually.
It regularly gets itself into messed up state and even with graceful shutdown for node updates the official client libraries throw errors for up to a minute.
You can use the ancient BerkeleyDB which is supported everywhere for last like 30 years. Or a more recent LevelDB. Or even SQLite which is plenty fast on simple queries.
You'll have to tolerate the high latency of safely writing tings to a block device, compared to RAM. If your load is mostly reads, it should be OK.
Ironic to see this, as even a cursory glance over the code shows a lot of memory bugs, such as dangling pointers, data races, some potential bugs like double free, etc.
It is good that the OP is learning things, but I would caution against relying on LLMs and taking on a bigger project like this, before the basics are well understood.
Personally, this is one of the reasons I dislike the LLM hype, people are enabled to produce much more code, code that they aren't qualified to support or even understand.
While the project linked is clearly designated as strictly for "learning purposes", the applications we will get in the large will be of no better quality.
The difference being, before LLMs, those, who didn't have qualification, wouldn't even approach problems like this, now they can vibecode something that works on a lucky run, but is otherwise completely inadequate.
It has little step-by-step tasks with automated tests. There are some other good ones like git and docker. It's pretty cool.
Something like LevelDB is relatively easy to write. Then you can build the rest of Redis on top of it.
I mean, I have my own C libraries for most of these!
I've found that LLMs are particularly bad at writing Zig because the language evolves quickly, so LLMs that are trained on Zig code from two years ago will write code that no longer compiles on modern Zig.
There seems to be a fair amount of stigma around using llms. And many people that use them are uncomfortable talking about it.
It's a weird world. Depending on who is at the wheel, whether an llm is used _can_ make no difference.
But the problem is, you can have no idea what you're doing and make something that feels like it was carefully hand-crafted by someone - a really great project - but there are hidden things or outright lies about functionality, often to the surprise of the author. Like, they weren't trying to mislead, just didn't take them time to see if it did all of what the LLM said it did.
In my experience, when you work with something like agentic development tools, you describe your goals and give it some constraints like “use modern zig”, “always run tests”… and when you ask it to write a README, it will usually reproduce those constraints more or less verbatim.
The same thing happens with the features section, it reads like instructions for an LLM.
I might be wrong but I spend way too much time using Claude, Gemini, Codex… and IMHO it’s pretty obvious.
But hey, I don’t think it’s a problem! I write a lot of code using LLMs, mostly for learning (and… ejem, some of it might end up in production) and I’ve always found them great tools for learning (supposing you use the appropriate context engineering and make sure the agent has access to updated docs and all of that). For example, I wanted to learn Rust so I half-vibed a GPUI-based chat client for LLMs that works just fine and surprisingly enough, I actually learned and even had some fun.
these seem to occur only in college assignment projects, and in the output of text generators trained on those.
> Memory safety with RAII patterns
I'm curious to see how they achieve RAII in Zig, which doesn't have destructors. If they mean defer + deinit methods, that's not the same thing.
No? It's the first thing that came to my mind when I've read RAII.
Naming is famously difficult in this world!
idk if redis labs (the organization aka big bad) are going to patent the “protocol” to disallow clones (or they’d be going after valkey first)
only if you want to refactor/rewrite a lot
