Drop-in replacement [1]

---

[1] Not a drop-in replacement

"Drop-in replacement" doesn't imply perfect 1:1 compatibility with no missing features or differences. Otherwise there would be no such thing as a drop-in replacement (in the software world at least).

If a drop-in replacement isn't almost assuredly 1:1 compatible then _what the heck is it_? The nodejs compat page for Bun notes that base64 encoding is still incomplete. Where do you draw the line?

> Where do you draw the line?

That's up to you, and society. Do you accept that tall people exist?

Right. Now exactly what height do you need to be a "tall person"?

This is the same. I haven't used it so I can't say how optimistic their "drop-in replacement" claim is, but they certainly don't need it to work 100% of the time with 100% of project with 0 changes to make that claim.

"Drop in replacement" makes an implicit guarantee about utility. It sets expectations about what I'm able to accomplish by investing time and effort into a solution. I don't expect tall people to have any specific utility.

If you call something a drop in replacement and it is not a drop in replacement, it's simply a lie.

> Otherwise there would be no such thing as a drop-in replacement (in the software world at least).

That's obviously wrong, because there are things that could be different while the API/compatibility is still matching 1:1, such as:

- speed, memory usage, memory safety

- additional features, more capabilities

- simple licensing stuff

Imho, a drop-in replacement actually suggests that you can simply swap out the runtime and expect your code to work out of the box.

To me it mostly implies that wherever the replacement is supported, it doesn't require substantial reconfiguration or learning a different interface. It's about that approach, even when the execution of that approach is limited or incomplete in scope.

It does generally suggest a high degree of compatibility to me though.

I think the definition on Wikipedia is correct, otherwise a "drop-in" replacement is no different than any other replacement, making it a meaningless term.

> [Drop-in replacement] refers to the ability to replace one hardware or software component with another one without any other code or configuration changes being required and resulting in no negative impacts.

https://en.wikipedia.org/wiki/Drop-in_replacement

I don't see a conflict by that definition. The drop in could easily or partially be interpreted from the perspective of the receiver and does not have to be a static property of the replacement.

Sure, and for many projects it can be replaced without any other code or configuration changes.

My feeling is that not all replacements have feature parity, but a drop in replacement does.

podman is a drop-in replacement for docker but yarn is not a drop-in replacement for npm. Makes sense?

Yes exactly. Podman is not 1:1 compatible with Docker. Occasionally you will run into issues e.g. due to the rootless nature. I actually recently had to uninstall Podman and replace it with Docker due to an incompatibility!

But it works enough of the time without any changes that it's reasonable to call it a drop-in replacement.

Either I missed this on first read-through, or they just added it.

It seems the note mentioning this feels buried for me under a large banner image, instead of near all the other text about compatibility.

Anyway, glad it is there, hope that their communications design improves in the future as at least a few others got caught with mismanaged expectations.