9 ms·

I definitely appreciate many parts of go's tooling ecosystem: pprof, gofmt, go get (in GOPATH mode), and go bug are all pretty good ideas. pprof in particular a

I definitely appreciate many parts of go's tooling ecosystem: pprof, gofmt, go get (in GOPATH mode), and go bug are all pretty good ideas. pprof in particular and the various profiling tools build out around it are great. That being said, I haven't found all aspects to be as nice - most notably among these is the lack of a good debugging environment. There is no debugger in the go tool, and users rely on delve[0] for their debugging needs. The dlv command line tool has actually gotten a lot better over the last couple years (props to the maintainers!), but integration in to visual front-ends is still lacking. VS Code and GoLand integrations at least are lacking to the point of it being nearly unusable except in the simplest cases. For a few examples, stepping is painfully slow (there are several machines/OSes I use), conditional breakpoints don't seem to work, keeping the tools up to date doesn't work consistently which means updating the underlying go/delve tooling or the IDE will frequently break the experience, and defining your debugging processes (e.g. via VS Code's launch.json) is tedious. None of these are go's fault per se, but it diminishes the overall experience. In general, it would be nice to have a better debugging experience, esp. since I prefer a GUI tool to the command line for debugging. In the meantime, I might switch back to just using command line dlv. But regardless, definitely agreed that go's tooling on the whole is great. pprof has saved my skin on countless occassions! [0] https://github.com/go-delve/delve https://github.com/go-delve/delve

kortex 7y ago
I feel your pain with the debugging and I have a feeling this will be an aspect of go which matures greatly in time. Especially with respect to goroutines, it can be tough tracing the program flow, which makes good debuggers even more valuable. Also a very hard challenge. I'd love to be able to see a diagram of goroutines and channels, like a chemical plant. That's probably asking for too much :p
odsb 7y ago
Do people really use a debugger ? This is a serious question because in 5+ years of programming I have never used a debuggers. The only time I used a debugger was when I was learning to program and to trace out for loops. Now I just use print statements and read code to figure out what’s going on.
- robrtsql 7y ago
  Yes! Try it! I often find myself working on a legacy codebase. The application will enter a state that I don't think should be possible. The debugger can usually help me figure out how that happened. It's worth mentioning that debuggers are less essential in languages like Go where the control flow is purposefully very straightforward. I often debug Python and end up being totally surprised to see the execution jump somewhere else because of a decorator.
- jcalabro 7y ago
  I step through almost every line of code I write in a debugger. I'm pretty visual based, and that combined with the action of clicking through forces me to slow down and really think about what my code is doing. Whenever I open the debugger, I find bugs that I can fix! :P I've heard it said that there are two types of programmers: those that stare at their text editor all day, and those that stare at their debugger all day.
  - arethuza 7y ago
    When I write a new unit test I pretty much always step through it in a debugger to make sure it is doing what I think it is doing.
- seanmcdirmid 7y ago
  Yes. Especially if the debuggers are easy to use and aren’t just gab-style shells. I can definitely lived without a debugger, I’ve done it before and you get used that after awhile. But given the choice between a programming experience with a good graphical debugger and one without, the former will almost always win out.
- vvanders 7y ago
  Really depends on your compile->deploy->launch iteration time. Printf'ing your way to victory works but I'm easily 5x faster with a debugger.
  - toolslive 7y ago
whateveracct 7y ago
It's crazy that Haskell has a better debugger (in ghci) than Go, despite Haskell being way less debugger-friendly of a language.
- ithkuil 7y ago
  "print/log" based debugging in Haskell is harder and thus there is more pressure to solve the debugging needs with a proper debugger. I rarely feel the need for a debugger in Go and other procedural languages because I often find it easier to just patch the code with some ad-hoc debugging logic that lets me understand what's going on. I find that usually easier to do rather than figure out how to attach a debugger in the right environment where the issue can be reproduced.
  - weavie 7y ago
    Print based debugging isnt necessarily harder in Haskell: https://www.stackage.org/haddock/lts-14.21/base-4.12.0.0/Debug-Trace.html#v:trace https://www.stackage.org/haddock/lts-14.21/base-4.12.0.0/Deb...
    - jerf 7y ago
      The laziness can make it a bit of a challenge to follow, though. I know trace itself is strict, but that thunk will still be lazy from the environment around it. Debugging has the same problem too, actually. "Step next" is much more challenging to know what is actually going to be "next" than in other languages. On the plus side (no sarcasm), it's a great way to get a feel for what the laziness really does. I recommend stepping through some non-trivial code of your own with the debugger for any intermediate Haskell programmer, even if it's working perfectly, because it'll actually show you the lazy evaluation order as it happens.
  - whateveracct 7y ago
    Oh the debugger in Haskell is not used that often. Usually people debug their logic in a repl session. Print debugging is a little weird in pure code, but it's useful and the same as any other language in any code that does IO.
simula67 7y ago
Delve also does not seem to be able to evaluate code fragments. This is something I miss from Java and Python.
sk0g 7y ago
Conditional debugging definitely works for me? I have no experience with terminal debugging mind you, work pays for GoLand because it definitely speeds me up by more than the 0.15% or whatever of my salary it costs. I have noticed slower run time with debugging on, but it's about half the speed usually, not too drastic. I'm usually debugging DB and network traffic and data flow anyway, so processing time is rarely an issue. VS Code integration is mostly hopeless from what I've read, with the go language server taking up massive amounts of RAM, so have you tried GoLand properly?
- hactually 7y ago
  It's interesting as talking to Go->Java guys they echo your sentiment and talk up goland. They also write "non-Go" go. Coming from deeply embedded and low level programming I've been perfectly fine without any more than printf style debugging... Tho we leverage logs/stats heavily. I aim to write simple and easy to grok code with few surprises and abstractions tho so maybe it's a mindset difference?
andromeduck 7y ago
I think the biggest barrier is still the compiler itself. The thing is built for compilation speed and not usefulness in terms of compille time semantics or readability of errors like the bad old days of GCC and GHC. In this day and age, I shouldn't have to understand how a parser/lexer works to understand what an error really is, especially for super simple stuff like missing semicolon, bracket, parents or comma, misspelled symbol. Small stuff like this is just a nussience for veterans, but I've seen it prove fatal on many an occasion for beginners who quicky get intimidated and start feeling stupid.
- pjmlp 7y ago
  Delphi and Turbo Pascal are also built for speed, with more expressive languages, and are still able to provide sensible error messages, all the way back to MS-DOS days.
  - Koshkin 7y ago
    The compilation times were extremely short, and that’s on a 4.77 MHz CPU. (Too bad we are unlike the Ancient Egyptians who would’ve stuck with it for a couple of millennia.)
- throwaway894345 7y ago
  I never really felt that way about Go error messages, but I also came from Python, Java, C, C++ (via GCC and Clang) where the error messages are far, far worse. Maybe there are languages/toolchains where the error messages are better?
- tensor 7y ago
  This is confusing to me, the pre-compilation tools catch these simple things instantly and display them right in your editor, which is far superior to having to wait until you compile to catch them.
mzs 7y ago
I've seen a number of comments like this here today. I stopped liking source level debuggers when optimizers got decent in the second half of the '90s. Go has an unusual usage of the stack but mdb has support for it https://www.joyent.com/blog/mdb-support-for-go https://www.joyent.com/blog/mdb-support-for-go

kortex 7y ago

I feel your pain with the debugging and I have a feeling this will be an aspect of go which matures greatly in time. Especially with respect to goroutines, it can be tough tracing the program flow, which makes good debuggers even more valuable. Also a very hard challenge. I'd love to be able to see a diagram of goroutines and channels, like a chemical plant. That's probably asking for too much :p

odsb 7y ago

Do people really use a debugger ? This is a serious question because in 5+ years of programming I have never used a debuggers. The only time I used a debugger was when I was learning to program and to trace out for loops. Now I just use print statements and read code to figure out what’s going on.

robrtsql 7y ago
Yes! Try it! I often find myself working on a legacy codebase. The application will enter a state that I don't think should be possible. The debugger can usually help me figure out how that happened. It's worth mentioning that debuggers are less essential in languages like Go where the control flow is purposefully very straightforward. I often debug Python and end up being totally surprised to see the execution jump somewhere else because of a decorator.
jcalabro 7y ago
I step through almost every line of code I write in a debugger. I'm pretty visual based, and that combined with the action of clicking through forces me to slow down and really think about what my code is doing. Whenever I open the debugger, I find bugs that I can fix! :P I've heard it said that there are two types of programmers: those that stare at their text editor all day, and those that stare at their debugger all day.
- arethuza 7y ago
  When I write a new unit test I pretty much always step through it in a debugger to make sure it is doing what I think it is doing.
seanmcdirmid 7y ago
Yes. Especially if the debuggers are easy to use and aren’t just gab-style shells. I can definitely lived without a debugger, I’ve done it before and you get used that after awhile. But given the choice between a programming experience with a good graphical debugger and one without, the former will almost always win out.
vvanders 7y ago
Really depends on your compile->deploy->launch iteration time. Printf'ing your way to victory works but I'm easily 5x faster with a debugger.
- toolslive 7y ago

whateveracct 7y ago

It's crazy that Haskell has a better debugger (in ghci) than Go, despite Haskell being way less debugger-friendly of a language.

ithkuil 7y ago
"print/log" based debugging in Haskell is harder and thus there is more pressure to solve the debugging needs with a proper debugger. I rarely feel the need for a debugger in Go and other procedural languages because I often find it easier to just patch the code with some ad-hoc debugging logic that lets me understand what's going on. I find that usually easier to do rather than figure out how to attach a debugger in the right environment where the issue can be reproduced.
- weavie 7y ago
  Print based debugging isnt necessarily harder in Haskell: https://www.stackage.org/haddock/lts-14.21/base-4.12.0.0/Debug-Trace.html#v:trace https://www.stackage.org/haddock/lts-14.21/base-4.12.0.0/Deb...
  - jerf 7y ago
    The laziness can make it a bit of a challenge to follow, though. I know trace itself is strict, but that thunk will still be lazy from the environment around it. Debugging has the same problem too, actually. "Step next" is much more challenging to know what is actually going to be "next" than in other languages. On the plus side (no sarcasm), it's a great way to get a feel for what the laziness really does. I recommend stepping through some non-trivial code of your own with the debugger for any intermediate Haskell programmer, even if it's working perfectly, because it'll actually show you the lazy evaluation order as it happens.
- whateveracct 7y ago
  Oh the debugger in Haskell is not used that often. Usually people debug their logic in a repl session. Print debugging is a little weird in pure code, but it's useful and the same as any other language in any code that does IO.

simula67 7y ago

Delve also does not seem to be able to evaluate code fragments. This is something I miss from Java and Python.

sk0g 7y ago

Conditional debugging definitely works for me? I have no experience with terminal debugging mind you, work pays for GoLand because it definitely speeds me up by more than the 0.15% or whatever of my salary it costs. I have noticed slower run time with debugging on, but it's about half the speed usually, not too drastic. I'm usually debugging DB and network traffic and data flow anyway, so processing time is rarely an issue. VS Code integration is mostly hopeless from what I've read, with the go language server taking up massive amounts of RAM, so have you tried GoLand properly?

hactually 7y ago
It's interesting as talking to Go->Java guys they echo your sentiment and talk up goland. They also write "non-Go" go. Coming from deeply embedded and low level programming I've been perfectly fine without any more than printf style debugging... Tho we leverage logs/stats heavily. I aim to write simple and easy to grok code with few surprises and abstractions tho so maybe it's a mindset difference?

andromeduck 7y ago

I think the biggest barrier is still the compiler itself. The thing is built for compilation speed and not usefulness in terms of compille time semantics or readability of errors like the bad old days of GCC and GHC. In this day and age, I shouldn't have to understand how a parser/lexer works to understand what an error really is, especially for super simple stuff like missing semicolon, bracket, parents or comma, misspelled symbol. Small stuff like this is just a nussience for veterans, but I've seen it prove fatal on many an occasion for beginners who quicky get intimidated and start feeling stupid.

pjmlp 7y ago
Delphi and Turbo Pascal are also built for speed, with more expressive languages, and are still able to provide sensible error messages, all the way back to MS-DOS days.
- Koshkin 7y ago
  The compilation times were extremely short, and that’s on a 4.77 MHz CPU. (Too bad we are unlike the Ancient Egyptians who would’ve stuck with it for a couple of millennia.)
throwaway894345 7y ago
I never really felt that way about Go error messages, but I also came from Python, Java, C, C++ (via GCC and Clang) where the error messages are far, far worse. Maybe there are languages/toolchains where the error messages are better?
tensor 7y ago
This is confusing to me, the pre-compilation tools catch these simple things instantly and display them right in your editor, which is far superior to having to wait until you compile to catch them.

mzs 7y ago

I've seen a number of comments like this here today. I stopped liking source level debuggers when optimizers got decent in the second half of the '90s. Go has an unusual usage of the stack but mdb has support for it https://www.joyent.com/blog/mdb-support-for-go https://www.joyent.com/blog/mdb-support-for-go