Live data from Hacker News

Bun 1.4 Rust rewrite is not looking good?

tipiirai.com

71–80 of 153 posts

Re: Bun 1.4 Rust rewrite is not looking good?

#71
post #11

This reads as another weirdly personal attack against Jarred for slighting a technology stack the author prefers, citing the even weirder personal attack against Jarred written by Andrew Kelley as the sole source to justify their "biggest worry", code quality. Idk why people have become so invested in this.

People _really_ don't want there to be success stories for llms and they will go through all lengths to discredit and disparage folks successfully exploring the space.

Watch this:

People _really_ want there to be success stories for llms and they will go through all lengths to discredit and disparage folks questioning the space.

Re: Bun 1.4 Rust rewrite is not looking good?

#72
post #66

Earlier quoted context omitted.

> What are you talking about? I think GP was pointing out how bun's release cadence stalled and the project is going nowhere at the moment. https://github.com/oven-sh/bun/releases The project was pretty healthy up to 1.13.14, but since may they stopped shipping anything. That's quite odd for a project that just went through a major rewrite and is lauded as being developed primarily by LLM coding assistants. Personall…

I wouldn't consider it particularly surprising that a big rewrite results in no new releases for a bit before the rewritten version is released.

Not surprising, but Jarred has been teasing "tomorrow I swear" for months and Bun keeps missing his own deadlines.

There's clearly something wrong in their confidence about Rust Bun: If it isn't ready they should have said "whenever it's done", and if it is they'd have met some deadline by now. I suspect the speed was supposed to be part of the stunt, yet they seem to have encountered the 90:90 rule.

Re: Bun 1.4 Rust rewrite is not looking good?

#73

Earlier quoted context omitted.

People _really_ don't want there to be success stories for llms and they will go through all lengths to discredit and disparage folks successfully exploring the space.

Watch this: People _really_ want there to be success stories for llms and they will go through all lengths to discredit and disparage folks questioning the space.

[deleted]

Re: Bun 1.4 Rust rewrite is not looking good?

#75
post #48

Earlier quoted context omitted.

I mean, how do you check that your frontend code (possibly not even managed by your team) is calling and needs all of your backend endpoints? I'm sure it can be done, and it probably should, but saying it should always be 0% is not very pragmatic.

Dead code likely means chunks of code not used by other chunks of code, which should be easy to determine statically in most modern languages. Whether an exposed endpoint is being hit (used) or not as an API is more of a test-code-coverage thing, different from the concept of "dead code".

True, but Bun actually has a similar problem. It's creating bindings to a JS runtime. If the JS glue code then no longer uses it, the code is still marked as alive because it's registered with the runtime.

Re: Bun 1.4 Rust rewrite is not looking good?

#76

I think this is a great chance for us to evaluate how capable AI is and at what cost does it deliver such capabilities. I would love to know how much token they spent on the rewrite starting from deciding to rewrite till they actually ship. I assume since the beginning of this whole rewrite saga they have been spending tokens on it every day so the number that Jarred mentioned in his blog post has increased a lot sin…

Jarred wrote a lengthy blog about the rewrite a little while ago and IIRC the token burn numbers were in there (or at least the burn up to that point in time).

https://bun.com/blog/bun-in-rust

Re: Bun 1.4 Rust rewrite is not looking good?

#77
post #4

> The last three months have not looked good for Bun. Apart from pro-AI or anti-AI posturing how have the last few months not looked good for Bun, exactly? I use it daily and I've seen basically zero regressions. I get it, you don't like AI or you like Zig over Rust, or whatever. I just haven't seen any serious argument that Bun has somehow become worse software. > The project has over 5k open pull requests, which is…

Legitimately curious, are you using the 1.4 canary release in a production environment?

Re: Bun 1.4 Rust rewrite is not looking good?

#78

I'm still waiting for someone to bring forth some reproducible stats and state something along the lines of "I did a comparison of Bun 1.3 vs 1.4, and found these user-affecting issues in the latter which are not in the former".

Is it a paid job?

can I do it with AI?

Re: Bun 1.4 Rust rewrite is not looking good?

#79
post #4

> The last three months have not looked good for Bun. Apart from pro-AI or anti-AI posturing how have the last few months not looked good for Bun, exactly? I use it daily and I've seen basically zero regressions. I get it, you don't like AI or you like Zig over Rust, or whatever. I just haven't seen any serious argument that Bun has somehow become worse software. > The project has over 5k open pull requests, which is…

> Apart from pro-AI or anti-AI posturing how have the last few months not looked good for Bun, exactly? The blog post states quite clearly that Bun stopped posting any release. During the Zig/pre-Rust days, Bun was posting s new release each 2-3 weeks. Since then, Bun's Rust migration is correlated with a complete stop of Bun's release cadence.

that could just be de rigeur enshittification.

Re: Bun 1.4 Rust rewrite is not looking good?

#80

Bun has been nothing but amazing wins for me, and I really like what it enabled me to do. Two examples: - I have a couple of projects that handle images. I was including Sharp, but since these are side projects in a small VM, often a redeploy that recompiled Sharp just crashed the full VM (out of memory). Bun includes Bun.Image[1] natively, which is built around Sharp's API, so swapping Sharp out was very easy, and n…

[deleted]
Post reply on HN