Rendered at 21:44:46 GMT+0000 (Coordinated Universal Time) with Cloudflare Workers.
xlii 2 hours ago [-]
I wonder if I'm the only one for whom the bun project vanished completely.
In software code is only part of the package. Stability and trust are big part of it, too. And for me 1800 files change PRs created by Anthropic overseen by one person is not necessarily adding to the package.
Even it that'd be the best code and design in the world, I won't use it. I don't trust it.
egorfine 1 hours ago [-]
Yeah, I have prepared our company software for migration back to node.
I would like to read the promised Jarred's blog post (if it ever comes out) before pulling the plug though.
okeuro49 24 minutes ago [-]
It looks like quite a lot of analysis went into the rewrite
might as well use openclaw at this point. that's the same vibe I'm getting with bun. from engineering excellence and jesus this guy really sweats the details (using zig woah!) to wow this is just openclaw ai permagenerated stuff. not a fan
Years ago I did "multithreaded Javascript" by calling into Rhino (Javascript engine) from multiple threads. Granted, I converted Rhino from JVM to CLR, so it wasn't exactly a stable environment, but it did "work".
aardvark179 1 hours ago [-]
It’s certainly possible, but I worry that weird things can happen when doing something as “simple” as defining a property if another thread is messing with the prototype chain. Even thread safe property maps can’t entirely save you because operations that need to go up the prototype chain are not and cannot be atomic.
sroussey 1 hours ago [-]
This won’t work well without a few other things, like structs
Structs aren’t necessary for my proposal to work well
pizlonator 51 minutes ago [-]
My blog post explains how to make prototype chain operations work in the presence of threads
CharlesW 3 hours ago [-]
That's excellent work and a great read, Filip!
quotemstr 2 hours ago [-]
Yes, you did. And it's a good design. You even did the GC question justice.
My concern is more in the spirit of "Your scientists were so preoccupied with whether or not they could, they didn't stop to think if they should.". Of course JS being single threaded wasn't a hard constraint. Lift it, and people like you can use the parallelism to do great things.
The problem is that most developers are not you. Shared memory concurrency is foot-artillery (especially if truly parallel). Adding threads to the JS ecosystem is selling W48 nuclear artillery shells at the toy store.
JS's ostensible limitation to a single thread forced users to do what they should have been doing anyway: message-passing, thread-per-core architecture, and actor-ish stuff. People who don't know better reach for shared memory concurrency because it seems like a good way to solve problems, but it's actually a dangerous attractor in idea space. JS engine limitations were accidentally keeping people away from it. Now that they can hear the siren's song of a mutex, they'll run around on the hard problems of parallel programming.
Now, that's not a reason to avoid shipping such a system. It's just not something I would have chosen to implement for the masses.
pizlonator 2 hours ago [-]
I don’t understand the thread phobia
Comparing it to nukes is a bit extreme, don’t you think?
hexasquid 2 hours ago [-]
This is consistent with the endless contempt people have had for JavaScript and those that use it.
pizlonator 2 hours ago [-]
Yeah I don’t get that either
It’s a super successful language
Waterluvian 2 hours ago [-]
I think with ES6 and newer things really cleaned up and now we’re left with avoidable ugly parts, of which every language has.
Before when you didn’t even have strict equality checking, for example, you were forced to know about implicit type casting.
Getting on the same page with modules also helped a lot. Typescript directly in Node is great. Look mom, no build system!! I’m just hoping one day browsers will accept TS the same way.
thedelanyo 22 minutes ago [-]
> I’m just hoping one day browsers will accept TS the same way.
Wouldn't that be a direct kill of JS?
ricardobeat 48 minutes ago [-]
When did JS not have strict equality?
jazzypants 26 minutes ago [-]
1995-1999. Strict equality was introduced in ES3 which was first released in December 1999.
You still need a compiler for TSX, though. There's also a tiny bit of non-erasable Typescript (enums).
Waterluvian 1 hours ago [-]
There’s a mode to pretend those features don’t exist and not allow them. Meaning it gets far simpler to just type elide rather than any actual compilation effort. I think this idea is getting more popular and it would be kinda nice if TS committed to not adding any more features like that.
MrJohz 31 minutes ago [-]
TS has committed to not adding any more features like that. Features only get added when they reach a certain threshold on the TC39 standardisation track.
hyperhello 1 hours ago [-]
It's successful because it's been kept away from the kind of programmers who think the time spent to endlessly specify everything four times is nothing compared to the sadness of losing a byte or a cycle. These are the descendants of people who hundreds of years ago would have insisted that real work is in Latin. C++26 is available for them, or Node/React with hundreds of dependencies if they want JavaScript, or they can even compile and run whole operating systems into WASM now, or anything else. Just let JavaScript be the domain of people who do other things for fun.
gwbas1c 20 minutes ago [-]
Back when Node was the new kid on the block, the single-threaded async model was justified by pointing out that the major challenge with multithreading was shared memory. It's one of the strong points of the language / environment, because you never have to worry that some callback will run on another thread.
Javascript shines when it's handling multiple concurrent IO operations, and concurrent operations can become very thread-like with async/await syntax. Multithreaded code in this context only helps with CPU-bound operations; but if I was doing something CPU-bound, I'd probably choose a different language.
One thing I wonder, does Bun (or Node) have a way to call into native code on another thread, but still keep single-threaded once back in JavaScript?
nasretdinov 3 hours ago [-]
The code needs to be not in the state of "no obvious bugs", but "obviously no bugs". Especially the programming language runtime. Otherwise there is no hope you can sustain any development whatsoever
pizlonator 3 hours ago [-]
No language runtime is ever in a state of "obviously no bugs".
Good luck demanding that of anything of JSC's or LLVM's complexity
TomatoCo 3 hours ago [-]
On one hand, sure, the entire point of a programming language is to make complex ideas able to be expressed in simpler abstractions. On the other hand, we can damn well try.
pizlonator 3 hours ago [-]
Damn well trying to enforce an "obviously no bugs" rule in a language runtime would mean zero progress in language runtimes.
We certainly wouldn't have gotten to where we are with runtime and compiler quality and performance if we had damn well tried to enforce such a rule
nasretdinov 3 hours ago [-]
IMO the very minimum requirement should be that you've demonstrated effort to reduce unnecessary complexity of the problem. Sure, some problems are complex enough that there might not exist an obvious solution, yet usually after a while once you're familiar with some topic the existing solutions do start to appear obvious. If they're not I'd argue we're doing something very very wrong
pizlonator 2 hours ago [-]
Adding concurrency to JavaScript definitely falls in the "complex enough" category
So does basically any feature or optimization in a JS runtime
nasretdinov 2 hours ago [-]
I think it's also worth distinguishing _problem complexity_ and _solution complexity_. The problem might be really really hard (and it very obviously is in the case of adding multi-threading to JavaScript). But it does not mean that the solution has to be hard to understand. It doesn't mean that any average PHP developer (I can say that, I started with PHP) should be able to verify the correctness of the patch, but for a person who is well familiar with the area there shouldn't exist areas they can't understand.
Look at the description of your own Fil-C: it focuses on clarity of explanation of how it works, and it actually does make sense (and, hopefully, works well enough too). Compare that with the pull request sent here. I'll wait
pizlonator 2 hours ago [-]
The solution to concurrency in JS is hard to understand and I would expect even hardened JSVM folks (me included) to be super confused by it
nasretdinov 1 hours ago [-]
I think you're underselling your own level of intelligence Fil. If even you would be confused by an implementation (and you're the author of the concept) what chances do you think this PR has to actually work correctly?
pizlonator 35 minutes ago [-]
Lots of tests
norir 2 hours ago [-]
Perhaps then it would be better to not use tools of this level of complexity.
nasretdinov 2 hours ago [-]
I think LLVM is a perfect example of what happens when it's too complicated: it's slow, it's bug-ridden when you stray away from the beaten path (e.g. Rust hits bugs in LLVM like this one https://www.reddit.com/r/rust/comments/l4roqk/a_fix_for_the_... ), and it's really hard to use and understand.
It's obviously not useless because of that, but it's a great example of what happens when you cannot fully control the implementation complexity
spankalee 2 hours ago [-]
So don't use compilers at all?
nasretdinov 2 hours ago [-]
Compilers aren't made equal either. E.g. compare Visual Studio C++.NET compiler and something like Go. And Go isn't that simple either to be fair
peesem 2 hours ago [-]
how would you suggest we compile literally anything?
baq 2 hours ago [-]
Won’t happen unless the thing is implemented in lean4.
nasretdinov 51 minutes ago [-]
Proving something is correct doesn't automatically make it obvious though. For it to be obvious it needs to either be intuitive or it needs to be (reasonably) simple
torben-friis 2 hours ago [-]
>Scalability, measured (the honest section)
Ugh.
poly2it 53 minutes ago [-]
I can't stand Claude's "honesty". Anthropic should hire some writers and linguists to make the output a bit more bearable. It's mentally taxing to read this type of dull text for hours every day.
greenchair 2 hours ago [-]
almost spit out my drink!
Retr0id 3 hours ago [-]
Is there a human-authored description of the PR anywhere?
How are there not race conditions all over the place?
pizlonator 3 hours ago [-]
It's substantially based on my design, read the blog post I wrote (linked in another comment here)
It's a very complex thing, but not impossible. I'm very impressed that any LLM can do this
3 hours ago [-]
sothatsit 2 hours ago [-]
It’s pretty incredible to me that a mammoth change like this is possible to prototype now using LLMs.
It makes me wonder how much of our software stack will become more malleable to big ideas and experiments in the future, like Filip’s idea here. Even if you don’t want to merge the code, it’s still an incredible existence proof that something like this could work.
rzmmm 13 minutes ago [-]
Bingo. Dozen LLM-prototypes and then a manmade final patch which is merged.
tomjakubowski 1 hours ago [-]
For what it's worth: this isn't a PR on mainline WebKit. The PR is on bun's own fork of WebKit (and JSC), which already has a bunch of their own changes.
mirekrusin 33 minutes ago [-]
Did they rewrote WebKit in Rust or not yet?
piterrro 2 hours ago [-]
think of all the poor web devs trying to use multiple threads on top of asynchronous operations. wild.
hexasquid 2 hours ago [-]
Standard contempt for web developers.
1 hours ago [-]
JCTheDenthog 1 hours ago [-]
I mean if they hadn't constantly reinvented the wheel by refusing to learn about existing technologies, and if they hadn't then effectively forced web dev garbage on the rest of the programming world via their sheer numbers, then they might not have earned such contempt. See React in the Windows start menu or Claude's CLI being written in React as two of the most egregious examples (but one of only many).
As I saw someone here on HN describe it a year or two ago, it's like mayflies debating politics.
curtisblaine 9 minutes ago [-]
Worth noting it's not web devs pushing for React in the Windows start menu. It's PMs looking at the problem and concluding React is the least painful way to solve it (correctly or incorrectly, but I doubt they optimize for the same measurements you do).
Ink (the React renderer) in Claude code, on the other hand, makes a lot of sense for interactive CLIs where you want to componentize your menus and dialogs. Actually not using a component framework normally ends up in state / render chaos.
Re: mayflies debating politics: React has been there for 13 years, and while the interface has shifted a couple of times (object factories to classes to functions), the main idea has always been really simple and really stable: isolated declarative components that can optionally have state and side effects. Many other popular frameworks have come and gone in the meantime.
asxndu 3 hours ago [-]
I am shocked by how good and comprehensive the bun docs & ecosystem is.
Its so well contained I never need to look outside its ecosystem for basic components. It's a true "Batteries Included" runtime.
Retr0id 3 hours ago [-]
Last time I read the bun docs I spotted an off-by-one bug in sample code, so I opened a github issue. An AI bot responded, confirming the issue, and opened a PR to fix it - A simple "+ 1" added in the right place. Two other AI bots reviewed the PR, which went on for several rounds of "improvements". Last time I checked, neither the issue nor the PR received any human attention (actually I just checked again, and the PR has been closed by stalebot).
Aurornis 3 hours ago [-]
> (actually I just checked again, and the PR has been closed by stalebot).
The difference is that the PRs to fix that problem were already open when I created the issue. I was unaware of them (I only searched for duplicate issues, not PRs addressing the problem). The robobun comment implies there are 5 open PRs addressing it, but I could only find two. They still haven't been merged, a month later.
Leaks memory left and right. And the core team seems unable to fix it.
fg137 3 hours ago [-]
Yet I rarely hear about it being used in production systems and replacing Node.js.
tomjakubowski 1 hours ago [-]
From what I've heard there are two main use cases:
- People use bun as an all-in-one frontend web bundler. Personally, I just use esbuild (and webpack, if I'm working on a system using its module federation, like Jupyterlab). My understanding is bun has a machine-translated port of esbuild (ported to Zig, then to Rust) built into it.
- Claude Code runs on bun.
The second point has to be why Anthropic acquired them.
doodlesdev 2 hours ago [-]
It famously is extremely memory leaky, with the core team having no idea how to fix it. With the new AI-automated unsafe Rust migration, this piece of slop may never actually become production-ready.
egorfine 34 minutes ago [-]
I run it in production for multiple systems.
Ready to migrate back to node once the slop version is out.
dgellow 6 minutes ago [-]
Why not deno?
anematode 3 hours ago [-]
This is terrifying. Evidently based on prior art by Mr. Pizlo – indeed, where's the acknowledgement of that?? (edit: I missed it) – but I'm assuming that was never translated into code.
I love the idea of experimentation and innovation; I abhor the idea of it being dependent on Anthropic and their theft. I've never rooted for the Chinese labs more strongly than after seeing this.
bojan 3 hours ago [-]
The acknowledgement is in the PR description, section "The design, and what it's based on".
anematode 3 hours ago [-]
Thanks, fixed
pavlov 11 minutes ago [-]
This LLM PR description style is getting very tiresome. The obvious signs are the little lists (“not x, not y, not z”) and pompous declarations like this:
“The bring-up log at the bottom is honest about what broke and what it took.”
skeledrew 1 hours ago [-]
This has me thinking of Python's NoGIL movement.
mwkaufma 2 hours ago [-]
Anslopic
applfanboysbgon 3 hours ago [-]
Imagine somebody doing a drive-by on your repo and dropping a 270k loc PR expecting you to merge it. Bonus points if they can't even put in the 0.001% smidgen of effort to write why they think the PR is useful or necessary in their own words. Oh, but we don't have to imagine it, because there are people who actually do that!
Retr0id 3 hours ago [-]
The PR is against bun's fork of WebKit, not upstream.
fg137 2 hours ago [-]
The title is of this post is definitely confusing if not misleading.
applfanboysbgon 3 hours ago [-]
Oh, my mistake, I thought they were doing the zig thing again.
gavinray 3 hours ago [-]
One of the biggest things preventing software like SQL DB's from being written in TypeScript is the lack of proper threading.
I genuinely think you could write a competitively-performant multi-threaded DB in Bun + TS if you had shared-heap threads and fast atomics/locking primitives.
jerf 2 hours ago [-]
"I genuinely think you could write a competitively-performant multi-threaded DB in Bun + TS if you had shared-heap threads and fast atomics/locking primitives."
Not likely. Databases that attain any significant use in the field end up getting optimized to the n'th degree because they're the bottleneck of the entire system of every system they get put into. Javascript runs on the "5-10x slower than C" language tier. Personally I think even picking Go, in the "2x slower than C" tier, is a huge mistake, though a few people seem to be doing OK with it. I don't think you can call it "competitive" when your C++ or Rust competition is consuming a factor of magnitude less resources.
WASM DBs, maybe, especially as it continues to mature. Not Javascript.
hedgehog 23 minutes ago [-]
Something compiled to WASM still gives a fair amount of control over memory layout, something that AFAIK is not possible in JS without building effectively a new embedded language on top of an array (Emscripten being an existence proof that you can do more or less anything that way).
One place where an interpreter + JIT language could be interesting is if it were sufficiently safe to allow user code into the query execution engine, such that the JIT could optimize it all together.
n_e 3 hours ago [-]
You have web workers, and for shared memory and synchronisation respectively SharedArrayBuffer and the Atomics namespace.
quotemstr 2 hours ago [-]
Exactly. Nothing stops your writing a high-performance parallel database in TypeScript today. Given that runtimes and tooling are actually pretty good, I think TypeScript is actually a fine choice of language for the task.
The only thing you can't do with JS today is share a heap across threads. You have SharedArrayBuffer. You have atomics. You don't need a shared address space.
There's a high performance database called "PostgreSQL" you may have heard about. It doesn't use threads. It uses separate processes and shared memory: just like standard JavaScript, with its service workers and SharedArrayBuffer.
If not sharing an address space is good enough for PostgreSQL, it's good enough for your TypeScript database.
The problem with shared-everything, unmarked, preemptive-parallel concurrency is that 90% of the time it gets used by people who don't know they shouldn't.
Groxx 3 hours ago [-]
Are you hoping to, like, run postgres in nodejs or something?
You can get parallelism with web workers and shove sqlite over there if you like, e.g. for running more intensive queries. Beyond that I kinda don't see much of a reason to use JS for databases, except maybe for isolation (e.g. via wasm).
piterrro 3 hours ago [-]
I honestly should print that comment and hang it on a wall.
> …competitively-performant…
Care to explain competitively to what?
forrestthewoods 3 hours ago [-]
…but why? JS/TS does not seem like the right tool for the job?
nesarkvechnep 3 hours ago [-]
It's probably what they know so not anything new should be learned.
bakugo 1 hours ago [-]
I like how the page is actually struggling to load due to the sheer amount of bot activity on the PR.
On a completely unrelated note, I wonder why Github is always down. Real mystery there.
throwrioawfo 1 hours ago [-]
> Shared-memory threads for JavaScriptCore. new Thread(fn) runs fn on another thread, in the same heap, with the same objects. No structured clone, no message passing, no SharedArrayBuffer-only escape hatch. You share an object by sharing the object.
If you can't even be bothered to write a non-slop PR description, it doesn't bode particularly well for the content of the PR itself...
user43928 1 hours ago [-]
I previously gave this author and the bun rewrite the benefit of the doubt. But an obvious slop PR to the WebKit repository?
I'd tap out here too if I was a maintainer. Even if the change was perfect, if you could not be bothered to write the PR description, I am not going to waste my time with it.
Edit: My bad, the PR is to a fork, in that case it's not our business how the PR description is written.
Me1000 45 minutes ago [-]
It’s a PR on their private fork, they’re not expecting to have this accepted upstream.
Yoric 3 hours ago [-]
Eh, Firefox/Thunderbird had multi-threaded JS in SpiderMonkey in the late 90s.
Then it was removed it because it made garbage-collection a real mess (the JavaScript gc needs to walk through lots of C++ data, some of it may have specific requirements for destruction/finalization).
I hope it's better this time :)
pjmlp 3 hours ago [-]
The JS / interoperability is why V8 eventually added a C++ GC.
the__alchemist 1 hours ago [-]
Bun alert!
richardbarosky 3 hours ago [-]
Don't have much to say on the topic but recalled this excerpt from the book Coders at Work in the chapter interviewing Douglas Crockford.
```
In my experience, the worst bugs are the real-time bugs, which have to do with interactions with multiple threads. My approach to those bugs is to avoid making them. So I don't like threads. I think threads are an atrocious programming model. They're an occasionally necessarily evil, but they're not necessary for most of the things we use threads for.
One of the things I like about the browser model is that we only get one thread. Some people complain about that—if you lock up that thread, then the browser's locked up. So you just don't do that. There are constantly calls for putting threads into JavaScript and so far we've resisted that. I'm really glad we have.
The event-based model, which is what we're using in the browser, works really well. The only place where it breaks down is if you have some process that takes too long. I really like the approach that Google has taken in Gears to solving that, where they have a separate process which is completely isolated that you can send a program to and it'll run there. When it's finished, it'll tell you the result and the result comes back as an event. That's a brilliant model.
```
RealityVoid 2 hours ago [-]
Soo... Essentially, still threads, but no shared state between threads, and they talk through this message interface?
masklinn 1 hours ago [-]
Threads which can’t share state are called processes.
quotemstr 3 hours ago [-]
I know a thing or two about VMs. Reading this post, I thought to myself "No way it was this easy. No performance hit in the single threaded case? No way".
I was right. Buried in the middle of the post is this tidbit:
> v1 collects synchronous and stop-the-world
Ah, there it is! I knew it!
Parallel garbage collection is a very hard problem. Years of experience and subtle implementation are required to get something like ZGC. A stop-the-world garbage collector will kill tail latency in many use-cases, especially for large programs. I'd say a good GC is the hardest part of a modern VM, even harder than a good JIT: not that a JIT is easy.
Show me multi-threaded JS with generational mark, sweep, compaction, etc. running in parallel with the mutator and I'll be impressed. (The smart thing would be to base it on the JVM or CLR. Doesn't count though.)
It's all so exhausting, this current programmer culture of doing the easy part of a system thing X and presenting your work, without qualifiers, as a complete and modern X.
Sure, sure, we can have memory safe C (just don't have any data races!). Sure, we can have an AI C compiler (just don't expect type checking). Sure, we can port SQLite to Rust (but don't expect it to be fast). Sure, you can one shot a Slack clone (just don't expect performance or security). Doing the easy part of a thing is not doing the thing! You can't trust a README's feature list these days.
To be fair, given that the README is obviously unedited LLM output, the authors might not have realized that their agents cheated and made threading easy by pessimizing the GC. The LLM certainly did though.
Now, maybe the JSC really is adaptable to a multi-threaded mutator world. If it is, great. But over and over, I've seen AI say "I will defer and charter $HARD_THING" and mean "I have no idea how to do $HARD_THING, so I'm creatively reinterpreting your request to make it easy". You have to be endlessly vigilant for LLMs subtly twisting your tasks into easy versions that might technically meet the requirements but they are less complete than you intend.
hedgehog 17 minutes ago [-]
I sometimes wonder if full GC is really worth it. For a lot of applications some compile time analysis + refcounting is close enough, and for some others arenas (per frame rendered, per request served, etc) are as fast as a GC to allocate and faster than malloc to free. Could we make the rest a compile error and save most people most of the time a lot of pain?
12_throw_away 2 hours ago [-]
In contrast, I don't know that much about VMs.
But if you're making a big fundamental change to a system, I do know that it shouldn't start with a single "+279,276 -4,272" PR. It starts with a small patch with the core of the change so that everyone can understand what it does and how it works. (I mean, ideally, a change like this starts with documentation, discussion, diagrams, surveys of existing implementations, etc, before you start writing code)
You don't cram everything into a single 270K line PR, even (especially) with an LLM, unless you specifically don't want anyone else to look too closely at what you did.
adem 3 hours ago [-]
I will never get over the overuse of adjectives like "real" in LLM outputs, it dilutes the meaning of these words.
Nnnes 3 hours ago [-]
Related, spinning "I did something poorly" into "I am being honest"
> Scalability, measured (the honest section)
so what about the other sections?!
fzzzy 1 hours ago [-]
The dishonest sections
lgtx 3 hours ago [-]
Counting 62 em-dashes in the PR description alone, are people reading those walls of slop anymore?
bakugo 3 hours ago [-]
No human has ever read or will ever read the PR description.
No human has read or will ever read any of the code, nor was any human thought involved in its creation.
Everything is performative now. As long as you just keep your eyes closed and believe it all works, that's all that matters.
skeledrew 1 hours ago [-]
Does it not work? I'm watching for the explosion and following "told you so"s.
slopinthebag 3 hours ago [-]
Course not. They have an LLM summarize it for them.
balgaly 9 minutes ago [-]
[dead]
MuffinFlavored 3 hours ago [-]
I know a ton of people absolutely hate this level of "LLM code + LLM PR description + LLM PR review" but my boss would have an orgasm if I was able to use AI half as well in our org... :/
Atotalnoob 3 hours ago [-]
Just stop caring about quality. It makes it 10x easier to produce slop with AI if you never bother to check
this_user 29 seconds ago [-]
Software Engineering may have very well entered its own Eternal September.
Yoric 3 hours ago [-]
I just wrote an internal report in my company.
My conclusion from the project I'm working on is that, as of this day, there is no way to have both this so-called 20x performance improvement _and_ any kind of quality. Or security if whoever is running the agent has any token in an .env anywhere on the same file system.
We'll see in which direction the CTO takes this. My bet is not on quality.
MuffinFlavored 55 minutes ago [-]
The company I work for, the code Opus 4.8 is able to generate, is higher quality than what was left behind by 10+ years of contractors that have come and gone.
Yoric 4 minutes ago [-]
I understand that some developers produce very poor code. Maybe in some companies it's the norm. Luckily for me, I've seldom worked alongside such developers.
In my company, the code Opus 4.8 is able to generate appears competent, but if you dig a bit, it contains way more timebombs than anything I've seen the team members develop.
rustystump 3 hours ago [-]
It is sad. This is a new reality. No one reads code, it is agents all the way down. It has been long enough now that I can safely say AI has not sped up project delivery nor improved quality when it did ship.
Is it the AI or the people using it? Idk
fzzzy 1 hours ago [-]
It is sad. This is a new reality. No one reads machine code, it is compilers all the way down. It has been long enough now that I can safely say C has not sped up project delivery nor improved quality when it did ship.
mannanj 1 hours ago [-]
Humans made the AI, and their goal is profit, so there’s no AI using people: it’s humans using people.
MuffinFlavored 2 hours ago [-]
> Just stop caring about quality.
I'm not so sure this is true anymore. It may have been years ago but... can you honestly say "the Bun project was fully AI written, therefore the quality is poor"?
Any concrete examples/proof?
stephen 3 hours ago [-]
Amazing. This is what the Typescript team should have done instead of rewriting to golang -- innovate the runtime.
bastawhiz 3 hours ago [-]
That doesn't help anyone using Node. I don't want to have to start using a new runtime because my compiler is slow. That's wild.
stephen 3 hours ago [-]
You're already using a new runtime with tsgo -- it's golang at build time -- but still running Node in prod, so the same could work here. :-)
Agreed I would not want all Typescript users forced to use /this/ runtime, but if the TS team shipped tsc as "oh now it's uses a special fast JS runtime" (just like tsgo is a different runtime) I'd love to at least have the option of using the same special fast runtime in my own still-written-in-TS apps.
Seems I've either struck or a nerve, or miscommunicated, given the insta down votes.
In software code is only part of the package. Stability and trust are big part of it, too. And for me 1800 files change PRs created by Anthropic overseen by one person is not necessarily adding to the package.
Even it that'd be the best code and design in the world, I won't use it. I don't trust it.
I would like to read the promised Jarred's blog post (if it ever comes out) before pulling the plug though.
https://bun.com/bun-unsafe-audit
If the tests pass, then why not accept the rewrite?
An interesting article of Prisma using the rewrite:
https://www.prisma.io/blog/bun-rust-rewrite-prisma-compute
https://webkit.org/blog/7846/concurrent-javascript-it-can-wo...
https://tc39.es/proposal-structs/
My concern is more in the spirit of "Your scientists were so preoccupied with whether or not they could, they didn't stop to think if they should.". Of course JS being single threaded wasn't a hard constraint. Lift it, and people like you can use the parallelism to do great things.
The problem is that most developers are not you. Shared memory concurrency is foot-artillery (especially if truly parallel). Adding threads to the JS ecosystem is selling W48 nuclear artillery shells at the toy store.
JS's ostensible limitation to a single thread forced users to do what they should have been doing anyway: message-passing, thread-per-core architecture, and actor-ish stuff. People who don't know better reach for shared memory concurrency because it seems like a good way to solve problems, but it's actually a dangerous attractor in idea space. JS engine limitations were accidentally keeping people away from it. Now that they can hear the siren's song of a mutex, they'll run around on the hard problems of parallel programming.
Now, that's not a reason to avoid shipping such a system. It's just not something I would have chosen to implement for the masses.
Comparing it to nukes is a bit extreme, don’t you think?
It’s a super successful language
Before when you didn’t even have strict equality checking, for example, you were forced to know about implicit type casting.
Getting on the same page with modules also helped a lot. Typescript directly in Node is great. Look mom, no build system!! I’m just hoping one day browsers will accept TS the same way.
Wouldn't that be a direct kill of JS?
https://www-archive.mozilla.org/js/language/e262-3.pdf
Javascript shines when it's handling multiple concurrent IO operations, and concurrent operations can become very thread-like with async/await syntax. Multithreaded code in this context only helps with CPU-bound operations; but if I was doing something CPU-bound, I'd probably choose a different language.
One thing I wonder, does Bun (or Node) have a way to call into native code on another thread, but still keep single-threaded once back in JavaScript?
Good luck demanding that of anything of JSC's or LLVM's complexity
We certainly wouldn't have gotten to where we are with runtime and compiler quality and performance if we had damn well tried to enforce such a rule
So does basically any feature or optimization in a JS runtime
Look at the description of your own Fil-C: it focuses on clarity of explanation of how it works, and it actually does make sense (and, hopefully, works well enough too). Compare that with the pull request sent here. I'll wait
It's obviously not useless because of that, but it's a great example of what happens when you cannot fully control the implementation complexity
Ugh.
How are there not race conditions all over the place?
It's a very complex thing, but not impossible. I'm very impressed that any LLM can do this
It makes me wonder how much of our software stack will become more malleable to big ideas and experiments in the future, like Filip’s idea here. Even if you don’t want to merge the code, it’s still an incredible existence proof that something like this could work.
As I saw someone here on HN describe it a year or two ago, it's like mayflies debating politics.
Ink (the React renderer) in Claude code, on the other hand, makes a lot of sense for interactive CLIs where you want to componentize your menus and dialogs. Actually not using a component framework normally ends up in state / render chaos.
Re: mayflies debating politics: React has been there for 13 years, and while the interface has shifted a couple of times (object factories to classes to functions), the main idea has always been really simple and really stable: isolated declarative components that can optionally have state and side effects. Many other popular frameworks have come and gone in the meantime.
Its so well contained I never need to look outside its ecosystem for basic components. It's a true "Batteries Included" runtime.
Can you provide the link?
Here is the ticket opened by @retr0id: https://github.com/oven-sh/bun/issues/28030
And here is the swarm of bots / LLMs / agents that open, review and bikeshed the PR before it's closed by the stalebot: https://github.com/oven-sh/bun/pull/28031
It's hilarious. But also a little sad.
https://github.com/oven-sh/bun/issues/31233
The difference is that the PRs to fix that problem were already open when I created the issue. I was unaware of them (I only searched for duplicate issues, not PRs addressing the problem). The robobun comment implies there are 5 open PRs addressing it, but I could only find two. They still haven't been merged, a month later.
https://github.com/oven-sh/bun/pull/30677 <-- later rolled up into:
https://github.com/oven-sh/bun/pull/30747
https://discord.com/channels/876711213126520882/148058965798...
Leaks memory left and right. And the core team seems unable to fix it.
- People use bun as an all-in-one frontend web bundler. Personally, I just use esbuild (and webpack, if I'm working on a system using its module federation, like Jupyterlab). My understanding is bun has a machine-translated port of esbuild (ported to Zig, then to Rust) built into it.
- Claude Code runs on bun.
The second point has to be why Anthropic acquired them.
Ready to migrate back to node once the slop version is out.
I love the idea of experimentation and innovation; I abhor the idea of it being dependent on Anthropic and their theft. I've never rooted for the Chinese labs more strongly than after seeing this.
“The bring-up log at the bottom is honest about what broke and what it took.”
I genuinely think you could write a competitively-performant multi-threaded DB in Bun + TS if you had shared-heap threads and fast atomics/locking primitives.
Not likely. Databases that attain any significant use in the field end up getting optimized to the n'th degree because they're the bottleneck of the entire system of every system they get put into. Javascript runs on the "5-10x slower than C" language tier. Personally I think even picking Go, in the "2x slower than C" tier, is a huge mistake, though a few people seem to be doing OK with it. I don't think you can call it "competitive" when your C++ or Rust competition is consuming a factor of magnitude less resources.
WASM DBs, maybe, especially as it continues to mature. Not Javascript.
One place where an interpreter + JIT language could be interesting is if it were sufficiently safe to allow user code into the query execution engine, such that the JIT could optimize it all together.
The only thing you can't do with JS today is share a heap across threads. You have SharedArrayBuffer. You have atomics. You don't need a shared address space.
There's a high performance database called "PostgreSQL" you may have heard about. It doesn't use threads. It uses separate processes and shared memory: just like standard JavaScript, with its service workers and SharedArrayBuffer.
If not sharing an address space is good enough for PostgreSQL, it's good enough for your TypeScript database.
The problem with shared-everything, unmarked, preemptive-parallel concurrency is that 90% of the time it gets used by people who don't know they shouldn't.
You can get parallelism with web workers and shove sqlite over there if you like, e.g. for running more intensive queries. Beyond that I kinda don't see much of a reason to use JS for databases, except maybe for isolation (e.g. via wasm).
> …competitively-performant… Care to explain competitively to what?
On a completely unrelated note, I wonder why Github is always down. Real mystery there.
If you can't even be bothered to write a non-slop PR description, it doesn't bode particularly well for the content of the PR itself...
I'd tap out here too if I was a maintainer. Even if the change was perfect, if you could not be bothered to write the PR description, I am not going to waste my time with it.
Edit: My bad, the PR is to a fork, in that case it's not our business how the PR description is written.
Then it was removed it because it made garbage-collection a real mess (the JavaScript gc needs to walk through lots of C++ data, some of it may have specific requirements for destruction/finalization).
I hope it's better this time :)
``` In my experience, the worst bugs are the real-time bugs, which have to do with interactions with multiple threads. My approach to those bugs is to avoid making them. So I don't like threads. I think threads are an atrocious programming model. They're an occasionally necessarily evil, but they're not necessary for most of the things we use threads for.
One of the things I like about the browser model is that we only get one thread. Some people complain about that—if you lock up that thread, then the browser's locked up. So you just don't do that. There are constantly calls for putting threads into JavaScript and so far we've resisted that. I'm really glad we have.
The event-based model, which is what we're using in the browser, works really well. The only place where it breaks down is if you have some process that takes too long. I really like the approach that Google has taken in Gears to solving that, where they have a separate process which is completely isolated that you can send a program to and it'll run there. When it's finished, it'll tell you the result and the result comes back as an event. That's a brilliant model. ```
I was right. Buried in the middle of the post is this tidbit:
> v1 collects synchronous and stop-the-world
Ah, there it is! I knew it!
Parallel garbage collection is a very hard problem. Years of experience and subtle implementation are required to get something like ZGC. A stop-the-world garbage collector will kill tail latency in many use-cases, especially for large programs. I'd say a good GC is the hardest part of a modern VM, even harder than a good JIT: not that a JIT is easy.
Show me multi-threaded JS with generational mark, sweep, compaction, etc. running in parallel with the mutator and I'll be impressed. (The smart thing would be to base it on the JVM or CLR. Doesn't count though.)
It's all so exhausting, this current programmer culture of doing the easy part of a system thing X and presenting your work, without qualifiers, as a complete and modern X.
Sure, sure, we can have memory safe C (just don't have any data races!). Sure, we can have an AI C compiler (just don't expect type checking). Sure, we can port SQLite to Rust (but don't expect it to be fast). Sure, you can one shot a Slack clone (just don't expect performance or security). Doing the easy part of a thing is not doing the thing! You can't trust a README's feature list these days.
To be fair, given that the README is obviously unedited LLM output, the authors might not have realized that their agents cheated and made threading easy by pessimizing the GC. The LLM certainly did though.
Now, maybe the JSC really is adaptable to a multi-threaded mutator world. If it is, great. But over and over, I've seen AI say "I will defer and charter $HARD_THING" and mean "I have no idea how to do $HARD_THING, so I'm creatively reinterpreting your request to make it easy". You have to be endlessly vigilant for LLMs subtly twisting your tasks into easy versions that might technically meet the requirements but they are less complete than you intend.
But if you're making a big fundamental change to a system, I do know that it shouldn't start with a single "+279,276 -4,272" PR. It starts with a small patch with the core of the change so that everyone can understand what it does and how it works. (I mean, ideally, a change like this starts with documentation, discussion, diagrams, surveys of existing implementations, etc, before you start writing code)
You don't cram everything into a single 270K line PR, even (especially) with an LLM, unless you specifically don't want anyone else to look too closely at what you did.
> Scalability, measured (the honest section)
so what about the other sections?!
No human has read or will ever read any of the code, nor was any human thought involved in its creation.
Everything is performative now. As long as you just keep your eyes closed and believe it all works, that's all that matters.
My conclusion from the project I'm working on is that, as of this day, there is no way to have both this so-called 20x performance improvement _and_ any kind of quality. Or security if whoever is running the agent has any token in an .env anywhere on the same file system.
We'll see in which direction the CTO takes this. My bet is not on quality.
In my company, the code Opus 4.8 is able to generate appears competent, but if you dig a bit, it contains way more timebombs than anything I've seen the team members develop.
Is it the AI or the people using it? Idk
I'm not so sure this is true anymore. It may have been years ago but... can you honestly say "the Bun project was fully AI written, therefore the quality is poor"?
Any concrete examples/proof?
Agreed I would not want all Typescript users forced to use /this/ runtime, but if the TS team shipped tsc as "oh now it's uses a special fast JS runtime" (just like tsgo is a different runtime) I'd love to at least have the option of using the same special fast runtime in my own still-written-in-TS apps.
Seems I've either struck or a nerve, or miscommunicated, given the insta down votes.