Live data from Hacker News

Claude Code uses Bun written in Rust now

simonwillison.net

671–680 of 920 posts

Re: Claude Code uses Bun written in Rust now

#671
post #323
post #223

Earlier quoted context omitted.

I never knew that running an interactive program in my terminal would absolutely rinse my CPU and battery but that's what Claude, OpenCode and Ghostty have colluded to achieve. Even when the laptop is asleep overnight it's practically melting. I'm sure there was some logical reason for shoehorning web technology into this stack given that we have a good 40 years or so of experience with interactive terminal programs…

The fundamental problem with all Js based apps is how they are very single threaded. With js you get 1 thread at 100% utilization. Power usage and heat scale non-linearly with cpu utilization and 100% utilization on a single threaded js app means you will have ui lag. Other languages like golang would split work across 8 threads and have 8 threads at 20% utilization and this would result in less power usage. Claude C…

> Power usage and heat scale non-linearly with cpu utilization

I don't doubt this, but I would love details and citations here.

Re: Claude Code uses Bun written in Rust now

#673

Bah. Personally my take on the entire affair is quite negative, whatever Jarred or Simonw says about it. I think Bun owned by Anthropic and the entire rewrite with AI is not the real point (even if it's quite interesting, though). My take is that Jarred, and Bun,didn't demonstrate a serious, adult approach, from "this is my branch, you are overreacting" message to just proceeding with a 1mil+ PR merged in less than m…

I don't know, I feel as though Bun went about it much more maturely than zig at any point in the process, from the initial attempted zig compiler commit by the Bun team to the Zig dev team member response to the Bun Rust blog post. Also, I think that fallout over this whole event will definitely favor Bun versus Zig.

Re: Claude Code uses Bun written in Rust now

#674
post #67

The port of Bun, which has >5000 open github issues, is used in Claude Code, which has >11000 open github issues. Do people use Bun in things that are expected to work reliably? Have any such projects tried the upgrade yet?

To be fair, https://github.com/python/cpython has over 5k open github issues, and that's still generally considered fairly reliably technology even if a lot of HN users seem to hate it.

Re: Claude Code uses Bun written in Rust now

#675

Earlier quoted context omitted.

What hypocrisy? Anthropic never said you don't need a human anymore.

I think we are not living in the same universe if you claim this. And I can't speak with someone who doesn't live in the same universe

Show me where Anthropic claims you don't need any humans anymore to build working, production ready software.

Re: Claude Code uses Bun written in Rust now

#676
post #537

Earlier quoted context omitted.

Zig is a DOA language for other reasons though. The reason why Rust enthusiasts act so morally superior is because they are: > Rob Pike, an unsafe guy, may insist that a small language and garbage collection are enough. But the typesafe visionary Grzegorz Wielbodłąński understands the deeper truth: every invalid state permitted by a compiler is a tiny act of civilizational sabotage. https://x.com/typememetics/status/…

The post you linked to seems to jump to conclusions, to say the least. For example: > One probable outcome of an unsafe-language-dominant world is full Andrew communism, which is precisely what Andrew “Smelley” Kelley proposes: abolish ICE and replace the market economy with a globally distributed network of community-maintained allocators. > Rather than a commercial product, software becomes a “public good,” ultimat…

> run by genuinely insane people who think type and memory safety are paramount societal issues

So. Rust evangelists ? :)

But yes, it is wild that people can honestly quote such drivel as evidence of the language and its philosophy being superior.

Each time I try to evaluate Rust, I do so on its own merits. Going online I am rapidly convinced that I don’t want to be in the same room as a large chunk of its userbase. Statements start to sound a bit like that one time I was dragged into a pentecostal meeting.

Re: Claude Code uses Bun written in Rust now

#677
post #667
post #654

Earlier quoted context omitted.

Unsafe Rust doesn't automagically disable typesystem (& borrow checker, but lifetime are a sort of types). Once raw pointer is turned into a T, &T or &mut T, the borrow checker is on.

True, but unsafe let's you conjure up any lifetime you want, or any lifetime necessary to satisfy the lifetime requirements in safe code. If you generously sprinkle pointer dereferences in unsafe code, you effectively disable the protection provided by the borrow checker – including in safe code – until you've checked and verified the correctness of all unsafe blocks.

> True, but unsafe let's you conjure up any lifetime you want

The only thing unsafe does is let you have an unbounded lifetime. As I said, it doesn't check those:

   fn get_str(s: *const String) -> &'a str {
       unsafe { &*s }
   }

https://doc.rust-lang.org/nomicon/unbounded-lifetimes.html

> if you generously sprinkle pointer dereferences in unsafe code, you effectively disable the protection provided by the borrow checker

You don't disable anything. You wrote a "trust me compiler" block, and compiler trusted you.

Rust won't ever protect from all possible problems, just the ones the compiler handles.

Re: Claude Code uses Bun written in Rust now

#678
post #18

Earlier quoted context omitted.

It’s made absolutely no negative difference, as we’ve seen in the real world in the last 60 days since the merge. I feel weird having to defend reality; reality being that it was merged nearly 2 months ago and tons of people have had their pitchforks out without a shred of actual evidence that this made bun worse in any measurable way. But they still insist it was a mistake. I’ve never met Jared or the bun team but I…

> It’s made absolutely no negative difference, as we’ve seen in the real world in the last 60 days since the merge. This is even more interesting given that prewar Bun was not a well respected code base. This matters if the code was bad, were the tests bad / not comprehensive as well? If so, the translation to rust whose sole / primary target was test-passing will have a fair amount of undocumented bugs in it. > post…

Did he say this opinion before the rewrite, or when he was taking tens of thousands of Bun's money per month?

Re: Claude Code uses Bun written in Rust now

#679
post #151

Earlier quoted context omitted.

The original code was one giant unsafe block with almost no tangible way to find or debug all the subtle memory bugs and leaks they had. Now it's smaller, faster and has fewer bugs. Also its every potential memory issue is neatly annotated by an unsafe block so you can go and refactor them out one by one with confidence. All this seems like a pretty huge improvement to me. Why is this an abomination in your eyes?

> The original code was one giant unsafe block True. > has fewer bugs Nope, this is demonstrably false because Rust has its own invariants around its types and the codebase is violating a lot of them. > every potential memory issue is neatly annotated by an unsafe block "Potential memory issue" can originate in unsafe blocks and safe code that are able to alternate the input condition of these unsafe blocks. Guess wh…

For someone who is not a rust dev, would you mind giving me an example of this: "Nope, this is demonstrably false because Rust has its own invariants around its types and the codebase is violating a lot of them."

Re: Claude Code uses Bun written in Rust now

#680

Earlier quoted context omitted.

I think we are not living in the same universe if you claim this. And I can't speak with someone who doesn't live in the same universe

Show me where Anthropic claims you don't need any humans anymore to build working, production ready software.

> The "General Labor Substitute": He rejects the idea that his employment forecasts are "doom marketing". Instead, he asserts that AI will act as a general substitute for human labor, noting that most software engineering could be entirely automated within 1 to 2 years

When someone says all Software engg could be automated within 1yr they don't mean 'oh use our agents and keep human in loop'

They mean 'AI superior than humans fire all humans and all SWEs will be jobless'

I am not going to reply to you going forwards as I can't speak with someone who lives in a different universe

Post reply on HN