Go is a great language. But why on Earth would you want to script with it?
2) Golang depends on code generation for a lot of it's features. Executing generated code immediately could be helpful.
3) Very quickly execute small tests - one of my favorite python and java/eclipse features that I find somewhat lacking in Go and very much lacking in C++ development : Unit tests that execute before you've fully processed the fact that you pressed the test button in the IDE.
4) Security isolation of parts of programs would be useful
5) Same with various other isolation principles - memory usage, cpu usage, ...
6) I've always thought that Go's best feature is that it's pretty good at compiling different processes into one binary that then work pretty independently. But as I've been making bigger programs I find this less and less true.
Truth is, we need a programming language that is an operating system. Sort of like Erlang, but euhm, somewhat more usable. Go isn't that language. A language where you can start up a thread with $megabytes memory available, $cpu cpu allocation, kill if it goes over it for more than 2-3 seconds and restart after waiting 500ms. Something like that. It needs to be a language where you can really do separation-of-concerns - optimization if compiled into the same binary - minimal code changes to move a specific service to a version running on a different machine.
my plan for this new go interpreter proposal, is to be able to use for scientific exploratory work (like we do with IPython right now when in a python-based ecosystem or CLing when in C++ land).
That's horrifying.
• You already know it.
• You want to use Go libraries.
• You want to extend a Go codebase at runtime, without integrating another language like Lua.
Weirder possibilities:
• You want to be able to use it as the basis for a Go "live image" system, where you can hot-reload modules on editor-save by re-parsing their source.
• You want to try building a Go version of Ruby's Pry (http://pryrepl.org)
• You want to enable your Go program to do stupid things involving generating strings of Go code and eval()ing them.
• You want to take some first steps toward some utopian dream of pushing live Goroutines over the network as frozen state + closure source, similar to what could be achieved on Mosix or the Erlang VM.