[flagged]
Bun's experimental Rust rewrite hits 99.8% test compatibility on Linux x64 glibc
681–690 of 754 posts
Re: Bun's experimental Rust rewrite hits 99.8% test compatibility on Linux x64 glibc
#682Earlier quoted context omitted.
>I don't agree that them actually doing an entire draft rewrite can just be characterized as them considering a rewrite. You're right, a rewrite is in existence, and whether it is good enough to be used or expand upon is what is being considered. I don't think that changes the fact that languages don't live or die by whether or not 1 large project using them continues using them. Especially a language like Zig which…
>It's not like Jarred has been begging the Zig devs to implement language changes to make Bun development easier. Zig was always upfront that you will have to manage memory manually, and that allows for operator error. Huh? The patch that Bun submitted was for Zig was about compilation times, and making Zig's type resolution faster. I am sure the Bun developer who is submitting patches to Zig is well aware that manua…
Side note, but Rust's long compile times aren't due to lifetime analysis, it's more about type resolution, monomorphisim, and LLVM codegen. Zig has fast compile times because they've been willing to remove features that don't play well with compiler parallelization (like removing usingnamespace).
Re: Bun's experimental Rust rewrite hits 99.8% test compatibility on Linux x64 glibc
#683Earlier 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
> 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 correctness too - I guess there aren't that many hardcore electrical engineers/physicists/mathematicians that can make sure the results it makes are correct and sound, and debug weird issues coming from numerical stability.
The sort of people who can do this are very rare, and it's not likely they will just randomly decide to donate their time to rewrite the codebase.
Re: Bun's experimental Rust rewrite hits 99.8% test compatibility on Linux x64 glibc
#684Earlier 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/
I hear your suggestion without feeling the need to remark the far too common Linux/Deveoper response of “but if you just do all this other stuff and run it this special way and install 15 dependencies and compile XYZ lib from source then clearly it works fine and you’re mistaken”. That’s exactly the type of thing that is needed is to optimize projects for modern compatibility, portability and safety when other modern…
You can instruct an LLM to improve the test coverage.
Re: Bun's experimental Rust rewrite hits 99.8% test compatibility on Linux x64 glibc
#685Earlier quoted context omitted.
I hear your suggestion without feeling the need to remark the far too common Linux/Deveoper response of “but if you just do all this other stuff and run it this special way and install 15 dependencies and compile XYZ lib from source then clearly it works fine and you’re mistaken”. That’s exactly the type of thing that is needed is to optimize projects for modern compatibility, portability and safety when other modern…
You can instruct an LLM to improve the test coverage.
You are absolutely correct!
Re: Bun's experimental Rust rewrite hits 99.8% test compatibility on Linux x64 glibc
#686Earlier quoted context omitted.
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 us…
> 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.
Right, it's exactly like C, and we kinda all know how that worked out in practice already...
Hence why I called Zig a "love letter to C". If all you want is C with a dash of zest, that's Zig. If you want a modern language that has learned from the many hard lessons the industry has dealt with over the years... well, Zig ain't it. Which is a perfectly fine thing for Zig to be, it doesn't have to be a good general purpose language. We have plenty of those already from Rust to Go to Java/C#/Kotlin to etc...
> arenas are useful for temporary allocations with poorly defined intermediate scope or lifetime (think functions directly or indirectly called by the arena owner).
Arenas are not good for that because the arena as a whole has to outlive all of those poorly defined scopes & lifetimes, which is hard to do. Especially if you later go add on something like an retry-with-backoff or asynchronous metrics/tracing or caching or whatever. Then suddenly you're either fighting use-after-frees or doing deep-copying of data.
Re: Bun's experimental Rust rewrite hits 99.8% test compatibility on Linux x64 glibc
#687Earlier quoted context omitted.
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.
I'm not sure the folks responding can tell the difference.
Re: Bun's experimental Rust rewrite hits 99.8% test compatibility on Linux x64 glibc
#688Earlier quoted context omitted.
>It's not like Jarred has been begging the Zig devs to implement language changes to make Bun development easier. Zig was always upfront that you will have to manage memory manually, and that allows for operator error. Huh? The patch that Bun submitted was for Zig was about compilation times, and making Zig's type resolution faster. I am sure the Bun developer who is submitting patches to Zig is well aware that manua…
Side note, but Rust's long compile times aren't due to lifetime analysis, it's more about type resolution, monomorphisim, and LLVM codegen. Zig has fast compile times because they've been willing to remove features that don't play well with compiler parallelization (like removing usingnamespace).
[deleted]
Re: Bun's experimental Rust rewrite hits 99.8% test compatibility on Linux x64 glibc
#689Earlier quoted context omitted.
The right to be suspicious of the motives of powerful people is infinitely more important than protecting their feelings from being hurt by suspicion.
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.
Re: Bun's experimental Rust rewrite hits 99.8% test compatibility on Linux x64 glibc
#690I harbor some hope that the (sad) fall of human SWEs will at least be accompanied by language defragmentation. We don't need 38 systems languages once human taste is mostly out of the picture.
Since the LLM craze started I have always assumed it would end up in a place where programming languages are dead and LLMs generate something more low level. Programming languages were always designed as an abstraction to allow humans to more easily instruct a computer than by writing binary or assembly. If humans write natural language and don't check the generated code, there's no reason to take the hit of generati…
If anything LLMs should use something higher level because it compresses the context and makes programming closer to natural language they are trained on.
Forcing LLMs to do a shitty job of what a compiler can do deterministically is not a good approach IMO.