[sephware]

Go was originally intended as a systems level language, suitable for writing extremely efficient servers, dealing directly with raw bytes where needed, therefore enabling writing code at both high and low levels. VMs typically take advantage of the lowest level of code that their language supports to be as efficient as possible. There's no reason Go code can't be as fast as C++ code with enough time for optimizations, and there's no reason a VM written in Go has to be slower than any other low-level program written in Go.

[skybrian]

I believe there are compiler improvements that can be made without changing the Go language, like computed goto's for large switch statements. That will help.

However, to really do as well as C, Go would need a more space-efficient union type. A Go interface is always two pointers due to how the garbage collector works, and that's not going to be as efficient as using something like NaN-encoding for a union between a pointer and a float64.

[ComputerGuru]

For go code to be as fast as C it would necessarily not look like go code as you’d have to avoid anything that would involve non-deterministic allocation or garbage collection. Sure, it’s possible. But it doesn’t make sense.

[stcredzero]

Go's native GC is specifically targeted for Go. To be performant, one would want GC targeted towards the language to be implemented.

[sephware]

Only if you're using Go's native GC as the Lua VM's GC, which isn't the only option.

[stcredzero]

I have to confess, I've been thinking of implementing Smalltalk in Go, using its native GC as a very unoptimized GC.