41–50 of 330 posts
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.
Earlier quoted context omitted.
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.
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
Is there a human-authored description of the PR anywhere? How are there not race conditions all over the place?
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
I will never get over the overuse of adjectives like "real" in LLM outputs, it dilutes the meaning of these words.
> Scalability, measured (the honest section)
so what about the other sections?!
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.
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).
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.
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!
The PR is against bun's fork of WebKit, not upstream.
Earlier quoted context omitted.
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
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
So does basically any feature or optimization in a JS runtime
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…
Ugh.