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

491–500 of 754 posts

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

#491

Post by cdud3 »

laurencerowe wrote: post #403
hiccuphippo wrote: post #355

Earlier quoted context omitted.

Single compiles for sure. Where Zig is optimizing compilation is in the incremental compiler, which I've seen compile the compiler itself in an instant after a single line change. Of course, that kind of speed is probably not interesting to some people if the AI is writing tons of lines of code before they go to the compilation step.

I found making single line changes in Bun’s zig code led to very long compiles compared to doing the same in Rust code. It was a while ago though and maybe I was doing something wrong.

Probably a very long time ago then. Try again with Zig 0.16. It's amazing how fast recompiles can be.

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

#492

Post by csande17 »

Greed wrote: post #487
fg137 wrote: post #407

Earlier quoted context omitted.

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

Enough to make judgement calls on them based on the individual Twitter posts of each of their developers? Absolutely not! If I go beyond the initial vetting, that's a minimum of 30+ projects multiplied by however many contributors each. Without even mentioning all of their sub dependencies. It's a pipe dream to think you can ever have a complete picture of the motivations and political machinations of your entire dep…

I have definitely dropped dependencies from production codebases in the past because "lead developer is widely known to be a clown". You don't need to catch everything but it's generally a good idea to have a picture of, like, the twenty most important dependencies in your codebase and the 90th percentile most notorious clowns in the community.

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

#493

Post by anilgulecha »

nothinkjustai wrote: post #115
anilgulecha wrote: post #9

I think the industry is moving to English as the programming language, and specifications-context-tdd as the framework for building software. Many find it distasteful, and many finding liberating. I think it's broadly correlates with how they feel about expressing themselves in english vs say C++. As a side question, is there anyone who's using LLMs primarily in non-english mode to program? I suspect there's quite a…

Natural language doesn’t have the precision required for building systems. We already have languages for specifying systems precisely. It’s called “code”…

Well, what we're seeing the past few months is that natural language does - at least enough to build code and tests.

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

#494

Post by energy123 »

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

Can you or someone shed some light on how much compute it took to do this?

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

#496

Post by txdv »

amarant wrote: post #97
nine_k wrote: post #41

> 99.8% of bun’s pre-existing test suite passes on Linux x64 glibc in the rust rewrite OK, they've got a working prototype, congrats! Now it needs to be put into shape so that all the unsafe blocks are eliminated (maybe with a few tiny exceptions), and the code is turned into maintainable, readable, reasonably idiomatic Rust. I wonder how long is it going to take.

About 2 months, or 60 days, if we go by the old 90/10 rule. Not sure that rule is even applicable anymore, but I don't have a better heuristic to make guesses by either.

maybe its tokens instead of time now? bun has access to an unlimited amount of it

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

#497

Post by pkolaczk »

bsder wrote: post #392
etimberg wrote: post #370

Earlier quoted context omitted.

The spice core that ngspice is built off is terrible code. It has a long history going back to 1970s era fortran. Starting fresh is probably preferable

> The spice core that ngspice is built off is terrible code. It has a long history going back to 1970s era fortran. Starting fresh is probably preferable That code is also hyper-optimized for performance . I sincerely doubt you are going to match the performance easily with any random rewrite. Now, if you had a very clear idea of why the code was making assumptions from the 1990s that are no longer valid, then you mi…

That code was optimized for performance for 1980s hardware. It’s very far from optimized for modern CPUs.

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

#499

Post by TheRoque »

tempaccount5050 wrote: post #489
matt_kantor wrote: post #468

Earlier quoted context omitted.

A few off the top of my head: - Video games - Medical device firmware - Synthesizers - Detailed universe-scale physics simulations - Mars rover control software - The Linux kernel

This list is funny. All of these things existed in pre computer form. A scheduler used to be a person putting punch cards into a machine.

What's the human form of a video game ?

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

#500

Post by skeledrew »

matt_kantor wrote: post #468
skeledrew wrote: post #444

Earlier quoted context omitted.

Why else would one create software, if not to do something that a human does/did?

A few off the top of my head: - Video games - Medical device firmware - Synthesizers - Detailed universe-scale physics simulations - Mars rover control software - The Linux kernel

- Video games - only feasible because of computers.

- Medical device firmware - hardware control layer for medical devices, which are used to aid in medical procedures.

- Synthesizers - help to make music.

- Detailed universe-scale physics simulations - help to make certain physics problems more tractable.

- Mars rover control software - helps to remote control rovers.

- The Linux kernel - control layer that sits between firmware and actual applications, pretty much just a common shared library so apps don't have to each ship with a full stack.

I don't really see your point here. None of these examples counter the argument that software is created to automate human labour as much as is practical.

Video games are an interesting category since they're entirely enabled by software: I can't imagine anyone driving a video game manually (note I don't consider things like Chess, etc software to be video games in this context; more things like FPS, racing, etc). I do remember as a kid I thought that there were actually little people doing the stuff in video games though.

Post reply on HN