pdimitar

As a guy who was a part of projects with an infinitely growing backlog (multiple times), I can tell you for certain that _not_ periodically addressing parts of your backlog absolutely will stop you from making more money; even lose you some due to customer churn.

Popular view to dunk on meaningless perfectionists, sure, but your comment conveniently does not address "let's have this architecture because we know these new requirements are coming and we know we can't accommodate them with the current one".

Arguing extremes is easy.

My only half-decent guess: they deem it too big and risky and believe they'll lose revenue while working on it and ironing out remaining kinks.

Claude Code is likely not well-specified and it's a product of rapid iteration and now nobody really knows how the whole thing works. LLMs don't do well when requirements are muddy.

I hear you on the worry, I have the same (and probably so do most devs even).

But IMO the endless churning of code will slow down, if it has not already. Quantity does not equal quality as we know, it even erodes it. There are already consulting companies that are "vibe-code fixers".

I am also not sure it's about "elegant" code. What we might call elegant has multiple measurable axii f.ex. well-isolated effectful code layer so you can easily static-code-check it, domains and enforcement of boundaries between them, bespoke linting to enforce business processes and standing code discipline, and many others.

CEOs love to promise the sky and the stars. Color me unimpressed.

Now whether they can do it -- that's a separate, and a much more interesting, discussion.

Even worse: it's much safer to assume you'll hire the wrong humans, most of the time.

I didn't claim that the cost is the prohibiting factor at all. Obviously they gave Jarred free Fable access and to do as his pleases. The cost was an FYI tidbit and nothing more.

What I argued was that you seemed to have been arguing an extreme point i.e. LLMs can one-shot stuff in any PL and that it does not matter in what PL they'd rewrite Bun.

If I misunderstood -- my apologies.

True on the premise, remains to be seen if that's what's going to happen in practice.

In my work I have Fable/Opus add bespoke linters and tie them to verify/precommit tasks (including in CI) so nothing of the reworks and 15+ initiatives we have in flight ever regresses.

Some discipline will remove that worry of yours. It's not nice to immediately assume that the rewrite's orchestrator (Jarred) did not use discipline. He even outlined a few false starts.

Good question. I'd guess they didn't want community split?

Maybe it's one of the cases when techies call the shots?

I can understand people being more sold on Rust compared to Zig -- there are legitimate differences on the memory safety front and I can see how people will prefer one or the other.

Plus I believe Jarred (Bun's main dev) went out of his way to explain why he chose Rust over Zig in his blog post.

Of course the marketing angle might indeed be the explanation; not arguing against that, I simply followed with interest and Jarred seemed very reasonable to me.

It's really not about a PL runtime vs. an agent harness, it's about how spaghetti and complex the code is. I do get your point though.

I know what Fable did for just 5x6h sessions, singular agent, for my professional work.

Jarred used many agents and they worked 24/7. It tracks for me.

So yes, I do believe it. What makes you skeptical?

I don't work for them and I don't know their priorities. I can only speculate they're not okay with it but no idea why exactly.

Yep, same thought. And it seems Anthropic agrees.

As much as an enthusiast dev like myself hates it -- this is innately true, way too often.

I am 46 y/o and still excited to code and solve problems with code and I still have trouble to admit to myself sometimes that people make dozens of millions with PHP and the tech hardly matters when you can throw bodies at the problem (and when that throwing of bodies at the problem actually solves it, of course).

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.

This is a spectrum, it's not just 0% vs 100%. Even Fable frakked up a few things really badly in my professional work (though to its credit after a very detailed 2h chat it self-corrected and fixed all the blunders).

I would also challenge "fast" -- Fable (and I assume Mythos) are wicked fast and efficient and even they can't compensate for f.ex. slow recompilations or test suite reruns or security scans, linters etc.

Reminder that the Bun's Zig-to-Rust rewrite took 11 days with dozens of agents working 24/7 and the author put the cost they'd pay (if they had to pay) at about $168k.

I just don’t see how one can say that building things reliably good is easy now when the company providing these tools can’t even do it well.

I don't know how you can't see it, to me it's blindingly obvious: risk aversion.

Let's say the risk for a problem is 1%; hell, let's put it at 0.1% even. For a company at this scale even that amount of risk is too much.

I trust Opus/Fable to drive prod database migrations and backfills. I don't trust it with our financial ledger. I trust it with part of the infra. I don't trust it with backups. Etc.

You and others are arguing against a premise that nobody defended, namely "Claude can rewrite everything, for free and with zero mistakes". A bit of a straw man, don't you think?

And that's not even touching the fact that writing a GUI app is difficult for LLMs due to difficulties in it getting feedback and a "feel" whether it delivered what was asked (though I know people are working on it).

I think I am willing to take it as an axiom that a native version of CC would be superior from a user perspective. Performance, etc.

How does that follow, and from where? I never once noticed any visual jank/lag in the TUI; not in iTerm2, not in Kitty, not in Alacritty, not in WezTerm and not in Ghostty. And even if we exclude those two, me and many other devs are quite fine with a TUI and don't miss a GUI program for everyday coding.

Not saying that our preference is superior -- but it'd be strange to blatantly claim: "for dev purposes, GUI > TUI/CLI".

Definitely. Sadly "capital that is not looking to maximize returns" is a very tall order in the last 20+ years.

And who might that be, I wonder? The company that seems more worried about executive bonuses than to adhere to its mission, for at least a decade now? Perhaps a certain one whose name starts with M and ends with ozilla?

Purely random thought, of course.

Yep, and I came to HN to make sure. Happened literally less than 20 minutes ago.

SQLite creators explicitly warn against using SQLite on a networked file system btw.

I don't disagree. I can only assume it's defaulted to off due to many people working on big codebases and there constantly evicting cache would objectively slow them down. But, far from ideal for everyone else.

OP said here that their team was familiar with Python and not with Rust.

It's as simple as that.

I replied that a frontier LLM can both write code in Rust _and_ educate you. And got down voted.

Don't forget cross-compilation and a single binary. Not small advantages in _many_ scenarios.

You are reaching quite a bit, and misrepresenting too.

But it's actually as simple as: Jarred's post was mature and didn't throw shade; Andrew's threw quite a bit of it while insisting it did not.

I and many others don't want to be slandered or trash-talked if we moved away from a language we previously chose. That can and has had actual business impact on projects / companies in the past. So naturally, people will judge you if you cannot be mature when responding to an event that made some splash in the ecosystem.

To comment separately: lack of familiarity is true of course but do consider your bias -- familiarity should come quickly and easily. Long gone are my days where I wanted to wear badges of honor and suffer through difficult tooling, and I am willing to bet that's true for a lot of programmers.

We want to iterate and progress. You likely are used to Haskell's tooling quirks long time ago. Everyone else outside of the ecosystem does not have that advantage.

Super curious then, and I stand corrected.

You can put the `cargo clean gc` command on a daily/weekly schedule then, or configure the `gc` option in your Cargo config. Or set `CARGO_UNSTABLE_GC=true` in your shell init. Or all of the above.

IMO from the info given in the OP it seems to me that they never actually needed Haskell, not playing to its strengths anyway, especially if they felt Python was an adequate replacement -- which it absolutely is not if you value the compile-time finding of bugs, better known as "a strong static typing system". But that's a separate discussion vector.

I don't think it has almost anything to do with vibe-coding. When I tried Haskell and OCaml some 3 years ago, they were infuriating in terms of tooling and just needless friction (don't ask, forgot, but it was mostly around package management and just entering a project and be able to run the program was a saga).

Iteration speed is not only to appease business people. As a long-time dev I prefer for my PL and its tooling to not stand in my way. I want to be enabled, not be left a scarred veteran with badges of honor like "Managed to install 5 dependencies and compile and run! And it only took me 3 hours!" or some such.

Compare to Golang, Rust, Elixir, and no small amount of others -- you add a dependency, run a command, twiddle your thumbs 30 seconds, done.

I want to solve problems. Not troubleshoot tooling that should have been prod-ready 10 years ago.

Using a frontier model you can combine it writing high-quality Rust and educate you in the process. You guys were too scared, needlessly.

But as others said: if Haskell was not giving you too much in terms of excellent typing system then maybe going for a PL with a much faster compiler like Golang would have been best for you.