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

641–650 of 754 posts

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

#641

Post by matt_kantor »

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.

My reply in a sibling thread[0] is applicable here too. I'm not sure if you have the same things in mind as skeledrew, but at least this seems probably relevant:

> If you broaden the criteria enough then you can interpret most anything as "something that a human does/did". Like: humans "have fun" and therefore video games don't count, or humans can jump therefore they "travel through the air" therefore airplanes are just "doing something that humans do". But I don't think this reading of the upthread comment leads to interesting discussion.

I'd be happy to discuss specific examples of the "pre computer forms", if you provide some.

[0]: https://news.ycombinator.com/item?id=48083805

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

#642

Post by 12948aH »

malisper wrote: post #250
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…

Same but for multi-threaded Postgres[0]. 96% pg regression tests pass after 1 month and 823K LOC. 8 Codex accounts at $200/mo is what i could use up with no Mythos I've also seen the benefits of Rust for this too. And making the bet that my pg experience will help me make good design choices around many of the things people have been having trouble with in pg for a long time[1]. Excited to see AI make it more possibl…

> PostgreSQL, rewritten from scratch in Rust.

You use the test suite and LLMs are trained on Postgres.

Are you at Freshpaint? A company that "helps healthcare marketing teams grow in a world where privacy is the baseline, but performance is the goal."

Nice promises! Surely the marketing teams will respect privacy!

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

#643

Post by johncolanduoni »

irishcoffee wrote: post #635
johncolanduoni wrote: post #481

Earlier quoted context omitted.

Not by trading the same suspicions on the internet with fellow true believers over and over again, I think the past 10 years have proven that pretty conclusively. Maybe people should try some of the things previous social movements did, seemed to work pretty well even against a much more uniform media environment and a stronger hostile social consensus. Protests don’t immediately solve everything, but I think looking…

I said assassinations don’t move the needle. Protests just give people the warm fuzzies. They don’t change anything. Tell me what has changed with all of the no kings protests? How well did it go for Iran when they protested? The onus is on you to prove your point, not me to disprove it.

I’m not asking you to prove my point, but I think you’re being myopic.

* Vikor Orban was just ousted by a popular protest movement. This took years due to structural electoral issues but it did work eventually. And it wouldn’t if the people opposing him gave up because they didn’t change anything right away.

* The US ICE protests (and the federal government’s insane overreaction to them) let to the head of DHS being fired and a quantifiable drop in ICE activity (e.g. arrests and number of people currently detained).

* Nepal’s protests last year led to the resignation of the prime minister and a resounding electoral victory this year for their opponents.

Protests aren’t magic win buttons, especially because even the people protesting don’t fully agree on exactly what “winning” looks like. But they accomplish more than acting out your emotions on the internet.

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

#646

Post by Greed »

voidhorse wrote: post #633
Greed wrote: post #487

Earlier quoted context omitted.

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…

Sure, but you need to consider that, in this case we are talking about the language runtime . It isn't just some other library dep. It's basically the base layer of the stack. It has a huge blast radius. It is, imo, a nontrivial decision to swap runtimes. If problems emerge you can't easily plug some other runtime, that's a major technical decision and should be treated as such. In the past at least you could assume…

You're implying that reckless rewrites within the JS ecosystem are a novel event, or more specifically that surprise language changes over a short period of time are. And yet... I can think of at least six times in which exactly this has happened and little fuss was made because the polarizing element of "AI" was not involved. Not just JS to Typescript, but to Dart, Go, C, Rust, Zig, Nim etc.

From any reasonable perspective, this is business as usual in the house of cards we all operate in. Perhaps the sensationalization would be justified if the lang migration wasn't one of less correct -> enforced correctness by default?

To your point in general about maintainers holding a mental model of the runtime: I would challenge that to say that it is very likely that there is no developer who holds a complete mental model of an entire runtime at any given point. As with anything of this scale you understand individual parts in their entirety and have general assertions about the rest until specifically revisited, even if you are the sole developer. In this case specifically, Bun has been largely AI driven for quite a while anyway so it is even more unlikely that the developers ever had a complete picture in the first place. If you trusted them before, then nothing has changed.

It's not lost on me that code logic can be subtly incorrect even as tests are passing either, but there isn't exactly a lot of grey area in this particular context. Does your code compile or not? If it builds as expected, then your own unit tests will highlight the difference.

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

#647

Post by ori_b »

wiseowise wrote: post #281
tempaccount5050 wrote: post #258

Earlier quoted context omitted.

Software companies have been about automating human labor since the invention of computers. It's the whole damn point. Why do you think finance used to be (sometimes still is) the head of the IT dept? Because we automated accounting away. Then typists. Then secretaries. Then drafting. Etc etc.

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

The purpose of a system is what it does. If people constantly use your device to turn kittens into pulp, you have built a kitten grinder, even if the label you slapped on the side says "coffee beans only".

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

#648

Post by skeledrew »

matt_kantor wrote: post #638
skeledrew wrote: post #500

Earlier quoted context omitted.

- 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 bet…

> 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 difficult/dangerous to totally impossible at this time (at some point in time it would at least be possible). Though that's just being pedantic, especially re video games.

> "this is just an implementation detail to let us run other software, so it shouldn't count"

That's essentially what I said, but in different words.

The main point in my original reply was to question the point of software creation, if not to stand in for human capability, wholly or partially. I don't see people creating software explicitly to just let it gather dust for example, even though that happens very often.

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

#650

Post by IshKebab »

program_whiz wrote: post #579
awesome_dude wrote: post #246

Earlier quoted context omitted.

Show code

I think he meant "show me a true linked list / node graph in rust that isn't unsafe". The reason being its not possible using c-style pointer following (or without just putting everything auto-pointers). What you've shown is exactly the tradeoff they were referring to. In rust, the answer is: make sure lifetime of all memory is explicitly managed, then use integers for the 'links' between nodes. His point was that fo…

> it also introduces other subtle bugs if your logic is wrong (e.g. you have edge 100 but actually those nodes were removed, so now you're pointing at the wrong node

This is not actually a different kind of bug; it's just use-after-free, which you can of course get when using pointers instead of indices.

Actually it's slightly safer than pointer use-after-free because it is type safe and there's no UB.

Also some of the Rust arenas give you keys (equivalent to pointers) which can check for this. There's a good list here (see "ABA mitigation"):

https://donsz.nl/blog/arenas/

Post reply on HN