I'm pretty sure that the range of platforms for which Go does cross compilation "very well" is quite small. Go has a sizeable runtime, and you need to have a version of the runtime that works on each platform (for exotic platforms you would probably have to write some of the building blocks from scratch). This isn't push-button, this is just "the distribution supports many common platforms"

For example, it seems like compiling to MIPS is not push-button for Go. On the other hand, Rust supports all platforms that LLVM supports, though you need a version of the stdlib compiled for that platform (you don't have to write any code like in the Go case, you just have to compile the sources with the right invocation). For push-button compilation, we just need to distribute these binaries.

I imagine the vast majority of cross-compiles for the core tasks that Go targets will be to x86 or ARM, which it does support well (from everything I've heard).

Don't things get more complicated than that if you are expecting certain architecture features like SIMD?

I remember some comments here on HN a few months back (maybe longer) about how there isn't really an "ARM" to target, as since there's such diversity in what an ARM chip can provide that it's hard to make assumptions about what you can rely on from just "ARM". I believe it was in response to what is available to help with booting the system, but I imagine it extends into what exactly your runtime can rely on.

> I'm pretty sure that the range of platforms for which Go does cross compilation "very well" is quite small

Given that the number of popular platforms is approximately 2 (Intel and ARM), I don't see that as a huge problem.

Well, the OS and bit width matters too. {x86-32, x86-64, 32-bit ARM, AArch64} on {Windows, Mac, Linux, Android, iOS} ends up describing a decently large set of targets.

Also, you'd be surprised how often people request minor platforms. It's enough that we regularly get people asking for a C backend because they only have a C compiler for that target (though I think a C backend ends up usually not being what those people actually want).

Hm... I probably don't know enough about compilers, but why does Windows/Mac/... matter for a compiler (I see why it would matter for the standard library)? AFAIK, the main differences between these platforms are calling conventions (and possibly exception mechanisms), which LLVM should abstract away.

You're missing at least (a) structure padding/alignment; (b) debug info; (c) name mangling. LLVM abstracts over some of the differences but definitely not all.

In any case, just having a Rust compiler isn't very useful; you need a standard library (or at least libcore) to do anything interesting with the language, and that's where most of the porting effort comes in.

Actually, for compilers, platform is typically not just hardware, but the operating system as well. Windows and Linux are night-and-day different for major platform requirements (e.g., filesystems, I/O), and even Linux and FreeBSD can be important target differences in some platform areas.

So the number of platforms is approximately {x86-32, x86-64, ARM, AArch64}×{Windows, OS X, Linux, iOS, Android} (- a few combos) ~= 17 (I think). MIPS, Sparc, and PowerPC can be useful in some scenarios, as can even x86-16 (hey, wanna write the initial startup code on x86?), and platforms like PNaCl, Emscripten, or WebAssembly are effectively their own platforms as well.

Even PowerPC can be both 32-bit and 64-bit, and has operating systems like AIX and Wii U. I'm guessing one of those ports would be a bit harder.

And PPC has big and little endian variants, to add to the matrix.

You're missing PIC, AVR and quite a few other architectures that exist in the uC space(and Rust could be a great target for).

In that case Rust has exactly the same cross compilation story. You're lowering the bar for Go but not for Rust if you're making that comparison.