71–80 of 91 posts
Unpopular opinion … 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
The obvious long-term solution is to obtain the .bun gTLD in the next round of applications (expected 2026)
So, anybody using Bun? Does it live up to hype?
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
Earlier quoted context omitted.
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
Ohh bun shell looks interesting. I was looking at zx[1] for some frontend pipeline scripting tasks that were just beyond maintainable bash, but maybe I'll give bun shell a go. [1] https://github.com/google/zx
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 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.
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!
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`
Does `bun foobar` translate to `bunx bun-foobar` as well?
Earlier quoted context omitted.
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`
Sounds like a security nightmare. Does `bun foobar` translate to `bunx bun-foobar` as well?
No.
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…
Unpopular opinion … 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
The obvious long-term solution is to obtain the .bun gTLD in the next round of applications (expected 2026)
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…
if you want that you can always just run the application with debug symbols, no?
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…
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.