Hi,
Dart had another VM version called Dartino where they were experimenting
with lighter weight
concurrency controls. But they didn't get to the point of adding the
syntactic sugar that Go has
for coroutines. Also Go is one step ahead of everybody else when it comes
to concurrency by
adding developer tools that help with detecting deadlocks and so on.
That brings to mind that one of the reasons they didn't want lower level
concurrency control was
that they wanted to keep it simple in order to have it on end-user
machines, say via the browser.
The browser imposes restrictions like the browser should have the ultimate
say about whether
something can run, can be suspended, and so on. Also the sandbox needs to
be tight with the
browser so that an out of control process does not take over the user's
machine.
Dart was trying to match the JavaScript features in order to leapfrog it
and become one of the
preferred VMs on the browser. Many of the choices that Dart made came from
this need to
match the present and future JS features. JS had Promises and Async/Await
in its goals, so
Dart naturally adopted them. I'm not sure why Dart didn't pick up JS's
yield though. I think it
has to do with Dart trying to have a coherent feature set, like when Dart
implemented Streams
which to this day may be one of its neatest features. Based on Streams, it
seems that developers
prefer to operate on whole lists instead of breaking them up midway. And
yield would have been
more of a stopgap before Async/Await.
One of the advantages of coroutines may be that they help to preserve the
stacktrace. But since
the browsers have to interfere so much in a program's execution by
inserting their own functions,
the stacktraces tend to be hacked together by the browser in order to show
only what the
end-user expects, so perhaps coroutines would have lost some of their
easier appeal there too.
The browsers often present just 1 thread to JS programs which also happens
to be their main UI
thread. Abstractions that play well with just that 1 thread would be easier
for the browsers. Recall
that the browsers themselves have to be careful regarding threads.
Async/Await may play better with a C++ program which the browser and the VM
are. Coroutines
may be better for languages that are mostly C, and Go borrowed a lot more
from C instead.
Cheers,
Joao
Post by Nicolas OcquidantJust for my information, why Dart didn't take the path of Go for
concurrency (goroutine instead of async/await)?
Maybe because of the JS adherence?
Thanks
--nick
--
For other discussions, see https://groups.google.com/a/dartlang.org/
For HOWTO questions, visit http://stackoverflow.com/tags/dart
To file a bug report or feature request, go to http://www.dartbug.com/new
---
You received this message because you are subscribed to the Google Groups
"Dart Misc" group.
To unsubscribe from this group and stop receiving emails from it, send an
--
For other discussions, see https://groups.google.com/a/dartlang.org/
For HOWTO questions, visit http://stackoverflow.com/tags/dart
To file a bug report or feature request, go to http://www.dartbug.com/new
---
You received this message because you are subscribed to the Google Groups "Dart Misc" group.
To unsubscribe from this group and stop receiving emails from it, send an email to misc+***@dartlang.org.