Hacker News new | ask | show | jobs
by LiamPowell 789 days ago
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...

5 comments

> 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.

"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.

> 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.

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.
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.
if you want that you can always just run the application with debug symbols, no?
The user is all too often not provided with debug symbols.
> 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.

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

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.

> I am not bothered by having to use Sentry to view it

I am. And by source maps in general.

> 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)

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.

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.

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.
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.
These can still be large. I generally include them unconditionally because I think they bring value but most software does not.