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

671–680 of 754 posts

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

#671

Post by the__alchemist »

bsder wrote: post #298
gobdovan wrote: post #256

Earlier quoted context omitted.

If this experiment ends up resulting in a real migration path, I think that would be completely awesome. Maybe it means we have a chance to revive older projects such as ngspice [0], but with modern affordances and better safety properties. From your post, though, it sounds like Bun may have been a pretty direct rewrite, without too many hard choices along the way. Is that fair? [0] https://ngspice.sourceforge.io/

[flagged]

I think this is highlighting the problem the poster you're responding to laments!

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

#672

Post by NewsaHackO »

stock_toaster wrote: post #424
NewsaHackO wrote: post #161

Earlier quoted context omitted.

I think the issue is that Zig lost their biggest project, which was a posterboy project for real uses of Zig. Worse, the project felt like Zig wasn't meeting their needs, to the point they abandoned Zig and rewrote their entire project in a different language. Really bad signal for anyone thinking of using Zig for a big project. It is still in beta, but has there been any situation like this, where a upcoming program…

> I think the issue is that Zig lost their biggest project, which was a posterboy project for real uses of Zig. Bun, Ghostty, and TigerBeetle are 3 popular projects that I have heard about using zig.

So I have barely heard about Ghostty, and not at all about Tigerbeetle. Honestly, even Bun is a 2nd/3rd tier JS engine. Regardless, I think that if Bun goes forward with the port, the biggest issue is that for a language to so not live up to expectations that someone was willing to rewrite a ~1M LOC project to an entirely new language is insane. The most common case when there are some deficiencies in a language stalling development is to rewrite/refactor parts of their code base to another language that they feel as though would be better suited, not completely rewrite everything.

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

#673

Post by dakiol »

tomnipotent wrote: post #297
sdevonoes wrote: post #286

Earlier quoted context omitted.

There are software components out there that are the backbone of our industry, and they are not governed by multibillion dollar companies. Linux, postgres, HTTP, TCP/IP, qemu,… It’s not that anthropic/google/openai/etc are unavoidable

> they are not governed by multibillion dollar companies Every tech you mentioned is absolutely governed by multibillion dollar companies. Something like 75-85% of OSS code is contributed by employees doing their day job. Most Linux and Postgres contributions come from those same employees. HTTP and TCP/IP are managed by standard bodies and industry working groups that, you guessed it, are governed by multibillion do…

The way I understood op is that we don't necessarily have to pay to use linux or postgres (when self hosting, for example). But we have to pay to use claude code... which sucks big time (also, open source models are behind private models)

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

#674

Post by zephen »

drysine wrote: post #501
zephen wrote: post #464

Earlier quoted context omitted.

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.

> If you don't explicitly invoke a destructor, you won't get a destructor. When you explicitly invoke a "destructor", you do it on many code paths (and miss one or two) >The fact that you can explicitly invoke the destructor to happen later You don't specify where the `defer`-red "destructor" will be invoked.

> When you explicitly invoke a "destructor", you do it on many code paths (and miss one or two)

Unless, of course, you do it inside a defer block.

> You don't specify where the `defer`-red "destructor" will be invoked.

Yes, actually, you do. It is patently obvious, by code inspection, where the destructor, or anything else specified in a deferred block, will be invoked. defer is a perfectly cromulent part of structured control flow, allowing for easy reasoning about when things occur without having to calculate an insane number of permutations of conditional branch instructions.

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

#675

Post by zephen »

smj-edison wrote: post #522
zephen wrote: post #464

Earlier quoted context omitted.

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.

And more importantly, you can choose what destructor to call. This is perhaps what's most underrated about defer, because defer can select among many different destructors possible, at multiple different levels (group free with arenas, individual free, etc).

Or even whether you need a destructor, or something simpler, like nulling out a pointer or two to break a reference loop.

defer is a perfectly general structured flow concept; it only cares about when you do something, and is completely orthogonal to what you need to accomplish.

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

#676

Post by anthk »

pjmlp wrote: post #556
anthk wrote: post #308

Earlier quoted context omitted.

You would like the T3X language as an exercise to port stuff from Free Pascal too it. In a near future I plan to port two libre text adventures with it, Beyond the Titanic and Supernova. If it fits under T3X, it might run in 'high end' CP/M systems out there. https://t3x.org/t3x/0/index.html https://t3x.org/t3x/0/t3xref.html Beyond these Curses simple games, there's a 6502 assembler and disassembler among a Kim-1 sim…

Have to look into it, thanks.

Eh, I made a typo. The PATH for tcvm and tx0 should be $HOME/t3x0/bin.

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

#677

Post by ethanpailes »

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

In the Haskell community I’ve seen the second kind called “space leaks.” I don’t see it used much outside that community but I like the term and use it when talking about other languages as well.

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

#678

Post by johncolanduoni »

dandellion wrote: post #597
johncolanduoni wrote: post #220

Earlier quoted context omitted.

Running an experiment, the experiment being more successful than you thought, and then deciding to put more effort into a bigger experiment is not hypocrisy. It’s engineering. If you think some of the objective facts they’re putting out (like test coverage and performance) are lies, go and prove it instead of appealing to emotion.

Running an experiment and deciding based on the results is not hypocrisy, it's engineering, 100%. Saying you have no intention of doing something then doing it is not engineering, it's being dishonest. He could have said "well decide when we see the results", why didn't he?

If he wasn’t willing to change his mind after he saw the results, then why would he do it at all? Can you explain the false motivation that you think he communicated in the original kerfuffle about this?

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

#679

Post by shimman »

tkiolp4 wrote: post #592
woah wrote: post #390

Earlier quoted context omitted.

Who's the whiny baby? The developer writing some code in their own repo, or the guy complaining about it on Hacker News?

How can you be so blind? This is all a marketing campaign by anthropic. No more no less. The developers doing the rewrite have no voice at all in this game.

People never want to admit when they're used, especially when they're only used to make someone slightly more rich.

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

#680

Post by shimman »

Greed wrote: post #651
csande17 wrote: post #492

Earlier quoted context omitted.

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…

React router duo would be a great example of known clowns. I totally get what the other person means.

Most of us what to avoid the circus.

Post reply on HN