I think compiling via LLVM is probably a better idea than compiling via Go..
(Also why do people invent a new word 'transpile', when the old word already perfectly describes translating from one formal language into another?)
(Also why do people invent a new word 'transpile', when the old word already perfectly describes translating from one formal language into another?)
The word “compiler” actually doesn’t do that (like, say, “translator” would). “Compiler” originally referred to something more like what is today called a linker. It “compiled” (put together) a set of subroutines (in assembly/machine code) into a combined executable.
Furthermore, translating from (say) JSON to XML is also “translating from one formal language into another”, but that’s not an example of what we mean by “compiler”.
So what do we mean? That’s actually not easy to define. Defining it as translating from one programming language into a different programming language isn’t quite correct, because machine-code binaries aren’t a programming language. Defining it as translating from a programming language into a different representation preserving the program semantics is also not quite correct, because e.g. pretty-printing to HTML would arguably fit that definition.
Clearly there’s some general definition of what we mean by “compiler”, even if I’m failing to find a precise and correct wording for it here. But there’s also the more narrow meaning of “translating from a programming language into object code”, which is what is usually meant in the majority of cases. Because we don’t have a separate word for that narrower definition, there is some ambiguity. The word “transpiler” resolves the ambiguity in one direction. In the other direction, the ambiguity is usually resolved by assuming that “compiler” means “to object code” by default when the context doesn’t specify otherwise.
Machine-code binaries aren't (they are programs), but ISA of a CPU is.
I'd plug in a requirement of Turing-completeness for the source and destination language, and at that point the "semantics-preserving" variant makes perfect sense to me. Although canonically textbooks and Wikipedia don't seem to require that, so I'm fine accepting a definition not requiring Turing-completeness, just preservation of semantics.
Perhaps the most practical example: just-in-time compilation of regular expressions to native code via LLVM. Regular expressions are not Turing complete.
Another example: take Agda as a source language. Agda is deliberately not Turing-complete, but can express almost any program you might be interested in. (Basically, Agda only allows you to express terminating programs. That's why it's not Turing complete.)
I'd be perfectly happy to describe that as a compiler.
I don't think anyone would say Unity's il2cpp is a transpiler even though it compiles .net bytecode into C++: producing readable C++ is a non-goal for il2cpp.
Not this ignorant myth again - it isn’t a new word, been in use since mid 60s. A transpiler is a form of compiler from high-level language to high-level language. A compiler didn't even originally translate, but just link.
The same way ‘navy’ is a kind of blue but we can say navy and add a little more specific information. Nobody rails against navy saying ‘but it’s just a shade of blue!’
> Also why do people invent a new word 'transpile', when the old word already perfectly describes translating from one formal language into another?
The answer is... the old word ('compiler') didn't mean what it does today, back in the 60s, when 'transpiler' was coined. Compiler with its current meaning isn't a much older word than transpiler - they're near contemporaries (50s and 60s). Before that a compiler meant a linker.
Your criticism doesn't match up with the history.
Of course, if we had more rational vocabulary, we'd call them 'translators' instead. (In fact, that's what German does. Perhaps they coined their corresponding term a bit later, when things had already shaken out a bit more.)