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

461–470 of 754 posts

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

#461

Post by Gigachad »

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…

The goal posts are always moving. This would have been an unthinkable task a couple years ago.

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

#462

Post by antonvs »

girvo wrote: post #262
mohsen1 wrote: post #75

Very impressive that they could do this so quickly because I have been on a similar project (porting TypeScript to Rust) for 5 months. But I guess I don't have access to Mythos and unlimited tokens. I'm also close to 100% pass rate. 99.6% at the time of writing. https://tsz.dev Rust is perfect for writing all of code using LLM. It's strict type system makes is less likely to make very dumb mistakes that other languag…

I’ve struggled to get Opus to not write the weirdest possible Rust, ignoring all idioms and so on. Any tips?

Give it coding guidelines. It'll largely try to do what you ask.

Left to itself, it often follows human developers who conceive of their goal as "get the program working, the end justifies the means." Which makes sense because there are a lot of systems like that in the training corpus.

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

#463

Post by y3ahd0g »

dandellion wrote: post #204
christopherwxyz wrote: post #152

Earlier quoted context omitted.

It’s disrespectful to immediately jump to adversarial conclusions from a simple desire to refactor and poor netiquette.

Four days ago there was no intention to rewrite, now it's a simple desire to refactor. It's not adversarial conclusion, it's pointing out the clear hypocrisy.

"People cannot change their mind!

One must stick to old assertions forever!

Giant foot is gonna squish us!"

...this forum is as bad as a single backwater sub Reddit.

I am so sick of emotionally frail software engineers. I don't know why I keep bothering floating back here every once in a while to see what is up.

Same old rustled jimmies over technology evolution like back during the emacs and vi! tabs vs spaces! Sysv init vs systemd!

Super hero power scaling message boards are more engaging than this site.

AI save us from these needlessly economically empowered labor exploiting non-contributor script kiddies. Such an unserious community.

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

#464

Post by zephen »

fooker wrote: post #422
reactordev wrote: post #398

Earlier quoted context omitted.

which is a good thing. C++'s RAII is magic-sauce that does a lot for you when you can simply use `defer` in zig. A constructor is just a function call. A destructor is just a function call.

How is defer not magic sauce?

Whether you consider it magic is up to you, but, unlike a destructor in RAII, there is nothing automatic going on. If you don't explicitly invoke a destructor, you won't get a destructor.

The fact that you can explicitly invoke the destructor to happen later is simply syntactic sugar, just like if/else/while, or any other control construct more powerful than a conditional jump instruction.

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

#465

Post by zephen »

jazzypants wrote: post #44
logicprog wrote: post #39

Earlier quoted context omitted.

Looks like he did the maintainability performance and test suite checks and made his decision :)

Honestly, I fully support the rewrite to Rust, but he should have just owned this from the start. I'm sure he knew in the back of his mind how dedicated he was to that branch as he had already spent the equivalent of thousands of dollars in tokens by that point.

But he was just working along and someone else outed his branch, right? Dude doesn't owe you any sort of explanation.

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

#466

Post by ethin »

josephg wrote: post #139
dnautics wrote: post #87

Earlier quoted context omitted.

rust does not promise leak safety.

True. But rust does make it a lot harder to leak memory by accident. Rust variables are automatically freed when they go out of scope. Ownership semantics mean the compiler knows when to free almost everything.

> But rust does make it a lot harder to leak memory by accident. Rust variables are automatically freed when they go out of scope.

RAII has entered the chat.

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

#467

Post by dnautics »

josephg wrote: post #451
dnautics wrote: post #448

Earlier quoted context omitted.

> I suppose you could work around that by adding lifetime annotations in zig comments. you can make a no-op function that gets compiled out but survives AIR > rust knows when it can Drop. and its possible to cause problems if you aren't aware where rust picks to dropp. > And rust can put noalias everywhere in emitted code. zig has noalias and it should be posssible to do alias tracking as a refinement. > But if you w…

> and its possible to cause problems if you aren't aware where rust picks to drop. Can you give some examples? I've never ran into problems due to this. > don't use that attitude to suck oxygen out of the air. rust comes with its own baggage Yeah, that's a totally fair argument. One nice aspect of the approach you're proposing is it'd give you the opportunity to explore more of the borrow checker design space. I'm co…

> Can you give some examples? I've never ran into problems due to this.

If it's doing a drop in the hot loop that may be an unexpected performance regression that could be carefully lifted.

thank you. Unfortunately in the last few weeks i've been too busy with my startup to put as much work into it. We'll see =D

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

#468

Post by matt_kantor »

skeledrew wrote: post #444
wiseowise wrote: post #281

Earlier quoted context omitted.

> It's the whole damn point. Believe it or not, for some of us it’s not “the whole damn point”.

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

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

#469

Post by ted_dunning »

dwattttt wrote: post #437
bsder wrote: post #386

Earlier quoted context omitted.

> As an amateur in the space Why are you not using this through KiCad? That's what I would expect an amateur to do; especially since they handle the UX that you are complaining about. And you are complaining about tangled code but that code is almost certainly hyper-optimized since performance actually mattered a LOT to people running spice simulations. ng-spice (and Spice3 and Spice2) were not written for programmin…

> Why are you not using this through KiCad? That's what I would expect an amateur to do; especially since they handle the UX that you are complaining about. They sound like an amateur at circuit design, not software engineering (which is how I'd describe myself too).

KiCad is still the preferred interface.

The original point stands. Ngspice shows its heritage from the days of Fortran far more than a modern code base would or should. It's sole great virtue (from my point of view) is that it integrates with KiCad and only falls over with no reason about 5% of the time.

I would suspect that some of the simulation systems coming out of the Julia community or Xyce would be a better base.

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

#470

Post by dash2 »

tempaccount5050 wrote: post #460
gravypod wrote: post #420

Earlier quoted context omitted.

My first "job" in computing, where someone else paid me for code, was in a research context where we were modeling radio propagation. Nothing about that was removing human labor. It in face eventually called for a bunch of humans to interact with each other. See: https://www.hamsci.org/basic-project/2017-total-solar-eclips... I don't think it is fair to claim computers are about putting people out of jobs.

I think it is. Before computers you would have had to write all that down on paper logs. By using code, you saved yourself time. If it wasn't less labor, you wouldn't have done it that way.

Before it was less labor, they might not have done it at all. Computers let you do things quicker. So you do more things.
Post reply on HN