13 ms·

More powerful Go execution traces

376 points by nalgeon 3y ago

akira2501 3y ago
[flagged]
- Xeoncross 3y ago
  That's actually PascalCase, which I like better than camelCase and snake_case.
  - biomcgary 3y ago
    PascalCase for public variables, camelCase for private variables. Just to keep you on your toes.
    - cwbriscoe 3y ago
      and snake_case for db/sql.
      - biomcgary 3y ago
        kebab-case might be feeling left out of the party.
- lagichikool 3y ago
  I was just thinking today that the case style is the only thing I continue to find objectionable on a day-to-day basis after a decade of writing/reading Go. I've fantasized about the idea of a future `go fmt` version rewriting all the code which seems possible if somewhat impractical.
  - bdzr 3y ago
    Go forth and prosper https://www.emacswiki.org/emacs/GlassesMode https://www.emacswiki.org/emacs/GlassesMode.
- 38 3y ago
  > I love go, but I hate CamelCase so much that I often find myself using a thesaurus to find better names for my structs and functions what does one have to do with the other? also yeah I agree, CamelCase is awful. for a while I was doing: Camel_Case but it just didnt fit with anything, so now I use: CamelCase // just the normal style, for public identifiers snake_case // for private identifiers but, I do not respect acronyms, as keeping them hurt readability I think: HtmlHello HelloHtml
- badrequest 3y ago
  There's nothing about the Go compiler that enforces any case standard. I can't imagine a more trivial hill to die on.
  - semiquaver 3y ago
    Nitpicking, but Go is one of the only languages I’m aware of where identifier case is semantically relevant (to determine visibility). Given that fact it’s hard to say “nothing” enforces a case standard.
    - rob74 3y ago
      Adding to that, the compiler doesn't enforce using "mixed caps", as the documentations calls it, but it's strongly recommended (https://go.dev/doc/effective_go#mixed-caps https://go.dev/doc/effective_go#mixed-caps)
    - dezgeg 3y ago
      Haskell enforces that types and type constructors start with Uppercase, and that everything else starts with lowercase.
  - akira2501 3y ago
    > I can't imagine a more trivial hill to die on. I can't imagine why this attitude pervades on hacker news. I can't imagine a more trivial reason than yours to make a reply. I guess some people see this as a place to discover differences, and others see it as a place to enforce blind conformity to the current fad.
- School-Cotton 3y ago
  That is a bizarre thing to care so much about.
lagichikool 3y ago
Really cool work. I'm still slightly paranoid about the overhead of leaving tracing enabled all the time but if it really is 1-2% that'd be totally worth it in many cases. More awesome work from the Go team. Thanks!
- heyoni 3y ago
  Go has a race detector that you can leave on for a while in like a dev environment and it’ll flag race conditions. There was documented overhead and at some point even a memory leak but they spent months looking into it and eventually plugged the leak and the saga is now part of their official docs. It’s really interesting to see that kind of stuff laid bare so I would trust that this feature will at least run reasonably well and if it doesn’t, they’ll likely fix it: https://go.dev/doc/articles/race_detector https://go.dev/doc/articles/race_detector https://go.dev/issue/26813 https://go.dev/issue/26813
  - swatcoder 3y ago
    > The cost of race detection varies by program, but for a typical program, memory usage may increase by 5-10x and execution time by 2-20x. That's "let's run the race detector and get some coffee" overhead, not "let's leave it on in dev" overhead. Still cool that they have it available!
    - cdelsolar 3y ago
      I am always running everything in race mode when developing locally and have caught stuff before.
    - TheDong 3y ago
      The main value of the race detector is enabling it for tests (go test -race), and then writing sufficiently exhaustive unit tests to cover all code paths. I do think most gophers, instead of tests, use a combination of prayer and automatically restarting crashed processes when they inevitably panic from a race, which seems to work better than you'd expect!
  - 3y ago
bsaul 3y ago
i've sometimes heard that the JVM had best in class tooling for server troubleshooting. How does go compare to it now ?
- Xeoncross 3y ago
  For good reason, the JVM has a ton more knobs that need adjusting. You can't just run Java code. The JVM has a lot of tricks you have to customize for based on your workload. For years until 1.19 the Go GC has had only one tuning parameter (GOGC).
  - tsimionescu 3y ago
    Note that Go needs those knobs just as much as the JVM does, at least some of them. They just didn't want to expose them.
    - philosopher1234 3y ago
      Which knobs does go need?
      - tsimionescu 3y ago
        Fine-grained control over various GC phases and decisions (such as the level of parallelism, max pause times). Until Go 1.19, it was even missing a max memory limit, and even now it only has a soft memory limit. Additionally, of course it would be nice to have more GC options, such as choosing between a throughput-oriented GC design and a latency-oriented one, having the option of a compacting GC of some kind to avoid fragmentation, or even having a real time GC option. Go has chosen a very old-fashioned GC design with very few tuning parameters possible, but even so it only exposes a very basic form of control.
        cwbriscoe 3y ago
        I would rather just write code and trust the existing GC than mess around with knobs all day. I suppose there are < 1% of projects that may see some benefit in messing with the GC.
Veserv 3y ago
The usage of the term execution trace really threw me off. I am more familiar with that term meaning a instruction execution trace or maybe just a function trace, so it made no sense why stack unwinding would be a bottleneck. Turns out it is actually a goroutine event (with stack trace at time of event) trace [1]. I guess Go does not have a code execution trace package? [1] https://pkg.go.dev/runtime/trace https://pkg.go.dev/runtime/trace
- Thaxll 3y ago
  Tracing code is a way to see what's happening in your code which Go provides: https://www.infoq.com/articles/debugging-go-programs-pprof-trace/ https://www.infoq.com/articles/debugging-go-programs-pprof-t... Many other language use the same technique, see Python with: https://github.com/bloomberg/memray https://github.com/bloomberg/memray
  - Veserv 3y ago
    I was talking about execution tracing, specifically, not tracing as a general concept. Tracing as a general concept just means a non-sampled time-series event stream and as commonly used these days generally also includes "stacking" to distinguish it from generic event streams or logging. When you add a additional term like "execution" you are specializing the term to mean a event stream of "execution". In areas I am familiar with, that would normally mean a trace of the complete execution of the program down to the instruction-level so you can trace the precise "execution" of the program through the code. What is described here would, in the terminology I am familiar with, be more like... a thread status and system event trace just applied to goroutines and the Go runtime, respectively, I guess? It does also include the stack trace at the time of the event, so it does have more data than that, but that is qualitatively different than a instruction execution trace that allows you to trace the exact sequence of execution of your program.
- felixge 3y ago
  Go doesn't have an instruction (execution) or function call tracer. Go's tracer is primarily tracing scheduler events. So maybe the term scheduler tracer should have been used? Anyway, using the term "execution tracer" in Go goes back to the initial design doc from 2014: https://docs.google.com/document/u/1/d/1FP5apqzBgr7ahCCgFO-yoVhk4YZrNIDNf9RybngBc14/pub https://docs.google.com/document/u/1/d/1FP5apqzBgr7ahCCgFO-y...
imiric 3y ago
This is really amazing! I look forward to giving it a try. Kudos to the Go team and contributors. Say what you will about the language itself, the Go stdlib is one of the most useful and pleasant standard libraries I've ever worked with. It gets better with every release, and great care is taken to make it featureful, performant and well documented. These days for most general things I rarely have the need to reach for an external package.
- traceroute66 3y ago
  > I rarely have the need to reach for an external package Agree 100 % ! And it gets better as time evolves. For example the recent `log/slog` introduction to stlib kills the need for 99.9999% of people to use third-party logging, because structured logging is now in stlib. Same with the new http mux. Many people will now be able to migrate over to stdlib because of the richer functionality, and only the small community of outliers who are doing stuff like regex mux parsing will need the third-party libs, but with time no doubt regex mux will make its way to stdlib too.
- throwaway894345 3y ago
  I remember hearing from people in the early days of Go that it was only nice because it hadn't aged. It didn't have the "barnacles" that Python and Java had acquired, but that it surely would after a decade. At the time, Python and Java were about 15 years old (since their 1.0 releases). Well, it's been 12 years and Go is still clean and minimalist. Maybe all of the cruft comes in years 12-15? :shrug:
  - arp242 3y ago
    Go did acquire some of that though; a few packages are deprecated, some have different ways of doing the same thing (e.g. the addition of context and fs packages added new paradigms, and later netip and new JSON package added "urllib2"-like "v2" packages), and some things weren't really a good idea to start with. I do think the situation is better than in Python and overall not bad after 12 years, but it's not as clean and minimalist as it could be.
pjmlp 3y ago
The Flight Recoding pun did not go unnoticed. https://docs.oracle.com/javacomponents/jmc-5-4/jfr-runtime-guide/about.htm https://docs.oracle.com/javacomponents/jmc-5-4/jfr-runtime-g...
Zuiii 3y ago
Go's standard library is a shining example of what all standard libraries should strive for. Yet, we still have some languages who's developers refuse to include even a basic http API in their standard libraries in an age where even embedded systems have started to speak http. Imagine if if the same had happened with TCP and UDP... Here's to the continued success of Go and other sanely-designed languages.
- nindalf 3y ago
  I think it’s a bit extreme to characterise it as sanity vs insanity. I think you need at least one of a large stdlib or good dependency management. I love Go, used it since the 1.0 release and have used it at work for years. No complaints about the language. But for the longest time Go didn’t have quality dependency management and pulling in dependencies was annoying. Building your programs with the large, high quality stdlib was the path of least resistance. Since Go 1.0 (2012) most new languages have coalesced on good dependency management. Rust, for example, copied Ruby’s bundler idioms since before 1.0 (2015). People who needed good quality libraries were able to pull them in with minimal hassle. That’s why they didn’t need a large standard library to succeed. I’ve written more about the tradeoff here - https://blog.nindalf.com/posts/rust-stdlib/ https://blog.nindalf.com/posts/rust-stdlib/ To you, I’d suggest using less charged language like sanity. In this case there’s a good technical case for both ways, and it’s not productive or nice to imply that people who choose a different path from you are insane.
  - bheadmaster 3y ago
    > To you, I’d suggest using less charged language like sanity. To the grandparent, I'd suggest keeping the language as it is. Status quo in the current programming ecosystem is often insane, and when it is, we should call it out. > it’s not productive or nice to imply that people who choose a different path from you are insane. In a general sense, I agree. However, when it comes to programming, insanity is so widely accepted as normality that I think it would be counterproductive to blunt the language used to describe it. As an example of insanity for those who may (justifiably) think I'm talking out of my bottom - in NodeJS ecosystem the standard library is so bad that it is considered acceptable to use dependencies for even the simplest tasks, which caused the `leftpad` incident which broke countless programs.
the_gipsy 3y ago
What about error stack traces? I find it crazy that you're supposed to grep error strings and pray they're all different.
- pipe01 3y ago
  You can do it yourself if you want using `runtime.Stack` and a custom error type
  - minzi 3y ago
    Embarrassingly, I’ve been writing Go for a while but never really thought about it. Now that it’s been mentioned I’m curious why this isn’t baked in by default for errors. Does anyone know?
    - sapiogram 3y ago
      > I’ve been writing Go for a while but never really thought about it. Don't feel bad, I've tried to do this in some places, but I'm not sure it's worth it. It adds a ton of boilerplate to Go's already verbose error handling, since you need to wrap every error that gets returned from libraries.
    - icholy 3y ago
      Creating stack traces is expensive.
      - tbarbugli 3y ago
        you only do it when there is a not nil err + being able to have a stacktrace is worth more than whatever it costs is CPU
        Cthulhu_ 3y ago
        That's still under the assumption that errors are exceptional, rare, and require a stacktrace to debug. But most errors are not exceptional and do not need debugging, like idk, a row not found error in a database. A crash, sure, that might need a stacktrace to debug. But that's already in place.
Donberry 3y ago
[dead]
kjqgqkejbfefn 3y ago
I've started development of something similar for Clojure's core.async library, which implements Go-like channels. This is something I cobbled together to trace the origin of a subtle sporadic bug that would happen once every 10,000 runs in a program that makes heavy use of channels. I'm not really working actively on it, so it only covers a subset of the functions in core.async but I keep on expanding it, adding debugging support for functions every now and then when I need it. It represents the flow of data between channels/threads as a sequence diagram using PlantUML. Today I implemented core.async/onto-chan! (it spins a thread that will take items from a sequence and put them onto a channel). Here's what it looks like: https://pasteboard.co/VhvDroREOvOQ.png https://pasteboard.co/VhvDroREOvOQ.png It's especially useful in Clojure, as the experience with channels is not as polished as in Go (or so I heard): when a put or a take hangs, your only recourse is to sit and squint at your code. This tool will color them red, so you can immediately spot what's wrong. It also allowed me to spot a channel spaghetti plate I had not anticipated and wouldn't have remarked otherwise. For now I've taken a "maximalist" approach which includes inspecting buffers, so it incurs a heavy runtime penalty that's only ok at dev-time (+ it keep tracks of the whole trace, so no flight recording in sight for now). In the future I'd like to give it a proper interface (it's just a svg file with hoverable elements for now), maybe using constraint-based graph layout to lay out the sequence diagram using cola.js/adaptagrams or the sequence diagram from Kiel university Kieler project when it's integrated into the Eclipse Layout Toolkit. Thesis from the developer of this module: https://web.archive.org/web/20220519080528id_/https://macau.uni-kiel.de/servlets/MCRFileNodeServlet/macau_derivate_00003371/kcss_2019_04.pdf https://web.archive.org/web/20220519080528id_/https://macau....

376 points by nalgeon 3y ago

akira2501 3y ago

[flagged]

Xeoncross 3y ago
That's actually PascalCase, which I like better than camelCase and snake_case.
- biomcgary 3y ago
  PascalCase for public variables, camelCase for private variables. Just to keep you on your toes.
  - cwbriscoe 3y ago
    and snake_case for db/sql.
    - biomcgary 3y ago
      kebab-case might be feeling left out of the party.
lagichikool 3y ago
I was just thinking today that the case style is the only thing I continue to find objectionable on a day-to-day basis after a decade of writing/reading Go. I've fantasized about the idea of a future `go fmt` version rewriting all the code which seems possible if somewhat impractical.
- bdzr 3y ago
  Go forth and prosper https://www.emacswiki.org/emacs/GlassesMode https://www.emacswiki.org/emacs/GlassesMode.
38 3y ago
> I love go, but I hate CamelCase so much that I often find myself using a thesaurus to find better names for my structs and functions what does one have to do with the other? also yeah I agree, CamelCase is awful. for a while I was doing: Camel_Case but it just didnt fit with anything, so now I use: CamelCase // just the normal style, for public identifiers snake_case // for private identifiers but, I do not respect acronyms, as keeping them hurt readability I think: HtmlHello HelloHtml
badrequest 3y ago
There's nothing about the Go compiler that enforces any case standard. I can't imagine a more trivial hill to die on.
- semiquaver 3y ago
  Nitpicking, but Go is one of the only languages I’m aware of where identifier case is semantically relevant (to determine visibility). Given that fact it’s hard to say “nothing” enforces a case standard.
  - rob74 3y ago
    Adding to that, the compiler doesn't enforce using "mixed caps", as the documentations calls it, but it's strongly recommended (https://go.dev/doc/effective_go#mixed-caps https://go.dev/doc/effective_go#mixed-caps)
  - dezgeg 3y ago
    Haskell enforces that types and type constructors start with Uppercase, and that everything else starts with lowercase.
- akira2501 3y ago
  > I can't imagine a more trivial hill to die on. I can't imagine why this attitude pervades on hacker news. I can't imagine a more trivial reason than yours to make a reply. I guess some people see this as a place to discover differences, and others see it as a place to enforce blind conformity to the current fad.
School-Cotton 3y ago
That is a bizarre thing to care so much about.

lagichikool 3y ago

Really cool work. I'm still slightly paranoid about the overhead of leaving tracing enabled all the time but if it really is 1-2% that'd be totally worth it in many cases. More awesome work from the Go team. Thanks!

heyoni 3y ago
Go has a race detector that you can leave on for a while in like a dev environment and it’ll flag race conditions. There was documented overhead and at some point even a memory leak but they spent months looking into it and eventually plugged the leak and the saga is now part of their official docs. It’s really interesting to see that kind of stuff laid bare so I would trust that this feature will at least run reasonably well and if it doesn’t, they’ll likely fix it: https://go.dev/doc/articles/race_detector https://go.dev/doc/articles/race_detector https://go.dev/issue/26813 https://go.dev/issue/26813
- swatcoder 3y ago
  > The cost of race detection varies by program, but for a typical program, memory usage may increase by 5-10x and execution time by 2-20x. That's "let's run the race detector and get some coffee" overhead, not "let's leave it on in dev" overhead. Still cool that they have it available!
  - cdelsolar 3y ago
    I am always running everything in race mode when developing locally and have caught stuff before.
  - TheDong 3y ago
    The main value of the race detector is enabling it for tests (go test -race), and then writing sufficiently exhaustive unit tests to cover all code paths. I do think most gophers, instead of tests, use a combination of prayer and automatically restarting crashed processes when they inevitably panic from a race, which seems to work better than you'd expect!
- 3y ago

bsaul 3y ago

i've sometimes heard that the JVM had best in class tooling for server troubleshooting. How does go compare to it now ?

Xeoncross 3y ago
For good reason, the JVM has a ton more knobs that need adjusting. You can't just run Java code. The JVM has a lot of tricks you have to customize for based on your workload. For years until 1.19 the Go GC has had only one tuning parameter (GOGC).
- tsimionescu 3y ago
  Note that Go needs those knobs just as much as the JVM does, at least some of them. They just didn't want to expose them.
  - philosopher1234 3y ago
    Which knobs does go need?
    - tsimionescu 3y ago
      Fine-grained control over various GC phases and decisions (such as the level of parallelism, max pause times). Until Go 1.19, it was even missing a max memory limit, and even now it only has a soft memory limit. Additionally, of course it would be nice to have more GC options, such as choosing between a throughput-oriented GC design and a latency-oriented one, having the option of a compacting GC of some kind to avoid fragmentation, or even having a real time GC option. Go has chosen a very old-fashioned GC design with very few tuning parameters possible, but even so it only exposes a very basic form of control.
      - cwbriscoe 3y ago
        I would rather just write code and trust the existing GC than mess around with knobs all day. I suppose there are < 1% of projects that may see some benefit in messing with the GC.

Veserv 3y ago

The usage of the term execution trace really threw me off. I am more familiar with that term meaning a instruction execution trace or maybe just a function trace, so it made no sense why stack unwinding would be a bottleneck. Turns out it is actually a goroutine event (with stack trace at time of event) trace [1]. I guess Go does not have a code execution trace package? [1] https://pkg.go.dev/runtime/trace https://pkg.go.dev/runtime/trace

Thaxll 3y ago
Tracing code is a way to see what's happening in your code which Go provides: https://www.infoq.com/articles/debugging-go-programs-pprof-trace/ https://www.infoq.com/articles/debugging-go-programs-pprof-t... Many other language use the same technique, see Python with: https://github.com/bloomberg/memray https://github.com/bloomberg/memray
- Veserv 3y ago
  I was talking about execution tracing, specifically, not tracing as a general concept. Tracing as a general concept just means a non-sampled time-series event stream and as commonly used these days generally also includes "stacking" to distinguish it from generic event streams or logging. When you add a additional term like "execution" you are specializing the term to mean a event stream of "execution". In areas I am familiar with, that would normally mean a trace of the complete execution of the program down to the instruction-level so you can trace the precise "execution" of the program through the code. What is described here would, in the terminology I am familiar with, be more like... a thread status and system event trace just applied to goroutines and the Go runtime, respectively, I guess? It does also include the stack trace at the time of the event, so it does have more data than that, but that is qualitatively different than a instruction execution trace that allows you to trace the exact sequence of execution of your program.
felixge 3y ago
Go doesn't have an instruction (execution) or function call tracer. Go's tracer is primarily tracing scheduler events. So maybe the term scheduler tracer should have been used? Anyway, using the term "execution tracer" in Go goes back to the initial design doc from 2014: https://docs.google.com/document/u/1/d/1FP5apqzBgr7ahCCgFO-yoVhk4YZrNIDNf9RybngBc14/pub https://docs.google.com/document/u/1/d/1FP5apqzBgr7ahCCgFO-y...

imiric 3y ago

This is really amazing! I look forward to giving it a try. Kudos to the Go team and contributors. Say what you will about the language itself, the Go stdlib is one of the most useful and pleasant standard libraries I've ever worked with. It gets better with every release, and great care is taken to make it featureful, performant and well documented. These days for most general things I rarely have the need to reach for an external package.

traceroute66 3y ago
> I rarely have the need to reach for an external package Agree 100 % ! And it gets better as time evolves. For example the recent `log/slog` introduction to stlib kills the need for 99.9999% of people to use third-party logging, because structured logging is now in stlib. Same with the new http mux. Many people will now be able to migrate over to stdlib because of the richer functionality, and only the small community of outliers who are doing stuff like regex mux parsing will need the third-party libs, but with time no doubt regex mux will make its way to stdlib too.
throwaway894345 3y ago
I remember hearing from people in the early days of Go that it was only nice because it hadn't aged. It didn't have the "barnacles" that Python and Java had acquired, but that it surely would after a decade. At the time, Python and Java were about 15 years old (since their 1.0 releases). Well, it's been 12 years and Go is still clean and minimalist. Maybe all of the cruft comes in years 12-15? :shrug:
- arp242 3y ago
  Go did acquire some of that though; a few packages are deprecated, some have different ways of doing the same thing (e.g. the addition of context and fs packages added new paradigms, and later netip and new JSON package added "urllib2"-like "v2" packages), and some things weren't really a good idea to start with. I do think the situation is better than in Python and overall not bad after 12 years, but it's not as clean and minimalist as it could be.

pjmlp 3y ago

The Flight Recoding pun did not go unnoticed. https://docs.oracle.com/javacomponents/jmc-5-4/jfr-runtime-guide/about.htm https://docs.oracle.com/javacomponents/jmc-5-4/jfr-runtime-g...

Zuiii 3y ago

Go's standard library is a shining example of what all standard libraries should strive for. Yet, we still have some languages who's developers refuse to include even a basic http API in their standard libraries in an age where even embedded systems have started to speak http. Imagine if if the same had happened with TCP and UDP... Here's to the continued success of Go and other sanely-designed languages.

nindalf 3y ago
I think it’s a bit extreme to characterise it as sanity vs insanity. I think you need at least one of a large stdlib or good dependency management. I love Go, used it since the 1.0 release and have used it at work for years. No complaints about the language. But for the longest time Go didn’t have quality dependency management and pulling in dependencies was annoying. Building your programs with the large, high quality stdlib was the path of least resistance. Since Go 1.0 (2012) most new languages have coalesced on good dependency management. Rust, for example, copied Ruby’s bundler idioms since before 1.0 (2015). People who needed good quality libraries were able to pull them in with minimal hassle. That’s why they didn’t need a large standard library to succeed. I’ve written more about the tradeoff here - https://blog.nindalf.com/posts/rust-stdlib/ https://blog.nindalf.com/posts/rust-stdlib/ To you, I’d suggest using less charged language like sanity. In this case there’s a good technical case for both ways, and it’s not productive or nice to imply that people who choose a different path from you are insane.
- bheadmaster 3y ago
  > To you, I’d suggest using less charged language like sanity. To the grandparent, I'd suggest keeping the language as it is. Status quo in the current programming ecosystem is often insane, and when it is, we should call it out. > it’s not productive or nice to imply that people who choose a different path from you are insane. In a general sense, I agree. However, when it comes to programming, insanity is so widely accepted as normality that I think it would be counterproductive to blunt the language used to describe it. As an example of insanity for those who may (justifiably) think I'm talking out of my bottom - in NodeJS ecosystem the standard library is so bad that it is considered acceptable to use dependencies for even the simplest tasks, which caused the `leftpad` incident which broke countless programs.

the_gipsy 3y ago

What about error stack traces? I find it crazy that you're supposed to grep error strings and pray they're all different.

pipe01 3y ago
You can do it yourself if you want using `runtime.Stack` and a custom error type
- minzi 3y ago
  Embarrassingly, I’ve been writing Go for a while but never really thought about it. Now that it’s been mentioned I’m curious why this isn’t baked in by default for errors. Does anyone know?
  - sapiogram 3y ago
    > I’ve been writing Go for a while but never really thought about it. Don't feel bad, I've tried to do this in some places, but I'm not sure it's worth it. It adds a ton of boilerplate to Go's already verbose error handling, since you need to wrap every error that gets returned from libraries.
  - icholy 3y ago
    Creating stack traces is expensive.
    - tbarbugli 3y ago
      you only do it when there is a not nil err + being able to have a stacktrace is worth more than whatever it costs is CPU
      - Cthulhu_ 3y ago
        That's still under the assumption that errors are exceptional, rare, and require a stacktrace to debug. But most errors are not exceptional and do not need debugging, like idk, a row not found error in a database. A crash, sure, that might need a stacktrace to debug. But that's already in place.

Donberry 3y ago

[dead]

kjqgqkejbfefn 3y ago

I've started development of something similar for Clojure's core.async library, which implements Go-like channels. This is something I cobbled together to trace the origin of a subtle sporadic bug that would happen once every 10,000 runs in a program that makes heavy use of channels. I'm not really working actively on it, so it only covers a subset of the functions in core.async but I keep on expanding it, adding debugging support for functions every now and then when I need it. It represents the flow of data between channels/threads as a sequence diagram using PlantUML. Today I implemented core.async/onto-chan! (it spins a thread that will take items from a sequence and put them onto a channel). Here's what it looks like: https://pasteboard.co/VhvDroREOvOQ.png https://pasteboard.co/VhvDroREOvOQ.png It's especially useful in Clojure, as the experience with channels is not as polished as in Go (or so I heard): when a put or a take hangs, your only recourse is to sit and squint at your code. This tool will color them red, so you can immediately spot what's wrong. It also allowed me to spot a channel spaghetti plate I had not anticipated and wouldn't have remarked otherwise. For now I've taken a "maximalist" approach which includes inspecting buffers, so it incurs a heavy runtime penalty that's only ok at dev-time (+ it keep tracks of the whole trace, so no flight recording in sight for now). In the future I'd like to give it a proper interface (it's just a svg file with hoverable elements for now), maybe using constraint-based graph layout to lay out the sequence diagram using cola.js/adaptagrams or the sequence diagram from Kiel university Kieler project when it's integrated into the Eclipse Layout Toolkit. Thesis from the developer of this module: https://web.archive.org/web/20220519080528id_/https://macau.uni-kiel.de/servlets/MCRFileNodeServlet/macau_derivate_00003371/kcss_2019_04.pdf https://web.archive.org/web/20220519080528id_/https://macau....