Live data from Hacker News

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

twitter.com

651–660 of 754 posts

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

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

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.

What is your definition of "known to be a clown"? I'm not sure how one would even begin to evaluate that at scale. Or what practical impact that would actually have for anything but the most critical of dependencies that might be too difficult to swap at will.

Hyperbole, yeah, but top 10% undesirable leads is literally thousands of people?

I couldn't imagine following the communities of even the top ten dependencies of one of our (many) projects very deeply. Every single one of them is having divisive conversations in threads like this all the time that never really lead anywhere or sum up to anything meaningful.

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

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

>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 languages might allow.

100%. I've been telling everyone who will listen this for 2 years. LLMs are infinitely more productive with swift code like

let engineCycleCount: Int = 5

vs

let eC = 5

They still make mistakes, but forcing _explicit_ typing in a strongly typed language makes them make far fewer mistakes + the compiler is catching >90% of what you try to catch with a billion rspecs in trash languages like ruby.

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

#653
post #524

Earlier quoted context omitted.

Is he working for Anthropic now?

anthropic bought bun recently

That's exactly my point. The fact they created Bun does not mean they will do what's better for Bun and the people using it.

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

#654

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.

I think it was Rich Hickey who said "Programmers understand the benefits of everything, and the costs of nothing."

I'm also reminded of video game forums where everyone argued whether the Xbox or Playstation is better, not because they're genuinely interested in the pros and cons of each system, but because they only have an allowance to buy one of them, so they're trying to gaslight everyone and themselves into believing the one they picked is better. In the case of programming languages, there's only so much time in the day, so the people who post on this site go all-in on the programming language they picked, and will rationalize any reason they can think of to believe the language they picked is better.

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

#655

Earlier quoted context omitted.

This is a hot take, but programming languages haven't progressed since the 90's. We've been conditioned to believe that if you want to be a serious programmer, you have to either use C++-style RAII (which includes Rust), or garbage collection, and there's no in-between, and C programmers are dinosaurs who can be ignored. Arena allocators are a great way to automatically manage memory allocations. You malloc a whole b…

Arena allocators are not some grand new concept. They're already commonly used in C++ in the places it makes sense to use them. Which is really not that many places, it's a fast but rather niche optimization. There's not a whole lot of scenarios where lots of temporary memory is needed for one well defined scope. Video games are large and have lots of state and lots of threads. Zig's lack of ownership here with fully…

I disagree with a lot of what you said, but I don't feel authorative enough to say you're wrong.

> Which is really not that many places, it's a fast but rather niche optimization. There's not a whole lot of scenarios where lots of temporary memory is needed for one well defined scope.

Arena allocators are not niche optimizations, or not something picked first for optimization. Contrary to what you said, arenas are useful for temporary allocations with poorly defined intermediate scope or lifetime (think functions directly or indirectly called by the arena owner). If the scope is local and well-defined, a regular allocator or even a fixed buffer would do just fine.

> Zig's lack of ownership

Zig doesn't have explicit annotations for it, but the concept of ownership and lifetime doesn't go away. It's not enforced by the compiler, which is an intentional tradeoff to let the programmer have more control and freedom. When you use languages with manual memory management, it's expected that you are capable of designing sensible programs in such a way that ownership and lifetimes are tractable and are part of the program design, rather than something to workaround to please the compiler.

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

#656

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…

> 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.

Are you referring to the developer's/organization's motivations? Maybe this is a proximate-vs-ultimate-cause sort of thing, but people are also motivated to create software by a desire to express themselves, to win competitions, to stave off boredom, to commit crimes, to prove theorems, to earn money, to show off, to learn things, and so on.

I write software to automate away plenty of my own activities (and occasionally others' too), but even when counting things like test suites, build scripts, etc, I'd estimate that less than a third of the code I've written was because I sat down at the keyboard thinking "I want to replace a human capability".

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

#657
post #105

From 4 days ago: https://news.ycombinator.com/item?id=48019226 > I work on Bun and this is my branch > > This whole thread is an overreaction. 302 comments about code that does not work. We haven’t committed to rewriting. There’s a very high chance all this code gets thrown out completely. > > I’m curious to see what a working version of this looks, what it feels like, how it performs and if/how hard it’d be to get i…

cargo check reported over 16,000 compiler errors when I wrote that message. It could not print a version number or run JavaScript. I didn’t expect it to work this quickly and I also didn’t expect the performance to be as competitive. There’ll be a blog post with more details.

UPDATE: This would make for an excellent case study if you don’t mind sharing the details. I am very curious about the number of agents, hours it took, and models used (did you use Mythos?).

This would not have been possible 5 years ago. LLMs are going to push us into the space age. Both Anthropic and OpenAI have committed to spending 10s of billions of dollars on training alone for the year. I am equally excited and terrified at the pace of progress!

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

#658
post #527
post #304

Earlier quoted context omitted.

I recall C++ OOP being the new hotness when I started out and C was always contrasted as the old & busted example. Kind of the "Everything-as-an-object will simplify everything" phase. Windows MFC was the new way, then STL. Java WORA write once, run anywhere was definitely a thing when it came out. Java Applets came out of the woodwork and were the WASM of their day. Even Cisco ran Java for their router UI for a whil…

> every other article ended in " ... written in Go" What happened to that: is Go no longer considered great / popular?

In the circles where I hang out I think community opinion is that go is _fine_, but python has faster iteration speed for experiments, and rust has better correctness and performance for production, so there's less excitement around it

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

#659

Earlier quoted context omitted.

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…

96% tests passing sounds impressive, but I remember that C compiler that had similar (or better) stats yet was still hilariously broken because the test suite didn't cover many "obvious" things that a human wouldn't get wrong even without the tests.

There's a few big differences between the Anthropic C compiler and pgrust. The C compiler was built mostly autonomously and as a clean room implementation. OTOH I'm steering codex and using the Postgres source code as a reference. That's leading to the implementation being based more on how pg does things than anything else. If you want to try it out, I compiled it to wasm so you can try it out here[0]. You'll see it's much more faithful to Postgres than a C compiler that doesn't handle type checks.

[0] https://pgrust.com/

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

#660
post #625

Earlier quoted context omitted.

Anti AI cope is unreal, the comparisons to smoking won't stop lol. The mental model of such people (like you) will be studied. LLM's won't go anywhere, keep dreaming.

Studied by whom? Your virtual AI concubine who has you under her thumb? I thought human thinking is obsolete, as can be seen by your comments.

Sure. Let’s see whether ai sticks or not. Till then whine about it in the internet. Maybe a few would care
Post reply on HN