Hacker News

Grouped and arena allocations work really well in Zig. For awhile, we tried to use this pattern almost everywhere in Bun but it gets really tricky when there’s some GC-managed memory and you want to free things incrementally to reduce RSS. Also, using arenas for arrays that grow wastes memory a lot since it keeps every previous version around (mimalloc arenas are slightly better for this)

Grouped allocations works especially well in parsers & ASTs where the lifetime is very bounded. Since the Rust rewrite, we still use arenas for Bun’s parsers and the bundler but not a ton elsewhere.

> You can just do that, and then Zig is really no less robust than Rust.

If you just don't write bugs, then yes all languages are equally robust, including assembly.

Zig, like C, is simply not a robust language. I don't know why this feels like something contentious? It's clearly not intended to be robust?

> You can just do that, and then Zig is really no less robust than Rust.

That's just it, using Zig required more rigorous engineering than the Bun team were capable of.

I think the main issue is that Bun relies heavily on existing C++ libraries like JavascriptCore, and these require RAII and ref-counting semantics from C++ that are closer to Rust than Zig.

You could write a JS engine with Zig-like idioms (arena allocation, static initialization), but that would require re-writing the whole JS engine from the ground-up (though I would definitely be interested in it if someone actually tries to do it!)

This reads like cope because you're re-inventing RAII from first principles.

I cannot take this seriously as tutorials on robust Zig Allocation Pools will store a deinit method for each item within the pool, so when the pool deinits, all internal objects can be deinit'd.

That is just RAII & dtors from first principles, except with extra overhead of manually storing fat pointers yourself (and the bugs that come with this). Instead of using a language with builtin guarantees & optimizations around handling this so your object pools don't need to carry around a bunch of function pointers. C++ has aggressive de-virtualization passes so at runtime a lot of the 'complex object hierarchies' can be flattened to purely static function calls.

You're getting confused between lifetimes (the static analysis that prevents use after free and similar errors) and lifecycles (more commonly discussed under the heading of ownership) which determines when objects (and thus memory) are allocated and deallocated.

Ownership is automatic. You don't have to explicitly drop things when they go out of scope. (although the responsibility for that is split between the compiler and the library code).

Lifetimes are not automatic, but also have no effect on memory allocation. They are purely a static analysis path and you can make a functioning rust compiler that completely ignores lifetimes.

It’s my understanding that bun was ported to unsafe rust, so even these gains would require additional effort on the team’s part, right?

You don't need to rehash the same old argument. Runtime memory management is forgiving but also inferior in a lot of ways to compiled stuff that works with memory deterministically.

Garbage collection is a method to make programming easier, not to make the resulting program better.

As opposed to every commit abd line of code being unsafe? They use a lot of C/C++ libraries with their own code so unsafe isn't even a a problem in most places they use it.

You think it’ll all stay there?

Of course they’ll iterate and remove the unsafe bits which were necessary for the transition

Fun fact, unsafe does not let you turn off the borrow checker in Rust: https://steveklabnik.com/writing/you-can-t-turn-off-the-borr...

Relevant passage from Jarred's post:

"At the time of writing, about 4% of Bun's Rust code sits inside an unsafe block (~13,000 unsafe keywords across ~27,000 lines / ~780,000 lines), and 78% of those blocks are a single line — a pointer that came from C++, or one call into a C library. I expect this number to go down over time as we refactor from a faithful Zig port (which had no greppable unsafe keyword) to idiomatic Rust, but we are going to continue using C & C++ libraries like JavaScriptCore so it will always have more unsafe than pure Rust projects."

what is surprising about it? The way porting works has alway been first doing a faithful pass before going back to address impedance mismatches case by case. You would do that even when porting things manually, let alone in a super risky completely automated bulk migration.

Mario Zechner's talk "Building Pi in a World of Slop" is a good listen, on the topic of adults in a "world of slop". https://www.youtube.com/watch?v=RjfbvDXpFls

The wig-vs-grok periodic cycle.

The lowest of the bars

It's a weird way to frame the event. Yeah, Andrew (Zig)'s responses were astonishingly immature, but it doesn't matter. Even if Andrew literally ate baby seals for breakfast and kicked puppies as a hobby, it wouldn't make Bun look better. You'd notice that the parent comment didn't even mention zig at all.

This is the correct approach (I dare to say the only correct approach) when porting to another language. You can examining the architecture later.

Indeed as much I dislike the approach Bun took, at least the port appears to be working. TS7 is going to cause problems for downstream users because Go is the wrong language to use for something that has to run in WASM.

Yes, they probably don't know C ABI.

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 don’t understand all the personal attacks, I just feel the need to correct the facts. Literally who cares what language a JS toolset is written in?

It’s not like they ported JavaScriptCore (the actual JS runtime) to rust even. All that stuff is largely untouched.

Rust as a language is irrelevant to this discussion, the problem is that bun was vibe coded by a single dude without any open source community involvement. “bun the open source project” is basically dead at that point: don't expect any of the zig enthusiasts who had their code being forcibly rewritten in a language they don't like to follow Jared.

“bun the JavaScript runtime ” is not dead though.

I am impartial on the matter, but I think one of the reasons Bun became a thing in the first place was because of Zig attracted a small but very active developer community. Switching from Zig to Rust effectively alienates that community.

Emphasis on the FOSS project. The v1.4 mentioned is not (yet?) open source, Claude Code is essentially using a proprietary fork, was GP's point.

Bun is now mainly the runtime for claude code. All changes will go in to make claude code better.

It's not about making the dev experience better than node, that use-case is now secondary.

The objection isn’t to the language. It’s to Claude using a version of Bun that is not available to us. We don’t know what’s actually in it.

Yeah same, according to one of the Zig team members, the original source code wasn't all that anyway.

But this is HN, a subsection of which places a high importance on what language something is written in, moreso than what it does (feels like).

Definitely, it was a possible reason why Zig actually matters in the industry.

Now it is a Deno clone, both without anything enticing over node.js.

As an open source - community driven project? Have you looked at the repo on github?

Theres thousands of PRs from claude agents or whatever.

Yeah really feels like a worthwhile place to contribute lol.

I didn't read OP as complaining about the rewrite, but about the (lack of clear) governance after being acquired by Anthropic.

My personal feelings about the matter is that having an LLM rewrite the entire thing as an experiment and then just going with it a few weeks later kills any incentive for a community to build up around it. It's a clear signal that every basic aspect of the runtime can change on a whim.

I don't care about meh Zig being rewritten to bad Rust if it does the same thing, but taking what is presented as" look at this funny experiment I did" and then taking that into production with barely any announcement is what kills off the interest to me.

Bun has been a great ad for whatever LLM they were using but the cool factor is gone now, and that's really what set it apart from basic NodeJS in my mind.

> Why does changing to Rust kill the project? I don't understand the point here.

I'm concerned that the complete rewrite in an entirely different language is not a sound technical decision and instead is a ploy to shed copyright claims from past contributors.

Now, based on comments from this thread, the formerly FLOSS project is somehow granting special access to a corporation that apparently is invested in going way out of their way to push implementations that consume the complete rewrite before the world has access to it.

I for one won't be touching Bun. This doesn't pass the smell test. It feels like a bait-and-switch in progress.

I don't care about the language, but pre-releases the community don't get access to but released (Anthropic) applications do have access to, feels a bit too on the nose after the acquisition.

> The PR is public

I'm talking about the 1.4.0 release:

> Claude supports them shipping a preview of a not-yet-released Bun version

Maybe Bun/Anthropic fixed this after Simon's initial release of the blog post, but seemingly when we both looked, it wasn't public.

> they did put the bun 1.4.0 version bump in the changelogs for claude code a while ago, over a month almost.

Where? Is see no CHANGELOG in the root. I do see LATEST, last modified 2 months ago, and it says 1.3.14

>It largely works and it's a massive business success. This is the classic engineer asking the 'why this technology?' to what amounts to a business question.

Your counter argument would be valid for a 2000 or a 2020 business decision about some tech stack.

But the whole point of their product is that it supposedly nullifies such "business" concerns around the use of technology, by making it cheap and fast to build whatever you like automatically.

That they wont, or worse, couldn't, speaks against that.

I have been working all day every day in Claude. I loathe their bug-ridden UI. Every release is a new crop of bugs, sometimes the old ones get fixed, usually not.

Any kind of scrolling back, copying text, using their menu system - basically anything that isn’t typing characters has had/still has unaddressed bugs.

OpenAI shipped a competitive model and I’m over in Codex now. I have yet to hit a bug.

If you’re holding the SOTA crown, people will put up with your buggy mess. As soon as that crown slips your pile of trash becomes a huge liability.

They succeeded in spite of their tech choices. Their model outshone it, which is an extremely rare thing to happen and not something they could've counted on. In any other timeline they could've/would've been hurt by their choices.

It's like "why did you go all in on buying scamcoin 3.0 as your investment strategy?" -- "I 5xed my money! End of story! It was fine!"

Massive business success? I don't know the financials since they're not published, but google says the acquisition cost low hundreds of millions. So they could throw away the code and rewrite it.

The criticism didn't appear to me to be that the solution didn't work, just that many of the working solutions we are selecting are dangerously overcomplicated due to shortsighted decisionmaking. The benefits of throwing redundant stacks of abstraction atop each other in terms of time to market are questionable, and obviously absent in every other metric.

This reply makes no sense in this context, though. Sure, it exploded in popularity based on whatever random tech choices were made. But now, when apparently they're deciding there's a problem there, why unleash $150k of tokens to rewrite a JS runtime wrapper from Zig to a million lines of rust, rather than simply rewrite Claude Code itself to rust?

This is the “eating yogurt with a hammer” argument. Yes, of course you can do that. Yes, the yogurt gets eaten. It’s just… you see someone eating yogurt with a hammer and it’s hard not to wonder wtf is going on.

Claude code still can’t handle scrolling history without corruption. It is embarrassingly broken.

> It largely works and it's a massive business success.

The engineer is suggesting that it could be done cheaper and maybe with better outcome. Ironically, this is a classic business case.

> “It largely works”

A ringing endorsement!

This is a confusing comment because it’s the exact argument you would present against rewriting Bun to Zig, but you are arguing for one and against the other.

> It largely works and it's a massive business success.

You can make anything work when you have enough money to buy and radically change the entire runtime you’re relying on.

One must suspect that if they did not have insane amounts of money to burn, they could have tried other approaches to fixing the problems. Maybe engineering, perhaps.

As an industry we are responsible for making our part good. So yes a business can succeed in spite of bad tech choices, but that doesn’t make it good tech.

Any choice would have made obscene money in this market. It doesn’t make it a good choice.

It doesn’t work, it performs horribly and is full of bugs. Serious people use open harnesses.

For a company that solved coding and doesn't need any software engineers… why spend money to acquire a runtime rather than ask claude to rewrite it in assembly directly and be done with it?

Could it be that they aren't being entirely honest?

> It largely works and it's a massive business success.

I'd argue these tech companies got popular because they have good models, nothing else.

Even OpenAI took two years to fix basic chat scrolling.

This is far less so in this case because this is thier hot path. Everything runs through it and tens of billions in revenue depends on it. It needs to be as fast and solid as possible

This is a useless post-hoc rationalization. "It worked out, so it doesn't matter". You're trying to galaxy brain yourself into ignoring the obvious conclusion.

The point is that if you were starting a new TUI LLM harness today, you would basically use CC's architectural decisions as a guide for what not to do.

So Claude isn't great for everything?!?

No, it's because they wanted a unified pipeline in claude code, claude app, and their website. All of them use more or less the same claude features (claude code has artifacts, claude website has "Ask User a Question" tool, etc.).

Much less fragmented compared to "write the app 3 times in 3 different languages".

I think it makes sense that when you've outlawed competition for many/most users of your product's matching service that you would cheap out on it if you were maximally extractive and took no pride in your work, sure.

But the "coding is mostly solved" narrative kinda doesn't match right? If good, correct, high-performance software is like, free now? Wouldn't you want it to be slick as hell, really reliable, all that? Even a little breakage costs a lot of money at that scale and pricing, it would be better than a wash if you put the magic code thing on the case.

"Claude. Do all employee work. Make no mistake. Notify in slack when revenue is double."

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 Code would have been better off performance wise being an electron app because it would be offloading rendering to the browser and gpu.

Also, the architecture of Open Code is actually a lot better here than Claude Code. ClaudeCode does everything, including rendering in a single thread and it's all in js. OpenCode has a zig based tui renderer it offloads that work onto.

But I will also say these coding agent tuis do get unfairly maligned because they launch subprocesses and those subprocesses tend to be expensive. If you are using Rust analyzer with claude code, it's rust analyzer that's causing the majority of your problems.

Why are you implicating ghostty? Have you compared its CPU usage to any other terminal?

> Even when the laptop is asleep overnight it's practically melting.

Then something is waking it up and it's not asleep at all. Asleep the CPU shouldn't be running.

yep, developers from 10 or even 5 years ago would have considered it a hilarious joke

Its so wasteful, but that tracks with the modus operandi of AI companies.

That blog post doesn’t make sense to me at all. The author is going from full modern Haskell (since he mentioned Servant and Beam, you could tell almost every file uses dozens of GHC extensions beyond what Haskell2010 gives you) to Python with dynamic types. He could instead rewrite the Haskell to use less modern type system features and get so much faster compilation speed.

Also GHC has an interpreter. It powers the REPL. No need to compile everything if you’re just experimenting. I do find that in the Haskell world the REPL is criminally underused compared to Python.

And the rest of your comment doesn’t make sense; this shop is rewriting their infra (not UI) from Haskell to Python.

Python was faster to iterate on than Haskell even before LLMs

Because I’ve been told that Fable can do anything :-)

My question is moreso “why was it ever JS in the first place”

& the cost of a native rewrite would be cheaper than acquiring Bun no matter how you shake it

I'm doubtful that it has fewer lines of code, but even so, it is almost certainly less tricky and simpler code. You could also rewrite it in a higher level and more forgiving language than Rust (e.g. Go) and get huge improvements. The improvements would probably be much bigger than the improvements they have achieved at the JavaScript runtime level.

I don't think people are saying it's easier, they're saying the results would be better.

this. /s

Codex appears to be a mildly complex, somewhat-but-not-outrageously-sloppy Rust program (yes, I’ve poked around at its source — thank you OpenAI for making it more or less open source). It has lots of features, mostly related all the fancy web features of Codex.

Claude Code seems to be an insanely complex program will all manner of cutesy features and telemetry features. The net result is approximately the same as Codex, but it’s pretty common in software engineering to find a simple thing and a complex thing that do more or less the same thing.

Code verbosity and complexity still matter with LLM coding

I feel like a year ago JavaScript and Python were the best languages for coding agents to use because of their heavier presence in the training data, but I'm not sure that's true any more now.

The latest frontier models are competent at Rust and Swift and all manner of other less widely used languages.

The more important factor is how good they language's compiler is at kicking out actionable error messages, since one-shot code generation isn't as important once you have a coding agent loop.

At a guess it's because Boris literally wrote a book on TypeScript: https://www.oreilly.com/library/view/programming-typescript/...

> I thought you need to clean and full redraw if anything changs anyways?

Unless you use an ancient teletype, you don't have to redraw everything. That would make any interactive applications way too slow/flickery.

You can move the cursor arbitrarily in the terminal and start overwriting characters from there. So you need to track state to know what is "dirty" and needs refreshing. Occasionally you issue a full redraw to catch missed artifacts left behind or when the terminal is resized (SIGWINCH).

You can do damage tracking for TUIs. Printing to the terminal is done by moving the cursor and redrawing the line the cursor is on.

Ncurses is how people used to do it.

The component trees have to be rewritten, only the non-view related JS code can be reused.

To the man with a hammer…

I thought maintenance was free with LLMs???

I think they bought Bun because it was a supply chain risk for them.

Their new flagship product (earning them billions of dollars in revenue per month) was dependent on a platform maintained by a tiny startup.

Buying Bun was a very rational way to reduce that risk, epically since it also got them some top tier engineering talent.

Thinking about that further, I wonder if that was part of the rationale for switching from Zig to Rust that they haven't talked about?

Zig is a much riskier bet for your multi-billion dollar cash cow than Rust is.

But saying that out loud would be rude - they took steps to NOT openly criticize Zig, even after Zig's founder did not show them the same courtesy.

If you are relying on live updates to change state in a dynamic language then you are not doing it "surgically", unless there is some other definition that means hitting it softly with a large rock.

There are several compiled languages with live reloading, including C++.

There's no surgery when you're a company with a trillion dollar hammer and every problem looks like a big ass nail.

Well, yeah, it's just good marketing and Bun ultimately doesn't matter anyway, not to the wider ecosystem and especially not to Anthropic. The only purpose Bun had for Anthropic was as a way of getting attention, so that's what they used it for.

So they had to rewrite Bun instead of Claud Code because they “already had bought Bun.”

This thread is filled with non-sequiturs.

People widely report very high memory and CPU usage.

Not all of the memory usage is the fault of Bun/JS. Some of it is likely memory leaks (holding on to data it shouldn't). However, some of the blame does go to using JS. In Rust you can tightly pack your data if you want to, but in JS you can't have nested structs for example. Every object referencing another object is two separate chunks of memory, each with a header, and a pointer from one object to the other. GCs also use more memory. The overhead adds up.

Building a CLI program in JS is a bad choice, and nobody should be defending this decision. Especially since Claude Code is very much able to write Rust code, and they've shown it can port code. Just port Claude Code to Rust directly.

Why is ecosystem of tools and plugins a bottle neck when they literally own Claude models and as per their boss, code is so cheap that anything us just an English sentence away?

it does seem to be very much bottlenecked by performance, yes. very slow to start up, for example.

It's not even about requirements. It's about responsibility. Someone has to take responsibility for the code and the product. Someone has to hotfix a bug that's costing millions of dollars an hour and someone has to be blamed for a bug that's consting millions of dollars an hour.

That's why it matters for people to hold the control of the tech, not companies, as I've already mentioned quite clearly.

LLM is here to stay, keep denying the fact won't work. What does is to make the tech so abundant, it flushes the bad actors, such as for-profit AIs, completely out. It's either this, or get crushed by for-profit AIs, pick one.

It's a "democracy", in which some people (Anthropic and co., and anyone willing to suck up to them) are more equal than others...

It definitely worked as a marketing stunt for sure

Perhaps. The thing I was trying to highlight more is comments (particularly disapproving ones) about the intersection of JavaScript (especially React, apparently), TUIs, and LLMs.

I just thought it was interesting. I'm a fan of TUIs, both positive and negative about JavaScript (the modern language is quite nice, given you avoid the historical warts, in my opinion - the ecosystem is unfortunate), and I think the best description for how I feel about LLMs is that I'm bearish. Also Simon is a fantastically prolific and intelligent person though, even though LLMs are not my cup of tea.

https://news.ycombinator.com/item?id=48960912 is a recent comment by someone I also respect related to how LLMs recreate human-like content (Widgets, really), making actual human-created content feel fake.

Sometimes it sure does feel like ELIZA is the main news source these days.

I have ~24 years of experience coding and the LAST thing I think about when opening claude code is "why is this written in react".

Tell you what I sometimes think about though: The fact it has clickable links and complex formatting rules for markdown, the most interactive and highest-quality clickable interface I've ever seen in a terminal, and somehow manages to work. That actually blows my mind.

THEN, I'm reminded that it's written in React, and I think "Huh, guess that does make it a ton easier than using ncurses or something."

And done.

> but in terms of stability it's terrible and segfaults 20x as much as node (I base that number on newrelic telemetry)

In Chrome or Firefox, a segfault is usually automatic CVE and in most cases a bounty of thousands of dollars…

I just had this happen today. It was indeed a segfault.

From what I could tell it looked like it was in JS code that had been JIT compiled. I haven't attempted to troubleshoot further beyond setting all my future Claude Code instances to pipe their stderr to disk so that I don't lose the stack trace next time.

But if the segfaults are new that implies it’s from the LLM no?

> Seems to be working just fine though?

As with all transpile ports, the true test will be how well it can be extended and maintained over time. Historically working with the output of a transpile is not pleasant and requires heavy rework to get it to the point where you can be comfortable enough to extend it.

The existing community is now either going to need to learn Rust or new Rust developers are going to have to join the project and they may not invested enough to refactor the transpiled output when they could work on something else like Boa.

> next step is to make it idiomatic rust

You can tell what will happen when they release it before sorting out all the new bugs introduced by the not-exactly-line-by-line port.

I don't think AI or humans are trained well on it.

No, but the project does not meet its goals around memory safety. It is usage Rust all the way down with same memory safety issues.

If it's not idiomatic, the memory safety won't be guaranteed.

This comment inspired me to take a look at the trend of "unsafe" in the Bun code over time since the rewrite PR first landed - here are the commits where that number changed by at least 10:

  2026-05-14 23427db 13907
  2026-05-14 19d8ade 13861
  2026-05-15 4d443e5 13840
  2026-05-17 172afa5 13803
  2026-05-17 80a06a8 13849
  2026-05-18 fba43af 14026
  2026-05-19 303cd28 14052
  2026-05-20 21db682 14243
  2026-05-22 a06a00a 14239
  2026-05-23 49c97de 14090
  2026-05-28 472a06a 14076
  2026-06-01 a0d1472 14071
  2026-06-04 8553428 14032
  2026-06-09 717542f 14053
  2026-06-10 1c90e5a 14043
  2026-06-11 6e91d24 14031
  2026-06-16 bd8edc7 14086
  2026-06-17 6ef5977 14104
  2026-06-20 315ed50 14106
  2026-06-22 c6be834 14120
  2026-06-23 ea7e44f 14108
  2026-06-23 03042ab 14128
  2026-06-29 86d32c8 14046
  2026-07-01 6640fcf 14077
  2026-07-04 51074e3 14099
  2026-07-06 9d0e93d 14186
  2026-07-08 ab6eb2d 13953
  2026-07-09 86caf6e 13936
  2026-07-10 91675d0 13930
  2026-07-13 73b6c14 13951
  2026-07-16 4bbe075 13978
  2026-07-16 57e30a5 13995

ChatGPT written script for counting here: https://gist.github.com/simonw/b1015bcadcedd1a781cedb7af9cbb...

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?

Same observation. One thing you can do is close out the session and `claude --resume`

Does exiting following by resuming the session fix it?

It's not a great way of inferring software quality, but I think the numbers for both Bun and Claude Code are pretty bad.

cpython has ~7,000 open issues, but ~70,000 closed ones, a 1:10 ratio. Bun's ratio is above 1:2.5, while for Claude Code it's slightly over 1:6.

Much more importantly, though, Bun's oldest issue is from Sep 2021, while Claude Code's is Feb 2025. cpython's oldest issue dates from June 2000 (presumably migrated from an older tracker). Claude Code has very nearly the same total number of issues (open + closed) as cpython at around 77,000, but Claude Code has done it in a year an a half whereas cpython has taken 26 years to get there.

It's a good comparison to pick, as it can't be explained by popularity. For all the real-world use Claude Code sees, it's nowhere near what cpython sees, even over the year and a half in question. Bun, meanwhile, is hitting these numbers while not even being the mainstream choice for what it does (node still holds that crown afaik).

Did Bun mass-close issues that predated the rewrite? It doesn't look like they did, as the oldest open issue is from 2021 and there are many from 2022, but maybe they did something that killed most of the old issues.

The motivation is obviously clear. No-one would be doing that for fun 24/7, only covering about AI and nothing else without getting paid for it.

If anyone else did that on HN, they would be accused of slop with their domain blacklisted.

I've not made any money at all from Anthropic.

You can see my list of previous weekly blog sponsors here: https://simonwillison.net/dashboard/sponsor-history/

None of them get any influence on my content. That would hurt my credibility, and my credibility is the reason my site is worth sponsoring in the first place.

Honestly, if OpenAI or Anthropic offered to sponsor I'd probably turn them down. The optics of taking sponsorship from companies that I frequently write about are not great.

Faster package manager

Faster startup

Typescript support out of the box

Better stdlib than node

Stdlib includes yaml, sqlite etc so you need to pull in fewer deps, so you can avoid the left-pad/is-even node_modules explosion problem to a greater extent

I don’t think you would use Bun for front end.

So much of JS dev is just saying no to random new stuff, Bun included

i assume it's because of all the built in tooling that node doesn't ship with.

but it's written in Rust too /s

> The rewrite was only possible because they mostly stick to 1-to-1 translation resulting in non-idiomatic Rust code.

That’s patently false, just read Jarred’s own blog post describing how that was the first stage only, they went through many more to get the amount of non idiomatic, unsafe Rust code to an acceptable level.

Isn't it just: "while true {refactorIdiomatically(); fixErrors()}"

That's like saying let's stay with horses.

We'll develop faster and better tech. We'll find resources to feed that. Use that to build better. Access better resources. We'll mine asteroids. We'll harness much more from the sun. The factory must grow.

Claude installer/updater had a high memory usage problem (Gigabytes of resident memory used during a fresh installation of Clade with it's native install.sh script, or during a claude update). This was reported as early as December 2025, see https://github.com/anthropics/claude-code/issues/12327#issue....

The latest Claude installer (2.1.215) possibly does not have it anymore https://github.com/anthropics/claude-code/issues/4953#issuec..., but more tries on various machines are needed to confirm that.