Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Bun 1.4 Rust rewrite is not looking good?

tipiirai.com

Post reply on HN
Print view View original

121–130 of 153 posts

Re: Bun 1.4 Rust rewrite is not looking good?

#121

Post by namblooc »

dgellow wrote: post #109
namblooc wrote: post #105

Earlier quoted context omitted.

Robert Sapolsky would disagree

I would assume Sapolsky understands how terms are defined by their context, and that someone saying “free will” in a forum discussion about software doesn’t literally imply the strictest, academic definition of the term. But if not he can reach out

I'm curious as to what other definitions of the term exist, other than the academic one? I had never though of using the term in any other context. But maybe that's because I've been concerning myself with this specific topic for too long.

Re: Bun 1.4 Rust rewrite is not looking good?

#122

Post by dgellow »

namblooc wrote: post #121
dgellow wrote: post #109

Earlier quoted context omitted.

I would assume Sapolsky understands how terms are defined by their context, and that someone saying “free will” in a forum discussion about software doesn’t literally imply the strictest, academic definition of the term. But if not he can reach out

I'm curious as to what other definitions of the term exist, other than the academic one? I had never though of using the term in any other context. But maybe that's because I've been concerning myself with this specific topic for too long.

In colloquial parlance that means “it’s up to you, you can do what you want and don’t need permission”

Re: Bun 1.4 Rust rewrite is not looking good?

#123

Post by locknitpicker »

owebmaster wrote: post #110
aypineau wrote: post #97

I'm really skeptical about this rewrite I chose to adopt bun about a year ago, and I've honestly lost count of the number of issues i've submitted and the amount of time i've wasted dealing with them. If I had to make the choice again, I would probably stick with node and pnpm for serious projects We're constantly being sold on promises of -XX% ram usage, but in practice, it's often builds randomly failing for no app…

> But I still strongly believe the project makes a lot of sense, and I genuinely think these issues can be solved by 2028, if the project keeps its focus on stability instead of another SDK for SQL, web sockets, image compression, or whatever comes next If you check the maintainer X, he's asking Claude for what features to implement next. Not only stabilizing isn't the priority, even the features implemented are rand…

> If you check the maintainer X, he's asking Claude for what features to implement next. Not only stabilizing isn't the priority, even the features implemented are random.

To me that sort of stunt sounds like blatant attempts to distract the audience away from relevant topics.

Re: Bun 1.4 Rust rewrite is not looking good?

#124

Post by itemize123 »

potsandpans wrote: post #65
joshuat wrote: 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.

but, importantly, it is not the main reason why people are skeptical of bun rewrite right

Re: Bun 1.4 Rust rewrite is not looking good?

#125

Post by rcxdude »

akkad33 wrote: post #107
rcxdude wrote: post #66

Earlier quoted context omitted.

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.

Isn't supposed to be faster with LLMs?

The rewrite was a lot faster. Actually shaking out the bugs from the rewrite (or just getting enough confidence in the new version from use by early adopters) is probably not going to be drastically faster.

Re: Bun 1.4 Rust rewrite is not looking good?

#126

Post by andsoitis »

tipiirai wrote: post #119
andsoitis wrote: post #118

Earlier quoted context omitted.

> If you check the maintainer X, he's asking Claude for what features to implement next. Link?

> Link? https://xcancel.com/jarredsumner/status/2089183223024943505

Thanks. Seems pretty innocent to me.

Re: Bun 1.4 Rust rewrite is not looking good?

#128

Post by andsoitis »

vga1 wrote: post #92
dafelst wrote: post #70

Earlier quoted context omitted.

It is yet to be determined whether or not the bun rewrite is a success, though.

What are the standards for determining that? The most obvious benefit Rust can give them is being safe from memory leaks. This is hardly controversial: it has been a Zig design choice that memory leaks are the developer/user's responsibility. They have already demonstrated to have fixed several of those [0]. Marketing-wise, it has been an obvious success. Dunno if that matters. [0] https://bun.com/blog/bun-in-rust

> What are the standards for determining that?

Seems pretty simple to me: if the software works, the port has been successful.

If this is unsatisfactory, another way to think about the question is to ask "what would make you conclude it has failed?" That requires a sharp choice.

Re: Bun 1.4 Rust rewrite is not looking good?

#129

Post by touisteur »

dminik wrote: post #48
verdverm wrote: post #18

Earlier quoted context omitted.

there are linters that check for dead code (depending on your language / ecosystem), it should always be 0%

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.

In a previous life I managed to deliver a system with (basic-block) coverage measurement compiled in (gcov) but instead of the mess of files gcov generates, the whole coverage structure was streamed to a remote server (it compressed very well). Once that was in place it was an amazing telemetry tool.

Later on used Intel Processor Trace in a similar fashion for even finer (mc-dc) coverage.

Coverage tools are very useful, if a bit hard to use...

Post reply on HN