(Also I just noticed the extra “it” in my previous comment, oops).

It makes me think of another similar one: I've noticed that British English speakers will say e.g. "the new iPhone will be available from September 20th"

To my ears that sounds like it's missing an “onwards” after it (or “starting September 20th” would sound even more natural).

https://www.nytimes.com/2019/11/16/opinion/sunday/pronouns-q...

Makes me think of how plists in macOS are xml because back then xml was the future

Comments URL: https://news.ycombinator.com/item?id=47546866

Points: 27

# Comments: 0

In this case it's the MacBook Neo that's causing them to get off their butts and reinvest in the quality of their software after letting it stagnate for years, but the pattern is the same: rest on their monopolistic laurels until competition makes them feel threatened, then magically start caring about their users again all of a sudden.

[1] https://www.crn.com/news/channel-programs/183701230/gates-of...

But I also trust that the company wouldn't deploy them in those areas until the quality data they need is available. So perhaps "safer in the environments where they are actually deployed" would be more accurate, but that's also the only thing that matters.

Speculating about what would happen if they were used in ways they are neither intended to be used nor are actually used feels a little silly. Most machines can be unsafe if you use them in ways they're not intended to be used.

It’s ironic how context cancellation has the opposite problem as error handling.

With errors they force you to handle every error explicitly which results in people adding unnecessary contextual information: it can be tempting to keep adding layer upon layer of wrapping resulting in an unwieldy error string that’s practically a hand-rolled stacktrace.

With context cancellation OTOH you have to go out of your way to add contextual info at all, and even then it’s not as simple as just using the new machinery because as your piece demonstrates it doesn’t all work well together so you have to go even further out of your way and roll your own timeout-based cancellation. Absurd.

Reading the examples I found myself thinking, “that looks like a really useful pattern, I should bookmark this so I can adopt it whenever I write code like that.”

The fact that I’m considering bookmarking a blog post about complex boilerplate that I would want to use 100% of the times when it’s applicable is a huge red flag and is exactly why people complain about Go.

It feels like you’re constantly fighting the language: having to add error handling boilerplate everywhere and having to pass contexts everywhere (more boilerplate). This is the intersection of those two annoyances so it feels especially annoying (particularly given the nuances/footguns the author describes).

They say the point is that Go forces you to handle errors but 99% of the time that means just returning the error after possibly wrapping it. After a decade of writing Go I still don’t have a good rule of thumb for when I should wrap an error with more info or return it as-is.

I hope someday they make another attempt at a Go 2.0.

There's a long history of Google slowly making the experience worse if you want to take advantage of the things that make Android open.

For example, by moving features that were in the AOSP into their proprietary Play Services instead [1].

Or coming soon, preventing sideloading of unverified apps if you're using a Google build of Android [2].

In both cases, it's forcing you to accept tradeoffs between functionality and openness that you didn't have to accept before. You can still use AOSP, but it's a second class experience.

[1] https://arstechnica.com/gadgets/2018/07/googles-iron-grip-on...

[2] https://arstechnica.com/gadgets/2025/08/google-will-block-si...