[dart-misc] Focus!

['Wm Leler' via Dart Misc]

Disclaimer: I'm a developer advocate for Dart and Flutter, but this post is
my personal opinion.

Regarding the whole discussion about Dart's focus on being the best
client-side language -- I don't see anyone complaining that focus is a bad
thing. In fact, almost all languages that have had a lasting impact were
originally very focused:

- C was a language for writing operating systems and compilers. It
became so much more.
- Java was a language for embedded systems.
- JavaScript was a scripting language for browsers (!).
- Even the often maligned PHP succeeded because it was focused on
writing Personal Home Pages (hence the name).

I'm sure you can think of many more examples.

On the other hand, many languages have explicitly tried (and failed) to be
completely general purpose I'm looking at you, PL/1 and Ada, among others.
Not good.

I think (as others have said) that Dart is already a good language for
writing server-side code. The fact that Dart avoids preemptive
multi-tasking gives it the same advantages as Node, but with much better
typing, and I doubt it is a coincidence that some of the original creators
of Dart also created the V8 compiler that enabled JavaScript on the server.

Nobody is going to tell you not to use Dart for server code (in fact, we
still use Dart on servers, so we would have to tell ourselves). And I
believe strongly that focusing Dart on being the best language for writing
client code will in fact make it a *better* language for writing other
kinds of code, including server-side code. Even more important, making Dart
successful on the client will inevitably generate more interest in using it
on the server (just like what happened with JavaScript and Node -- why
force people to use two different languages?).

Focus is important, and the purposes for which a language can be used is
not a zero-sum game.

So keep using Dart on the server. And if there is some library that would
help with server-side Dart, consider writing it so that the Dart team can
focus on the client. Think of this as an opportunity.

[kc]

At the recent DartConf there was a real sense of focus and direction.

Are Lars Bak and Gilad Bracha still leading the Dart project - they weren't at the conference.

K.

[Randal L. Schwartz]

kc> Are Lars Bak and Gilad Bracha still leading the Dart project - they
kc> weren't at the conference.

Linkedin shows Gilad leaving Google in July of 2017 to work for another
company, and Lars leaving Google in September of 2017 to be a
contractor, although that doesn't rule out that either of them might
still be involved with Dart.
--
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - [phone]
<***@stonehenge.com> <URL:http://www.stonehenge.com/merlyn/>
Perl/Unix/Dart consulting, Technical writing, Comedy, etc. etc.
Still trying to think of something clever for the fourth line of this .sig

[Joao Pedrosa]

Hi,

Welcome on board. :-)

I would like to talk about some of the things that servers may need though.
And even clients may need it too.

What I have in mind is access to other native services and libraries.
Someone on this mailing list has mentioned
before that at their company they extended Dart with things like barcode
libraries. On the phones, folks may need
to extend Dart with access to APIs that aren't native to Dart. And this
does something that may be unwelcome
to a centrilized project: they add uncertainty in the way that bugs may
cross the boundaries from Dart to native
code. They may also ask for other compilers to be added to the toolchain.

I understand that Dart is based on C++ and this would make it a bit more of
a hassle when extending it with
native libraries, whereas languages that were centered on C would ask less
from the runtime and language
version. I for example would not welcome having longer compilations added
to the toolchain if I had to compile
the SDK myself and so on.

If Dart gets extended more with native extensions, then things like
hot-reload may not work as well when developing
in the IDE. Or at least it would not be as supported. All of this adds more
uncertainity.

Dart's killer feature of a type system may fly in the face of other
shortcomings.

It is true that Dart has users as it is. But so do the opposition.

Dart has to make up for its true killer feature that is the way to compile
a program while doing tree-shaking to leave
the unused code behind. The issue is that when creating a library, you may
notwant to leave all unused code
behind though. At some point this feature got mixed up with the type
system, as Google couldn't imagine the
language without the type system. And we are where we are as a result.

I'm happy that Google has uses for Dart internally. But my dream of having
a language where productivity would
be unmatched hasn't really been realized. One of my worries has always been
about having hard to explain
type system bugs. You can call it opaque type system errors.

But another complain I have is that Dart's fondness of callbacks in Futures
has created hard to understand
error backtraces too. In a way it reminds me of Java's large framework
backtraces. What would be alternative?
Concurrency that could halt execution. Not to happen even in server code as
it is not a priority.

Thanks for listening!

Cheers,
Joao


<https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail>
Livre
de vírus. www.avast.com
<https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail>.
<#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>

Post by 'Wm Leler' via Dart Misc
Disclaimer: I'm a developer advocate for Dart and Flutter, but this post
is my personal opinion.
Regarding the whole discussion about Dart's focus on being the best
client-side language -- I don't see anyone complaining that focus is a bad
thing. In fact, almost all languages that have had a lasting impact were
- C was a language for writing operating systems and compilers. It
became so much more.
- Java was a language for embedded systems.
- JavaScript was a scripting language for browsers (!).
- Even the often maligned PHP succeeded because it was focused on
writing Personal Home Pages (hence the name).
I'm sure you can think of many more examples.
On the other hand, many languages have explicitly tried (and failed) to be
completely general purpose I'm looking at you, PL/1 and Ada, among others.
Not good.
I think (as others have said) that Dart is already a good language for
writing server-side code. The fact that Dart avoids preemptive
multi-tasking gives it the same advantages as Node, but with much better
typing, and I doubt it is a coincidence that some of the original creators
of Dart also created the V8 compiler that enabled JavaScript on the server.
Nobody is going to tell you not to use Dart for server code (in fact, we
still use Dart on servers, so we would have to tell ourselves). And I
believe strongly that focusing Dart on being the best language for writing
client code will in fact make it a *better* language for writing other
kinds of code, including server-side code. Even more important, making Dart
successful on the client will inevitably generate more interest in using it
on the server (just like what happened with JavaScript and Node -- why
force people to use two different languages?).
Focus is important, and the purposes for which a language can be used is
not a zero-sum game.
So keep using Dart on the server. And if there is some library that would
help with server-side Dart, consider writing it so that the Dart team can
focus on the client. Think of this as an opportunity.
--
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

[tatumizer-v0.2]

Post by Joao Pedrosa
Concurrency that could halt execution. Not to happen even in server code
as it is not a priority.

I was never able to understand how the idea of async-await got so popular.
It's a normal "ancient" non-preemptive multitasking, but with lots of
unnecessary, weird ceremony in the form of Futures, async/await, Zones(*),
unreadable stack traces, 2 flavors of functions that don't compose...
But WHY?
My theory(tentative) is that when it async/await was implemented in C#, the
language already had (preemptive!) multithreading. Maybe they didn't want
to mix 2 kinds of multitasking, so they invented a second mechanism,
completely different from the first one.
But if the only thing you have is non-preemptive one, then why not simply
implement it behind the scenes? Probably I misunderstand something. Can
someone explain it to me?
(Another thing I was never able to wrap my head around in dart is operator
"new". What was the idea? Why should we type the word "new"? Did it have
purely ceremonial purpose?)

[Randal L. Schwartz]

tatumizerv0> I was never able to understand how the idea of async-await
tatumizerv0> got so popular. It's a normal "ancient" non-preemptive
tatumizerv0> multitasking, but with lots of unnecessary, weird ceremony
tatumizerv0> in the form of Futures, async/await, Zones(*), unreadable
tatumizerv0> stack traces, 2 flavors of functions that don't compose...
tatumizerv0> But WHY? My theory(tentative) is that when it async/await
tatumizerv0> was implemented in C#, the language already had
tatumizerv0> (preemptive!) multithreading. Maybe they didn't want to mix
tatumizerv0> 2 kinds of multitasking, so they invented a second
tatumizerv0> mechanism, completely different from the first one. But if
tatumizerv0> the only thing you have is non-preemptive one, then why not
tatumizerv0> simply implement it behind the scenes? Probably I
tatumizerv0> misunderstand something. Can someone explain it to me?
tatumizerv0> (Another thing I was never able to wrap my head around in
tatumizerv0> dart is operator "new". What was the idea? Why should we
tatumizerv0> type the word "new"? Did it have purely ceremonial
tatumizerv0> purpose?)

Have you missed Isolates? Those map to share-nothing threads in the VM,
and WebWorkers (for now) in Javascript.
--
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - [phone]
<***@stonehenge.com> <URL:http://www.stonehenge.com/merlyn/>
Perl/Unix/Dart consulting, Technical writing, Comedy, etc. etc.
Still trying to think of something clever for the fourth line of this .sig

[Marcello Dias]

Tatumizer said

Post by Joao Pedrosa

I was never able to wrap my head around in dart is operator "new". What

was the idea?
If you wrote all the messages since the beggining of this groups, for each
10, 6 were about the new Keyword;
SO I think it was introduced to distract people,so nobody complained about
other things,like the type sytem, for instance. :>}

Post by Joao Pedrosa
Concurrency that could halt execution. Not to happen even in server code

as it is not a priority.

I was never able to understand how the idea of async-await got so popular.
It's a normal "ancient" non-preemptive multitasking, but with lots of
unnecessary, weird ceremony in the form of Futures, async/await, Zones(*),
unreadable stack traces, 2 flavors of functions that don't compose...
But WHY?
My theory(tentative) is that when it async/await was implemented in C#,
the language already had (preemptive!) multithreading. Maybe they didn't
want to mix 2 kinds of multitasking, so they invented a second mechanism,
completely different from the first one.
But if the only thing you have is non-preemptive one, then why not simply
implement it behind the scenes? Probably I misunderstand something. Can
someone explain it to me?
(Another thing I was never able to wrap my head around in dart is operator
"new". What was the idea? Why should we type the word "new"? Did it have
purely ceremonial purpose?)
--
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

[Alex Tatumizer]

Have you missed Isolates? Those map to share-nothing threads in the VM, and

WebWorkers (for now) in Javascript
Isolates are not threads in the same sense as in Java or C#.
They are isolated, by definition. That is, no shared memory. Same
non-preemtiveness applies to each isolate..
You may have N separate non-preemptive threads of execution. Nothing new.
These "threads" were always there in non-preemptive runtimes. They are
basically different processes.

[Alex Tatumizer]

Post by Marcello Dias
you wrote all the messages since the beggining of this groups, for each

10, 6 were about the new Keyword;

The mailing list started much earlier than you joined it.. It was long time
ago. I used to complain just about everything :).

You would be surprised: the other day, there was a thread in HN where
somebody mentioned flutter, and the only comment was about the 'new'
keyword (it wasn't MY comment, in case of any suspicions!). Yeah, open any
flutter example, you will see 'children' and 'new".
One thing you certainly cannot see is the structure of the widget.
Both problems are fixable though.

[Randal L. Schwartz]

Alex> Isolates are not threads in the same sense as in Java or C#.

Yes, hooray! No more deadlocks!

Alex> They are isolated, by definition. That is, no shared memory. Same
Alex> non-preemtiveness applies to each isolate..

But if you have 8 cores, you can have 8 Isolates, and keep them all
burning at 100%. And within each Isolate (thread), you have
event-driven programming, using Futures and Streams to avoid "callback
hell".

Not sure what you would think is better than that? It looks rather
ideal to me.
--
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - [phone]
<***@stonehenge.com> <URL:http://www.stonehenge.com/merlyn/>
Perl/Unix/Dart consulting, Technical writing, Comedy, etc. etc.
Still trying to think of something clever for the fourth line of this .sig

[tatumizer-v0.2]

What is better than that?

What is better than that is the language with no await/async. Just remove
them from the language, along with Futures and their friends.
Non-preemptive systems were quite common at some point (early versions of
Windows and MacOS)
There was no async/await in there. IO is blocking, and there's also 'yield'
operator that explicitly yields control to others.
And the stack is a stack, not a 'synthetic stack" (how is synthetic stack
better than a real one?)

The mechanism based on Futures could make some sense if we wanted to
parallelize computation. But async/await doesn't parallelize anything, it
models non-preemptive runtime exactly as it was 40 years ago, but with MUCH
more boilerplate (the purpose of which is unknown to me).. it can be
removed from the language and hidden under the hood.
(If I'm mistaken, please somebody explain to me, in technical terms, what
my mistake is)

[Anatoly Pulyaevskiy]

Async io and no shared memory between isolates is a lot easier to reason
about comparing to multithreaded models where debugging a issue can easily
become a nightmare. Async stack traces are not nearly as bad.

Mental model is simpler and more predictable, side-effects are more
explicit.

These are just a few reasons I find the most important personally. There
might be a way to hide async/await to make the language even more concise
but it doesn’t seem like it will bring a lot of benefits.

Post by tatumizer-v0.2

What is better than that?

What is better than that is the language with no await/async. Just remove
them from the language, along with Futures and their friends.
Non-preemptive systems were quite common at some point (early versions of
Windows and MacOS)
There was no async/await in there. IO is blocking, and there's also
'yield' operator that explicitly yields control to others.
And the stack is a stack, not a 'synthetic stack" (how is synthetic stack
better than a real one?)
The mechanism based on Futures could make some sense if we wanted to
parallelize computation. But async/await doesn't parallelize anything, it
models non-preemptive runtime exactly as it was 40 years ago, but with MUCH
more boilerplate (the purpose of which is unknown to me).. it can be
removed from the language and hidden under the hood.
(If I'm mistaken, please somebody explain to me, in technical terms, what
my mistake is)
--
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

[tatumizer-v0.2]

Post by Anatoly Pulyaevskiy
Async io and no shared memory between isolates is a lot easier to reason

Post by Anatoly Pulyaevskiy
about comparing to multithreaded models where debugging a issue can easily
become a nightmare. Async stack traces are not nearly as bad.

Looks like nobody remembers what non-preemtive runtime was. I am ALL FOR
non-preemtive runtime. I am ALL AGAINST multithreading. It's just
ridiculous to think that non-preemtive runtime somehow makes it necessary
to introduce the concept of Futures.
Futures were invented as a hack to make something backwards-compatible with
something else.
So maybe they are justified in javascript. But if we are talking about
server-side dart, there was an opportunity to implement non-preemtive
runtime directly.
That's why I'm all against server-side dart until the language removes all
boilerplate. There's a niche wide open right now for a sane modern
server-side language. Dart could easily occupy it, if interested. Some work
required though.

[Istvan Soos]

Post by tatumizer-v0.2
The mechanism based on Futures could make some sense if we wanted to
parallelize computation. But async/await doesn't parallelize anything, it

A bit of nitpicking here:
- you can get **parallelism** with isolates
- you can get **concurrency** with async/await models

For the later, have a look at the example here:
https://pub.dartlang.org/packages/executor
I'm using it to run concurrent tasks in the same Dart VM, with great
results, and I haven't found it limiting.

Btw. Dart VM's model is really similar to Erlang's VM (shared-nothing
threading), I think that is the closes alternative, but I'm not fluent
enough in Erlang to compare the differences.

Post by tatumizer-v0.2
Looks like nobody remembers what non-preemtive runtime was

Would you show us an example of what you are looking for and what it
would achieve?

Cheers,
Istvan

[tatumizer-v0.2]

Post by Istvan Soos
Would you show us an example of what you are looking for and what it
would achieve?

What we achieve is - composability of functions (plus remove noise from the
program). That is, we get back whatever we lost in a bizarre historical
accident.
Whenever you write
var str= await file.readLine()
you will simply write
var str = file.readLIne();

The call it blocking. The stack is a stack. readLine returns a string, not
a Future. Good old times. Note that the runtime is single-threaded. exactly
as it is now. And everything else is (almost) the same under the hood.
When someone is blocked, the system reviews the internal queue and resumes
previously blocked calls if ready. The difference with multi-threaded
execution: function cannot be interrupted and blocked at arbitrary place,
only on IO calls.

Composability of functions - is it too much to ask?

[tatumizer-v0.2]

For a context, here's the link to Bob's post of Feb 2015 where he describes
the problem with clarity worthy of Tolstoy's :)
http://journal.stuffwithstuff.com/2015/02/01/what-color-is-your-function/

Probably, not everybody was part of the original debate, that's why my
arguments may sound vague.

[Istvan Soos]

Post by tatumizer-v0.2

Post by Istvan Soos
Would you show us an example of what you are looking for and what it
would achieve?

What we achieve is - composability of functions (plus remove noise from the
program). That is, we get back whatever we lost in a bizarre historical
accident.
Whenever you write
var str= await file.readLine()
you will simply write
var str = file.readLIne();
The call it blocking. The stack is a stack. readLine returns a string, not a
Future. Good old times. Note that the runtime is single-threaded. exactly as
it is now. And everything else is (almost) the same under the hood.
When someone is blocked, the system reviews the internal queue and resumes
previously blocked calls if ready. The difference with multi-threaded
execution: function cannot be interrupted and blocked at arbitrary place,
only on IO calls.

I'd suggest that you further your example, by providing more details
on e.g. 5 concurrent http request, and detail it (steps to yield
control, steps to get their results). I have no evidence, but I think
it is not as self-evident as you wish it to be.

Istvan

[tatumizer-v0.2]

Istvan:
What you really mean by 5 concurrent http requests?
That one function, say, foo(), wants to initiate 5 https requests in
parallel, receive 5 futures, and handle them by ad-hoc logic (no await?)?
Or that 5 different functions initiate 5 different http requests, each
using await for the Future, like 'await http.request(...)'?
If the former, runtime can provide the method to send N requests in
parallel (*). If the latter, it's a normal blocking call in each case.

Again, it's like normal multithreading, which everyone is familiar with,
it's just no one can interrupt the running function until it either blocks
on io or calls yield explicitly. And yes, if any function invokes something
like 'while (true);` then the whole thing will just hang.
Same as now. Note that there's nothing new here at all.

(*) E.g. java.nio makes it possible to initiate concurrent low-level
read/write operations on disks and sockets since 2004 or so, no Futures
required).
But the use cases for this are limited to very special scenarios. I used it
once, and not even sure it made practical sense. Basically, did it for fun.

[Istvan Soos]

I was thinking 5 requests **concurrently** (parallel == different
threads, concurrent == same thread, overlapping processing), and not
started at the same time (one blocking call with 5 URL parameters
won't make it).

As an alternative, this code is a simpler use case, you shall be able
to describe how it would change to your liking:

Future<String> complexHttpPlusProcessing(int id) {...}

Future f1 = complexHttpPlusProcessing(1);
print('async #1 started...');
Future f2 = complexHttpPlusProcessing(2);
print(await f2);
Future f3 = complexHttpPlusProcessing(3);
print(await f1);
print(await f3);

Cheers,
Istvan

Post by tatumizer-v0.2
What you really mean by 5 concurrent http requests?
That one function, say, foo(), wants to initiate 5 https requests in
parallel, receive 5 futures, and handle them by ad-hoc logic (no await?)? Or
that 5 different functions initiate 5 different http requests, each using
await for the Future, like 'await http.request(...)'?
If the former, runtime can provide the method to send N requests in parallel
(*). If the latter, it's a normal blocking call in each case.
Again, it's like normal multithreading, which everyone is familiar with,
it's just no one can interrupt the running function until it either blocks
on io or calls yield explicitly. And yes, if any function invokes something
like 'while (true);` then the whole thing will just hang.
Same as now. Note that there's nothing new here at all.
(*) E.g. java.nio makes it possible to initiate concurrent low-level
read/write operations on disks and sockets since 2004 or so, no Futures
required).
But the use cases for this are limited to very special scenarios. I used it
once, and not even sure it made practical sense. Basically, did it for fun.
--
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

[tatumizer-v0.2]

No way to do it like you wrote. Why bother? Can you point to a project that
uses this kind of processing?
Can you point to sufficient number of projects that show it's statistically
likely that we need such processing to the extent that would justify the
whole machinery of Futures, Zones, synthetic stacks, non-composable
functions etc as the DEFAULT, which cannot even be escaped?
That's the question language designers should consider.
But your question implies that the edge case, however unlikely, should
drive the entire design? From a different angle: do you think your program,
as written above, pass the code review? Is it easy to maintain? Etc...

In any case, the system can expose low-level machanisms for those who
really need them. With this low-level mechanisms, you can do that. But your
function (the entire function where you do that) will be blocking, until
you notify the system that it's done.
What this means that async'ness of it will not be infectious for callers,
and callers of callers, and the entire system.

As a counter-question: suppose you are writing in java, and you think you
need to access some instruction of Intel processor that java does not
utilize? What do you do then? Or you need some kernel function that java
does not expose to you? Petition java compiler devs to provide built-in
assembly language?

[tatumizer-v0.2]

Found a good summary
ttps://techdifferences.com/difference-between-preemptive-and-non-preemptive-scheduling-in-os.html

dart's runtime is non-preemptive. Which is good for the most applications.
Good OS cannot be made non-preemptive (1 process can hang the entire
system), but concurrency inside a single application can, and should be
(IMO).
How it happened that dart's runtime became entangled with Futures - I don't
know. Probably because javascript.

[Istvan Soos]

Why bother? Can you point to a project that uses this kind of processing?

I see it differently: it is a tradeoff, with values spelled out
earlier in this thread. The architecture was not a random choice, many
good systems were built in shared nothing architectures, it was well
studied (roots goes well before Erlang VM).

You may prefer different tradeoffs, but we are different, and I prefer
this over the Java concurrency model. I've had my fair share of both,
and I'm currently running a large-ish Dart server app with many
isolates and many concurrent processing in each isolate (not open
source). The scenario which I've described may not be in the code in
this exact form, but conceptually I have similar things there.

Writing async/await with a shared-nothing Dart VM is really great: I
can forget three classes of issues (deadlocks, thread starvation and
partially written values in non-volatile fields in the Java VM). It is
possible that one needs to burn themselves with these issues before
putting more value on the shared-nothing VMs, but after that, the
choice seems to be easier.

Is it easy to maintain?

Yes, it is.

What this means that async'ness of it will not be infectious for callers, and callers of callers, and the entire system.

In other words: complex programs are complex, and async makes that
explicit. Not a bad thing in itself.

Cheers,
Istvan

No way to do it like you wrote. Why bother? Can you point to a project that
uses this kind of processing?
Can you point to sufficient number of projects that show it's statistically
likely that we need such processing to the extent that would justify the
whole machinery of Futures, Zones, synthetic stacks, non-composable
functions etc as the DEFAULT, which cannot even be escaped?
That's the question language designers should consider.
But your question implies that the edge case, however unlikely, should drive
the entire design? From a different angle: do you think your program, as
written above, pass the code review? Is it easy to maintain? Etc...
In any case, the system can expose low-level machanisms for those who really
need them. With this low-level mechanisms, you can do that. But your
function (the entire function where you do that) will be blocking, until you
notify the system that it's done.
What this means that async'ness of it will not be infectious for callers,
and callers of callers, and the entire system.
As a counter-question: suppose you are writing in java, and you think you
need to access some instruction of Intel processor that java does not
utilize? What do you do then? Or you need some kernel function that java
does not expose to you? Petition java compiler devs to provide built-in
assembly language?
--
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

[tatumizer-v0.2]

Post by Istvan Soos
In other words: complex programs are complex

Here's the difference; for me, saying that the program is complex is the
same as saying it's not working. Complexity doesn't make sense from 2
points of view: first, the program is ugly. That's bad enough. And the
second, it's not working, or, worse, pretends to be working. but no one
really knows why. Maybe it's only me. Let's agree to disagree then. The
point I was trying to make is this: whoever loves complexity, already has a
very good choice of languages, frameworks and what-not. So this segment is
very-well served already. But the rest of us are severely
under-cared-about. My speculation is that whichever language emerges to
cater to this segment will succeed beyond all expectations. This segment is
huge, but silent..

['Lasse R.H. Nielsen' via Dart Misc]

Post by Joao Pedrosa
Concurrency that could halt execution. Not to happen even in server code

Post by Joao Pedrosa
as it is not a priority.

I was never able to understand how the idea of async-await got so popular.
It's a normal "ancient" non-preemptive multitasking, but with lots of
unnecessary, weird ceremony in the form of Futures, async/await, Zones(*),
unreadable stack traces, 2 flavors of functions that don't compose...
But WHY?

In short: You can implement futures on top of a single-threaded platform
with no concurrency primitives (like, say, JavaScript).

Proper multi-stack based blocking concurrency is clearly superior, and the
Dartino experiment showed that, but there is no way to compile that model
to JavaScript without CPS-transforming the entire program. With explicit
async/await, we can get away with only CPS-transforming the async
functions, which is most likely the same reasoning that was used in C#.

Post by Joao Pedrosa
My theory(tentative) is that when it async/await was implemented in C#,
the language already had (preemptive!) multithreading. Maybe they didn't
want to mix 2 kinds of multitasking, so they invented a second mechanism,
completely different from the first one.
But if the only thing you have is non-preemptive one, then why not simply
implement it behind the scenes?

If you only have one stack, then you need to somehow store the entire
continuation at any await and restore it when it resumes. If you can't copy
the stack, you need to transform the program to reify the continuation, a
CPS transformation, on all methods that can possibly be on the stack at the
time of an await. Without very clever analysis, that means CPS transforming
the entire program (some leaf-functions might be considered safe, but
anything calling a user function, say `toString` on an unknown object, is
not a leaf function).

That's pretty costly in practice (and it is what we are currently doing to
async functions, even in the VM, which could theoretically be using
multiple stacks instead).

(Another possible optimization is that an `await` of a function call can
reuse the same stack for the function because the await will only complete
when the function call is done, but again, that just helps a little bit, it
doesn't solve the general problem).

Probably I misunderstand something. Can someone explain it to me?

Post by Joao Pedrosa
(Another thing I was never able to wrap my head around in dart is operator
"new". What was the idea? Why should we type the word "new"? Did it have
purely ceremonial purpose?)

Can't answer that one, but it's probably just about familiarity. The three
other languages Dart was trying to look similar to (JavaScript, Java and
C#) uses "new".
Some people actually like the `new` because it shows intent that isn't
readily visible without it.

/L
--
Lasse R.H. Nielsen - ***@google.com
'Faith without judgement merely degrades the spirit divine'
Google Denmark ApS - Frederiksborggade 20B, 1 sal - 1360 KÞbenhavn K
- Denmark - CVR nr. 28 86 69 84

[Istvan Soos]

On Fri, Mar 2, 2018 at 10:18 AM, 'Lasse R.H. Nielsen' via Dart Misc

Post by 'Lasse R.H. Nielsen' via Dart Misc
(Another possible optimization is that an `await` of a function call can
reuse the same stack for the function because the await will only complete
when the function call is done, but again, that just helps a little bit, it
doesn't solve the general problem).

Thanks for the explanation!

I'm wondering: is it possible to implement this same-stack approach
(at least in the VM) and call it "20% of the effort solves 80% of the
user pain"?

Istvan

[tatumizer-v0.2]

Post by 'Lasse R.H. Nielsen' via Dart Misc
If you only have one stack, then you need to somehow store the entire
continuation at any await and restore it when it resumes

Yes, I understand that. Does anyone know WHY javascript has one stack? What
is the benefit of one stack? Saving ... memory maybe? Buying a bit of
memory in exchange for tons of complexity? And if it was just an oversight
(many decisions in javascript were quick and dirty for the lack of time,
which is understandable in historical context), why other languages started
copying it?
I haven't heard a single argument clearly saying the king in naked, this
thing sucks, there's a trivial non-preemptive model that avoids all these
problems. And it seems no one is suggesting to move javascript to
multiple-stack model, but WHY?
(Probably I misunderstand something, please explain)

Not sure if dart can switch to multi-stack without javascript doing the
same. It's ironic, isn't it? Compilation to Javascript now is just 1/5 of
dart's scope (we have flutter on 2 OS, will have desktop native flutter on
2 or 3 OS, plus VM), but javascript compatibility still dominates the
overall design of dart, right?

['Bob Nystrom' via Dart Misc]

Post by 'Lasse R.H. Nielsen' via Dart Misc
If you only have one stack, then you need to somehow store the entire

Post by 'Lasse R.H. Nielsen' via Dart Misc
continuation at any await and restore it when it resumes

Yes, I understand that. Does anyone know WHY javascript has one stack?
What is the benefit of one stack?

I think it depends on what alternative you have in mind. I think the two
main options are:

- *Coroutines/fibers/green threads.* Those give you cooperative
multitasking with no involvement from the OS. I think these are typically
implemented either by defining your own stack at the interpreter level and
not using the "C" stack at all for the language, or by using something like
setjmp()/longjmp(). The former is easy but tends to have a negative
performance impact. The I think is complex and has portability challenges.

- *Actual operating system threads.* Using these dramatically increases
the complexity of the language design and implementation because you need
to define a memory model for the language and implement a thread-safe GC.

For a language whose initial intended goal was simply to make buttons
animate, both of those really sound like overkill. By the time JS was used
for large enough applications that the lack of concurrency was a real
problem, the existing corpus of JS code and multiple competing mature JS
implementations makes it *really* hard to change the status quo.

So far, the solution they've come up with is Web Workers. That gives you
true concurrency, but has very limited support for sharing memory between
tasks.

– bob

[tatumizer-v0.2]

The former is easy but tends to have a negative performance impact

Yes, that's what I meant - the former. Cooperative multitasking, stack
defined on interpreter level. I can't see how performance would be
different from the one we have now with the Futures. Where will the extra
overhead come from? Please explain. There're no context switches in either
case, so it's by far more effective than real multithreading. (Maybe more
memory has to be allocated for multiple stacks, that's true, but these are
peanuts).

[tatumizer-v0.2]

Oh, maybe I see what you meant. No, you can't do that in pure C. This small
piece of code should be written in Assembly. When somebody reached IO, save
all registers (including SP) and find somebody who is ready to continue.
Restore his registers. It's a trivial amount of Assembly code. (I did that
on old processors similar to Intel-8080 when I had to write micro-OS for
"raw" processors without standard OS)