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

621–630 of 754 posts

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

#621

Post by ptnpzwqd »

Responses seem to be very "either or" as usual on such topics.

I think it should be possible to appreciate how impressive this is on one hand, while also discussing the limitations of the approach.

Everyone can probably agree that getting this far without LLMs would have taken substantially longer and required a huge amount of work.

But what is then the end result?

Personally, for me it would still be hard pass on using a 1M LoC LLM-migrated language runtime - I have seen CC do enough crazy things to still be wary of any code without a human in the loop. It simply plays too fundamental a role in the tech stack. Others might feel differently, and time will tell how things play out.

Even if this does play out as optimistically as one can imagine, would it then mean I can go and migrate some of my enterprise codebases the same way? I doubt it.

Bun has the nice feature that it has an extensive set of black box / E2E tests that don't themselves need migrating. Most projects in the wild seem to be much more reliant on unit and integration tests that are part of the codebase itself, and would therefore also need to be migrated and be subject to mistakes in the migration process.

It also seems fairly rare that test suites are good enough to guarantee that the program will work as expected in all cases. I am yet to come across a larger enterprise codebase where the tests were good enough to make human review and even manual testing fully redundant. To be honest I doubt that is the case for Bun either, but I don't know enough about bun to conclude that.

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

#622

Post by kllrnohj »

ChrisTrenkamp wrote: post #459
kllrnohj wrote: post #339

Earlier quoted context omitted.

Zig is a love letter to C. It does not do much of anything to address memory management. Doesn't even have any concept of ownership like C++ does (ergo, no equivalent of unique_ptr / shared_ptr). All you get over C is the addition of defer, and even that isn't really that different if you're using GCC or Clang and thus have __attribute__((cleanup)).

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 manual memory management is overall a poor fit.

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

#623

Post by vb-8448 »

perlgeek wrote: post #545
vb-8448 wrote: post #371

Earlier quoted context omitted.

Let's take a SW business like a ticketing system. Do you think 100 enterprises with 1 bln of tokens are going to make a better product than specialized vendor with 100bln of tokens? For sure SW vendors and SAAS like "logo creator" are already dead, but unless the next generation of LLMs aren't going to have an embedded ticketing system the ticketing system vendor will be fine(maybe less headcount, but not sure).

> Do you think 100 enterprises with 1 bln of tokens are going to make a better product than specialized vendor with 100bln of tokens? I'm not sure if this is sound reasoning, because "better product" is very context-dependent. My currently employer has migrated away from RT to OTRS as ticket system, and now moving to servicenow. The RT instance was heavily patched/customized. The OTRS instance was heavily patched/cus…

> or do we LLM-build it from the ground-up?

But in this case you don't spend tokens only on your workflows: you have to patch it constantly, perform vulnerability scans, check and adapt for law changes(eg. if you in europe: GDPR or DORA), create and maintain (again security) integrations with other systems and so on.

And, most importantly, you as a corporate need an internal team to do the work and that means it's a liability to you as a corporate ... and we all know it's better to have some else to blame.

Just imagine the CTO or CISO explaining to the CEO that the data breach they had last week and that cost them millions was due to some customization they did on top of an open source ticketing system.

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

#624

Post by tardedmeme »

dmytrish wrote: post #551
X0Refraction wrote: post #547

Earlier quoted context omitted.

What language doesn't allow memory leaks?

There are two kinds of memory leaks: forgotten manual freeing (all references are gone, but allocation is not) and forgetting to get rid of references that keeps an allocation alive. Both are a kind of logical error, but the first is mostly possible in languages with manual memory management. The second one is a universal logical error (only programmer knows which live references are really needed).

Rust allows reference-counting cycles, right?

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

#625

Post by sdhAt1 »

simianwords wrote: post #583
rkajdh wrote: post #441

Earlier quoted context omitted.

The hype machine is real and we will talk about it as long as it pleases us. It took decades to get rid of smoking in public places and restaurants, and the clankers will eventually fall, too. So cash out before that.

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.

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

#626

Post by mohsen1 »

aapoalas wrote: post #569
mohsen1 wrote: post #107

Earlier quoted context omitted.

Thank you! It's much faster in single file benchmarks (3 to 5x) https://tsz.dev/benchmarks/micro I have optimizations planned for large projects that I'm still flushing out.

Regarding the architecture documentation you have up on tsz.dev, one thing that jumped out to me was the use of the per node typed side pools. A semi-recent talk[0] had benchmarked this and found it to be a deoptimisation: he couldn't explain it, but an audience member suggested it is likely because an AST is not generally very type-homogenous in its visit order. After a CallExpr node the next node to visit is probab…

That talk is very interesting. Thanks for sharing. I'll watch it later.

Now that most of the implementation is nearly completed, I'm building a lot of instrumentations to have better visibility into those things to have concrete answers to that sort of question. I'm experiencing huge RSS right now that could be exactly what you're pointing to.

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

#627

Post by simonkagedal »

zipy124 wrote: post #578
IshKebab wrote: post #263

Earlier quoted context omitted.

Err https://github.com/petgraph/petgraph What are you asking for exactly?

Forgive me if I've mis-understood this thread, but there are unsafe declerations in that crate. Is there really any difference between using unsafe in your own code, versus wrapping it inside some crate? I guess you are making the point that the user does not have to concern themselves with the unsafe declarations?

I would say yes, there’s a difference, in general. I would much rather leave the unsafe code to crates used and tested by many other applications, than have them in the application code itself.

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

#628

Post by ruszki »

bsder wrote: post #386
gobdovan wrote: post #362

Earlier quoted context omitted.

As an amateur in the space: I download on Mac, run `ngspice`, "Error: Can't open display: :0". I look in the code - hardcoded X11-era assumptions. Not exactly modern affordances... Then I try to understand and extract the actual formulas, and there isn't a clean formula layer anywhere. All is procedural, e.g. in `b4v6temp.c` formulas are tangled with branching, caching, model-state mutation. Extracting the computatio…

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

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

I can 100% guarantee you, that these are never mutually exclusive at all.

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

#629

Post by anttiharju »

chrisco255 wrote: post #617
anttiharju wrote: post #562

Earlier quoted context omitted.

I remember looking into the nodejs alternatives some years ago, one way to compare them is to look at the open issues. bun had so many hits for 'segfault' and deno has basically none. Even now: bun (zig) [1] 119 open / 885 closed deno (rust) [2] 0 open / 1 closed I don't think this has that much to do with Zig's anti-AI stance. More about using the right tool for the job. [1] https://github.com/oven-sh/bun/issues?q=i…

You misspelled segfault as segfaut on your Deno search: https://github.com/denoland/deno/issues?q=is%3Aissue%20state... There 10 open and 40 closed on Deno.

oh, good catch! Point stands

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

#630

Post by yen223 »

nextaccountic wrote: post #439
nhatcher wrote: post #211

Earlier quoted context omitted.

That's a post I am eagerly waiting to read. 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. I am a Rust developper myself but I really love Zig and Bun. I am just overly curious of all this.

> 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
Post reply on HN