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

451–460 of 754 posts

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

#451

Post by josephg »

dnautics wrote: post #448
josephg wrote: post #380

Earlier quoted context omitted.

It'd take more than that to match rust's borrow checker. Rust's borrow checker tracks lifetimes, and sometimes needs annotations in code to help it understand what you're actually trying to do. I suppose you could work around that by adding lifetime annotations in zig comments. Then you've have a language that's a lot like rust, but without an ecosystem of borrowck-safe libraries. And with worse ergonomics (rust know…

> I suppose you could work around that by adding lifetime annotations in zig comments. you can make a no-op function that gets compiled out but survives AIR > rust knows when it can Drop. and its possible to cause problems if you aren't aware where rust picks to dropp. > And rust can put noalias everywhere in emitted code. zig has noalias and it should be posssible to do alias tracking as a refinement. > But if you w…

> and its possible to cause problems if you aren't aware where rust picks to drop.

Can you give some examples? I've never ran into problems due to this.

> don't use that attitude to suck oxygen out of the air. rust comes with its own baggage

Yeah, that's a totally fair argument. One nice aspect of the approach you're proposing is it'd give you the opportunity to explore more of the borrow checker design space. I'm convinced there's a giant forest of different ways we could do compile time memory safety. Rust has gone down one particular road in that forest. But there's probably loads of other options that nobody has tried yet. Some of them will probably be better than rust - but nobody has thought them through yet.

I wish you luck in your project! If you land somewhere interesting, I hope you write it up.

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

#452

Post by wallstop »

ozgrakkurt wrote: post #442
Tiberium wrote: post #34

I just want to comment that I think it's a good change if we look past the AI involvement. Bun has had an extremely high amount of crashes/memory bugs due to them using Zig, unlike Deno which is Rust. Of course, if Bun's Rust port has tons of `unsafe`, it won't magically solve them all, but it'll still get better

[flagged]

Ah, yes, the "you're holding it wrong" defense. If one tool has a higher safety rating than another, significantly so, preventing entire classes of mistakes from happening that the other does not, in a kind of superset manner - even the most skilled craftsman will inevitably make mistakes that would have been prevented by the safer tool.

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

#453

Post by aragilar »

nextaccountic wrote: post #430
bsder wrote: post #392

Earlier quoted context omitted.

> The spice core that ngspice is built off is terrible code. It has a long history going back to 1970s era fortran. Starting fresh is probably preferable That code is also hyper-optimized for performance . I sincerely doubt you are going to match the performance easily with any random rewrite. Now, if you had a very clear idea of why the code was making assumptions from the 1990s that are no longer valid, then you mi…

> and generally resistant to parallelization (each device can have its own model which are a unique set of linear differential equations). Solving sets of differential equations is something that's parallelizable though See for example how there's physics engines running on GPU. That's mechanics and not electric circuits, however it's differential equations all the same.

Which differential equations are you talking about? Linear ones have standard solutions and are definitely parallelisable (though you can basically just write the solution down by hand). Non-linear ones vary from can basically be approximated by a linear solution with corrections to needing to use relaxation methods (which are obviously not parallelisable).

Mechanics is generally linear, and for game physics engines fast is more valuable than correct (fast inverse square root being the obvious poster child). Add viscosity and you're in for a bad time.

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

#454

Post by aaomidi »

Georgelemental wrote: post #447
gravypod wrote: post #420

Earlier quoted context omitted.

My first "job" in computing, where someone else paid me for code, was in a research context where we were modeling radio propagation. Nothing about that was removing human labor. It in face eventually called for a bunch of humans to interact with each other. See: https://www.hamsci.org/basic-project/2017-total-solar-eclips... I don't think it is fair to claim computers are about putting people out of jobs.

Human labor could do the math by hand

And in fact, was how it was done.

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

#455

Post by thayne »

dinkumthinkum wrote: post #349
thayne wrote: post #162

Earlier quoted context omitted.

It is much harder to write quality stuff in c/c++ that doesn't have memory bugs (use after free, out of bounds access, use of unitialized memory, double free, memory races, etc.). I wouldn't say it isn't feasible to build high quality software in those languages, but even the highest quality software written in those languages has these types of bugs. Zig is better than c, and maybe a little bit better than c++, espe…

Based on what? I am not familiar with this language called called "c/c++" but if you are writing Modern C++, you shouldn't be creating problems like "double free." It's really not that hard to avoid at all. This reminds me of how all the people carried on as if they were making the kernel so much safer not realizing they needed to use unsafe rust. I think so many people call themselves programmers now but so few know…

Sure if you restrict yourself to a subset of c++ that avoids the more unsafe features, you can avoid some of those problems, but not all of them. And IME, a lot of c++ in the wild still uses those unsafe features, especially when interfacing with c libraries. And even if you always use smart pointers and make sure you always initialize your variables there are still plenty of ways you can get undefined behavior in c++.

> This reminds me of how all the people carried on as if they were making the kernel so much safer not realizing they needed to use unsafe rust.

Those are not contradictory. Confining unsafe code to a few unsafe blocks makes it easier to identify areas that need closer scrutiny. Just because there are unsafe blocks doesn't mean that using rust in the kernel isn't making it safer.

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

#456

Post by antonvs »

righthand wrote: post #142
des429 wrote: post #136

Earlier quoted context omitted.

What's your point

To demonstrate engineers may not be as skilled and knowledgeable as they appear. To make such a comment then turn around and make an announcement days later indicates that the engineers are not skilled in the tools they’re using or even possibly the domain they’re working in.

Being an expert software developer - which Jarred Sumner indisputably is, having created Bun - doesn't automatically make you an expert on predicting the improvements in software development performance that LLMs enable. All of us - experts and amateurs alike - are in the process of figuring that out, in real time, around the world, right now.

Underestimating how quickly a non-trivial project will come together is an almost unheard of phenomenon. It used to invariably be the other way around, to the point that there are laws about it, like Hofstadter's Law, which says that projects always take longer than anticipated, even when accounting for the law itself. Or Fred Brooks' work, which puts limits on how much the development of software projects can be sped up.

The sane takeaway here is that if what's being reported is true (keeping in mind it's coming from a newly minted Anthropic employee), it implies an astonishing, unheard of improvement in software development speed, at least for certain kinds of tasks, enabled by LLMs.

To somehow twist that into "experts may not be as skilled and knowledgeable as they appear" or "not skilled in the tools they’re using" makes me think of the Charles Babbage quote, "I am not able rightly to apprehend the kind of confusion of ideas that could provoke such [an opinion]."

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

#457

Post by [deleted] »

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…

[deleted]

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

#458

Post by johncolanduoni »

rkajdh wrote: post #441
johncolanduoni wrote: post #425

Earlier quoted context omitted.

What do you think one would have to pay to have flesh-and-blood engineers get a cross-language port of a codebase of over half a million lines with a broad test suite to over 99% conformance? I think it would be astronomically high, especially given that for this specific project your hiring pool is going to be limited to people who can get up to speed with Zig and JavaScriptCore right away (or you’re going to have t…

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.

Did I say it wasn’t real? Or tell you that you couldn’t talk about it? No, I just pointed out that it’s all anybody talks about and it’s boring and doesn’t engage with anything specific about this stunt/project. And I can make melodramatic analogies too — like to the panic about global overpopulation that led to mass sterilizations in The Emergency. Panic is not an unalloyed good, and if you want to fight “the clankers” you should understand what they are and are not capable of.

Also I already cashed out, jokes on you.

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

#459

Post by ChrisTrenkamp »

kllrnohj wrote: post #339
afavour wrote: post #57

Earlier quoted context omitted.

> There is a lot of quality stuff made with C/C++ There’s a lot of leaky crap written in those languages too. One of the core promises of Rust is that the compiler will catch memory issues other languages won’t experience until runtime. If Zig doesn’t offer something similar it’ll make Rust very compelling.

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 bunch of memory and release it all with a single free, which makes it much easier to reason about your program's memory safety.

Casey Muratori has a good video talking about this. https://www.youtube.com/watch?v=xt1KNDmOYqA

And about Zig, you have an Arena Allocator out of the box: https://zig.guide/standard-library/allocators/ . And it's not just limited to that, you have debug allocators that detects memory leaks and gives you stack traces where they occurred.

This isn't to say that Zig is great at everything. I think Rust is great for things like kernels, high-frequency trading systems, and authentication servers where memory safety and performance is paramount. But for things like video games, memory leaks and buffer overflows aren't that big of a deal, and Zig's "Good Enough" approach is great for those types of applications.

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

#460

Post by tempaccount5050 »

gravypod wrote: post #420
tempaccount5050 wrote: post #306

Earlier quoted context omitted.

Whether or not you want to admit that is up to you. If you're selling automation or efficiency gains, you're removing human labor.

My first "job" in computing, where someone else paid me for code, was in a research context where we were modeling radio propagation. Nothing about that was removing human labor. It in face eventually called for a bunch of humans to interact with each other. See: https://www.hamsci.org/basic-project/2017-total-solar-eclips... I don't think it is fair to claim computers are about putting people out of jobs.

I think it is. Before computers you would have had to write all that down on paper logs. By using code, you saved yourself time. If it wasn't less labor, you wouldn't have done it that way.
Post reply on HN