Ultra fast key value store (in C btw) | Hacker News Reader

Ultra fast key value store (in C btw)

freshql.ai

19 pointsmkristiansen23 comments

I'd love for your next post to be a read through of the Redis source code to understand why it's performance characteristics are different than yours. I assure you that it's not out of laziness or naivite :)

Writing your own implementation of something is fantastic way to learn. So is reading a good one.

I like that idea.

Flagged because without code or even binaries there's no way to learn anything from this. Is the code memory safe? Does it gracefully handle error conditions? What tradeoffs were chosen?

Plenty of OSS "simple redis clones" exist with performance better than Redis. I think it would be more useful to re-post those than share this.

I went over the guidelines and cannot figure out which rule I broke?

"You write that it would be more useful to re-post something else" -- Is your critique just that you didnt like the quality of what I wrote? or is there something more tangable?

Just post your source. Benchmarks should be reproducible.

I think this is a great question to ask so I'll chip in with some more feedback. Feel free to skip if you didn't want a wall of text, I always try to throw in some thoughts when someone takes the time to ask for them so it sometimes ends up being more than they really cared for :). Of course, the guidelines also guide to not why you/others flag... though I think cases where the author is well meaning and involved in the comments it's ultimately a good thing and example of why they are "guidelines". After all, it's ultimately about fostering the "anything that gratifies one's intellectual curiosity" (admittedly a bit wishy-washy) bit at the top, not a complete list of hard and fast truths to bench things against.

A lot of people here are likely to consider things like "(in C btw)" being in the title at least distracting from that goal and at the most flamebait and editorialized. It's already distracting enough when "(in Rust)" or what have you is in the title and most of the comments end up being the same X vs Rust comments we've been reading for years instead of about this new thing but it's even more distracting when presented as a counter in that way.

Another factor that will likely rub a lot of folks the wrong way is it's (reductively) a post about how "X is bad so here's Y" but without all of the interesting bits that make Y tangible and engaging. Things like an interesting set of reproducible tests rather than at-word claims about one benchmark, comparisons of where Y fell short that allowed X to get such gains, and a single Y to focus on. On the latter in particular, is it a post detailing development of a new ultra fast key value store or is it a post trying to give examples of why modern complicated software is bad? It's a bit short of either as a result - the first is lacking enough data and clouded by the distraction of the second topic and the second being more a short take than something to engage with. Both topics are actually pretty interesting to think about, just neither as presented.

The final thing I'll bother to mention, and I this is definitely the least relevant IMO, is your submission history is heavily weighted towards posting your own content. You've even posted your same articles multiple times (at least spaced out a bit). I'm not saying you're necessarily abusing posting to the point of being against the rule about self promotion or anything of that nature but that combined with the average engagement should be a good hint how much things like (in C btw) gather and encourage the (wrong) kind of attention for discussion.

Overall I think you probably have an extremely interesting bit of software and the post is very close to being something that would be near the top of the front page. I honestly want to know so much more about it and see it go places if it's nearly as cool as it sounds it might be. I also don't want any of this to seem like a bored rule book read to screw you or anything like that, hopefully it's instead useful to you as the constructive feedback on what kind of content launches a solid discussion here.

Might be interesting, but this tone is nails on a chalkboard to me. Bailed after the third "dear reader"

I'm sorry to hear that it read like that to you. I was "slightly" inspired by reading "The Tale of Despereaux" to my kid and was trying to capture the tone of the book. :)

    document.body.innerHTML = document.body.innerHTML.replace(/,?\s*dear\s*reader,?\s*/gi, ' ');

After that it's much more tolerable. It does leave me wishing it spent more time exploring the differences themselves and less time setting the stage for how it's different though! I want to learn how, what, and why, or what still needs to be done and how it may or may not impact things... not just that someone wrote code and it supposedly went fast in one set of tests.

I personally prefer "dear leader"

I'm sure people will call out performance is likely due to the different nature of the beast that is now redis -- there are lots of wire compatible implementations that are faster thant redis, with some lost affordances.

Either way, the templating bit on the homepage is a pretty interesting concept. Storage and templating in one with write operations in the template. Im curious how this grows out and whether it will be great or a regret. Somewhat dynamic static sites like that could be fun.

On the first part, yes there are pleanty of wire-compatable redis clones. And while those are interesting, its your second part that I find interesting as well.

The idea of having a strong templating engine with a fast storage backend able to use dynamic content to deliver efficiently renderes websites with minimal hardware.

I wonder how a site with three pages and no code lands on the HN homepage? Impressive marketing.

Just to note for anyone like me, Dark Reader appears to mess up the formatting of the article/website. You might need to disable it for the article to actually fill the screen and not be squeezed into a small column.

While I agree with, and share, the sentiment, and I like (in C btw) and think we should use it like Rust people do with written in Rust.. there's a bit too much pontificating going on here without going into why's and no source to show and tell. I don't mind as much the latter as the former; It leads nowhere good.

Also, site is rendered in a way that sucks to read.

Where is the code?

Great read but I would love to see some parts being open sourced.

I'm considering open sourcing parts of the system -- at its core this is a hashtable with wrapped in a tcp server. At its core a system like this is fairly simple :)

>dude, trust me

Beating over-hyped web tech with reasonably written C is hardly an achievement.

Why do you think so? I think it's an achievement and I'd welcome more similar ones for other over-hyped web techs.

Still a good reminder for all those who don’t know for whatever reason.

I have at work to deal with people that hear “caching” and they immediately answer “we have to install redis” - well no - I meant we can do local in-process caching of classes/variables/other structures that will be faster than calling redis over the network.

I think doing things like this in a language like C can serve as a reminder that it is, very much posible, to do actual work with minimal tools - In my case emacs and a clang.

Reply on news.ycombinator.com