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 2 hours ago | parent | next [-]

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

	▲	hedgehog an hour ago \| parent [-]
		Something compiled to WASM still gives a fair amount of control over memory layout, something that AFAIK is not possible in JS without building effectively a new embedded language on top of an array (Emscripten being an existence proof that you can do more or less anything that way). One place where an interpreter + JIT language could be interesting is if it were sufficiently safe to allow user code into the query execution engine, such that the JIT could optimize it all together.

▲

n_e 3 hours ago | parent | prev | next [-]

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

	▲	quotemstr 3 hours ago \| parent [-]
		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 3 hours ago | parent | prev | next [-]

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 4 hours ago | parent | prev | next [-]

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

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

▲

forrestthewoods 4 hours ago | parent | prev [-]

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

	▲	nesarkvechnep 4 hours ago \| parent [-]
		It's probably what they know so not anything new should be learned.