3 ms·

Author here. I noticed before both mdb support and the Delve project that other have mentioned, and I find them great. The point of my excitement for godebug re

Author here. I noticed before both mdb support and the Delve project that other have mentioned, and I find them great. The point of my excitement for godebug resides in the fact that it's an easy to work with, zero complexity added tool to replace most tedious println() debugging sessions. That is, the non-exciting stuff. Not all bugs only happen on production load, architecture, etc. Many times (with DNS servers even more so, I'd say) bugs are simple state or logic bugs. The Heisenbugs exist. The complex resource-constrained races exist. And I find it fun to track them down, but many bugs are much more mundane, and godebug is a great tool for catching those. Speaking instead about hard to trace production bugs, I think the Go design and library deserve their daily share of praise here, since they solve many of those problems. Take Valgrind (or ASAN). Amazing tools. Completely useless in Go -- the language is memory-safe and will make that kind of bugs both hard to introduce and immediately detectable. And about concurrency, first of all the simple design makes bugs harder to introduce and easier to reason about. But even when they make their way in I find provisions like net/http/pprof and its various profile a pleasure to work with. And finally there's obviously the race detector. Still, I can't wait to see more tools developed to cover different Go debugging needs. Today I'm just happy about making my println() session much more pleasant and elegant :)

bcantrill 11y ago
The enthusiasm is fine -- I just wish it were couched in the understanding of the limitations of the technique. I also think it's naive to say that Go's design solves "many [production] problems" -- memory-safe languages solve one set of problems, but often introduce or exacerbate another. (The most obvious example being memory exhaustion: postmortem heap analysis is often much easier on a C-based system than in memory-safe languages.[1][2]) More generally, do not fall into the trap of correctness from smugness: nasty production bugs can exist in any language, and time is much better spent on the production tooling to debug such problems rather than simply asserting that such bugs are tautologically impossible. [1] http://dtrace.org/blogs/ahl/2004/07/13/number-11-of-20-libumem/ http://dtrace.org/blogs/ahl/2004/07/13/number-11-of-20-libum... [2] https://queue.acm.org/detail.cfm?id=2039361 https://queue.acm.org/detail.cfm?id=2039361 Edit: added a much better reference.
- pron 11y ago
  > postmortem heap analysis is often much easier on a C-based system than in memory-safe languages. For a specific kind of leak. Java heapdumps and MAT are great postmortem heap-debugging tools (of course, Java Flight Recorder is even awesomer, but unfortunately not part of OpenJDK).
- mwcampbell 11y ago
  The blog post you referenced in [1] doesn't mention managed language runtimes itself, so let me make sure I understand the point. If I understand your point correctly, it's that with managed language runtimes, particularly mature ones like HotSpot and V8, the C heap isn't used in the typical C way; instead, the runtime has its own heap, closely integrated with the garbage collector. In that case, Go probably has the same problem, just because it tries not to use libc at all. I'm guessing that CPython isn't as bad, because it doesn't use a garbage collector. No idea about Ruby.
  - bcantrill 11y ago
    Yes -- and you understand the point correctly. And it's independent of whether a language is GC'd or not; to provide memory safety means to provide a layer of indirection between the system's notion of memory and that of the run-time -- and that layer becomes opaque to traditional native tools. I apologize that that reference was a little hasty; [1] is a much, much better one. [1] https://queue.acm.org/detail.cfm?id=2039361 https://queue.acm.org/detail.cfm?id=2039361
    - pcwalton 11y ago
      > And it's independent of whether a language is GC'd or not; to provide memory safety means to provide a layer of indirection between the system's notion of memory and that of the run-time -- and that layer becomes opaque to traditional native tools. No! You can enforce memory safety at compile time and use the platform's native memory allocation subsystem. There's no need for memory safety to imply any extra runtime support.
      - 11y ago

bcantrill 11y ago

The enthusiasm is fine -- I just wish it were couched in the understanding of the limitations of the technique. I also think it's naive to say that Go's design solves "many [production] problems" -- memory-safe languages solve one set of problems, but often introduce or exacerbate another. (The most obvious example being memory exhaustion: postmortem heap analysis is often much easier on a C-based system than in memory-safe languages.[1][2]) More generally, do not fall into the trap of correctness from smugness: nasty production bugs can exist in any language, and time is much better spent on the production tooling to debug such problems rather than simply asserting that such bugs are tautologically impossible. [1] http://dtrace.org/blogs/ahl/2004/07/13/number-11-of-20-libumem/ http://dtrace.org/blogs/ahl/2004/07/13/number-11-of-20-libum... [2] https://queue.acm.org/detail.cfm?id=2039361 https://queue.acm.org/detail.cfm?id=2039361 Edit: added a much better reference.

pron 11y ago
> postmortem heap analysis is often much easier on a C-based system than in memory-safe languages. For a specific kind of leak. Java heapdumps and MAT are great postmortem heap-debugging tools (of course, Java Flight Recorder is even awesomer, but unfortunately not part of OpenJDK).
mwcampbell 11y ago
The blog post you referenced in [1] doesn't mention managed language runtimes itself, so let me make sure I understand the point. If I understand your point correctly, it's that with managed language runtimes, particularly mature ones like HotSpot and V8, the C heap isn't used in the typical C way; instead, the runtime has its own heap, closely integrated with the garbage collector. In that case, Go probably has the same problem, just because it tries not to use libc at all. I'm guessing that CPython isn't as bad, because it doesn't use a garbage collector. No idea about Ruby.
- bcantrill 11y ago
  Yes -- and you understand the point correctly. And it's independent of whether a language is GC'd or not; to provide memory safety means to provide a layer of indirection between the system's notion of memory and that of the run-time -- and that layer becomes opaque to traditional native tools. I apologize that that reference was a little hasty; [1] is a much, much better one. [1] https://queue.acm.org/detail.cfm?id=2039361 https://queue.acm.org/detail.cfm?id=2039361
  - pcwalton 11y ago
    > And it's independent of whether a language is GC'd or not; to provide memory safety means to provide a layer of indirection between the system's notion of memory and that of the run-time -- and that layer becomes opaque to traditional native tools. No! You can enforce memory safety at compile time and use the platform's native memory allocation subsystem. There's no need for memory safety to imply any extra runtime support.
    - 11y ago