Honestly not trying to be a brat here, but I do this a lot myself, and I'm no Ken. Sometimes sitting back and just examining the symptoms of a bug can help narrow down the context that it was likely to have arose from (if you know the code base well enough). I often find that firing up the debugger tends to lead down tangential rabbit holes, particularly when dealing with a heavy framework.
That said, a REPL would be nice. Seems like go compiles fast enough that some ambitious dork could make a REPL-faker?
Absolutely, that's true. Obviously, not every problem needs to be solved with print statements, a debugger or a REPL. But it can help in many cases, and it's better to have too many tools than too few. Of course, it's flippant to just say "there should be a REPL" -- presumably, there are good reasons (better than the one stated) why there isn't one, or isn't one yet, in Go.
presumably, there are good reasons (better than the one stated) why there isn't one, or isn't one yet, in Go.
Languages that have a REPL were engineered from the start to allow it. Go doesn't do late binding so much. It prioritized a higher degree of control over low level memory layout and substituted fast compiling for a REPL.
That said, a REPL would be nice. Seems like go compiles fast enough that some ambitious dork could make a REPL-faker?