Hacker News Reader

Comment by thinkpad20 | Hacker News Reader

I hope that wasn't the actual reason why they decided against a REPL or other tools, because unfortunately, most of us aren't as smart as Ken.

View on HN

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.

Yeah agreed, wasn't trying to cast doubt, mostly just pontificating.

I think it would be nice if there was one, but I'm not going to write it. I would guess that's the problem.

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.

Reply on news.ycombinator.com