Go Portability Limitations
Comments discuss Go's portability issues, heavy runtime with GC and scheduler, challenges with cgo interoperability, and comparisons to C for system-level use.
Activity Over Time
Top Contributors
Keywords
Sample Comments
they are trying to build on top of the go runtime, so implementing it in go makes sense.
Not run at all I think. Go is more strongly coupled to systems than most languages as it implements a lot itself, eg it directly uses the (non stable) syscall interface on osx.
Go is "native code" but anyway nice work!
Go isn't as portable as it should be.
Not looking for a debate: Why can't you use it everywhere you could write or compile Go code?
This remember me one of the Go Proverbs, Cgo is not Go https://www.youtube.com/watch?v=PAAkCSZUG1c&t=12m37s
Go has a heavy runtime, including both a garbage collector and a userland scheduler. Those features both make it inappropriate for some applications where you would use c, and also make calling (and especially being called from) foreign code problematic. You effectively cant implement a library in go and then call it from another language, not without considerable ffi overhead at the very least.
How is go more portable than C?. Genuine question.
Go would totally be a viable option. Cross compilation for the win.
Go has a supported alternative implementation, gccgo.