5 ms·

So the argument for using this over a regular stack trace is that they don't have to ship megabytes of debug symbols. However they have seemingly just ignored t

So the argument for using this over a regular stack trace is that they don't have to ship megabytes of debug symbols. However they have seemingly just ignored the better option of only including function names in the debug table, which is obviously a much nicer option than having to use a web service to view you stack trace. This isn't just a theoretical solution either, it's already implemented in LLVM: https://clang.llvm.org/docs/UsersManual.html#cmdoption-gline-tables-only https://clang.llvm.org/docs/UsersManual.html#cmdoption-gline...

simscitizen 2y ago
Another option on macOS/iOS is to ship just the LC_FUNCTION_STARTS section in the Mach-O binary. This is how symbolication can discover function names from system libraries even without full debug symbols on those platforms.
saagarjha 2y ago
These can still be large. I generally include them unconditionally because I think they bring value but most software does not.
LewisJEllis 2y ago
"they have seemingly just ignored the better option...obviously much nicer" This comes off a bit presumptuous. I would assume that they are aware this is a possibility. "having to use a web service to view you stack trace" This is just not a downside that matters for this usage scenario. It's almost the same story as minifying your frontend JS bundle, uploading source maps to Sentry, then using Sentry to view an unminified stack trace from a user's browser. The user was never going to view that stack trace anyway, and I am not bothered by having to use Sentry to view it - I never would have seen it at all otherwise.
- LiamPowell 2y ago
  > This comes off a bit presumptuous. I would assume that they are aware this is a possibility. They don't present it here, they justify their solution by claiming that the existing solution is bad because it includes several megabytes of debug symbols.
- tambourine_man 2y ago
  > I am not bothered by having to use Sentry to view it I am. And by source maps in general.
- AnthonyMouse 2y ago
  > The user was never going to view that stack trace anyway Speak for yourself. The ability to understand and affect what's going on in your own user agent is important not just to users having control over their own devices, it changes the social fabric. You can't get interested in how something works because to you it's an opaque blob whose priests have declared you unworthy. Curiosity suppressed. That's bad for the kids.
  - raziel2p 2y ago
    if you want that you can always just run the application with debug symbols, no?
    - AnthonyMouse 2y ago
      The user is all too often not provided with debug symbols.
  - janderland 2y ago
    Bun is open source, right? If you want the debug symbols then build them. This feature is for the users who don’t want to debug Bun and simply submit a comprehensive report, which will be the majority of users.
    - AnthonyMouse 2y ago
      Bun is MIT licensed, meaning any derivatives aren't required to give you source code. But it's more about the principle. People do the same thing in web pages and give you minified gibberish "to save bandwidth". Meanwhile the hot garbage is still a megabyte of JS. Maybe cut some of the bloat and keep the human-readable text which is known to be efficiently compressed by ordinary lossless compression algorithms.
- hitekker 2y ago
  On the note of awareness of possibilities vs ignorance, I found this thread on HN to be gold: https://news.ycombinator.com/item?id=37592471 https://news.ycombinator.com/item?id=37592471 The creator of Vue pointed out a new feature for Svelte was a similar feature that Vue had tried and discarded. The creator of Svelte showed up to explain their position; I thought their exchange was illuminating. I was also impressed by Vue's research & experimentation.
- RicoElectrico 2y ago
  > The user was never going to view that stack trace anyway, Well akchually, I found stack traces useful as a user. It allowed me to pinpoint an issue (SPICE simulator crashing due to inconsistent quote handling in E-sources vs another simulator which did not crash). IDK how else I'd be able to find this other than file a Jira ticket to the simulator team (and then wait 2 days for various people to pass the ticket, as they almost always do)
dewey 2y ago
If you criticize something where you have no context, were not part of the discussions and aware of the trade offs that were made it comes across a bit arrogant to say they should “obviously” “just” do something else. There’s other ways to suggest an alternative solution.
- LiamPowell 2y ago
  Maybe it comes off that way a bit, but I can only go off what's in the blog post where they begin by calling the existing solution bloated in order to justify their new solution without ever mentioning that the debug table contains much more than just function names and line number mappings. I do think it should be obvious that displaying text directly in the console is better than relying on a web service to display that same text.
  - simjnd 2y ago
    OBVIOUSLY you haven't read the blog post since it is about a crash REPORTER: making it easy for users to REPORT crashes to the maintainers with all of the relevant info. Offering a link with a pre-filled form is OBVIOUSLY easier than making the user copy-paste console text into a browser.
Jarred 2y ago
> the argument for using this over a regular stack trace is that they don't have to ship megabytes of debug symbols No, it’s because almost nobody has enough patience to upload a crash report for a GitHub issue. It has to be easy. Making it a URL that autofills the form with almost everything we need makes it easy. The size matters too, we didn’t want it to have downsides for our users, but the important thing is making this whole process really easy for the user so that enough developers actually upload crash reports.

simscitizen 2y ago

Another option on macOS/iOS is to ship just the LC_FUNCTION_STARTS section in the Mach-O binary. This is how symbolication can discover function names from system libraries even without full debug symbols on those platforms.

saagarjha 2y ago

These can still be large. I generally include them unconditionally because I think they bring value but most software does not.

LewisJEllis 2y ago

"they have seemingly just ignored the better option...obviously much nicer" This comes off a bit presumptuous. I would assume that they are aware this is a possibility. "having to use a web service to view you stack trace" This is just not a downside that matters for this usage scenario. It's almost the same story as minifying your frontend JS bundle, uploading source maps to Sentry, then using Sentry to view an unminified stack trace from a user's browser. The user was never going to view that stack trace anyway, and I am not bothered by having to use Sentry to view it - I never would have seen it at all otherwise.

LiamPowell 2y ago
> This comes off a bit presumptuous. I would assume that they are aware this is a possibility. They don't present it here, they justify their solution by claiming that the existing solution is bad because it includes several megabytes of debug symbols.
tambourine_man 2y ago
> I am not bothered by having to use Sentry to view it I am. And by source maps in general.
AnthonyMouse 2y ago
> The user was never going to view that stack trace anyway Speak for yourself. The ability to understand and affect what's going on in your own user agent is important not just to users having control over their own devices, it changes the social fabric. You can't get interested in how something works because to you it's an opaque blob whose priests have declared you unworthy. Curiosity suppressed. That's bad for the kids.
- raziel2p 2y ago
  if you want that you can always just run the application with debug symbols, no?
  - AnthonyMouse 2y ago
    The user is all too often not provided with debug symbols.
- janderland 2y ago
  Bun is open source, right? If you want the debug symbols then build them. This feature is for the users who don’t want to debug Bun and simply submit a comprehensive report, which will be the majority of users.
  - AnthonyMouse 2y ago
    Bun is MIT licensed, meaning any derivatives aren't required to give you source code. But it's more about the principle. People do the same thing in web pages and give you minified gibberish "to save bandwidth". Meanwhile the hot garbage is still a megabyte of JS. Maybe cut some of the bloat and keep the human-readable text which is known to be efficiently compressed by ordinary lossless compression algorithms.
hitekker 2y ago
On the note of awareness of possibilities vs ignorance, I found this thread on HN to be gold: https://news.ycombinator.com/item?id=37592471 https://news.ycombinator.com/item?id=37592471 The creator of Vue pointed out a new feature for Svelte was a similar feature that Vue had tried and discarded. The creator of Svelte showed up to explain their position; I thought their exchange was illuminating. I was also impressed by Vue's research & experimentation.
RicoElectrico 2y ago
> The user was never going to view that stack trace anyway, Well akchually, I found stack traces useful as a user. It allowed me to pinpoint an issue (SPICE simulator crashing due to inconsistent quote handling in E-sources vs another simulator which did not crash). IDK how else I'd be able to find this other than file a Jira ticket to the simulator team (and then wait 2 days for various people to pass the ticket, as they almost always do)

dewey 2y ago

If you criticize something where you have no context, were not part of the discussions and aware of the trade offs that were made it comes across a bit arrogant to say they should “obviously” “just” do something else. There’s other ways to suggest an alternative solution.

LiamPowell 2y ago
Maybe it comes off that way a bit, but I can only go off what's in the blog post where they begin by calling the existing solution bloated in order to justify their new solution without ever mentioning that the debug table contains much more than just function names and line number mappings. I do think it should be obvious that displaying text directly in the console is better than relying on a web service to display that same text.
- simjnd 2y ago
  OBVIOUSLY you haven't read the blog post since it is about a crash REPORTER: making it easy for users to REPORT crashes to the maintainers with all of the relevant info. Offering a link with a pre-filled form is OBVIOUSLY easier than making the user copy-paste console text into a browser.

Jarred 2y ago

> the argument for using this over a regular stack trace is that they don't have to ship megabytes of debug symbols No, it’s because almost nobody has enough patience to upload a crash report for a GitHub issue. It has to be easy. Making it a URL that autofills the form with almost everything we need makes it easy. The size matters too, we didn’t want it to have downsides for our users, but the important thing is making this whole process really easy for the user so that enough developers actually upload crash reports.