Inlining is actually something JITs are really good at... I'm not sure why you think it would be easier in Go than in C, but the relevant angle is the JVM. Go'

Inlining is actually something JITs are really good at... I'm not sure why you think it would be easier in Go than in C, but the relevant angle is the JVM. Go's value types are hyped up, but they're really not that great. Taking a reference instantly heap-allocates them, C# already has them, and Java is getting them too (in 10). Calling into C from Go is easier than in Java, but it's not any faster (in fact, it's generally slower, because you can't call into it without switching away from one of Go's tiny stacks into one that the C expects). One of the unfortunate consequences of this is that optimizing a hot loop by calling out to C doesn't work nearly as well in Go as it does in many other languages. As far as general points about AOT compilation: many don't apply to go compile simply because it will not waste the time to actually perform those optimizations, because it is very focused on its goal of compilation speed. gccgo, sure.