> The other side of this is building safety nets. Takes ~10min to revert a bad deploy.

Does it? Reverting a bad deploy is not only about running the previous version.

Did you mess up data? Did you take actions on third party services that that need to be reverted? Did it have legal reprecursions?

> Does it? Reverting a bad deploy is not only about running the previous version.

It does. We’ve tried. No it’s not as easy as running the previous version.

I have written about this: https://swizec.com/blog/why-software-only-moves-forward/

I read the article and to be honest I don't know where we disagree. I disagree with this quote,

> Takes ~10min to revert a bad deploy

A bad deploy can take way over that just in customer or partner management communication.

Having data model changes be a part of regular deployments would give me persistent heartburn.

It's why you always have a rollback plan. Every `up` needs to a `down`.

If you do that, it expands your test matrix quadratically.

So, it makes sense if you have infinite testing budgets.

Personally, I prefer exhaustively testing the upgrade path, and investing in reducing the time it takes to push out a hot fix. Chicken bits are also good.

I haven’t heard of any real world situations where supporting downgrades of persistent formats led to best of class product stability.

Would love to hear of an example.

Aircraft engineer: “That’s why you have parachutes.”

They might be an appropriate safeguard for a prototyping shop, but not for Delta.

I wouldn't say acceptance of crappy code. I think the issue is the acceptance of LLM plans with just a glance and the acceptance of code without any code review by the author at all because if the author would waste any more time it wouldn't be worth it anymore.

The problem is those plans become huge. Now I have to review a huge plan and the comparatively short code change.

It shouldn't be any longer than the actual code, just have it write "easy pseudocode" and it's still something that you can audit and have it translate into actual coding.

Does that mean CXMT is one inch away from also eating into the DDR5 market?

They're still at somewhat of a process disadvantage, but they have demonstrated an ability to produce DDR4 on older processes than it's typically been produced on. So it stands to reason that their process disadvantage will not stop them from producing DDR5 at scale. Their DDR5 will just use a little more silicon, and squeeze the jigglyness from a few more electrons, but in this market, who cares if RAM cost 15% more to make and was 15% less efficient to run, if it's available to purchase at all.

They will eventually eat everything while they laugh at us. Why would you build a rail network if it isn't profitable? Why build anything if it isn't profitable? Why would you even house people if the profit isn't guaranteed to be as big as other sectors?

Everyone wanted denarius then escudos then guilders then pounds then dollars and soon yuan. They make stuff over there, you can buy it with yuan.

I think India might come after that but Africa is sure to follow. Give it a few hundred years.

Maybe they reverted it because they are already planning to get rid of the super rounded corners!

Well Coq has program extraction built in.

Yeah and that's why it's way better than the likes of TLA+.

I would upvote this comment more if I could.

I already refrained from introducing event sourcing to tackle wierd dependecies multiple time just by justaposing the amount of discipline that the team has that lead to the current state vs the discipline that is required to keep the event source solution going.

I don't agree with this cache take. Adding operations to the cache is easy. Taking the django-redis project as an example there are only two levels until you reach redis-py: The cache abstraction and the client abstraction.

The problem with channels is that if you need to touch the ORM you will have to use a sync_to_async call which will block the event loop.

Why don't you post the original broken Python code.