261–270 of 1001 posts
No strategic roadmap is ever going to tell you: "Build a $0-revenue JavaScript runtime and one day an AI company will acquire you"
Earlier quoted context omitted.
That's because it's not written in JS at all but a compiled systems language, no wonder it's gonna be fast.
Virtually all JavaScript engines are written in compiled languages. (Most runtimes for that matter nut just JS)
This announcement made me check in on the arbitrary code execution bug I reported that the Bun Claude bot created a PR for about 3 weeks ago: https://github.com/oven-sh/bun/pull/24578 So far, someone from the bun team has left a bunch of comments like > Poor quality code ...and all the tests still seem to be failing. I looked through the code that the bot had generated and to me (who to be fair is not familiar with t…
So you pushed a PR that breaks a bunch of tests, added a 5 layer nested if branch block that mixes concerns all over the place, then ignored the reviewer for three weeks, and you’re surprised they didn’t approve it?
...Did you miss the part where Bun used Claude to generate that PR?:)
Earlier quoted context omitted.
Search for pointer exceptions or core dumps on Bun's GitHub issues and you'll see why people (should) use Deno over Bun, if only because Rust is a way more safe language than Zig.
This is a non sequitur. Both Rust and Zig and any other language has the ability to end in an exception state. Whether it be kernel exception, pointer exception, or Rust's panic! - these things exist. The reason why you see so many GitHub issues about it is because that's where the development is. Deno is great. Bun is great. These two things can both be great and we don't have to choose sides. Deno has it's use case…
Quote from the CEO of Anthropic in March 2025: "I think we'll be there in three to six months where AI is writing 90% of the code and then in 12 months we may be in a world where AI is writing essentially all of the code"
Bun is such a great runtime. If you haven't tried it, try it. It's got bells and whistles. This will make sure Bun is around for many, many , years to come. Thanks Anthropic. Why Bun? Easy to setup and go. bun run Bells and whistles. (SQL, Router, SPA, JSX, Bundling, Binaries, Streams, Sockets, S3) Typescript Supported. (No need to tsc, bun can transpile for you) Binary builds. (single executables for easy deployment…
Well, until the bubble bursts and Anthropic fizzles out or gets acquired themselves.
Bun is such a great runtime. If you haven't tried it, try it. It's got bells and whistles. This will make sure Bun is around for many, many , years to come. Thanks Anthropic. Why Bun? Easy to setup and go. bun run Bells and whistles. (SQL, Router, SPA, JSX, Bundling, Binaries, Streams, Sockets, S3) Typescript Supported. (No need to tsc, bun can transpile for you) Binary builds. (single executables for easy deployment…
Earlier quoted context omitted.
It just works. Whatever JavaScript/TypeScript file or dependencies I throw at it, it will run it without needing to figure out CJS or ESM, tsconfig, etc. I haven't had that experience with deno (or node)
Same. I had a little library I wrote to wrap indexedDB and deno wouldn't even compile it because it referenced those browser apis. I'm sure it's a simple flag or config file property, or x, or y, or z, but the simple fact is, bun didn't fail to compile. Between that and the discord, I have gotten the distinct impression that deno is for "server javascript" first, rather than just "javascript" first. Which is understa…
As someone who have been using Deno for the last few years, is there anything that Bun does better? Bun seems to use a different runtime (JSC) which is less tested than V8, which makes me assume it might perform worse in real-world tasks (maybe not anymore?). The last time I checked Bun's source code, it was... quite messy and spaghetti-like, plus Zig doesn't really offer many safety features, so it's not that hard t…
Bun is fast, and its worked as a drop in replacement for npm in large legacy projects too.
I only ever encountered one issue, which was pretty dumb, Amazon's CDK has hardcoded references to various package manager's lock files, and Bun wasn't one of them
https://github.com/aws/aws-cdk/issues/31753
This wasn't fixed till the end of 2024 and as you can see, only accidentally merged in but tolerated. It was promptly broken by a bun breaking change
https://github.com/aws/aws-cdk/issues/33464
but don't let Amazon's own incompetency be the confirmation bias you were looking for about using a different package manager in production
you can use SST to deploy cloud resources on AWS and any cloud, and that package works with bun