Re:A distributed key value store in under 1000 lines
by arp242 on Tuesday January 05, 2021 @06:41AM
(#25644500)
It depends on the project; I haven't looked at this one in depth specifically, but it's certainly possible to write useful things with a (much) small codebase for to replace (much) larger ones. Usually the trade-offs are:
1. It solves a more limited set of use cases. It's perfectly reasonable to want to solve a wide range of use cases, but there's value in more limited software which solves a more limited set of use cases, too.
2. It caters to a more limited set of users. Suckless is perhaps the epitome and most extreme flavour of this, where they just excluded things like config files in favour of a config.h file. This doesn't make the software less stable, but it does make it less usable for some users.
For example, I am working on a CI system right now, as I ran out of Travis "open source credits" pretty fast and didn't care much for the alternatives (or Travis, for that matter, but it did work) and I figured there's some space for a somewhat different kind of CI. It's currently functional but unfinished at abut 1500 lines of code, and I'd be surprised if the finished version will be more than ~3000 lines.
It's smaller because it excludes features that are useful, but not for my (and I suspect many people's) use cases, and because it makes some assumptions that you roughly know what you're doing instead of abstracting everything. Combined, this drastically reduces the code size. This also means it's not useful for everyone, but I'm okay with that and it's a deliberate trade-off: not every project needs to solve all use cases or cater to all users.
1. It solves a more limited set of use cases. It's perfectly reasonable to want to solve a wide range of use cases, but there's value in more limited software which solves a more limited set of use cases, too.
2. It caters to a more limited set of users. Suckless is perhaps the epitome and most extreme flavour of this, where they just excluded things like config files in favour of a config.h file. This doesn't make the software less stable, but it does make it less usable for some users.
For example, I am working on a CI system right now, as I ran out of Travis "open source credits" pretty fast and didn't care much for the alternatives (or Travis, for that matter, but it did work) and I figured there's some space for a somewhat different kind of CI. It's currently functional but unfinished at abut 1500 lines of code, and I'd be surprised if the finished version will be more than ~3000 lines.
It's smaller because it excludes features that are useful, but not for my (and I suspect many people's) use cases, and because it makes some assumptions that you roughly know what you're doing instead of abstracting everything. Combined, this drastically reduces the code size. This also means it's not useful for everyone, but I'm okay with that and it's a deliberate trade-off: not every project needs to solve all use cases or cater to all users.