[dead]
Rewriting Bun in Rust
401–410 of 560 posts
Re: Rewriting Bun in Rust
#402It's depressing seeing so little critical thinking despite clear and obvious incentives (Bun now being part of Anthropic) behind the reckless decisions that's been made here. Judging by this thread a well-formed article is all that's required for lots of people to just take everything at face value since it confirms the biases of what's currently fashionable.
What specific critical thought(s) do you wish were voiced?
That this is a technological decision rather than rationalizations (e.g. fixing self-inflicted problems are now marketed as a rewrite win) that Rust is a better fit for an Anthropic-owned project.
Re: Rewriting Bun in Rust
#403Earlier quoted context omitted.
Unless you hire smart people from EU and what have you (especially ex-USSR) Which takes us to a point of future US dev salaries if this thing with agents gets better more and more
Sure, but can we not work out how to make humans more efficient for less money? There are obvious optimizations there that none of us would like to be part of.
Humans can't become 100x efficient cost wise. That's how cheap LLMs are.
Re: Rewriting Bun in Rust
#404Earlier quoted context omitted.
You are assuming an infinite productivity boost, i.e. that no programmers at all are needed to make programs. A more realistic scenario is that programmers are still needed in the foreseeable future (for some definition a what a programmer is, even if it's "understands software enough to be able to write good prompts and judge the results"). So the question is how the productivity boost compares to the increase in th…
yes, I assume we will have the 'replicator' from Star Trek, and programs will just appear as you want them. experiencing the gpt3->4o->sonnet4->opus4.6->fable trajectory I am fairly confident what we call programmer today will not exist, in the same time regular people will finally be able to tell computers what to do and this will unlock the next stage of complexity in manufacturing/material science/medicine and so…
> gpt3->4o->sonnet4->opus4.6->fable
While there are a lot of resources being poured into improving and integrating tooling and use cases and increasing model sizes, the leap between the models you notes are not as much as you think it is. It's the same tech that's scalable to a certain limit of diminishing return. It's a recurrent pattern in technology.
> yes, I assume we will have the 'replicator' from Star Trek, and programs will just appear as you want them.
Yes, perhaps one day. Probably no other "job" as they are today will have the same shape and form. Cancer will be cured and fission will be solved. We may even crack teleporting. Let's hope these all happen and the outcome is not detrimental the livelihood of humans.
Re: Rewriting Bun in Rust
#405One thing that I found interesting is that most of the discourse surrounding the topic happened with the assumption that the rewrite was happening with an Opus-like model, and not with Fable. Those assumptions, at least partially, were used as arguments against the fact that the rewrite was feasible and/or a good idea. Clearly the model itself doesn't completely change the narrative, but at least as a note to myself,…
Silly assumption, Mythos was available at the time. Benefit of the doubt should've gone to Jarred.
Re: Rewriting Bun in Rust
#406Earlier quoted context omitted.
From a PL Theory perspective, Zig is vibe-coded. Not sure why people use it.
Pretty much everything except Haskell and the like can be considered as such. That's because closely following PL theory isn't always the right goal for a language. Ergonomics and pragmatism are far more important.
I wouldn't disaree on the ergonomics: a powerful but unusable tool is... useless!
Though ignoring all the PL lessons for the sake of "pragmatism" is just plain ignorance.
Rust has a quite solid theory backing. Zig has nothing interesting really: it's "vibe coded" by someone who was doing game dev or something like that.
Re: Rewriting Bun in Rust
#407Earlier quoted context omitted.
> The rust compiler is very slow. It was very slow. It's gotten a lot faster over time (over 2x faster). It's still not exactly fast , but it's definitely faster than C++. Although C++'s slow compile times are often complained about they were never really enough to stop most people using it, including for games. > a garbage collector eliminates a large amount of defects (including the ones stated in the article) with…
Because contrary to Rust, C and C++ have a culture of binary libraries. You are seldom compiling the world from scratch. Especially in the platforms dear to game devs.
> You are seldom compiling the world from scratch.
True in Rust too though - you're normally doing incremental compiles. And even though you're compiling the world, it's still on par with C++. For example I just tried compiling a hello world Bevy project, which has 462 crate dependencies - pretty big. It took 2m20. Totally reasonable to build an entire game engine and all it's dependencies.
I wish they had reported the compile time of Bun before/after the Rust port - that would have been very interesting.
Re: Rewriting Bun in Rust
#408Earlier quoted context omitted.
do you think price per task completed will rise as well?
Isn't that equivalent? The task here was port Bun from Zig to Rust. He's saying that task will cost more.
That's not the direction of LLM progress these past 2 years. Cost has always decreased per unit intelligence. Open weight models with lower parameters beat gpt4 that we were so impressed by.
Re: Rewriting Bun in Rust
#409Until this bug is fixed, there's no trusting Bun
This is also not a memory issue but an actual logic issue, so Rust doesn't help there.
Re: Rewriting Bun in Rust
#410It seems that Deno made the right decision by choosing Rust from the get-go.
Deno started in Go, but was rewritten in Rust before 0.1