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

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.

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.

After years following bun, (seen first tweets about from zig) have recently started using it. Stuff just works without any hassle! Thank you

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.