Golang plugin system
johnhoffman opened this issue · 2 comments
I'm not sure if this is the appropriate place to ask, but I'm wondering why the Golang runtime spawns a subprocess instead of using the plugin system to dynamically load the function.
Did you decide one is better than the other for Golang?
in some cases the other process is not a go function but an arbitrary binary (the go proxy is used for running functions from multiple languages now including swift, ruby, php, ...).
this may be the primary reason - @sciabarra can you comment?
The initial design was actually to build an executable including the proxy code to get a single executable. Community feedback was to build something that can work with other languages, most notably swift. Currently, the runtime spawning an executable is actually used for Go, Swift, PHP, Python, Rust, Java and Ruby. The communication layer is the old Unix pipe that is very fast and efficient. It was carefully measured and using it improved performances of other runtimes from a factor of 10 to 100. I also did an experiment using a plugin and I did not notice any improvement in speed than using a pipe. Data are passed in-memory anyway using a pipe.