Torch simply has to work this way because it cares about performance on a combination of multiple systems and dozens of GPUs. The complexity leaks into packaging.

If you do not care about performance and would rather have portability, use an alternative like tinygrad that does not optimize for every accelerator under the sun.

This need for hardware-specific optimization is also why the assembly language analogy is a little imprecise. Nobody expects one binary to run on every CPU or GPU with peak efficiency, unless you are talking about something like Redbean which gets surprisingly far (the creator actually worked on the TensorFlow team and addressed similar cross-platform problems).

So maybe the the blogpost you're looking for is https://justine.lol/redbean2/.

> Torch simply has to work this way because it cares about performance on a combination of multiple systems and dozens of GPUs

Or, looked at a different way, Torch has to work this way because Python packaging has too narrow of an understanding of platforms which treats many things that are materially different platforms as the same platform.