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

Bun's experimental Rust rewrite hits 99.8% test compatibility on Linux x64 glibc

twitter.com

Post reply on HN
Print view View original

541–550 of 754 posts

Re: Bun's experimental Rust rewrite hits 99.8% test compatibility on Linux x64 glibc

#541

Post by muglug »

perlgeek wrote: post #540

Has anybody thought through the legal aspects of this, regarding code ownership? As far as I understand the situation in the US (sorry, no idea where he is located), output from LLMs, once published, is essentially in the Public Domain, since there isn't any human who owns it. However, in some sense, this is also a machine-assisted translation from one computer language into another, so one could argue that the owner…

> output from LLMs, once published, is essentially in the Public Domain, since there isn't any human who owns it

That’s not what the court case in question was about: https://www.morganlewis.com/pubs/2026/03/us-supreme-court-de...

If I ask an LLM to come up with an entirely new story on its own, the output is not copyrightable.

But if I feed an LLM a Tom Clancy novel and ask it to regurgitate that same novel, I cannot legally then put the output on a website for anyone to download.

Re: Bun's experimental Rust rewrite hits 99.8% test compatibility on Linux x64 glibc

#542

Post by perlgeek »

spicyusername wrote: post #11

What a time to be alive. So much of the fundamental dynamics of the industry and the job have changed in so little time. Basically over night. Some days I am so excited at how much I can do now. You can build anything you want, in basically no time! 100% of my software dreams can be a reality. Some days I am terrified at what's going to happen to the job market. Suddenly you can get so much with so little. The world…

> Is every company that sells software as their core business model going to go out of business?

Probably not, for a number of reasons:

* Some software suites are (probably still for a few years) too big to regenerate them through a coding LLM

* There's quite a lot of proprietary knowledge not just in the code itself, but in the requirements, industry knowledge etc. For example if you want to write a hospital management system, you need to know a lot about how hospital works, how they are billing their services in different legislatures, data protection rules etc.

* For some pieces of software (like computer-aided engineering), validation of the software is just as important as the software itself.

* Liability: suppose you build bridges, and you're on the hook if it fails too early. Do you really want to vibe-code your own software that validates the bridge's design? Will any insurance company cover that? Probably not in the near future...

* Currently, security and safety of LLM-generated code is still a pretty big concern. I guess this will get better as the LLM-Coding industry matures.

Re: Bun's experimental Rust rewrite hits 99.8% test compatibility on Linux x64 glibc

#543

Post by mort96 »

mort96 wrote: post #248
afdbcreid wrote: post #238

Earlier quoted context omitted.

Even assuming that's a correct interpretation, does "using C/C++ results in having an extremely high amount of crashes/memory bugs" not true?

No, that's provably false by a fairly simple existence proof. If it was true that using C results in an "extremely high amount of crashes/memory bugs", we would expect to not find any substantial pieces of software written in C without an "extremely high amount of crashes/memory bugs". Now where exactly you draw that line is necessarily going to be somewhat arbitrary, but by any definition, I think we can all agree t…

Bah waking up today to notice a typo, after the edit window. "And both C++ and Rust inherit some ... aspects" was of course meant to be "And both C++ and Zig inherit some ... aspects".

Re: Bun's experimental Rust rewrite hits 99.8% test compatibility on Linux x64 glibc

#544

Post by duggan »

qudat wrote: post #170
afavour wrote: post #46

Earlier quoted context omitted.

FTA: > why: I am so tired of worrying about & spending lots of time fixing memory leaks and crashes and stability issues. it would be so nice if the language provided more powerful tools for preventing these things. Not a hard number obviously but a clear indication those issues exist.

I don’t understand: just use an agent to find all memory leaks and segfaults. I don’t get the argument if you are gonna vibe code anyway. With unlimited tokens make it a lint rule or auto formatter.

LLMs are a force multiplier, not magic. They benefit from good tooling.

Re: Bun's experimental Rust rewrite hits 99.8% test compatibility on Linux x64 glibc

#545

Post by perlgeek »

vb-8448 wrote: post #371
spicyusername wrote: post #11

What a time to be alive. So much of the fundamental dynamics of the industry and the job have changed in so little time. Basically over night. Some days I am so excited at how much I can do now. You can build anything you want, in basically no time! 100% of my software dreams can be a reality. Some days I am terrified at what's going to happen to the job market. Suddenly you can get so much with so little. The world…

Let's take a SW business like a ticketing system. Do you think 100 enterprises with 1 bln of tokens are going to make a better product than specialized vendor with 100bln of tokens? For sure SW vendors and SAAS like "logo creator" are already dead, but unless the next generation of LLMs aren't going to have an embedded ticketing system the ticketing system vendor will be fine(maybe less headcount, but not sure).

> Do you think 100 enterprises with 1 bln of tokens are going to make a better product than specialized vendor with 100bln of tokens?

I'm not sure if this is sound reasoning, because "better product" is very context-dependent.

My currently employer has migrated away from RT to OTRS as ticket system, and now moving to servicenow.

The RT instance was heavily patched/customized.

The OTRS instance was heavily patched/customized.

We try not to customize servicenow quite as much, but the less we customize it, the more we have to change the workflows in our company. And humans are slow to adapt.

With this experience in mind, the question is more: do we want to spend lots of money on a vendor-supplied ticket system, and then spend lots more LLM tokens to customize it, or do we LLM-build it from the ground-up?

If we started a new ticket system migration project today, maybe the best answer would be to start with an easily-customizable Open Source ticket system, and then throw LLM-power at customizing it.

Re: Bun's experimental Rust rewrite hits 99.8% test compatibility on Linux x64 glibc

#546

Post by folderquestion »

Jarred wrote: post #105
legerdemain wrote: post #38

From 4 days ago: https://news.ycombinator.com/item?id=48019226 > I work on Bun and this is my branch > > This whole thread is an overreaction. 302 comments about code that does not work. We haven’t committed to rewriting. There’s a very high chance all this code gets thrown out completely. > > I’m curious to see what a working version of this looks, what it feels like, how it performs and if/how hard it’d be to get i…

cargo check reported over 16,000 compiler errors when I wrote that message. It could not print a version number or run JavaScript. I didn’t expect it to work this quickly and I also didn’t expect the performance to be as competitive. There’ll be a blog post with more details.

Just an aside, is there any way to know how many of those 16,000 compiler errors are independent. I mean, could it be that just by changing say 500 lines of code all those errors disappear?

Perhaps 16,000 could just measure cascade breakage, for example one lifetime mismatch can cause errors in every function that tries to use that reference.

Rust reference lifetime bookkeeping is a difficult task for LLMs. The LLM has to maintain, across multiple functions and structs, which references outlive which. Furthermore compiler messages are highly contextual and lifetime patterns are sparse in the training set.

Re: Bun's experimental Rust rewrite hits 99.8% test compatibility on Linux x64 glibc

#547

Post by X0Refraction »

efficax wrote: post #144
sysguest wrote: post #118

Earlier quoted context omitted.

> I am so tired of worrying about & spending lots of time fixing memory leaks and crashes and stability issues. it would be so nice if the language provided more powerful tools for preventing these things. haven't used zig...(only used rust) but zig doesn't solve those problems?

zig is unmanaged memory. But rust also allows memory leaks, and they're not uncommon in large, complex programs. So this rewrite will not necessarily control for that.

What language doesn't allow memory leaks?

Re: Bun's experimental Rust rewrite hits 99.8% test compatibility on Linux x64 glibc

#548

Post by f311a »

ozgrakkurt wrote: post #442
Tiberium wrote: post #34

I just want to comment that I think it's a good change if we look past the AI involvement. Bun has had an extremely high amount of crashes/memory bugs due to them using Zig, unlike Deno which is Rust. Of course, if Bun's Rust port has tons of `unsafe`, it won't magically solve them all, but it'll still get better

[flagged]

I think the main problem with Bun is that they are trying to move very quickly.

Tigebeetle devs spend 90% time working on stability, safety, tests and so on. They don't need new features, they need reliable software. Their database is pretty simple in terms of features and their goal was always stability and speed. Bun devs spend the majority of the time adding new features.

Re: Bun's experimental Rust rewrite hits 99.8% test compatibility on Linux x64 glibc

#549

Post by baranul »

ozgrakkurt wrote: post #442
Tiberium wrote: post #34

I just want to comment that I think it's a good change if we look past the AI involvement. Bun has had an extremely high amount of crashes/memory bugs due to them using Zig, unlike Deno which is Rust. Of course, if Bun's Rust port has tons of `unsafe`, it won't magically solve them all, but it'll still get better

[flagged]

> This just sounds like they are not good at using Zig.

That's odd, because of the visibility of team Bun using the language, one would think they could get whatever help and guidance they asked for. Seems weird for team Bun to complain about crashes, leaks, and bugs if they could have what they are doing wrong explained to them or their issues fixed in a timely manner.

Re: Bun's experimental Rust rewrite hits 99.8% test compatibility on Linux x64 glibc

#550

Post by mawadev »

esjeon wrote: post #483
Tiberium wrote: post #34

I just want to comment that I think it's a good change if we look past the AI involvement. Bun has had an extremely high amount of crashes/memory bugs due to them using Zig, unlike Deno which is Rust. Of course, if Bun's Rust port has tons of `unsafe`, it won't magically solve them all, but it'll still get better

Last time i checked their issue tracker (in 2025), the main source of problem was the engine, not their Zig code. A lot of core dump was happening inside and around JSC.

I remember back in the day we used to blame the user and not the tool, but I guess we changed that notion when it comes to tool vs tool comparisons LOL
Post reply on HN