[HN Gopher] Bun's New Crash Reporter
___________________________________________________________________
Bun's New Crash Reporter
Author : zackoverflow
Score : 192 points
Date : 2024-04-26 16:20 UTC (6 hours ago)
(HTM) web link (bun.sh)
(TXT) w3m dump (bun.sh)
| vvpan wrote:
| So, anybody using Bun? Does it live up to hype?
| numbers wrote:
| oh yeah, it's amazing! The speed is great but just the DX is so
| much nicer than npm, yarn, or node itself. It took us a few
| tries to getting it working for our prod environments, but
| nothing we couldn't figure out within the same day.
|
| I thought having a binary for a lock file was weird (don't know
| the technical reasons behind it besides maybe speed) but after
| using it for months now, it never has caused an issue for us.
| M4v3R wrote:
| Started using it as soon as they hit 1.0 and never looked back,
| we're implementing it in every project now.
| fellowniusmonk wrote:
| Bun + uwebsocket cut my server costs and requirements
| significantly for my websocket app. It's a real delight to
| work with.
| Alupis wrote:
| How did it cut your server costs - increased performance
| and therefore reduced load?
|
| Bun looks quite promising, but I've heard mixed feedback on
| it being a "drop in" replacement of node. Any experience
| with that aspect?
| fellowniusmonk wrote:
| Perf gain mostly from uwebsocket is what it looks like.
| yieldcrv wrote:
| using it on all my side projects, some of which made it to
| production. some of which had lots of dependencies in the past
| and seamlessly switched over
|
| one employer/client has a big project I'm afraid to attempt
| changing anything on, but I wonder
| basil-rash wrote:
| It's good unless you want a repl (they pretend to have one but
| it's miserable: >6s latency _all the time_ when it updates), or
| you plan to use any native modules. The error messages are also
| significantly worse than node's. I used it for a bit, but node
| with '--loader tsx' does everything I want nowadays with none
| of the downside. If I was building a simple server, perhaps
| with websockets, and I was sure it need native modules, I'd
| consider using Bun. I have several such services live now
| actually.
| robxorb wrote:
| I too would use it if the REPL worked properly. JS developers
| are often used to working interactively - the browser/console
| workflow - and have come to rely on testing ideas or problems
| / solutions in the REPL interactively.
|
| It's efficient, as you can test and narrow things down in
| isolation and figure out what is working or not-working very
| quickly. It's also a good way to try a new module, and this
| is reflected in docs that eg, use node's REPL as a demo.
|
| One bizarre problem with bun's REPL at the moment, which can
| be quite the unexpected "gotcha", is the REPL itself seems to
| be cached, and it goes stale. It actually expects to be able
| to update itself online every day or so, or it breaks!
|
| Yeah, well cool - unless you _ever work offline_. Eg, had you
| expected to work on a long flight and now half your dev
| workflow was broken, for no good reason. (And unfortunately
| bun 's "--prefer-offline" flag had no effect.)
|
| I don't want to criticise bun too much - it is incredibly
| fast, and has made other significant workflow enhancements.
|
| But a REPL is a dealbreaker for some of us. I guess it's
| similar to hot code-reloading in compiled languages, you
| don't go back to the minutes-long compile-wait cycle for the
| kinds of problems that kind of workflow makes instantaneous.
| Jarred wrote:
| Currently, the REPL is an alias of `bunx bun-repl`, and
| bun-repl is a community-maintained npm package. We haven't
| had the time to do our own REPL. Honestly, we really need
| to hire more engineers. We're a small team and there's so
| much to do
| Stoids wrote:
| I have not used it in production yet, but it's been great for
| one-off scripts and side projects. Setting up a TypeScript Node
| environment with ts-node, ts-jest, ESM support, top level
| await, etc. is more annoying than it should be. More recent
| Node releases have alleviated some of this pain, but not as
| trivial as running bun init.
|
| I've enjoyed using the bun shell [1] API.
|
| [1] https://bun.sh/blog/the-bun-shell
| verisimilidude wrote:
| The Bun libraries made it very easy to create my own static
| site generator. Not a huge lift, I know, but it's been a
| delight to work with.
| afavour wrote:
| It's super fast and nice. But I can't bring myself to use it
| with anything other than side projects because of the VC
| funding model.
| ivanjermakov wrote:
| I'm using it for my programming language (~15kLOC) as a dev and
| test runner and haven't had any Bun specific issues so far.
| Rucadi wrote:
| A lot of people trash about bun, but I think that they are highly
| motivated people bringing a lot to the table.
| ComputerGuru wrote:
| Having VCs kind of forces that motivation on you, for better or
| worse.
| bluelightning2k wrote:
| This guy ships
| toxik wrote:
| I feel like this post was a great case study of Zig. Interesting!
| ctoth wrote:
| TIL: Bun runs on Windows and can be installed with scoop.
| lelo_tp wrote:
| Few people would notice how much attention was put into it. Love
| it, really tells how much the folks behind bun care about their
| craft
| nikita wrote:
| Microsoft is really good at this BTW. At SQL Server we had mini
| dumps they were tiny stripped out of personal info and incredibly
| useful. And a full dump of a production SQL Server even at that
| time (15 years ago) would be a huge file - too big to move
| around.
| jallmann wrote:
| Curious - was this for Microsoft internal services or customer
| deployments? If the latter, how did they know what was PII?
| nikita wrote:
| I believe you had to opt in and it has some legal language
| before it. All the data pages were stripped and SQL Servers
| stores all data in the buffer pool. But of course you could
| find some stuff on the stack and other caches.
| malkia wrote:
| Possibly this was used MiniDumpFilterTriage (from
| https://learn.microsoft.com/en-
| us/windows/win32/api/minidump...) and some of other
| stripping/scrubbing data fields.
|
| This one fills all non-null ptr in the callstack (and other
| areas?) with 0xAAAAAAAA
|
| I actually had to fix this for us two weeks ago, as our
| internal tools were crashing on the CI with this, and it
| wasn't helpful (to us), but at the same time understand how
| important is for this if shipped to external customers.
|
| Crashdumps are underrated field that needs more eyes to solve
| the big data problem there.
| tredre3 wrote:
| Did you know that bun needs to download 37 packages before the
| repl becomes available? No internet no repl for you.
| PS C:\Users\anon> bun repl bun-repl [6/6]
| error: FailedToOpenSocket downloading package manifest bun-repl
| error: bun-repl@latest failed to resolve
|
| Not a big deal, but I was expecting (and frankly excited) to have
| a single no-install executable to drop in my PATH and have it
| just work!
| Jarred wrote:
| We haven't prioritized implementing a repl yet. The current
| repl is a community-implemented bun-repl npm package. `bun
| repl` internally does the equivalent of `bunx bun-repl`
| LiamPowell wrote:
| 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...
| simscitizen wrote:
| 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 wrote:
| These can still be large. I generally include them
| unconditionally because I think they bring value but most
| software does not.
| LewisJEllis wrote:
| "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 wrote:
| > 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 wrote:
| > I am not bothered by having to use Sentry to view it
|
| I am. And by source maps in general.
| herpderperator wrote:
| Bun 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. Track the status & thumbs up the issue:
| https://github.com/oven-sh/bun/issues/887 code:
| "ERR_NOT_IMPLEMENTED" at new
| NotImplementedError (internal:shared:19:27) at
| internal:shared:2:69 at node:http2:48:53
| at getServerInstance (/Users/user/d/temp/server/node_modules/fast
| ify/lib/server.js:342:16) at createServer (/Users/
| user/d/temp/server/node_modules/fastify/lib/server.js:25:18)
| at fastify (/Users/user/d/temp/server/node_modules/fastify/fastif
| y.js:198:30) at
| /Users/user/d/temp/server/index_fastify.js:4:13
|
| The linked issue is actually about implementing support for
| http/2 clients, which was already released in v1.0.13
| (https://bun.sh/blog/bun-v1.0.13#http2-client-support). The
| NotImplementedError message should be updated to point to the
| issue for the server variant: https://github.com/oven-
| sh/bun/issues/8823
|
| Implementing http/2 server support is in the top few feature
| requests (https://github.com/oven-
| sh/bun/issues?q=is%3Aissue+is%3Aopen...). It looks like once they
| ship this, a lot more people will be able to move over to Bun.
| drewbitt wrote:
| 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!
| cryptonector wrote:
| > Linux: Use dl_iterate_phdr to iterate over the loaded modules,
| once you find one that the raw address is contained in,
| .dlpi_addr on the dl_phdr_info struct will be the base address.
|
| Er, just use `dladdr()`.
| cryptonector wrote:
| This is great. Very creative. Many should copy this scheme. The
| key is the relative-to-executable/shared object base stack trace
| program counters.
|
| bun is statically linked, yes? In a dynamically linked system one
| would need to prefix every normalized program counter with a
| small numeric shared object ID.
| andersa wrote:
| It's not really anything new. Very common in environments where
| you can't ship symbols such as games crashing on player's
| computers.
|
| For example, the Unreal Engine crash reporter has been capable
| of sending such a simple format for many years. You can restore
| a reasonably accurate function/line number from it for each
| stack frame.
|
| Though minidump is usually preferred as having the stack
| variables can give additional hints to what happened.
| heldrida wrote:
| After years following bun, (seen first tweets about from zig)
| have recently started using it. Stuff just works without any
| hassle! Thank you
| dzogchen wrote:
| I just cannot get excited for this VC funded experimental piece
| of technology. 10 years ago, maybe. Node.js is not going anywhere
| anytime soon.
| sgammon wrote:
| This is awesome. Great work Bun team
| elliotlarson wrote:
| 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 rolled out.
___________________________________________________________________
(page generated 2024-04-26 23:00 UTC)