Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Bun has an open PR adding shared-memory threads to JavaScriptCore

github.com

Post reply on HN
Print view View original

311–320 of 330 posts

Re: Bun has an open PR adding shared-memory threads to JavaScriptCore

#311

Post by tomjakubowski »

jitl wrote: post #160
anematode wrote: post #130

Earlier quoted context omitted.

I'd actually love to see a relatively high-performance (i.e., including a decent JIT) runtime for a dynamic language that's written in Rust. There's a lot of implementations like Rust Python, the Boa JS engine, etc. that are purely interpreted – and fun! – but I haven't seen a proper, high-performance VM yet. I considered writing such a JVM in Rust, following writing one in C ( https://github.com/anematode/b-jvm ) th…

rust seems alergic to the un-safety required of "i dynamically built this executable code segment just now, please jump into it"

This is wrong, demonstrably. There are multiple OS kernels written in Rust (with small amounts of ASM glue, as is required in any kernel project).

Re: Bun has an open PR adding shared-memory threads to JavaScriptCore

#312

Post by tomjakubowski »

jitl wrote: post #206
anematode wrote: post #169

Earlier quoted context omitted.

Why the snark? wasmtime is a (pretty popular) Rust project which uses a JIT, demonstrating that it's not incompatible with Rust. Obviously a proper VM wouldn't depend on wasmtime, but implement its own JIT and paraphernalia.

fair. i guess i used “rust” in collective noun sense for “rust the ecosystem and community”; from my armchair experience there’s a big contingent of that community that abhors unsafe and software that uses it, and it’s that community/ecosystem aspect that prohibits unsafe since of course the language and compiler support it just fine.

The community does not abhor use of unsafe. The community abhors bad usage of unsafe: unsafe code should be used only when necessary, and ideally to build safe abstractions.

Re: Bun has an open PR adding shared-memory threads to JavaScriptCore

#313

Post by verandaguy »

rstuart4133 wrote: post #234
verandaguy wrote: post #195

Earlier quoted context omitted.

I've seen the Bun Zig->Rust MR a few weeks ago when it was current. Now I'm seeing this, and I have to ask, since you're here: Is there no way to make this changeset smaller? At work, I've usually written large patches. I used to be worse at it. I was mentored out of it, and while I still like my patches to be complete, I balance that with the available bandwidth of the team and what the team can reasonably actually…

> I was mentored out of it, and while I still like my patches to be complete, I balance that with the available bandwidth of the team and what the team can reasonably actually process. I struggle with the same issue. In my experience you can't reduce the total number of lines. If the feature took 10k or 15k loc to deliver it, you aren't going to be able to reduce that meaningfully. You can usually break it into stack…

I will say that a good solution to this starts before a line of code is written, and does require a PM or scrum master with a deft touch (ideally one who's been involved with the engineering side of a project for a while).

Working with them, the scope can be brought down, sometimes, though this obviously depends a lot on externalities like who the customer is and how much flex they're comfortable adding to the timeline, since that often becomes a factor.

Part of becoming a more mature developer involves being able to navigate these situations with PMs better, and dealing with the frustrations that can often bring (in my experience). I'm still working my way up this side of the job. Historically this stuff has been managed up really thoroughly by my immediate manager (a factor of both the manager's working style, the work being done, and the broader company structure), but my current company structure means that I have to get better at this stuff a lot more actively.

Re: Bun has an open PR adding shared-memory threads to JavaScriptCore

#315

Post by kibibu »

re-thc wrote: post #281
kibibu wrote: post #251

Earlier quoted context omitted.

Take a look at Deno. It's pretty great and now has exceptional node compatibility

> Take a look at Deno. It's still heavily AI driven. Maybe less than Bun. And they've gone in the route of just taking Node native libraries and what not just because they gave up on working out the compatibility. It's a bit of tacked on mess now.

Where are you seeing that it's heavily AI driven?

---

Edit: the contribution guidelines allow AI-assisted patches with disclosure. Also, there are a bunch of recent commits co-authored by bots

Re: Bun has an open PR adding shared-memory threads to JavaScriptCore

#316

Post by mhofman »

conartist6 wrote: post #199
Jarred wrote: post #190

I’m the author of this PR. This PR is an implementation of the design from https://webkit.org/blog/7846/concurrent-javascript-it-can-wo... . I think it would be really cool if JavaScript had true shared object multi-threading without compromises (SharedArrayBuffer, postMessage are not that). If we had both threads and structs, it’s likely the TypeScript compiler would never have needed to be rewritten in Go. The titl…

I ran your proposed changes by TC39 and their initial reaction was simply "no". Is Bun the new IE6, then?

To be clear, that was my opinion as a delegate, not the consensus of the committee, as that hasn't been formally discussed. That said, I believe other delegates share my opinion that shared memory concurrency needs to come with more constraints than what is suggested here, and while some delegates might be fine with it, I doubt any unconstrained shared memory concurrency would ever reach consensus if brought forward as a proposal. Currenntly the language spec is actually unclear on whether this is allowed for a compliant engine, and something we might want to update.

Re: Bun has an open PR adding shared-memory threads to JavaScriptCore

#317

Post by 1123581321 »

charrondev wrote: post #293
1123581321 wrote: post #254

Earlier quoted context omitted.

Ideally, you could find pieces of that 10k that would also work as a standalone improvement to the app. I understand that team cultures can vary, but doing small features or refactors in service of a larger goal is nice, because while the reviewer knows you must be up to something, they can still approve your preparatory PRs as face value beneficial.

I have some disagreement here. There are factors other than just code review to worry about when implementing changes, quite notably quality assurance. It does not one any favours if your 10k LoC gets split in 5 changes that aren’t supposed to regress anything (but need to be validated not to) then 1 tiny on that brings things together. Some features will be confusing for end users if you drip feed them. We had a who…

That’s a good point; it depends on the extent to which you can make either invisible changes or you can roll out improvements that don’t require coordinated communication.

QA should be happening either way.

Re: Bun has an open PR adding shared-memory threads to JavaScriptCore

#318

Post by TalkingCodeMonk »

Eufrat wrote: post #239
TalkingCodeMonk wrote: post #232

Earlier quoted context omitted.

jhack's perspetive is something that is all too common in tech. The implication that if code is open source the owners and maintainers don't owe consumers anything because "you can always fork or build it yourself"... as if that were ever possible for the average user, or in a digital world where anything you do with a computer depends on endless recursive sub-dependencies. It's analogous to saying "it's your fault b…

I still really don’t understand what is so entitled about asking for a level of base empathy and care from maintainers. People now yell at you that their only obligation is whatever is spelled out in the license they attached to the code. I think this is the same place where the logic of Code = Law comes from. People who think that you can encode the legal/judicial system into a set of axioms. This is not how the law…

I'm not arguing against a base level of empathy and care for maintainers.

I'm arguing FOR a base level of empathy and care FROM maintainers WHO CHOOSE to build for-profit products in the open, and that empathy for all parties should be the base expectation from a healthy community, rather than the narcissistic view of "nobody owes their communities anything, regardless of context".

The narssisist view leads to the behaviour of Minio, Bambu, etc becoming an accepted norm; to the abuse, exploitation, and deterioration of open source communities by for-profit orgs.

Re: Bun has an open PR adding shared-memory threads to JavaScriptCore

#319

Post by senordevnyc »

JCTheDenthog wrote: post #298
senordevnyc wrote: post #295

Earlier quoted context omitted.

For us, but for an LLM with the right tooling? Idk…

Poe's law is making it hard to tell if your comment is sarcasm or AI-induced psychosis.

My experience is that the people who talk about AI psychosis when it comes to coding are mostly skeptics with their head in the sand.

Do you seriously think that in a decade we'll all still have our agents writing code in the same architectures that we were using a few years ago?

Re: Bun has an open PR adding shared-memory threads to JavaScriptCore

#320

Post by gwbas1c »

jitl wrote: post #158
gwbas1c wrote: post #120

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…

yes, all of node.js is built on such operations. what do you think is happening when you `await fs.promises.readFile(name, 'utf8')`? it dispatches a libuv thread to read the file you want, and resolve the promise when the background thread has completed the operation.

That really varies significantly depending on the underlying OS. On Windows, you can do threaded (IE, your thread blocks) or async (you have a callback) IO. There isn't a requirement to spin up a background thread to perform non-blocking IO.
Post reply on HN