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.

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.

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.

Most Go programmers I know use printf debugging, not GDB. It fits with the Go philosophy of doing everything from the code, minimizing tools and config files.

This is not because the tools are so bad we are forced to bang rocks together. It's because writing code is an effective way to diagnose bugs. Even when I'm in a full-blown IDE with a GUI debugger, I prefer to use printf debugging.

Printf debugging and its equivalents is something that can be done in all languages. I use it in Erlang too from time to time in dev.

What makes it win is how easy it is to use. What makes it lose is how tedious and manual it is. And how it is restricted to an environment where you are allowed to recompile and load code all the time, and where the output is not going to mess up any other data stream.

I'm starting to phase out printf debugging in favor of tracing, because the tracing tools in Erlang are just infinitely better and more flexible, AND they can work on a production running system without impacting performance in any major way.

I'm able to match specific functions, with specific argument sets. I can see what they returned, and match only specific processes or generations of processes. I can do it from a REPL (because there is one, even in production systems, without needing to run stuff in a screen session), without messing up any related output stream.

Printf debugging is attractive because of how simple and minimally disruptive it is when you're already writing code. As much as it amazes me, it turned out not to be the most convenient tool available for most cases, even if I still use it from time to time.

I do too, I think this is more efficient when I understand what's going on.

However, let's say I'm given a third party library, and I know essentially what it does. I want to "see" the properties and methods of the object, I want to "inspect" values, and I want to "test" expressions, all at once. If you're just using printf, then between each of those steps you need to write a line of code, recompile, and reach that state in your program again. Like I said, if you already know essentially what's going on, deep dives like this become less and less important. However, I just think it's a boneheaded philosophy for a language / toolchain to just like...I don't know, assume you're good. I'm trying to become good, but I am getting more and more frustrated with Go every time the default answer to my problem is "be less of an idiot"

It's not necessarily a matter of being good. Writing efficient code doesn't mean that you can build a mental model for a reasonably complex projects, which will naturally accumulate dependencies. If you're lucky, you'll get a mental model of the component you're working on, and some of the more problematic dependencies. That's where being able to dive into arbitrary code during execution becomes crucial. Especially if the problem occurs in a piece of code you don't have access to at the layer you operate, and hence can't display the value for easily, or at all.

Yes, I usually rely on printf as the Go fmt library string formatting options are so powerful ("%#V" for instance). I have however found that sleep is the best debugger. Move away from the computer, visualize the problem in your head, and sleep on it. Not the best advice for those on tight release schedules, but true none the less.

Sometimes, however, it's nice to be able to see a live flow of the program and to watch variables change as you step through. I think we'll see more powerful tooling for Go debugging coming through very soon.

I'd love to see more integration in the various editors for go oracle, go cover tool etc. as these would probably show me when I started introducing errors, with the relevant info a click (or key combo) away, before they turned into horrible bugs requiring their own git branch to solve. TDD with the go cover tool is brilliant!

For instance, there is very little in the toolchain about debugging other than "use GDB". For someone very familiar with the workflow of typing "debugger" in Javascript code, being able to stop the world at any state, examine variables, and having a fully-functional REPL to test expressions,

Use cgdb for a nicer interface. Also, you can examine variables and set break points in gdb. Instead of a REPL, you can try out expressions in main(). Your workflow has to change, so if that's a deal-breaker, it is what it is. But if you can change, there are some advantages to be gained.

Maybe I didn't express this clearly, but I am entirely willing to learn new workflows, toolchains, etc. It just seems that the Go community is entirely uninterested in helping me out. I'm not complaining that somebody else hasn't coded a REPL for me, I'm complaining that the vast majority of Go developers don't understand the need for a REPL or a debugger or any of these things, because they seem ultimately unconcerned about helping me or other newcomers out.

If the answer was, "yes, that would be great, we just haven't had the time for it", I would say awesome, and start working on building it. However, the general answer seems to be, "you are an idiot, get out of my language."

I'm complaining that the vast majority of Go developers don't understand the need for a REPL

Well, asking for a REPL in Go is kind of like designing a bicycle for a fish. You can imagine what that would look like, but it's not really the most pragmatic or useful thing in context.

don't understand the need for a...debugger or any of these things, because they seem ultimately unconcerned about helping me or other newcomers out.

Are you sure that it's not partly that you haven't lurked around enough to come up to an acceptable level of background knowledge first? Maybe certain members of the Go community could've been more friendly, but one doesn't have to look very long to figure out that gdb is the standard way to debug Go. To be fair, such "background" is pretty easy to get wrong when going into unfamiliar territory. Sometimes, we don't even know what we yet need to learn. I've had such travails myself.

It's kind of ironic, since back in the day, I was a compiled language programmer who discovered dynamic languages like Perl then Smalltalk. Once I switched, I was frustrated by the too-broadly applied assumptions everyone had about programming in general. (Programming = edit-compile-test; "Where can I find the compiler?") Now, I find myself meeting dynamic language programmers who have no exposure to environments like C, where there is no managed VM and no dynamic runtime with even an inkling of late binding. We've somewhat come full circle.

Ironically compared to debuggers for Common Lisp or Smalltalk, the Javascript debuggers are not all that good.

Preaching to the choir!

I think a Go REPL would be a very cool project. I think it is doable. I always have ipython up, when I program in Python.

There is even a C++ REPL somewhere. It basically compiles very time your enter the expression and runs the code. I think it can be done in Go (but someone correct me, if I am wrong here).

You can try this: https://github.com/vito/go-repl

I use https://github.com/shurcooL/goe, which is a repl without the loop.

go run is surprisingly effective for playing around with code. I keep a main.go file in my home directory that I edit with vim and then run with ':!go run %'. Go compiles and runs fast enough that I almost don't notice its'a compiled language.

There is also the Go Playground[1], which is great for testing out and/or sharing small code blobs.

  [1]: http://play.golang.org

I know Rust is currently doing a ton of work in being fully GDB compatible, does this apply to Go as well?

Yes. http://golang.org/doc/gdb