Show HN: Knuckleball – An in-memory data structure server
github.com
github.com
Building a data structure server is great exercise in understanding a lot of different things: networking basics, efficient storage, fast retrieval and memory safety. Obviously I don't mean to claim that the author of the project necessarily had the same aims.
Exactly. People complain about reinventing the wheel, but compare the wheels we have today with the wheels we had 2,000 years ago, plus all the different wheels in between.
The wheel has been reinvented many times throughout history, and we are all better off for it.
I don't think everyone was naysayer about your submission. Some including me were confused about the purpose since it reflects how we should look at it. If it was done to explore redis like server but with different priorities/knob everyone would have wanted to explore if that helps their use cases or how that affect the tool. Since its for learning the focus might be how readable/understandable the code is and maybe trying to learn from it themselves.
I hope you learn the kind of things you were planning to.
It's been a scary thought; I'm dreading to realize all the know-how's I once had known, that I've managed to forget. So in the meanwhile I've been looking at starter-projects, big C++ projects (somehow, there aren't small, simple ones) to understand how modern C++ projects should be _structured_ these days.
To those looking at this negatively I say - this projects is great for what I've been looking for. You can take it and build a differently flavored server from it, and still have modern tooling (CMake, GTest). It is simple enough.
Then again, we'll see if I ever get around to it. It's not like I'm swimming in free time.
However C++14/17 is getting a ton of new features and a fresh effort to push it towards Rust's innovation. I wouldn't be surprised that if this energy continues, we'll see a lot of Rust in C++.
What is completely certain, that 3 years into the future, if I look at this very comment I'm writing now, C++ will still be as common and valuable. Rust - not sure.
I know I sound like a conservative dinosaur now (but trust me, I'm not), but this kind of thought process you get only after 20 years in the field, and I do apply it only for topics that deserve it (systems programming).
In cases where the read exceeds write, such as genomic data processing, this can provide additional performance gain, as opposed to querying the database.
While redis _can_ be used, I think that this having a much smaller codebase is advantageous, in case one wishes to implement additional domain-specific requirements. Nice work!
It would also be a fun project, though. Redis is something that I really wish that I had had the opportunity and the vision to build myself. Classic data structures as a service; too cool for school.
I either replied to the wrong comment or it got edited.
Now the curious question is whether it provides some different feature, its a learning exercise or something else.
To put it another way, tools like Redis are often designed and documented and optimized based on assumptions of large scale deployment and sophisticated engineering teams. While this doesn't preclude small scale and/or individual use, it still assumes a significant level of time commitment: for example, a reasonable understanding to achieve a 95% chance of successful deployment on a random application might require 8-developer-weeks of experience. On a team of four with an average of six years experience, there's a good chance that some of the necessary time commitment has already occurred. On a team of one there's going to be a deep dive even if the person already has half the required experience.
I mean suppose Redis does everything that is necessary except in terms of persistence model, or more likely it did everything fine until now when I realized I need a different persistence model. Sure it's a rabbit hole either way, and neither is necessarily better, but changing the persistence model of my code to suit my use case may be easier than kludging on or choosing among other people's kludges.
To be clear, I'm not arguing that the author's use case is a snowflake. What I am proposing is that the author's knowledge and skill set and time availability probably are, and writing a key value store may be more productive and efficient than figuring out how to adapt and apply Redis.
In Comments
Be respectful. Anyone sharing work is making a contribution, however modest.
Ask questions out of curiosity. Don't cross-examine.
Instead of "you're doing it wrong", suggest alternatives. When someone is learning, help them learn more.
When something isn't good, you needn't pretend that it is. But don't be gratuitously negative.
In Comments
Be respectful. Anyone sharing work is making a contribution, however modest.
Ask questions out of curiosity. Don't cross-examine.
Instead of "you're doing it wrong", suggest alternatives. When someone is learning, help them learn more.
When something isn't good, you needn't pretend that it is. But don't be gratuitously negative.
In addition, not all software on the internet is meant to replace other software, compete with other software, or even be deployed in a production environment. The internet is more than large enough for lots of wheels of all shapes and sizes. Contributing to existing projects is good and so is writing your own programs.I understand the underlying sentiment people are getting at - this seems similar to Redis - but we should keep an open mind. Maybe he wanted to write C++ instead of C? Maybe he was trying out boost::asio? Maybe he just wanted to write some code?