who's going to buy deno ?
Anthropic acquires Bun
771–780 of 1001 posts
Re: Anthropic acquires Bun
#772Earlier quoted context omitted.
Good question, hard to say, but I think it's mainly because of Zig. At its core Zig is marketed as a competitor to C, not C++/Rust/etc, which makes me think it's harder to write working code that won't leak or crash than in other languages. Zig embraces manual memory management as well.
> At its core Zig is marketed as a competitor to C, not C++/Rust/etc What gives you this impression? I directly created Zig to replace C++. I used C++ before I wrote Zig. I wrote Zig originally in C++. I recently ported Chromaprint from C++ to Zig, with nice performance results. I constantly talk about how batching is superior to RAII. Everyone loves to parrot this "Zig is to C as Rust is to C++" nonsense. It's some…
You have pretty explicitly framed Zig as a C replacement yourself, e.g.: https://www.youtube.com/watch?v=Gv2I7qTux7g
More broadly, I think the observation tends to get repeated because C and Zig share a certain elegance and simplicity (even if C's elegance has dated). C++ is many things, but it's hardly elegant or simple.
I don't think anyone denies that Zig can be a C++ replacement, but that's hardly unusual, so can many other languages (Rust, Swift, etc). What's noteworthy here is that Zig is almost unique in having the potential to be a genuine C replacement. To its (and your) great credit, I might add.
>> At its core Zig is marketed as a competitor to C, not C++/Rust/etc, which makes me think it's harder to write working code that won't leak or crash than in other languages. Zig embraces manual memory management as well.
@GP: This is not a great take. All four languages are oriented around manual memory management. C++ inherits all of the footguns of C, whereas Zig and Rust try to sand off the rough edges.
Manual memory management is and will always remain necessary. The only reason someone writing JS scripts don't need to worry about managing their memory is because someone has already done that work for them.
Re: Anthropic acquires Bun
#773As 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…
At this stage I don't think either is better over the other. Deno has inexplicable high memory usage issues in Linux containers. Bun more or less suffers from the same with an added dose of segfaults.
1. https://github.com/denoland/deno/issues?q=is%3Aissue%20state... 2. https://github.com/oven-sh/bun/issues?q=is%3Aissue%20state%3...
Node.js is a no-brainer for anyone shipping a TS/JS backend. I'd rather deal with poor DX and slightly worse performance than risk fighting runtime related issues on deployment.
Linux needs to be a first class citizen for any runtime/langauge toolchain.
Re: Anthropic acquires Bun
#774Earlier quoted context omitted.
I think Deno's management have been somewhat distracted by their ongoing lawsuits with Oracle over the release of the Javascript trademark. I started out with Deno and when I discovered Bun, I pivoted. Personally I don't need the NodeJS/NPM compatability. Wish there was a Bun-lite which was freed of the backward compatability.
What do you dislike about having node compatibility?
The bloat. I prefer lean designs with plug-in modules for additional functionality. Not only do unused sub-systems take up memory, but they also increase the potential attack surface.
Re: Anthropic acquires Bun
#775Earlier quoted context omitted.
Sure, but I'm more confused about the next.js usage than I am about the bundler. The bundler makes sense.
What effect do you imagine Next.js has on a bunch of code manipulating an HTML canvas? For vanilla code directly using browser APIs it’s basically just a bundler configuration, and while it’s not optimally configured for that use case (and annoying for other reasons) it’s probably better than what someone who has never configured webpack before would get doing it themselves.
Well for one, it ships next.js and react.js bundled in with the code manipulating an HTML canvas.
Re: Anthropic acquires Bun
#776Earlier quoted context omitted.
But like... so can an index.html with a script tag? Am I missing something, where did you read that there was a lot of work involving the header or an attached marketing blog?
My point isn’t that you absolutely need that, just that the negative effect on your game development are pretty minimal if you’re not leaning on the SPA framework for anything related to the game. If your game is going to be embedded into an otherwise normal-ish website, this isn’t a terrible way to go (I’ve done it personally with a game mostly written in Rust and compiled to WASM). You can get gains by splitting yo…
I meant specifically was there something I was missing about the Bun developer's game that required a complicated header and thus next.js.
Re: Anthropic acquires Bun
#777Look Bun is a great product but something hilarious about the company that is “going to replace all software developers with AI” BUYING software. You are building a product that is supposed to make software cost 0 right? Why wouldn’t you just “vibe” code yourself Bun?
Re: Anthropic acquires Bun
#778Earlier quoted context omitted.
JS has the fastest, most robust and widely deployed sandboxing engines (V8, followed closely by JavaScriptCore which is what Bun uses). It also has TypeScript which pairs well with agentic coding loops, and compiles to the aforementioned JavaScript which can run pretty much anywhere.
> It also has TypeScript which pairs well with agentic coding loops, (...) I've heard that TypeScript is pretty rough on agentic coding loops because the idiomatic static type assertion code ends up requiring huge amounts of context to handle in a meaningful way. Is there any truth to it?
I think this is contingent on the skill of the human reviewing the AI's code.
Re: Anthropic acquires Bun
#779Look Bun is a great product but something hilarious about the company that is “going to replace all software developers with AI” BUYING software. You are building a product that is supposed to make software cost 0 right? Why wouldn’t you just “vibe” code yourself Bun?
Those aren't your customers. The people that want to build things with bun are. The problem with people who already know how to code is that they have opinions if they actually read the generated code. If you sell to people who don't (for whatever reason), you face less criticism.
Re: Anthropic acquires Bun
#780Earlier quoted context omitted.
You might want to revise what you consider to be "absolutely zero chance". Bun has an insanely fast startup time, so it definitely can be true for small workloads. A classic example of this was on Bun's website for a while[1] - it was "Running 266 React SSR tests faster than Jest can print its version number". [1]: https://x.com/jarredsumner/status/1542824445810642946
I only claimed there is absolutely zero chance that Bun is twice as fast at executing general JavaScript as Deno. The example doesn't give any insight into the relative speeds of Bun and Deno, as fast as I can tell.
johnfn@mac ~ % time deno eval 'console.log("hello world")'
hello world
deno eval 'console.log("hello world")' 0.04s user 0.02s system 87% cpu 0.074 total
johnfn@mac ~ % time bun -e 'console.log("hello world")'
hello world
bun -e 'console.log("hello world")' 0.01s user 0.00s system 84% cpu 0.013 total