6 ms·

Is it that common for these functions to be used? Perhaps transitively through some popular libraries? Just being in the standard library doesn't even necessari

Is it that common for these functions to be used? Perhaps transitively through some popular libraries? Just being in the standard library doesn't even necessarily mean that these functions (and the data they need) should get included by the linker.

zer00eyz 7y ago
Backtrace can be amazing at run time if your going to put that info into logs. It makes finding "fringe" errors a lot less painful or more easily reproducible.
benesch 7y ago
Any program that uses a logging framework, including the stdlib log package, will wind up depending on runtime.Callers at least transitively. That’s probably most Go programs; certainly most of the programs large enough to be worrying about binary size. Unlike in C, there are no macros like __FILE__ and __LINE__, so there is no alternative to runtime.Callers (short of preprocessing your Go source code).
- umanwizard 7y ago
  You can still get a backtrace without symbols though. Why couldn't the Go team introduce a flag that strips symbols, while making clear to people that they should only use it if they are okay with backtraces looking like #1 0x00007ffff7ddb899 in __GI_abort () at abort.c:79 #2 0x0000555555555156 in ?? () #3 0x0000555555555168 in ?? () #4 0x000055555555517d in ?? () #5 0x0000555555555192 in ?? () or similar
  - giovannibajo1 7y ago
    Because one of the mantra of Go is not telling users to have a "debug" build and a "release" build. The development build is the one that goes into production, with no difference in optimizations, symbols and whatnot. This has pros and cons, like all tradeoffs.
    - umanwizard 7y ago
      Thanks; I didn’t know that, but it makes sense. Not a design decision I agree with, but it’s coherent, at least.
    - roberson87 7y ago
      Are you sure this is true? Doesn't delve for example build Go source with special flags (gcflags=all='-N -l')to generate debugging symbols. I also remember having to build Go code with those flags for Stackdriver to get the correct debugging information without any optimisations.
      - sagichmal 7y ago
        This shouldn't be necessary anymore.
        roberson87 7y ago
        Thanks for the reply. Would appreciate if you could expand on this a little, since when? FWITW Google Stackdriver documentation [1] still states that you have to build source with those flags for version 1.1>. [1]https://cloud.google.com/debugger/docs/setup/go https://cloud.google.com/debugger/docs/setup/go
    - shaklee3 7y ago
      It seems like this can only be a con if other languages give you a choice. In other words, in C++ you can decide that your debug and release are the same, or you can make them different if you know what you're doing (like a good IDE does).
      - firethief 7y ago
        Having more options is inherently better in C++, a language designed to reward mastery. Having fewer choices is better in Go, a language designed to make onboarding a new developer easy.

zer00eyz 7y ago

Backtrace can be amazing at run time if your going to put that info into logs. It makes finding "fringe" errors a lot less painful or more easily reproducible.

benesch 7y ago

Any program that uses a logging framework, including the stdlib log package, will wind up depending on runtime.Callers at least transitively. That’s probably most Go programs; certainly most of the programs large enough to be worrying about binary size. Unlike in C, there are no macros like __FILE__ and __LINE__, so there is no alternative to runtime.Callers (short of preprocessing your Go source code).

umanwizard 7y ago
You can still get a backtrace without symbols though. Why couldn't the Go team introduce a flag that strips symbols, while making clear to people that they should only use it if they are okay with backtraces looking like #1 0x00007ffff7ddb899 in __GI_abort () at abort.c:79 #2 0x0000555555555156 in ?? () #3 0x0000555555555168 in ?? () #4 0x000055555555517d in ?? () #5 0x0000555555555192 in ?? () or similar
- giovannibajo1 7y ago
  Because one of the mantra of Go is not telling users to have a "debug" build and a "release" build. The development build is the one that goes into production, with no difference in optimizations, symbols and whatnot. This has pros and cons, like all tradeoffs.
  - umanwizard 7y ago
    Thanks; I didn’t know that, but it makes sense. Not a design decision I agree with, but it’s coherent, at least.
  - roberson87 7y ago
    Are you sure this is true? Doesn't delve for example build Go source with special flags (gcflags=all='-N -l')to generate debugging symbols. I also remember having to build Go code with those flags for Stackdriver to get the correct debugging information without any optimisations.
    - sagichmal 7y ago
      This shouldn't be necessary anymore.
      - roberson87 7y ago
        Thanks for the reply. Would appreciate if you could expand on this a little, since when? FWITW Google Stackdriver documentation [1] still states that you have to build source with those flags for version 1.1>. [1]https://cloud.google.com/debugger/docs/setup/go https://cloud.google.com/debugger/docs/setup/go
  - shaklee3 7y ago
    It seems like this can only be a con if other languages give you a choice. In other words, in C++ you can decide that your debug and release are the same, or you can make them different if you know what you're doing (like a good IDE does).
    - firethief 7y ago
      Having more options is inherently better in C++, a language designed to reward mastery. Having fewer choices is better in Go, a language designed to make onboarding a new developer easy.