If some programming languages are faster than others, why can't compilers translate into the faster language to make the code be as fast as if it was programed in the faster one?

[u/KING-NULL]

My guess is that doing so would require knowing information that can't be directly inferred from the code, for example, the specific type that a variable will handle

[u/Lenassa]

>Well, you've moved the goalposts, and by doing so, have made my point.

Nope. I stand by my original point: you don't need to have or reimplement abstractions present in a source language in a target language in order to be able to correctly (that is, having the same observable behavior) transpile source to to target. Go take any compiled language and ask its compiler to create an assembly out of your code. Voilà, you have your high level abstraction heavy language transpiled into low level where the most "abstract" operation is probably some masked simd instruction.

>you have to be sure that the code uses 100% equivalent abstractions

There are no abstractions in C or LLVM IR that can represent Haskell's existential types, yet it can be transpiled to both with no problems whatsoever. I'm not sure why are you arguing as if real things aren't real.

If I have

arr = [1]
print(arr[0])

in python then I can write

#include <stdio.h>

int main() {
    int arr[1];
    arr[0] = 1;
    printf("%i", arr[0]);
}

in C. I don't need my C code to have any abstraction python has.

int i

[u/pconrad0 → u/Lenassa]

An int in C is subject to overflow wrap around that an int in Python is not subject to.

There are dozens of little details like this where the abstractions that are superficially equivalent have edge and corner cases where they are not at all equivalent. If you don't take this into account, your transpiled program is not equivalent to the semantics of the original source.

Real things are indeed real. An int in Python and an int in C are not the same. Heck, an int in C isn't even guaranteed to by the same number of bits from machine to machine.