kacy

Hey Wayne, I bought wheretheheckdidmytaxesgo.com and will make it live after work today. Sorry about the profanity! It’s just how I felt after seeing the stats firsthand :)

fun fact I discovered in this process: if the US just went back to 2019 spending (with 2025 tax revenue), there would be a $780B surplus.

I’ve been consumed by building https://emberdb.com https://github.com/kacy/ember over the last few months.

It’s a drop-in replacement for Redis written in Rust. Most if not all of your client code should work without issues. Outperforms in many areas and has more out of the box features like proto storage, raft/swim, and encryption at rest.

I’m pretty proud of it, and I hope you’ll give it a shot and open bug reports. :)

Hi folks,

I'm anxious & excited to share Ember: a low-latency, memory-efficient distributed cache written in Rust. I designed it as a drop-in replacement for Redis, but with some modern twists that I've been iterating on and have been on my wishlist.

* https://github.com/kacy/ember

* https://emberdb.com

Here's what makes Ember different IMO:

* Native Protobuf storage (so no string serialization overhead and can encode/decode in the DB)

* Full gRPC API alongside RESP3 (think bi-directional streaming support for pub/sub)

* Mature distributed systems foundations (Raft consensus, gossip failure detection, automatic failover, live resharding)

* Built-in vector storage with a much smaller footprint

* Single static binary, zero runtime deps, and no garbage collector pauses

* It's also a true drop-in replacement. No need to use ember-cli or any of the client libraries. Your code should hopefully "just work" without too many issues.

This whole thing started purely as a learning project. For the last 15 years or so, I've worked with Redis, distributed systems, and all the fun and painful parts of building reliable infrastructure. But I had never actually sat down and /implemented/ those concepts from scratch myself. I wanted to really understand them. Not just read papers or use someone else's code.

So I started small. `cargo new test-db` and a single main.rs file. "How does RESP3 parsing work?" and "Can I do a basic SET and GET command?" It was really messy, but it slowly grew. At some point, I realized this had turned into something very solid and performant. The benchmarks early on were very convincing, but that's because it was architecturally very simple in the beginning. Now there's full Raft for replication, shared-nothing sharding by core, gossip membership, and live slot migration, and it still punches above its weight. All of the benchmark stuff is secondary though. I'm just proud that it works reliably and that I learned so much along the way.

A huge thank you to the Redis community and especially antirez (Savatore Sanfilippo). I don't know if you'll see this, but you've been such an inspiration. Redis changed how the industry thinks about caching, and its elegance and simplicity have been a source of inspiration, long before this project. Hundreds of thousands of developers have built incredible things on it.

One side comment I want to mention: AI has been an absolute game-changer in getting this project where it is today. Models like Opus 4.5 and Gemini 3 helped me reason through tricky Raft edge cases, profile expensive calls, debug obscure concurrency bugs, generate > 1200 tests, and generally helped describe very hard to understand concepts in plain English. It let me learn faster, iterate quicker, and ship something I'm proud of in a fraction of the time it would have taken. Grateful for how these tools are democratizing deep systems work like this.

It still feels immature in some respects, but the core is stable. All of my benchmarks are shared with the GCP VM config so other folks can replicate. Like all projects, there will be bugs, but I'll be here for a while hacking on it to make it better. Please take a look and give it a shot with your workloads. Thanks for any feedback!

I grew up in a poor town that sourced water from the Cape Fear river. There were two major factories in our immediate area: one that made paper and the other made industrial chemicals. The Dupont plant mentioned in the article was 10 miles upstream from where we were. We knew it was better to buy bottled water than to drink what came through the pipes. Grateful for the scientists and journalists for their work exposing all of this.

We’ve been using a Meilisearch for the last six months or so and have been delighted with its performance and usability. It uses a fraction of the resources as Elasticsearch, and the language support is extensive and very active.

That being said, our cluster is much smaller than other ones I’ve worked with in the past, so I can’t comment on its reliability at massive scale. I’ve also been very impressed with how active contributors are on GitHub and in their Discord. Everyone seems like good people, and it’s a project I’m excited to keep using.

Because it's a helpful contribution to the the engineering community?

the n+1 graphql problem is more difficult than most people realize. graphcdn makes it incredibly easy to globally scale a backend application with dynamically changing queries. of course, it _is_ possible to hack together some clever cloudflare workers (i've tried), but it gets increasingly difficult to actually have the cache hit if you have a ton of changing fields (with nested values). then, there's the sunk cost of managing/tweaking everything if you're a small team. I also really like how clean and useful the visualizations are.

it's not for every use case, but it's clearly useful for the thousands of companies that have signed up and are paying them. :)

This dismissive take is the biggest bull case for me.

GraphCDN is a killer product with an impressive business and a sharp team. Excited to see what's next for them.

I've probably been streaming SomaFM off and on for the last 15-20 years. Thanks for the reminder to donate!

Very cool and congrats on what you’ve built! This is something I’ve been looking for. Any plans to do iCloud syncing and maybe a mobile app?

If you're curious how it's built, here are the two main libraries: https://github.com/codealchemist/webamp-ipfs https://github.com/captbaritone/webamp

If it's at the stage where they're talking to partners, and it's expected to ship in less than a year, I'd argue that those are pretty clear indications that this isn't a skunkworks project that will be shelved.

Page 184 looks like it has some of the info you’re looking for

Fitbit | Infrastructure Engineer | San Francisco, CA (Remote USA ok) | Full-time | https://grnh.se/f13deb511

Our tooling for Infrastructure Engineering is largely written in Python and Go. On a daily basis, this team is building tools and supporting infrastructure with: Terraform, Vault, Docker, Kubernetes, Aurora/Mesos, and Prometheus.

You'll work on fresh and challenging technical problems that support hundreds of engineers and hundreds of millions of Fitbit's customers. Come help us build world-class infrastructure and tooling. We'd love to chat if you're interested.

I wonder if Jack is a victim of a SIM port hack?

Also showing up on a traceroute to spotify.com for me.

I think this was for the web version. They were mobile first for a long time, and a lot of the core team left years ago before the web version was complete.

This looks like a great product! Congrats on your success so far

haha! I went back and edited it to avoid confusion. :)

I'm a homebrew (beer) nerd. The global community is very warm and welcoming for people at all levels. Everyone is interested in building each other up, and it promotes experimentation and precision. As far as niche communities go, there's a very strong but surprisingly small underground of sour beer enthusiasts. http://www.milkthefunk.com/ is an online forum and massive wiki dedicated to discovering and sharing new methods into souring beer. Some of the most well known sour beer brewers contribute and use it as a resource.