If there is a reasonable downside, probably no? You have a right to try to keep yourself alive, in nearly all contexts.

Anecdotally, bells have always come through fairly clearly for me. They filter out lower tones, not higher + sine waves. Nothing about this adds up to more than any normal $5 bell, especially rotating ones which hammer repeatedly.

They've also been useful more than once, e.g. you can do that to know what iteration of a loop failed. There are of course other ways to do this, but it's hard to beat "stupid, simple, and works everywhere" when normal options (e.g. logs) stop working.

what do you think the vote would be, though? "we don't like him"? last I checked, change.org-petition-style voting didn't have much of an effect on country laws.

browsing is slowly reducing as time goes on too, as while it's convenient on my phone, it's rarely efficient. it doesn't take long at all before I'd rather pull out a laptop and finish more quickly.

margins to control the width of large blocks of text have a ton of research in their favor, it's not just "more whitespace = more gooder" UI design madness. there's some of that of course, but there's a sane core underneath it all.

Forcing the app is almost certainly for tracking purposes and justifying the decision for whatever braindead higher-up decided it was a good idea, therefore it must be made to work.

E.g. GC doesn't need to be precise. You could reserve CPU budget for GC, and only use that much at a time before yielding control. As long as you still free enough to not OOM, you're fine.

Stuff outside stdlib can, and almost always does, improve at an incomparably faster rate.

But also everyone sane avoids the built-in http client in any production setting because it has rather severe footguns and complicated (and limited) ability to control it. It can't be fixed in-place due to its API design... and there is no replacement at this point. The closest we got was adding some support for using a Context, with a rather obtuse API (which is now part of the footgunnery).

There's also a v2 of the json package because v1 is similarly full of footguns and lack of reasonable control. The list of quirks to maintain in v2's backport of v1's API in https://github.com/golang/go/issues/71497 (or a smaller overview here: https://go.dev/blog/jsonv2-exp) is quite large and generally very surprising to people. The good news here is that it actually is possible to upgrade v1 "in place" and share the code.

There's a rather large list of such things. And that's in a language that has been doing a relatively good job. In some languages you end up with Perl/Raku or Python 2/3 "it's nearly a different language and the ecosystem is split for many years" outcomes, but Go is nowhere near that.

Because this stuff is in the stdlib, it has taken several years to even discuss a concrete upgrade. For stuff that isn't, ecosystems generally shift rather quickly when a clearly-better library appears, in part because it's a (relatively) level playing field.

There's clearly merit to both sides, but personally I think a major underlying cause is that libraries are trusted. Obviously that doesn't match reality. We desperately need a permission system for libraries, it's far harder to sneak stuff in when doing so requires an "adds dangerous permission" change approval.