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