4 ms·

>The second big gripe is that Golang has neither an IDE nor a REPL. The IDE part is not true at all, why do people keep saying this? LiteIDE (aka golangide) wo

>The second big gripe is that Golang has neither an IDE nor a REPL. The IDE part is not true at all, why do people keep saying this? LiteIDE (aka golangide) works great, I use it all day everyday. It has syntax highlighting, autocomplete, gofmting, building, debugging, etc and is very lightweight. Downloads: https://code.google.com/p/golangide/downloads/list https://code.google.com/p/golangide/downloads/list Source: https://github.com/visualfc/liteide https://github.com/visualfc/liteide As for the merit if REPL over something like the go playground (http://play.golang.org/ http://play.golang.org/) or a debugger, I can't say. Most of the code I wrote before Go was C/C++/C#/Java.

cynwoody 13y ago
The main benefit of a true REPL over the Go playground is that a REPL allows you to interact with the state of a partially-run program. By contrast, the Go playground is one-shot. Your code runs quickly, but completely, and you see the result. But you can't examine the data structures interactively. For instance, when debugging a simple Python utility, I will often put the steps it goes thru into individual functions and tie them together with a main() function normally called via "if __name__ == '__main__':main()". That allows me to import the program as a module into a REPL session, from which I can call the functions individually and examine the resulting outputs. If something's not right, I can alt-tab to the editor, make a change, save the program, and use the reload() function in the REPL. Sometimes, the REPL-obtained data is all I'm looking for, and I never get around to running the code from the command line.
- voidlogic 13y ago
  OK, in a compiled language like Go a REPL implementation looks hard- am I wrong? It seems like besides the code being R/O a debugger is pretty close too. When testing with a debugger I setup my program to run the same tests, read the same input etc. In this way I can use the debugger, find and issue, change the code, set a break point, re-run the program and I'm right back where I left off. This sounds functionally similar to using a REPL.

cynwoody 13y ago

The main benefit of a true REPL over the Go playground is that a REPL allows you to interact with the state of a partially-run program. By contrast, the Go playground is one-shot. Your code runs quickly, but completely, and you see the result. But you can't examine the data structures interactively. For instance, when debugging a simple Python utility, I will often put the steps it goes thru into individual functions and tie them together with a main() function normally called via "if __name__ == '__main__':main()". That allows me to import the program as a module into a REPL session, from which I can call the functions individually and examine the resulting outputs. If something's not right, I can alt-tab to the editor, make a change, save the program, and use the reload() function in the REPL. Sometimes, the REPL-obtained data is all I'm looking for, and I never get around to running the code from the command line.

voidlogic 13y ago
OK, in a compiled language like Go a REPL implementation looks hard- am I wrong? It seems like besides the code being R/O a debugger is pretty close too. When testing with a debugger I setup my program to run the same tests, read the same input etc. In this way I can use the debugger, find and issue, change the code, set a break point, re-run the program and I'm right back where I left off. This sounds functionally similar to using a REPL.