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
Bun has an open PR adding shared-memory threads to JavaScriptCore
21–30 of 330 posts
Re: Bun has an open PR adding shared-memory threads to JavaScriptCore
#22Amazing. This is what the Typescript team should have done instead of rewriting to golang -- innovate the runtime.
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.
Re: Bun has an open PR adding shared-memory threads to JavaScriptCore
#23I 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.
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).
Re: Bun has an open PR adding shared-memory threads to JavaScriptCore
#24Amazing. This is what the Typescript team should have done instead of rewriting to golang -- innovate the runtime.
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.
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.
Re: Bun has an open PR adding shared-memory threads to JavaScriptCore
#25I 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.
Bun is so good that can’t be used as server and only as local script runner.
https://discord.com/channels/876711213126520882/148058965798...
Leaks memory left and right. And the core team seems unable to fix it.
Re: Bun has an open PR adding shared-memory threads to JavaScriptCore
#26The 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
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
Re: Bun has an open PR adding shared-memory threads to JavaScriptCore
#27I 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.
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…
> (actually I just checked again, and the PR has been closed by stalebot).
Can you provide the link?
Re: Bun has an open PR adding shared-memory threads to JavaScriptCore
#28I 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... :/
Just stop caring about quality. It makes it 10x easier to produce slop with AI if you never bother to check
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
Re: Bun has an open PR adding shared-memory threads to JavaScriptCore
#29Eh, 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 :)
Re: Bun has an open PR adding shared-memory threads to JavaScriptCore
#30I knew it was possible :-) https://webkit.org/blog/7846/concurrent-javascript-it-can-wo...
That's excellent work and a great read, Filip!