I've long wished for a Go package that provided an API into the Go compiler to allow JIT compilation and loading of Go code into a running process. The compiler being written in Go already means this would be technically not super difficult.
There are many applications for JIT compilation in Go. It would extend Go's "systems language" reach to the full spectrum of what can be done readily in other languages. Implementing scripting languages is just one obvious application. Dynamically extending Go programs at runtime is pretty tricky at the moment, because if one loads a new DLL (.so) that is based on Go, then one has two Go runtimes going at once; and the idea with a JIT would be that only one would be needed, and channels could be used to communicate with the newly added extension code. As it stands, when one's project wants to load code dynamically at runtime, Go is a poor choice for such a project. I did hear RSC mention that extensibility might be a future project, which is a hopeful direction. Now I've always intuited that JIT raises security concerns for cloud facing programs such as web servers that has caused the Go team to shy away from it, for fear of expanding the attack surface of Go based web servers, for example. My intuition may be wrong, but in any case, I thought it worth thinking about the question: Would there be any easy approach to adding a JIT that would not be troublesome, security wise, for webservers that don't need it? Strategies that come to mind: - some way to make it obvious if the Go compiler was linked to the binary - a tainting mechanism for externally derived strings - a means of sandboxing code produced from the JIT when it runs - a way of marking functions such that only they may call into the JIT. The idea here is that if an attacker gets to inject code into one part of the program, it may still not be able to access the JIT from that part. - ability to restrict the packages that JIT-ed code may access may be very helpful; for example, being able to say "no access to the network from JIT-ed code" may help. - others? -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/3182fc27-bbe7-4f9a-88d2-cde5823f0f9an%40googlegroups.com.