I'm not really sure what it costs these days - i know certain projects not entirely free like they were a few years ago, but there's a pretty good "build your own redis" among other things.
It has little step-by-step tasks with automated tests. There are some other good ones like git and docker. It's pretty cool.
This is an interesting project but a poorly chosen name because it can easily be considered trademark infringement for being confusingly-similar to "Redis", especially since it's a self-admitted clone. I would change it now before you are forced to change your name and you lose time confusing people and wasting time renaming everything.
Sorry if somewhat off-topic, but might help with getting more users. Redis is actually good enough and easy to install for most projects, but it has downside that it's "memory-only" (needs to fit in ram), and if you're in a tight container/vm – you'd better not rely on it solely.
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.
Redis is for high frequency cache, disk latencies would slow it too much. Maybe putting something that would normally be evicted to disk could be valid compromise.
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.
If you're in a tight VM and are running Redis inside it, as opposed to a separate VM / cluster, you need an embedded DB, not Redis.
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.
> Written in Zig for optimal performance and memory safety
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.
26 comments
[ 7.0 ms ] story [ 439 ms ] threadIt has little step-by-step tasks with automated tests. There are some other good ones like git and docker. It's pretty cool.
https://app.codecrafters.io/courses/redis/overview
> 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.
Naming is famously difficult in this world!
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.
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.