I clicked on the link expecting information on how to shed big tech's golden handcuffs. Instead of that, I was assaulted with a bunch of barely coherent bragging about the author's career and sex life.

1/5 would not click again.

What information did you expect? Don't apply for jobs that you'd find objectionable if it wasn't your paycheck. If you find yourself forced to do something objectionable, refuse, do a terrible job, and look for something else. The whole point of the post is that the golden handcuffs are only golden if you value money over morals.

It seems that was the point of the original post, if you click through the complainers and whiners link, and then click the link in that HN post.

This post was basically a giant response to the HN comments on his blog instead of in the comments. It was rather odd.

I probably would not have read the article, but your comment piqued my curiosity. I couldn’t resist.

1/5 would not click again.

Cloudflare's goal is to become the default choice for anyone deploying an app to the cloud. It makes sense for them to support popular frameworks such as Astro, so that they can ensure that the frameworks work very well on their Workers platform.

Anyone except users that need to serve the German market. Due to peering issues with the biggest German ISP that have been unresolved for years, websites hosted with Cloudflare simply don’t load in the evening.

Proposals like these seem to assume that FOSS is mostly produced by unpaid volunteers. But a lot of the open-source stuff that I personally use is produced by massively profitable companies.

For example, I am currently working with React, which was produced by Meta. I write the code using TypeScript, which was produced by Microsoft (and other corporate behemoths such as Google). I am writing this comment in Chrome (produced by Google). Etc.

> I am writing this comment in Chrome (produced by Google).

Which depends on a lot of code not produced by Google, like libxml2 which was on the news recently because the maintainer step down.

Chrome is not FOSS btw. Google Chrome is proprietary software based on the open-source Chromium (also created by Google), which in turn is a fork of Webkit (by Apple, and with many corporate and non-corporate contributors), which itself is a fork of KHTML/KJS from the KDE project.

You are still right that corporations found and contribute to countless open source projects though.

I'm glad you wrote it up. Thanks! But I feel like the folks behind the HTML5 spec and the comprehensive test suite deserve the lion's share of the credit for this (very neat) achievement.

Most projects don't have a detailed spec at the outset. Decades of experience have shown that trying to build a detailed spec upfront does not work out well for a vast class of projects. And many projects don't even have a comprehensive test suite when they go into production!

I completely agree. I hope I gave them enough credit in the blog post and the GitHub repo.

Yep, and I think it is a great way to draw attention to their work!

Having a comprehensive spec and test suite is an absolute requirement, without it all you got is vibe-testing, LGTM feels. As shown by the OP, you can throw away the code and regenerate it back from tests and specs. Our old manual code is now the new machine code.

It would be very interesting to see a post-mortem for each of the design mistakes, with links to the original design discussions and docs, and analysis of how the decision-making process went astray.

That's an interesting point, but in many (most?) cases productivity doesn't depend on all services being available at the same time. If one service goes down, you can usually be productive by using an alternative (e.g. if HN is down you go to Reddit, if email isn't working you catch up with Slack).

If HN, Reddit, email, Slack and everything else is down for a day, I think my productivity would actually go up, not down.

During 1st Cloudflare outage StackOverflow was down too.

Many (I’d speculate most) workflows involve moving and referencing data across multiple applications. For example, read from a spreadsheet while writing a notion page, then send a link in Slack. If any one app is down, the task is blocked.

Software development is a rare exception to this. We’re often writing from scratch (same with designers, and some other creatives). But these are definitely the exception compared to the broader workforce.

Same concept applies for any app that’s built on top of multiple third-party vendors (increasingly common for critical dependencies of SaaS)

The system rewards people who can exploit it.

To be fair to Rust, the issue was an "unwrap" in the Rust code[0]. "unwrap" means "if the operation did not succeed then panic". Production Rust code should not use "unwrap", and should instead have logic to handle the failure case.

You don't need exotic formal verification methods to enforce this best practice. You just need a linter.

[0] https://blog.cloudflare.com/18-november-2025-outage/#memory-...

I don’t know why anyone thinks that you can’t or shouldn’t use unwrap in a production environment. If this was enforced you’d likely end up with people using something like “.expect()” and there are real world cases where you KNOW that unwrapping will never cause issues.

The reality is the code should not have used unwrap, but that doesn’t mean using unwrap is bad.

My guess is that Claude's "bad days" are due to the service becoming overloaded and failing over to use cheaper models.

Seems like a substantial fraction of the web was brought down because of a coding error that should have been caught in CI by a linter.

These folks weren't operating for charity. They were highly paid so-called professionals.

Who will be held accountable for this?