> It is much much better for an API to be kinda crappy (but stable) for historical reasons

But this does more than just add a maintenance burden. If the API can't be removed, architectural constraints it imposes also can't be removed.

e.g. A hypothetical API that guarantees a callback during a specific phase of an operation means that you couldn't change to a new or better algorithm that doesn't have that phase.

▲

TheDong 2 hours ago | parent [-]

Yes you can, and Go has done exactly that.

Realize the "log" api is bad? Make "log/slog". Realize the "rand" api is bad? Make "rand/v2". Realize the "image/draw" api is bad? Make "golang.org/x/image/draw". Realize the "ioutil" package is bad? Move all the functions into "io".

Te stdlib already has at least 3 different patterns for duplicating API functionality with minor backwards-incompatible changes, and you can just do that and mark the old things as deprecated, but support it forever. Easy enough.

	▲	dwattttt 2 hours ago \| parent [-]
		> mark the old things as deprecated, but support it forever Is that 'supported'? A library that uses a callback that exists in 'log' but not in 'slog'; it'll compile forever, but it'll never work. 'Compiles but doesn't work' does not count as stable in my book. It's honestly worse than removing the API: both break, but one of them is noticed when the break happens.