I've enjoyed using the bun shell [1] API.
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.
It still surprises me with its instant startup.
one employer/client has a big project I'm afraid to attempt changing anything on, but I wonder
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.
This isn't just a theoretical solution either, it's already implemented in LLVM: https://clang.llvm.org/docs/UsersManual.html#cmdoption-gline...
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.
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.
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.
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.
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. And by source maps in general.
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)
There’s other ways to suggest an alternative solution.
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.
Please use the same TLD for all your services.
Don’t do: Bun.sh, and now Bun.report
It’s confusing for users and also a security vector.
Just make it report.bun.sh
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.
Still plenty of UNIX admins keep using Perl 5.
Absolutely zero regrets, the cumulative savings across everything that is faster and the massive step up in DX is worthy of the hype.
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/fastify/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/fastify.js:198:30)
at /Users/user/d/temp/server/index_fastify.js:4:13
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.
PS C:\Users\anon> bun repl
bun-repl [6/6]
error: FailedToOpenSocket downloading package manifest bun-repl
error: bun-repl@latest failed to resolve
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.
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.
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?
Er, just use `dladdr()`.