Proposal of Multithread JavaScript

Henri Tuhola henri.tuhola at gmail.com
Thu Nov 3 15:08:48 UTC 2016


Leo Dutra wrote:
> looks like community is OK with the current state and that's more than
enough.

This whole mailing list looks like it suffers from a severe case of
Dunning-Kruger. Most of you people barely understand what is being
discussed and deny the ideas presented because you have irrational love for
the concepts that have been already presented and irrational fear of the
new concepts. At worst you rationalize your actions based on the popularity
rather than merits.

The green thread proposal such as this would be great. Most Javascript
programs are interactive and have to run concurrently. With bit of work
they wouldn't exclude each other. You could both wait for an event in
thread as well as pass a callback for it.

Async/await has at least two problems.

a) Async routines are infective. The problem here is that it forces you to
copy/paste otherwise well-behaving programs to make them behave
concurrently.

For example, you might want to run a parser such that the callback it runs
will trigger a download and wait for the completion before it proceeds.

With async/await, to do this you have to rewrite portions of the parser
with async/await keywords to have it run asyncronously. With green threads
you could just do it.

b) Async/await is a mini-language on top of an existing one. The problem is
that it's too similar to vanilla Javascript.

You already have exceptions in form of reject/catch. Did you already have
async/await iterators too?

Promises are just control flow graphs in disguise. Why would you need two
when you already have proper constructs to represent control flow? These
are complex concepts and excess of them is bad.


The benefits of Async/await over true concurrent model are questionable:

c) Javascript is a dynamic language lacking type annotations prior
evaluation. With Async/await you insist that it becomes annotated with two
variations for functions prior evaluation.

You insist you should have safety for non-atomic changes of variables in a
language where the correctness is up to the user in the first place. Why
should we have async/await "safety net" when we don't have types "safety
net"?

-- Henri Tuhola, author of https://leverlanguage.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20161103/6e8b93e3/attachment.html>


More information about the es-discuss mailing list