631–640 of 754 posts
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…
Earlier quoted context omitted.
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.
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/
That’s exactly the type of thing that is needed is to optimize projects for modern compatibility, portability and safety when other modernization efforts or forks don’t exist.
That said, I suspect this rewrite went so quickly and so optimally because it had the benefit of (effectively) 100% test coverage already in place in a really well defined system. Most open source project spawn from efforts of a single developer who frequently never waste time writing tests for a little side project. Later as it grows, they rarely stop and go back to implement testing. So if you’re truly working with an old dead project, there is a really good chance there are zero tests to be found. That is far more difficult to reach the same completeness unless the goal is simply to port all of those same problems to a new language and hope type safety fixes them.
(Not specific to ngspice, just mean generally.)
Earlier quoted context omitted.
> Do you scrutinize the rest of your dependencies this way? You don't?
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…
In the past at least you could assume the maintainers of the runtime had some kind of mental model of how it worked. In my view, with the way this rewrite has been approached, you can't assume that at all. It's good the test suite passes, but who knows how this will affect the evolution of the codebase? Do we even know if the code is good? How much is just slop? Tests do not test architecture. Is this new rewrite even going to be maintainable? How is the team going to get up to speed on a new codebase in a new language that the main author presumably doesn't even fully understand?
There are many reasons to be concerned. Treating this as no big deal would make me question one's ability to make assessments of technology. There's a world of difference between relying on gen AI heavily in products and leaf nodes of the stack, using it in a purely assistive way, and using it to drive a massive scale rewrite of a base component in a language the maintains team has an unproven amount of experience with. From a reliability standpoint the way this project was executed is completely preposterous, and it's very clearly a marketing stunt more than a sound technical decision on how to drive a project. It's not about the use of LLMs, it's about thee stupid and blatantly obvious generation of cognitive debt all to help sell claude. I'd have way fewer qualms if they used LLMs to do a rewrite in a way that retained developer understanding (i.e. not driven by one person and in such a short timespan that having a robust mental model, even for that person, is highly unlikely)
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?
Yes, in the same way that there's a difference between using `std::Vec` (which uses `unsafe`), and writing an unsafe Vec class yourself.
Or even the difference between using Python (which wraps an unsafe CPython implementation), and doing everything in unsafe Python code.
The difference is that widely used code like CPython and `std::Vec` are much much better tested and audited than anything I would write myself, because so many people use them. This is a continuum so something like petgraph is going to be not as well tested as std::Vec but still way better tested than anything I've written.
Earlier quoted context omitted.
> 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. How does one accomplish change? Even being a martyr doesn't get traction. As far as I can tell, you need to already be powerful. Nobody lets you into that group if you're not aligned with said group. Protests (at least in their current…
Not by trading the same suspicions on the internet with fellow true believers over and over again, I think the past 10 years have proven that pretty conclusively. Maybe people should try some of the things previous social movements did, seemed to work pretty well even against a much more uniform media environment and a stronger hostile social consensus. Protests don’t immediately solve everything, but I think looking…
The onus is on you to prove your point, not me to disprove it.
Earlier quoted context omitted.
Rust is really fun to work with and the compiler is great, just make sure the rewrite takes compile times into account since larger projects often have to be organized in a way that makes compilation reasonably fast.
how long does it take to compile? @jarredsumner: It's basically the same as in zig using our faster zig compiler. If we were using the upstream zig compiler, rust port would compile faster. https://x.com/jarredsumner/status/2053050239423312035
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…
Sure, but you need to consider that, in this case we are talking about the language runtime . It isn't just some other library dep. It's basically the base layer of the stack. It has a huge blast radius. It is, imo, a nontrivial decision to swap runtimes. If problems emerge you can't easily plug some other runtime, that's a major technical decision and should be treated as such. In the past at least you could assume…
Earlier quoted context omitted.
A few off the top of my head: - Video games - Medical device firmware - Synthesizers - Detailed universe-scale physics simulations - Mars rover control software - The Linux kernel
- Video games - only feasible because of computers. - Medical device firmware - hardware control layer for medical devices, which are used to aid in medical procedures. - Synthesizers - help to make music. - Detailed universe-scale physics simulations - help to make certain physics problems more tractable. - Mars rover control software - helps to remote control rovers. - The Linux kernel - control layer that sits bet…
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 devices, which are used to aid in medical procedures.
I should've been more specific, maybe "MRI scanner firmware". Lots of medical devices could not exist without software.
> Synthesizers - help to make music.
Yes, they "help to make music", but synthesizers can produce sounds that humans cannot produce by themselves. If the upthread comment were about technology broadly rather than software specifically, I could've written "saxophones" here.
> Detailed universe-scale physics simulations - help to make certain physics problems more tractable.
"More tractable", or "tractable at all"? Simulations that would take 100 human lifetimes to compute on paper weren't even attempted before.
> Mars rover control software - helps to remote control rovers.
This clearly wasn't ever done without software, so I don't think I understand your response. I can't even imagine how it could have been done without software (my first ridiculous thought is very long cables going from Earth to Mars mechanically controlling a rover, but even if we had a magical material that'd enable that, the cables would get tangled up as the planets move).
> The Linux kernel - control layer that sits between firmware and actual applications, pretty much just a common shared library so apps don't have to each ship with a full stack.
I thought the pushback on this would be "this is just an implementation detail to let us run other software, so it shouldn't count". I don't think I understand your response here either.
---
I guess my general reaction is: sure, if you broaden the criteria enough then you can interpret most anything as "something that a human does/did". Like: humans "have fun" and therefore video games don't count, or humans can jump therefore they "travel through the air" therefore airplanes are just "doing something that humans do". But I don't think this reading of the upthread comment leads to interesting discussion.
Earlier quoted context omitted.
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?
Maybe he didn't think it would work. Maybe even if it does "work" they'll keep the zig version anyway. Maybe further study is needed beyond existing compiling/test-suite. Intentions and perspectives change over time, even only a few days, without dishonesty. I'm guessing that if I said it ... that we have no intention of re-writing in rust ... that what I mean is "we have no intention of spending the extreme cost it…
If you mean "we have no intention of spending the extreme cost it would take to rewrite" then say that, and it would be fine. If you instead say "we have no intention of re-writing in rust" you've said something very different, using a different set of words, which changes the meaning. Especially, if you say it directly in response to someone asking you whether you're going to rewrite or not like was the case here, and say that there's a high chance you'll just be throwing it away, to get the other person off your back. If then you go ahead and do it, expect them to call you out for it.
This is a very simple concept that can generally be understood by children at around age 4. Trying to cover it with vague terms and using the defence of "well I said I had no intention, and I probably won't do it but you see, I saw the results so I changed my mind so the chance was small but not zero", that's what a slightly older kid will try to do to see if they can get away with it, and as any kid discovers, that doesn't fly.
Earlier quoted context omitted.
> On the other hand, Rust is a complex language prone to refactoring avalanches, where a small change in a component forces refactoring distant code. Are you saying this out of personal experience or just hypothesizing? I am working on a large, complex rust project with Claude Code and do not experience this at all.
It can happen like this: - write sleek operator-overloading-based code for simple mathematical operations on your custom pet algebra - decide that you want to turn it into an autograd library [0] - realise that you now need either `RefCell` for interior mutability, or arenas to save the computation graph and local gradients - realise that `RefCell` puts borrow checks on the runtime path and can panic if you get alias…
However, a) I think the compiler telling me everywhere I need to fix it is great, and b) even before LLMs, using compile mode with emacs and setting up a macro to jump to next clippy warning, jump to code, fix, and then repeating in batches of like 20-50 could often make it go quite fast.