Live data from Hacker News

Bun 1.4

bun.com

91–100 of 198 posts

Re: Bun 1.4

#91

For me, notably absent from the release changelog and accompanying YouTube video they were excited to trumpet in the blog back in July, and the claim (still) this took 11 days. It's August 20th.

Yes, I'm fine with the AI rewrite, just don't claim it was done in 11 days when it actually took ~50.

The rewrite part of get to functionally equivalent to the existing zig version in rust did in fact take 11 days based on the available data. When that was done, they spend some time on a ton of new features and hardening and bugfixing that the Rust rewrite enabled. This took additional time.

Re: Bun 1.4

#92

Absolute crickets from the "there's no way LLM's can rewrite Bun to Rust this quickly, it's going to be buggy, it's marketing" crowd Comments here 3 months ago are quite something: https://news.ycombinator.com/item?id=48132488

The copium has run out it seems

Re: Bun 1.4

#94

Absolute crickets from the "there's no way LLM's can rewrite Bun to Rust this quickly, it's going to be buggy, it's marketing" crowd Comments here 3 months ago are quite something: https://news.ycombinator.com/item?id=48132488

this is currently on the front page of lobsters, I saw it even before I saw the bun 1.4 release announcement https://tipiirai.com/writing/bun-rust-rewrite-worries

Re: Bun 1.4

#95
Bun was pretty cool as a test runner with a lot of promise for back-end services in Node shops, but it burned me with arcane issues in production repeatedly, agents changed the economics of writing software, and being owned by anthropic is the final nail in the coffin.

Re: Bun 1.4

#96
post #23
post #12

Earlier quoted context omitted.

> Why would I want everything reimplemented in this massive binary? Why would Bun be anymore in touch with nuances of all these different technologies then individual projects dedicated to their own speciality? It's funny because the top article on HN is about a malicious rust crate package, and people keep making comparisons to js/npm and how both language suffer from frequent security issues because they have weak…

I saw a post recently about how LLMs are much more effective in Ruby on Rails because it's batteries included, so you don't get so many implementation details crapping up the context window. I assume the same benefit applies to humans as well!

If agents are good at RoR, it's ironic because they're bad at Ruby. They aren't good at holding a model of the 20 different things various code you've loaded has monkey patched, no longer respecting their original contracts.

Re: Bun 1.4

#97
post #62
post #50

Why do these people look and talk so stiff in the video?

Was the idea to put a human face on the automated refactor? Can't say it's especially effective

Bun has been doing release videos for years. There's no drama here to create.

Re: Bun 1.4

#98
post #45

So this is kind of a systemd for web developers. All functionality is absorbed into a vibe coded, un-auditable black box. Maybe run it as process 1 in a future ClaudeOS.

The code is here https://github.com/oven-sh/bun/ go and audit all you want

The author didn’t care to himself, just merging enormous PRs with “lol” tweets about how github doesn’t display all the changes because there are too many.

This is unmaintable mess, and the author himself is struggling already, given how he pushed the release date ten times.

Re: Bun 1.4

#100
post #78

Earlier quoted context omitted.

Its strange how flip floppy the JS ecosystem is, because go back literally 1-3 years or so and the BIGGEST complaint was the lack of a standard library and having to use a package for everything. But now that Bun is actually doing it its somehow bad? Its also still open source, so those implementations you mention need dedicated teams can still get the attention they need by the community if needed. I'm on the side t…

I would guess that many devs' preference would be for a larger standard library, but not a kitchen sink. Personally, I'd be happy with a larger suite of utility functions (say, most of Lodash / es-toolkit - remove the need for left-pad silliness), probably SQLite bindings (having a good persistence layer is great, it's perhaps the most robust and most widely deployed software on the planet), but not YAML (complex, se…

SQLite bindings should absolutely not belong in a JS "standard library". SQLite is a project that most JS environments won't have enbedded.
Post reply on HN