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
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.
Yes. People are losing the plot and embracing corruption with logic like this:
There will always be a few employees stealing. So why don't we just use this system that consistently and randomly introduces theft into every level of our cashflow. We can't expect perfection!
This em-dash stricken PR is yet more evidence that the bun project has AI psychosis.
The most important feature for a language runtime is reliability. It's the foundation, it should be boring. I need to know that the foundation is stable so that I can control the reliability of whatever's built on top.
AIs hallucinating a multithreaded JSC is not boring, it's scary.
You have web workers, and for shared memory and synchronisation respectively SharedArrayBuffer and the Atomics namespace.
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 ca…
SharedArrayBuffer gives you a byte array, and asks you to re-implement the entire JavaScript universe on top of that. String -> use TextEncoder to copy in / out of a byte buffer. Object/class? Sure, devise your own protocol to serialize + copy instances in/out of a byte array. Even basic arithmetic operations on a TypedArray over a SharedArrayBuffer is slow AF in v8 compared to a "native" JS Array for small-medium integers, because our current JIT compilers can jit the fuck out of regular arrays but struggle with TypedArray stuff. It's so sad.
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…
this is why operating systems have forbidden threads since 1999 and no one has ever used them since.
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"
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 ow…
if there was a thingy that compiled JS to a 10mb native executable with shared heap multithreading, im sure we'd use it. however, no one has invented such a thing. until this pr.
> quite a lot of analysis went into the rewrite Literally just prompted for an LLM to review it and asked for a fancy presentation. That is not "quite a lot of analysis". That is anything but . > If the tests pass, then why not accept the rewrite? Because (1) tests passing are absolutely not a guarantee that no regressions were introduced in a change, and (2) even if they were, those tests are the result of thousands…
I hear a lot of complaints about bun but nothing concrete about what broke in the migration. You are also assuming one prompt, and then arguing against your assumptions with zero evidence. It is lazy arm chair criticism.
>I hear a lot of complaints about bun but nothing concrete about what broke in the migration.
yes i love to use a language runtime within another language runtime for a sweet sweet 30% performance penalty
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.
> (actually I just checked again, and the PR has been closed by stalebot). Can you provide the link?
Here's a trivial docs issue I opened, where I had a similar experience: 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…
Utter dysfunction. I ripped out bun from my projects after the vibe Rust rewrite, but seems like the problem has existed much longer...