[Question] Have you given thought to go-like Deno-routines?

[alshdavid]

Right off the bat, I realise that Node is single threaded and any sort of threading implementation must occur in the V8 engine, which isn't modified in the case of Deno.

I'd just like to pose the question as TypeScript (in my view) is one of the most expressive and ergonomic languages available and I would love the ability to use it on the server side with a competent threading model.

Go

Goroutines in Go are follow a concurrency model where concurrent functions aren't guaranteed to be executed in parallel, but may be.

You kick off a go-routine by putting go in front of a function invocation and it will run concurrently (pretty much like wrapping something in a setTimeout)

func main() {
   go foo()
}

func foo() {
   fmt.Println("Foo!")
}

Behind the scenes, Go does this through the use of an n-m threading model. When the application starts, the Go runtime launches a few worker threads (usually equivalent to the number of OS threads available) that sit there and wait. Go has a similar scheduler to JavaScript's event loop, but it's repeated on each worker thread and the queues can steal tasks from other queues that are blocked.

If you set Go to only use one queue, it will be single threaded but still allow concurrent code execution, exactly like JavaScript.

TypeScript

In TypeScript, concurrency is asserted through the use of async/await(also using timers that put tasks on the event loop).

void async function main() {
  await foo()
}()

async function foo() {
   console.log('Foo!')
}

If you look at the above code purely syntactically, there really isn't anything stopping this code from being capable of handling the execution of foo on another thread (n-m style). Of course V8 does not do this and JavaScript enforces memory safety by ensuring it's single threaded.

Deno
Is this sort of thing at all possible with Deno or does this change live with the V8 team (who wouldn't do it because it doesn't follow the JavaScript spec)?

[kitsonk]

The "threading" model for Deno is and will continue to be web workers.

If you look at the above code purely syntactically, there really isn't anything stopping this code from being capable of handling the execution of foo on another thread (n-m style).

There are lots of things... TypeScript and JavaScript are single threaded by design and none of the structures in the isolate are thread-safe, so who modifies what structures if something where executed in another thread is really problematic. There are lots and lots and lots of edge cases to deal with how async and await work and how promises are resolved. They still expect to execute in the same thread, with a predictable event loop schedule. Anything that doesn't work like that breaks lots and lots of JavaScript and TypeScript code.