Live data from Hacker News

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

twitter.com

691–700 of 754 posts

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

#691
post #491

Earlier quoted context omitted.

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

They can't, because Bun is tied to a fork of Zig 0.14 which is not compatible with regular Zig compiler.

[deleted]

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

#692
post #491

Earlier quoted context omitted.

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

They can't, because Bun is tied to a fork of Zig 0.14 which is not compatible with regular Zig compiler.

Bun’s patched Zig is on Zig 0.15.1

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

#693
post #436

Earlier quoted context omitted.

One should care about tests more than how code was coded. If I had a codebase with lots of tests and asked someone else to rewrite it to another language passing the same test suite, I honestly wouldn't expect a great quality job. I say this because it happened 3 times in the company I work for: we conducted experiments by tasking different companies to rewrite the same code in another language. All of them passed (m…

I have seen, many times, code that has lots of tests but don't work. Why? Some of the patterns that I saw: * The code is only called from tests but never called in production * Tests are not testing the actual application logic, or the logic that matters. In some cases, the tests have nothing to do with the application code at all, because it does not even run any application code. * Tests repeat the same logic as in…

I think you and I don't share what is a "test". Are you thinking about unit tests? I'm thinking about unit tests, smoke tests, integration tests, e2e tests, functional tests, manual QA tests and probably even "the-product-works-as-expected-as-I-can-see-from-the-amazon-reviews-of-our-clients tests".

I agree with your point of view in general, but "having tests" doesn't mean "having great tests". If I rewrite my code and give the binary to our clients and they don't see any difference or bug, well, that means the rewrite passed the ultimate test. In fact, the percentage of our clients that care about implementation details (such as PL) is precisely 0%.

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

#694
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…

Interesting, but why not then use an even stricter language? Say Idris, ATS, Lean or F* ?

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

#695
post #630

Earlier quoted context omitted.

> Basically we are seeing now an "inverse Hofstadter's Law" where doing something with an LLM takes less time thanexpected even when you take into account this law. Even LLMs themselves can't accurately estimate this (though this may be out of distribution stuff)

LLMs have no conception of time, unless you explicitly feed in timestamps to the context

It doesn't stop LLMs provide "this feature set will require 4 months to finish" (and then finishing it one hour)

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

#696

Earlier quoted context omitted.

Powerful people figured out how to make suspicion work for them long ago. You have every right to be unconditionally suspicious, but it’s not a good way of accomplishing any change. Also their feelings are not hurt by what you or I think, they don’t care.

> Also their feelings are not hurt by what you or I think, they don’t care. Definitely not true, they tend to care more than most.

They generally care about what powerful/influential people think. I’m not powerful or influential, but I guess maybe the person I was talking to is. If so I apologize for the miscommunication.

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

#697
post #582

Earlier quoted context omitted.

Powerful people figured out how to make suspicion work for them long ago. You have every right to be unconditionally suspicious, but it’s not a good way of accomplishing any change. Also their feelings are not hurt by what you or I think, they don’t care.

> Also their feelings are not hurt by what you or I think, they don’t care. I would have agreed with this like 15 years ago, but the very existence of Twitter (and the acquisition saga) proves this to not be true.

Dario Amodei is not Elon Musk. Most powerful people do not internalize the emotions of others (though obviously some do). If you think powerful people are disproportionately sociopaths, you either agree with me or are not using the word correctly.

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

#699

Now in Zig, Julia, Nim, Crystal. I just love programming languages. But in all honesty, I don't understand the extremism in Rust engineers that reject any other language.

Steelmanning a rust programmer's argument: memory issues have a very large blast radius, as the bugs tend to show up in completely unrelated. Because of this, dependencies on languages not written in Rust can easily corrupt areas that are unrelated.

I feel like one of Rust's defining philosophies is modularity, in the sense that each module should be self-contained, and have clear boundaries. This can come up as an assumption behind their arguments imo.

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

#700

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?

Nope! Zig is like C in this regard. There’s no borrow checker. Managing memory is your responsibility. It gives you a few more tools than C - like a debug allocator, bounds checked array slices and so on. But it’s not a memory safe language like rust.

Those tools exit in C tooling as well, now that many ignore them is another matter.

MSVC has a debug allocator since at least Visual Studio 5.

Post reply on HN