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

661–670 of 754 posts

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

#661

Post by NavinF »

ycui7 wrote: post #471
aragilar wrote: post #453

Earlier quoted context omitted.

Which differential equations are you talking about? Linear ones have standard solutions and are definitely parallelisable (though you can basically just write the solution down by hand). Non-linear ones vary from can basically be approximated by a linear solution with corrections to needing to use relaxation methods (which are obviously not parallelisable). Mechanics is generally linear, and for game physics engines…

The type of people who need spice is dead serious about accuracy. 1ppm error sometimes is not tolerable. So, an optimization in a game engine is definitely not suitable for engineering simulation.

Dude these are incredibly oversimplified models of real components. How are you getting 1ppm when basic shit like tempco and self heating are missing from pretty much every vendor provided spice model?

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

#662

Post by matt_kantor »

skeledrew wrote: post #648
matt_kantor wrote: post #638

Earlier quoted context omitted.

> I don't really see your point here. The parent comment said "to do something that a human does/did", so I tried to come up with a diverse list of software that performs functions humans hadn't/couldn't've done. > software is created to automate human labour as much as is practical That's certainly a reason software is created, but not the only reason. > Medical device firmware - hardware control layer for medical d…

Ah I think I see where things went off the rails. I should've explicitly added "would have to do" to purposes for creating software; it was just on my mind, and left as an implicit. I don't think there's anything out there that a computer can do but humans can't do per se. Whether it's manually doing what an MRI does, or sending people with the Mars rover. It would be anything from tedious/inefficient through crazy d…

> I don't think there's anything out there that a computer can do but humans can't do per se.

The first thing that comes to mind is complex calculations that need to happen within a certain time budget to be useful. Like, sure, I could "play GTA 5" by sending each of my inputs to a room full of mathematicians frantically doing calculations who then instruct artists how to paint the next frame to send back to me[0], but even if you could somehow get that to run at 1 frame per day, I'd argue that's not really "playing GTA 5" anymore (a core aspect of the game is reacting to things in real time). For a more tangible scenario, imagine trying to pilot a quadcopter by manually controlling each actuator individually (there's no way you could do that quickly/accurately enough to avoid crashing).

[0]: Also this is arguably still "a computer", just one with an unconventional architecture.

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

#663

Post by IshKebab »

boxed wrote: post #600
lionkor wrote: post #530

Earlier quoted context omitted.

> Of course, if Bun's Rust port has tons of `unsafe`, it won't magically solve them all, but it'll still get better You get very few of the Rust guarantees when you litter your code with unsafe to get around the safety checks (which is what they're doing here). I would not recommend running this in production.

From what I understand, rust "unsafe" is actually pretty damn safe compared to an actually memory unsafe language.

Not really. In fact unsafe Rust is widely considered to be significantly harder to get right than C or Zig.

E.g. see https://chadaustin.me/2024/10/intrusive-linked-list-in-rust/ or https://lucumr.pocoo.org/2022/1/30/unsafe-rust/

The saving grace is that in idiomatic Rust code you have very little unsafe code - usually none. But yeah there's no way I would trust AI to get unsafe Rust right.

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

#664

Post by whimsicalism »

wiseowise wrote: post #573
woah wrote: post #390

Earlier quoted context omitted.

Who's the whiny baby? The developer writing some code in their own repo, or the guy complaining about it on Hacker News?

> You're posting valid criticism, therefore you're a crying baby Yawn.

To me it reads much more as political polemic/signaling than any sort of valid critique

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

#665

Post by whimsicalism »

fg137 wrote: post #407
Greed wrote: post #388

Earlier quoted context omitted.

I don't have the personal investment that you appear to have with Bun, but why does this matter? Do you scrutinize the rest of your dependencies this way? Much of working in the JS / NPM ecosystem is already pure faith on un-vetted dependencies, and this appears no different pre or post LLM rewrite. If it satisfies the intended goal and API contract it originally did, is there any difference? Were you carefully readi…

> Do you scrutinize the rest of your dependencies this way? You don't?

No, and I don’t really believe that you do to this degree either.

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

#666

Post by FuckButtons »

Aurornis wrote: post #156
aurareturn wrote: post #5

6 days of work to do this. Even if it doesn't end up becoming meaningful, it shows just how tokens and work done will be linked now and in the future. It's going to be hard to compete with someone or a company that has more compute. They will just be able to do things you can't.

Translating a project that includes a good test suite from one language to another is known to be a great case where LLMs work well. When you’re starting with a complete codebase to use as an example and a test suite to check everything it’s much easier to iterate toward the desired goal. The LLM can already see what the goals are and how they’ve been implemented once already, which is a much easier problem than star…

Sure, but, given that, does it not seem like the conclusion is: if you have something that could in principle be reverse engineered by a competitor with more compute, they can and will steal it, because the only constraint is roi.

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

#668

Post by gbgarbeb »

Gigachad wrote: post #566
nine_k wrote: post #63

Earlier quoted context omitted.

Zig is a great low-level language. It's much better than C, while not being so much larger as e.g. Rust or C++. AFAICT Zig does well in embedded development, and should continue to do so. Note that Zig is not even 1.0 yet.

For most use cases I can’t imagine why you’d make the effort to move off C and not just go all the way to Rust.

Rust is too mainstream now. Every Zig fanboy clutches to their heart the confidence that they are still a little bit "alt" in some way.

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

#669

Post by LtWorf »

gobdovan wrote: post #377
skeledrew wrote: post #372

Earlier quoted context omitted.

I see "sourceforge" and immediately I think "this project is way behind time and is going to pose a lot of issues to new users, if it's still active".

I could have linked Github repo which has been abandoned for 11 years and ranks higher on Google than the sourceforge page, but that would have maybe been disingenuous. ( https://github.com/ngspice/ngspice )

I moved to codeberg and google still insists on linking SOLELY the old archived project on github. While of course snyk and such awful scanners mark them as abandoned because they don't know codeberg exists.

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

#670

Post by NewsaHackO »

toshinoriyagi wrote: post #473
NewsaHackO wrote: post #395

Earlier quoted context omitted.

>Having a project consider a rewrite isn't so big a deal. I don't agree that them actually doing an entire draft rewrite can just be characterized as them considering a rewrite. >I don't think the Zig team is concerned at all. I wonder if that's the mentality that got them in this situation in the first place.

>I don't agree that them actually doing an entire draft rewrite can just be characterized as them considering a rewrite. You're right, a rewrite is in existence, and whether it is good enough to be used or expand upon is what is being considered. I don't think that changes the fact that languages don't live or die by whether or not 1 large project using them continues using them. Especially a language like Zig which…

>It's not like Jarred has been begging the Zig devs to implement language changes to make Bun development easier. Zig was always upfront that you will have to manage memory manually, and that allows for operator error.

Huh? The patch that Bun submitted was for Zig was about compilation times, and making Zig's type resolution faster. I am sure the Bun developer who is submitting patches to Zig is well aware that manual memory management is a core tenet of Zig. The issue is that Zig has to "pick a struggle"; When using C, you manage all of the memory yourself, and get blazing fast compile and run times. In Rust, Rust uses the borrow checker to reduce the amount of memory safety bugs, however Rust can also have slower compile times due to this. Why would it make sense to use a language that is not helping you manage memory and is slow to compile, especially if you submit a patch to the language to address the issue and get rebuffed?

Post reply on HN