[gavinray]

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]

"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.

[n_e]

You have web workers, and for shared memory and synchronisation respectively SharedArrayBuffer and the Atomics namespace.

[quotemstr]

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]

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]

I honestly should print that comment and hang it on a wall.

> …competitively-performant… Care to explain competitively to what?

[forrestthewoods]

…but why? JS/TS does not seem like the right tool for the job?

[nesarkvechnep]

It's probably what they know so not anything new should be learned.