←back to thread

39 points nubskr | 1 comments | | HN request time: 0s | source

not able to post the link in url for some reason, here it is: https://github.com/nubskr/nubmq
Show context
fnordian ◴[] No.43372049[source]
What first principles were used to build this?
replies(1): >>43372114 #
nubskr ◴[] No.43372114[source]
First principle? Don't respect traditions—burn them.

No threads waiting on locks, no hard pauses for resizes, no conventional polling mechanisms. Instead, nubmq's entire architecture revolves around one relentless obsession: never let a client wait. Everything else—adaptive sharding, real-time migrations, soft expiry handling—is just engineering fallout from aggressively challenging every assumption Redis and Memcached made decades ago.

Would love to see which of these breaks with convention you're most curious (or skeptical) about!

replies(1): >>43372914 #
fnordian ◴[] No.43372914[source]
I am interested in the assumptions or new paradigms. How to distinguish “from first principles” from “intuitively from scratch”?
replies(2): >>43373030 #>>43373051 #
1. nubskr ◴[] No.43373030[source]
Most 'built from scratch' projects still borrow heavily from established thinking—just reimplementing known patterns in different languages or flavors. But first principles means ripping out the assumptions entirely, starting with raw, fundamental constraints: CPU cycles, memory latency, concurrent I/O contention. nubmq doesn't assume that traditional sharding, resizing, or even Redis's single-threaded event loop is optimal just because they're popular. Instead, it assumes almost nothing: keys have to move fast, scaling must be invisible, and downtime is unacceptable. In other words: Don't just tweak existing approaches, burn them to the ground and rebuild from physics upwards. If your 'from scratch' doesn't actively challenge foundational assumptions, it's just another coat of paint—not a true redesign