This is crazy. Amazing work!
Bun’s New Crash Reporter
61–70 of 91 posts
Re: Bun’s New Crash Reporter
#62So 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://clan…
"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 unmi…
> 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.
Re: Bun’s New Crash Reporter
#63> That's why in Bun v1.1.5, I wrote a compact new format for Zig and C++ crash reports.
why did the author use the pronoun I instead of we? isn't it a team work and there is no I in team as they say?
Re: Bun’s New Crash Reporter
#64> That's why in Bun v1.1.5, I wrote a compact new format for Zig and C++ crash reports. why did the author use the pronoun I instead of we? isn't it a team work and there is no I in team as they say?
We are a team, but Dave wrote the code for this project so "I" makes sense
Re: Bun’s New Crash Reporter
#65So 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://clan…
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.
Re: Bun’s New Crash Reporter
#66Bun is amazing, but I recently tried to make an http/2 server through fastify and was not able to: user@host:~/d/temp/server$ bun run index_fastify.js 14 | warned.add(feature), console.warn(new NotImplementedError(feature, issue)); 15 | }, $; 16 | 17 | class NotImplementedError extends Error { 18 | code; 19 | constructor(feature, issue) { ^ NotImplementedError: node:http2 createServer is not yet implemented in Bun. T…
That's just the status of Bun. Wait for implementations -> turns out you need more implementations of other APIs once that's done -> wait some more -> it comes out but will crash at various edge cases -> wait some more -> repeat. Bun is just too early in its lifecycle. Very hopeful for the project though!
Yes, but http2 is one of the few features Bun is missing. Overall it's pretty complete.
Re: Bun’s New Crash Reporter
#67Earlier quoted context omitted.
Started using it as soon as they hit 1.0 and never looked back, we’re implementing it in every project now.
Bun + uwebsocket cut my server costs and requirements significantly for my websocket app. It's a real delight to work with.
Do you use uwebsocket with Bun explicitly? I thought Bun has websocket support built in by internally using uwebsockets?
Re: Bun’s New Crash Reporter
#68I just cannot get excited for this VC funded experimental piece of technology. 10 years ago, maybe. Node.js is not going anywhere anytime soon.
They used to say "perl is not going anywhere", too, and it turns out they were right.
Turns out a full rewrite turns people away.
Still plenty of UNIX admins keep using Perl 5.
Re: Bun’s New Crash Reporter
#69Re: Bun’s New Crash Reporter
#70So 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://clan…
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.