4 ms·

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

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/ http://play.golang.org/

ibdknox 13y ago
The big difference is that you lose state every time you do that, the main goal with the eval in LT is to prevent that :)
- voidlogic 13y ago
  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.
  - peterwaller 13y ago
    Relevant: https://github.com/jteeuwen/mitosis https://github.com/jteeuwen/mitosis
  - pjmlp 13y ago
    Have you ever used a REPL? It is an interactive process. You are build pieces of the application bit by bit. There is no complete application state where to set breakpoints.
piranha 13y ago
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.
coldtea 13y ago
>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.

ibdknox 13y ago

The big difference is that you lose state every time you do that, the main goal with the eval in LT is to prevent that :)

voidlogic 13y ago
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.
- peterwaller 13y ago
  Relevant: https://github.com/jteeuwen/mitosis https://github.com/jteeuwen/mitosis
- pjmlp 13y ago
  Have you ever used a REPL? It is an interactive process. You are build pieces of the application bit by bit. There is no complete application state where to set breakpoints.

piranha 13y ago

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.

coldtea 13y ago

>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.