Proposal of Multithread JavaScript

Bradley Meck bradley.meck at gmail.com
Thu Nov 3 15:19:44 UTC 2016


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

Ad hominem.

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

Agree if done right.

> The problem is that it's too similar to vanilla Javascript.

Similarity is a good thing between language constructs.

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

Unclear why this is relevant.

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

JS has been run on event loops, understanding/controlling when you may
yield control back to the event loop is why. Agree that too many concepts
is a bad thing. Unclear how adding greenlets would alleviate this, in
particular things like deferred rendering until your DOM is in a fully
formed state so you don't get FOUC when interacting with *existing* code
that does not expect access/invocation of arguments to yield back to thread.

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

Adding more warts because of warts is never a compelling argument.

On Thu, Nov 3, 2016 at 10:08 AM, Henri Tuhola <henri.tuhola at gmail.com>
wrote:

> 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
>
> _______________________________________________
> es-discuss mailing list
> es-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20161103/ba3e4ad0/attachment.html>


More information about the es-discuss mailing list