Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Bun’s New Crash Reporter

bun.sh

Post reply on HN
Print view View original

81–90 of 91 posts

Re: Bun’s New Crash Reporter

#81

Post by billywhizz »

alimnes wrote: post #67
fellowniusmonk wrote: post #13

Earlier quoted context omitted.

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?

Yes, Bun uses uWebSocket internally. I think OP was saying the perf gain comes from the combination of Bun + uWebSocket. For http, most of that is coming from uWS, which is pretty much best performing HTTP framework out there ime.

https://github.com/oven-sh/bun/blob/main/src/http.zig#L34

Re: Bun’s New Crash Reporter

#84

Post by seabass »

vvpan wrote: post #3

So, anybody using Bun? Does it live up to hype?

It has been extremely fun to use for personal projects. There are still some things that just do not work, though, like brotli compression which means any library using axios with their default brotli compression setting will crash at runtime. There is also no equivalent to the `npm outdated` command and a few other niceties. It is always little unexpected things, so it would be difficult to recommend for production uses just yet, but things are improving rapidly and I could see it becoming stable enough very soon. The APIs it exposes are so awesome—like giving node an excellent standard library—and the fact that I don’t need a compile step to execute TypeScript code makes it easier to get up and running with Bun than without it. Highly recommend trying for non-production work!

Re: Bun’s New Crash Reporter

#85

Post by nathankleyn »

elliotlarson wrote: post #46

Bun seems really compelling. I tried it out for a couple of small example projects and I like the speed and the fact that it combines package management and a JS runtime. However, I use Dependabot on most of my serious projects. I know work is under way, or at least there is some discussion in a couple of repo issues, for Bun support in Dependabot. I'm kind of holding off on using it until support for it has been rol…

We had the same reticence about Dependabot missing before we made the switch, but realised Renovate works with Bun and is a good enough stand in for now until support arrives.

Absolutely zero regrets, the cumulative savings across everything that is faster and the massive step up in DX is worthy of the hype.

Re: Bun’s New Crash Reporter

#86

Post by elliotlarson »

nathankleyn wrote: post #85
elliotlarson wrote: post #46

Bun seems really compelling. I tried it out for a couple of small example projects and I like the speed and the fact that it combines package management and a JS runtime. However, I use Dependabot on most of my serious projects. I know work is under way, or at least there is some discussion in a couple of repo issues, for Bun support in Dependabot. I'm kind of holding off on using it until support for it has been rol…

We had the same reticence about Dependabot missing before we made the switch, but realised Renovate works with Bun and is a good enough stand in for now until support arrives. Absolutely zero regrets, the cumulative savings across everything that is faster and the massive step up in DX is worthy of the hype.

Yeah, I had heard about Renovate supporting Bun. I guess I was reluctant to start working with another 3rd party dependency management system when I already knew how to setup and use Dependabot, and I assumed Bun support was coming soon-ish. But maybe the benefits of moving over to Renovate and getting to use Bun now outweighs the costs.

Re: Bun’s New Crash Reporter

#87

Post by RicoElectrico »

LewisJEllis wrote: post #40
LiamPowell wrote: post #21

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://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,

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)

Re: Bun’s New Crash Reporter

#88

Post by janderland »

AnthonyMouse wrote: post #62
LewisJEllis wrote: post #40

Earlier quoted context omitted.

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

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.

Re: Bun’s New Crash Reporter

#89

Post by AnthonyMouse »

janderland wrote: post #88
AnthonyMouse wrote: post #62

Earlier quoted context omitted.

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

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.

Re: Bun’s New Crash Reporter

#90

Post by simjnd »

LiamPowell wrote: post #70
dewey wrote: post #65

Earlier quoted context omitted.

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…

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.
Post reply on HN