Go compiles so fast you can just pretend there is dynamic eval. People sometimes use the "go run" command to compile and run Go source in one operation, that is not really too different from just invoking an interpreter. Go provides a lot of tools to parse Go source, I imagine between that, Go's fast compiler and GDB support it wouldn't be as hard as many compiled langs to support.
Also if I am figuring out something OBO (off by one) prone sometimes I use this to double check myself: http://play.golang.org/
>Go compiles so fast you can just pretend there is dynamic eval.
Yes, the Go people keep mentioning that. You might as well eat soy and pretend it's a delicious steak.
For people that have used good REPLs, from Lisp machines to iPython, it's not the same thing at all.
You lose your state, you loose context, you loose good introspection, etc etc. And if you try loading stuff that's big (several packages as dependencies etc), the compile time starts adding up too.
If there is a way to consistently inject the input to the program (to lead to the same state), I would be OK with editing a Go program to cause (behind the scenes):
1. moving a break point
2. recompile
3. run
4. stopping at new break point
I think that happening behind the scenes could be made to appear like live editing in other languages. Go is fast enough compiling and fast enough executing that I think it could be pulled off as not appear laggy as well. But maybe I'm wrong and I don't understand well enough how LT handles other langs.
But compiling + running means that every time you have absolutely fresh process without old state, so it's pretty different from what you can do with JS or Python.
Also if I am figuring out something OBO (off by one) prone sometimes I use this to double check myself: http://play.golang.org/