the beautiful thing about bloom filters is they let you say "definitely not here" without checking everything. that asymmetry is weirdly powerful for specific problems.
I've seen them save startups real money in caching layers - checking "did we already process this event" before hitting the database. false positives are fine because you just check the database anyway, but true negatives save you thousands of queries.
the trick is recognizing when false positives don't hurt you. most engineers learn about them in theory but never find that practical use case where they're actually the right tool. same with skip lists and a bunch of other algorithms - brilliant for 2% of problems, overkill for the rest.
Exactly. A 1.2% false positive rate means unnecessary reads 1.2% of the time vs
100% without the filter. Even at 10% FP rate, you skip 90% of I/O.
This asymmetry works great for I/O-bound workloads (skip-indexes) but fails for TFA's approach where every document needs its own filter.
In practice, you combine both: inverted index for the dictionary (amortizes across documents), then bloom filters per chunk of the index (amortizes across chunks). This two-level approach handles scale much better than TFA's one-filter-per-document design. It's bloom filters as an optimization layer, not a replacement.
> that asymmetry is weirdly powerful for specific problems.
100% agree when it works in your favor. We use it for exactly that situation where a non-zero false positive rate is fine and you can choose how much memory to devote to getting it closer to zero.
There have a been a couple times though where we've needed a "keep everything not on this list" operation, and unfortunately bloom filters don't work well for that situation. There are alternatives, but none as elegantly compact as bloom filters.
the obsession with code elegance vs shipping velocity is telling here. Whitney's style works for him because he's building tools he'll maintain himself for decades. same product, same developer, same context.
most startups are in the opposite situation. you need three different engineers to understand what you built last quarter because two people quit and one went to a different team. your clever abstractions become technical debt when the person who made them isn't around to explain them.
here's the real question: are you optimizing for the code or the business? sometimes boring, verbose, googleable patterns beat clever compression because your constraint isn't keystrokes - it's hiring, onboarding, and velocity when half your team is new. that's startup reality.
I’m wondering now with LLM in the loop, how the languages of solving complex problems will evolve in the long run.
Perhaps I will start to playing with this macro style ladder of abstraction with the help of LLM. Such as literate programming with an AI agent. Computer is much better at parsing than us. We can stand on highest rung of the ladder.
what's always wild to me about these language debates is how much energy people spend defending syntax preferences instead of asking "does this help me ship?"
OCaml's real pain point isn't the syntax - it's that you can't hire for it. if you're building a startup and you pick OCaml, you've just cut your hiring pool by 95%. that's way more painful than learning a different way to write functions.
the whole "academic vs practical" thing is backwards. academic languages often have killer features that would save you real pain, but if your team can't debug it or you can't find Stack Overflow answers at 2am, none of that matters. language choice is a business decision, not a technical purity contest.
> OCaml's real pain point isn't the syntax - it's that you can't hire for it. if you're building a startup and you pick OCaml, you've just cut your hiring pool by 95%. that's way more painful than learning a different way to write functions.
I hear this a lot about Scala and it's never been an issue in practice.
A smaller pool of candidates makes hiring easier, I'd much rather screen 20 résumés than 400. The typical candidate, whether experienced or willing to learn, is also better on average.
"We can't find qualified developers" usually tells more about the employer, in reality that means:
- We aren't willing to pay market rates.
- We don't invest in even the most basic on-the-job training.
- Seniority distribution is junior heavy; we expect one senior developer per team who can mentor all the other ones.
Or a combination of the above.
I know two relatively small companies that use OCaml, they don't pay anywhere near Jane Street salaries, but they're willing to hire people who show interest in the language and invest a little in their training. This works. On my end I've hired several people coming almost purely from Python, after a few weeks they contribute to fairly advanced Scala codebases.
Indeed. The idea that increasing your hiring pool is good per se is like saying the best way to look for gold in California is to exhaustively sweep every inch of the state of California.
> if you're building a startup and you pick OCaml, you've just cut your hiring pool by 95%. that's way more painful than learning a different way to write functions.
You can hire anyone who already understands pattern matching, closures, map/fold (these are more and more common constructs nowadays) and train them to learn OCaml. It's a simple language overall, especially if your codebase doesn't use any complicated features.
It's almost certainly the opposite problem. You can't find a job in it.
There's a whole pool of people out there like myself who like to work in languages like this but don't because there's very few jobs in them.
When I heard people say they "can't hire for tech X" I usually find there's something else going on. I just left a job where they said they "couldn't hire" for Rust -- let me tell you... Finding Rust talent is not their problem. They have far more serious problems from which "retaining Rust talent" is a symptom.
The challenge with making good software is not language choice. It's communication and culture and making good foundational choices about software architecture that fit your problem domain. Writing code is the easy part, usually.
I mean, the issue is not learning the language. It's the best practices, the standard libraries, the language idioms, etc. A week is a tad unreasonable.
A week to learn syntax? Sure. But to really be a fully operational battle-station engineer in a new language stack is probably 6 months to a year.
I would however expect people to be able to submit code reviews for e.g. bug fixes and small features after two to three weeks.
No really, that's a small ecosystem, we are not talking about Java or JS or python. Also, you should not need to know all the ropes of an ecosystem to work in one given environment.
If you are reasonably experienced with computers, learning the syntax will take you 2h. Again, that's Ocaml we are talking about. ML syntax has been designed to teach programming to fresh students with just a background in math.
If you already know C and Unix, you will be good to go in one afternoon... unless you want to use dune or compile to JS or use the repl etc.
I taught myself both StandardML and OCaml 20+ years ago as hobby. But I'd never advertise myself as an OCaml programmer. Yes, the syntax is relatively easy to learn. But when I look at what Jane St etc have created for libs, the tooling, etc.
Ok but the amount of education that is needed to join Jane St is certainly very large, but acquiring the language itself is probably a very tiny amount of that.
That's exactly why I'm disagreeing: there is much more to know and to learn than the syntax and semantic of a programming language to do a good job, that's why when I consider hiring I'm not insisting too much about previous familiarity with a given language; that's the easy part.
yeah i think we broadly agree. Language syntax is the frankly lowest hurdle. Or should be. Knowledge of ecosystem and best practices and engineering wisdom is much more important.
As someone building a SaaS product launching soon, outages like this are incredibly instructive—though also terrifying.
The "cold start" analogy resonates. As an indie builder, I'm constantly making decisions that optimize for "ship fast" vs "what happens when this breaks." The reality is: you can't architect for every failure mode when you're a team of 1-2 people.
But here's what's fascinating about this analysis: the recommendation for control theory and circuit breakers isn't just for AWS-scale systems. Even small products benefit from graceful degradation patterns. The difference is—at AWS scale, a metastable failure can cascade for 14 hours. At indie scale, you just... lose customers and never know why.
The talent exodus point is also concerning. If even AWS—with their resources and institutional knowledge—can struggle when senior folks leave, what chance do startups have? This is why I'm increasingly convinced that boring, well-documented tech stacks matter more than cutting-edge ones. When you're solo, you need to be able to debug at 2am without digging through undocumented microservice chains.
Question: For those running prod systems, how do you balance "dogfooding" (running on your own infra) vs "use boring, reliable stuff" (like AWS for your control plane)? Is there a middle ground?
For a startup, boring tech stacks are absolutely the correct choice. Using an opinionated framework like Django can be a very good idea for the same reason - it provides a structure which you just have to follow without too many decisions to make, and any new hires with experience in the framework can hit the ground running to a larger extent.
The only exception is if you are doing something where your tech stack is integral to your product (e.g. you need crazily high performance or scale or something from the get go).
Split out the front ends into separate services but leave the back end as a monolith, just try not to get logically separate parts too entangled so you have a decent chance of separating them later if and when "later" arrives
> If even AWS—with their resources and institutional knowledge—can struggle when senior folks leave, what chance do startups have?
My personal crusade is trying to convince anyone who will listen to me that the value of a senior employee in any role isn't in their years of experience. It's in their years of experience with your system. More companies should do whatever it takes to retain employees long term. No matter how good your documentation procedures are, no matter how thorough your knowledge base, no matter how many knowledge transfer sessions you have, your long tenured employees have forgotten they know more knowledge than they will ever be able document.
I have never seen a team lose a (productive) long standing member that still wasn't suffering from that loss years later. We like to pretend that software and especially reusable libraries, components and frameworks make developers interchangeable widgets. Substitutable cogs that can simply be swapped out by having enough documentation. But writing software is converting a mental state into a physical one. And reading code is trying to read someone else's mind (incidentally this is part of why two excellent developers can find themselves unable to work together, they just don't think enough alike). When you lose those senior people, you lose the person who was around for that one outage 8 years ago, and who if they were around for the current outage would have a memory float up from the forgotten depths that cause them to check on the thing no one (yet) suspects.
This isn't to say you shouldn't document things, and that you shouldn't work to spread knowledge around. The "bus factor" is real. People will retire. People will leave for reasons you have no control over. So document everything you can, build good knowledge transfer systems. But always remember that in the end, they will only cover a portion of the knowledge your employees have. And the longer your employees are around, the more knowledge they will have. And unless you are willing to pay your people to document everything they know full time (and I assure you, neither you nor your customers are willing to do that), they will always know more than is documented.
Nor despite my analogies does this apply only to software developers. One team I worked on lost a long term "technical writer" (that wasn't their full time work but it was a role they filled for that team). This person was the best person I've ever known at documenting things. And still the team reeled at losing them. Even with all the documentation they left behind, knowing what was documented, where and how recently and all sorts of metadata that wasn't captured in the documentation itself went with them when they left. Years later their documentation was still useful, but no one was anywhere near their level of encyclopedic knowledge of it all.
To use an analogy, the New York Yankees perform the best when they focus on building up their roster from their farm system. Long tenured players mentor the new ones, and a cohesive team forms that operates as more than the sum of its parts. They perform the worst when success and money take control and they try to hire "all-stars" away from other teams. The intangibles just aren't there, or aren't as strong. A good company is the same. A long term team built from the ground up is worth far more than a similarly "experienced" team made up of outside hires.
Talent exodus is concerning, so don't give your people a reason to leave. You can't stop it all, but you can do a lot to avoid self inflicted wounds.
I get to live this routinely in consulting projects, where management thinks teams are like playing footbal, replacing players mid game and keep going, naturally it isn't without all sorts of hickups as you well point out.
I think a lot of developers may not appreciate the fleshy human parts of organisations, given most of our efforts to date as an industry are typically to reduce headcount, but staff really are key to any successful organisation.
I have never heard of a control plane before this AWS outage, sounds instructive without needing an explanation but for 1-2 person what does a control plane provide?
“Control plane” and “data plane” are very common terms. It’s just a way to think about responsibilities within a system, not necessarily its physical architecture.
The size of the team is irrelevant. It's like asking if a load balancer is useful for a two person team. What's the system the two person team is in charge of, and for how many users? The two people might be in charge of the backend for a sprawling complex system with millions of users, or they might also be the only users of some small local physical bulletin board made out of cork.
At the end of the day,
AWS is still physically made up of physical computers that still have to obey the laws of physics. If you max out the bandwidth of the connection going in or out of, say, an RDS system (which is available via NDA if you are spending enough money with them), suddenly the physical is very important.
The common thread in many responses here is *reducing decision fatigue*. Whether it's checklists, clean workspace, scheduling meetings early, or aggressive filtering—it's all about removing micro-decisions so your brain can actually focus on the work.
My biggest unlock has been ruthlessly protecting "deep work blocks" on my calendar. Not just blocking time, but treating those blocks as sacred. No meetings, no "quick calls," no exceptions. If someone tries to schedule over it, I move heaven and earth to find another time.
The killer insight: *context-switching isn't just about switching tasks, it's about switching between maker mode and manager mode.* Even checking a single Slack message can pull you out of flow for 20+ minutes. Paul Graham's "Maker's Schedule, Manager's Schedule" essay nailed this years ago, but we keep forgetting it.
Since I'm building a scheduling tool right now, I think about this constantly—how do we design systems that protect focus instead of fragmenting it? Most scheduling tools optimize for "maximize meetings packed into calendars." The better question is: how do we help people create MORE uninterrupted time?
Anyone here use calendar/scheduling tools specifically to CREATE boundaries rather than fill time?
This looks solid! A few thoughts from someone also launching a product soon:
*What's working:*
- The privacy angle is compelling, especially with Iceland's jurisdiction
- Transparent pricing is HUGE. So many hosting providers hide the real costs
- €15 credit for beta testers is smart—shows you value feedback over vanity metrics
*Suggestions:*
- Your Ask HN post is thorough but might benefit from a clearer "hero statement" up top. Right now it's buried. Something like: "Privacy-first VM hosting from Iceland, powered by 100% renewables"
- Consider showing a pricing calculator on the landing page. "Pay for what you use" is great, but people want to estimate their costs immediately
- The beta tester offer is good, but you might get more traction offering it to the first 25-50 people. HN moves fast and 10 slots will fill quickly (or people won't bother if they think they're too late)
*Question for you:*
How are you planning to handle launch/marketing after beta? I'm launching a scheduling tool on Product Hunt soon and wrestling with similar distribution challenges. The indie builder reality is: building is the easy part, getting eyeballs is brutal.
What's your strategy been for building awareness before launch?
Hey, thanks for the feedback. I'll update the hero statement in a bit, the pricing calculator is available on landing (and actually takes you to the order form with the config you select), although upon further thought it should be more visible so I'll change that too.
I only have 2 servers at the moment, although this will change gradually as customers arrive (my last business took 3 years to become profitable), realistically I have around 27 slots free right now due to the amount of IPs I have available. I want to put it on Product Hunt soon although a lot has changed since I last launched a product and I see a ton of AI related wrapper products that have no real use, and it might get buried underneath.
I plan to advertise it through X, Instagram and TikTok after the beta is over. It's completely bootstrapped, as was my last product, although that one was launched and gained traction through the word of mouth.
But you are right, getting eyeballs (especially paid ones) is quite brutal in the current market.
What do you think about the NoJS Privacy/Tor mode? You can access it via clearnet by pressing on the privacy mode button the the bottom left of the screen in case you haven't looked at it.
This resonates deeply. I'm actually doing exactly this—though solo rather than with a team. Left corporate to build a scheduling tool (think Calendly alternative) that's launching on Product Hunt soon.
A few observations from this journey:
1. The hardest part isn't building—it's finding the discipline to ship something "good enough" rather than perfect. Corporate trained me to over-polish.
2. Distribution is BRUTAL. You can build something genuinely useful, but without an audience or marketing chops, you're shouting into the void. I'm learning this the hard way.
3. The skillset mismatch is real. Big tech teaches you to work within massive systems with established users. Indie building is the opposite—you're creating systems AND finding users simultaneously.
For those considering this: Start building in public NOW. The audience you build while employed becomes your launchpad when you go solo.
Curious—for those who've done Product Hunt launches: what actually worked for you? I'm seeing so much conflicting advice about timing, pre-launch strategies, etc.
The most brutal part of distribution I've seen is finding people who care about trying things out.
Maybe something like https://smallbets.com is better than Product Hunt in finding that group of people. PH doesn't allow signups with only a username/email and password.
I'm starting to believe a different community is needed for building in public that isn't HN or PH though it might be smallbets, I didn't try it.
It worked for me to be highly uncompromising on what I want to have while at the same time highly accommodating to what people want. Also to indulge in things I like that others don't.
Another thing that worked in the past is to have a mobile app because it gets you users simply because the app store puts it in front of people.
What didn't work is emailing people asking for feedback. People mostly don't care.
I want a showhn.com where builders commit to try each other's stuff.
You've captured something important here. There's been a shift from "solve problems" to "create novel patterns." The incentives are all wrong—framework authors get validation from innovation theater, not from boring reliability.
I think part of it is that the web developer community exploded. More developers = more people trying to make their mark = more churn. Everyone wants to be the person who "fixed React" or "reimagined routing."
But when you're actually building a product that users depend on, you realize how much of a tax this is. Every framework "upgrade" that breaks things is time NOT spent on features, user feedback, or actual problems.
The irony is that the best products are often built with "boring" tech that just works. Instagram ran on Django for years at massive scale. Basecamp is still Rails. These teams focused on users, not on having the hottest stack.
What frameworks/tools have you found that stayed stable and just worked over the years?
what's the moderation policy/etiquette for calling out obviously LLM-generated comments? doing so feels like more heat than light, but letting them pass by without saying anything feels like another step towards a dead internet.
I think you've got to handle them on their own merits. Ultimately humans can write like AI and AI can write like humans, but a good answer is a good answer and a bad one is bad. Karma and moderation already have plenty of ways to handle inappropriate answers.
I think the value of the interaction matters. Who ever got an LLM to reply wanted to learn? be thoughtful? argue? what? And will this interaction be valuable for anyone replying to it? reading it? I think yelling at the void and hearing the coherent echo of a million people is not the same as having a conversation.
This mindset is criminally underrated in the startup/indie builder world. There's so much pressure to architect for scale you might never reach, or to use "industry standard" stacks that add enormous complexity.
I've been heads-down building a scheduling tool, and the number of times I've had to talk myself out of over-engineering is embarrassing. "Should I use Kafka for event streaming?" No. "Do I need microservices?" Probably not. "Can Postgres handle this?" Almost certainly yes.
The real skill is knowing when you've actually outgrown something vs. when you're just pattern-matching what Big Tech does. Most products never get to the scale where these distinctions matter—but they DO die from complexity-induced paralysis.
What's been your experience with that inflection point where you actually needed to graduate to more complex tooling? How did you know it was time?
This is the eternal tension for early-stage builders, isn't it? Multi-cloud gives you resilience, but adds so much complexity that it can actually slow down shipping features and iterating.
I'm curious—at what point did you decide the overhead was worth it? Was it after experiencing an outage, or did you architect for it from day one?
As someone launching a product soon (more on the builder/product side than infra-engineer), I keep wrestling with this. The pragmatist in me says "start simple, prove the concept, then layer in resilience." But then you see events like this week and think "what if this happens during launch?"
How did you handle the operational complexity? Did you need dedicated DevOps folks, or are there patterns/tools that made it manageable for a smaller team?
I don't think I would recommend multi-cloud right out of the gate unless you already have a lot of experience in the space or there is a strong demand from your customers. There's a tremendous amount of overhead with security/compliance, incident management, billing, tooling, entitlements, etc. There are a number of external factors that drove our decision to do it, resiliency is just one of them. But we are a pretty big shop, spending ~$10M/mo on cloud infra and have ~100 people in the platform management department.
I would recommend focusing on multi-region within a single CSP instead (both for workloads AND your tooling), which covers the vast majority of incidents and lays some of the architectural foundation for multi-cloud down the road. Develop failover plans for each service in your architecture (eg. planned/tested runbooks to migrate to Traffic Manager in the event AFD goes down)
Also choose your provider wisely. We experience 3-5x the number of service-impacting incidents on Azure that we do on AWS. I'm sure others have different experiences, but I would never personally start a company on Azure. AWS has its own issues, of course, but reliability has not been a major one (relatively speaking) over the past 10 years. Last week's incident with DynamoDB in us-east-1 had zero impact on our AWS workloads in other regions.
I've seen them save startups real money in caching layers - checking "did we already process this event" before hitting the database. false positives are fine because you just check the database anyway, but true negatives save you thousands of queries.
the trick is recognizing when false positives don't hurt you. most engineers learn about them in theory but never find that practical use case where they're actually the right tool. same with skip lists and a bunch of other algorithms - brilliant for 2% of problems, overkill for the rest.