often when I am developing systems code or RPC client code, I sit in a REPL and make repeated ad-hoc calls to various functions, building up various bits of state (I started using python long before Jupyter). I find this much more intuitive than writing code, compiling it, executing it, going back to the editor, changing the code, re-running it with something that loads a bunch of data, just so I can answer a question about the runtime behavior of the system I'm working with.
There is certainly something to be said about being able to answer questions about another system by poking at it, but that is a scripting task. You would be better served by a scripting language. And, as it happens, most scripting languages come with REPLs. That is a solved problem that was solved long before Go was ever imagined.
Just because you are building a particular systems program does not mean everything you do has to be a systems problem. And, really, if you don't exactly know what you're building, it is probably too soon to consider any of it a systems problem.
