5 ms·

The biggest turn-off about Go, for me, is that the community seems to be incredibly unfriendly to newcomers. He touched on the lack of REPL, but it goes furthe

The biggest turn-off about Go, for me, is that the community seems to be incredibly unfriendly to newcomers. He touched on the lack of REPL, but it goes further than that. 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, Go's way of "debugging" code is...well. I don't really know how to do it in Go. The general answer seems to be something along the lines of "think about the code you wrote and then write it correctly you idiot." Seriously, this is the canonical debugging advice, from Rob Pike himself: "When something went wrong, I'd reflexively start to dig in to the problem, examining stack traces, sticking in print statements, invoking a debugger, and so on. But Ken would just stand and think, ignoring me and the code we'd just written. After a while I noticed a pattern: Ken would often understand the problem before I would, and would suddenly announce, "I know what's wrong." He was usually correct. I realized that Ken was building a mental model of the code and when something broke it was an error in the model. By thinking about how* that problem could happen, he'd intuit where the model was wrong or where our code must not be satisfying the model."*[1] [1] http://www.informit.com/articles/article.aspx?p=1941206 http://www.informit.com/articles/article.aspx?p=1941206

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 ago
  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?
  - thinkpad20 12y ago
    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.
    - courtf 12y ago
      Yeah agreed, wasn't trying to cast doubt, mostly just pontificating.
    - howeman 12y ago
      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.
    - stcredzero 12y ago
      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.
rdtsc 12y ago
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).
- zaphar 12y ago
  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.
  - stock_toaster 12y ago
    There is also the Go Playground[1], which is great for testing out and/or sharing small code blobs. [1]: http://play.golang.org
- foofoobar 12y ago
  You can try this: https://github.com/vito/go-repl https://github.com/vito/go-repl
- shurcooL 12y ago
  I use https://github.com/shurcooL/goe https://github.com/shurcooL/goe, which is a repl without the loop.
oofabz 12y ago
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.
- natural219 12y ago
  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"
  - mercurial 12y ago
    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.
- Intermernet 12y ago
  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!
cordite 12y ago
I know Rust is currently doing a ton of work in being fully GDB compatible, does this apply to Go as well?
- noselasd 12y ago
  Yes. http://golang.org/doc/gdb http://golang.org/doc/gdb
stcredzero 12y ago
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.
- orbifold 12y ago
  Ironically compared to debuggers for Common Lisp or Smalltalk, the Javascript debuggers are not all that good.
  - stcredzero 12y ago
    Preaching to the choir!
- natural219 12y ago
  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."
  - stcredzero 12y ago
    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.

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 ago
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?
- thinkpad20 12y ago
  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.
  - courtf 12y ago
    Yeah agreed, wasn't trying to cast doubt, mostly just pontificating.
  - howeman 12y ago
    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.
  - stcredzero 12y ago
    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.

rdtsc 12y ago

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).

zaphar 12y ago
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.
- stock_toaster 12y ago
  There is also the Go Playground[1], which is great for testing out and/or sharing small code blobs. [1]: http://play.golang.org
foofoobar 12y ago
You can try this: https://github.com/vito/go-repl https://github.com/vito/go-repl
shurcooL 12y ago
I use https://github.com/shurcooL/goe https://github.com/shurcooL/goe, which is a repl without the loop.

oofabz 12y ago

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.

natural219 12y ago
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"
- mercurial 12y ago
  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.
Intermernet 12y ago
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!

cordite 12y ago

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

noselasd 12y ago
Yes. http://golang.org/doc/gdb http://golang.org/doc/gdb

stcredzero 12y ago

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.

orbifold 12y ago
Ironically compared to debuggers for Common Lisp or Smalltalk, the Javascript debuggers are not all that good.
- stcredzero 12y ago
  Preaching to the choir!
natural219 12y ago
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."
- stcredzero 12y ago
  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.