cap10morgan

I am already using Claude in Xcode 26.2. What did they change / add specifically in 26.3? It's not super clear behind the marketing haze.

This highlights a common pitfall: If you “solve” a problem with a “temporary” solution, you lower the priority of the better solution below every unsolved problem. And there are always enough of those to ensure no one ever revisits the temporary solutions.

They think they aren’t, but it’s yet another thing they’re confused about.

Peter Thiel almost certainly didn’t invent this. The idea that our decisions are heavily influenced by those around us is one of those things that’s been well-established in the relevant scientific communities for some time but has a hard time breaking into the popular consciousness because we don’t want it to be true.

In my experience "Does your company measure the long term benefit of X?" is 99.99999% "no" for any X.

I'm hoping this leads to an announcement of some kind of hypervisor support in iPadOS 15. I would imagine that would come at WWDC if it's coming. Seems like it would allow software development on the iPad while retaining app sandboxing.

That's a fair question and something I should have clarified in my comment (though I have a feeling it is likely addressed in the blog post I linked to).

It gets into the deeper motivation behind not breaking backwards compatibility within the same-named module. There are two bad extremes here:

1. Never update dependency versions for fear of breakage. This leaves you open to security vulnerabilities (that are easy to exploit because they are often thoroughly documented in the fixed version's changelog / code). And/or you're stuck with other bugs / missing features the upstream maintainer has already addressed.

2. Always just updating all deps to latest and hoping things don't break, maybe running the test suite and doing a "smoke test" build and run if you're lucky. Often a user becomes the first to find a broken corner case that you didn't think to check but they rely on.

The approach outlined by Rich Hickey in that Spec-ulation talk I linked to allows you to be (relatively) confident that a package with the same name will always be backwards-compatible and you can track the latest release and find a happy middle ground between those two extremes.

Go's approach is one of the few (only?) first-class implementations of this idea in a language's package system (in Clojure, perhaps ironically, this is merely a suggested convention). The Go modules system has its fair share of confusing idiosyncrasies, but this is one of my favorite features of it and I hope they stick to their guns.

> During a brownout, password authentication will temporarily fail to alert users who haven't migrated their authentication calls.

This took me a second to correctly parse. Would have been better written as: “During a brownout, password authentication will temporarily fail. This is to alert users who haven't migrated their authentication calls.”

It is free for the time being. But you point out a good reason why we built dgit to support other storage backends.