4 ms·
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.
by thinkpad20 12y ago
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.
- courtf 12y agoHonestly 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?
- thinkpad20 12y agoAbsolutely, 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.
- courtf 12y agoYeah agreed, wasn't trying to cast doubt, mostly just pontificating.
- howeman 12y agoI think it would be nice if there was one, but I'm not going to write it. I would guess that's the problem.
- stcredzero 12y agopresumably, 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.