Avoiding "Dart is single-threaded" confusion

[mit-mit]

I've seen statements on various social media a number of times stating that "Dart is single-thread". I've not before been able to understand where that impression comes from, but someone recently linked to this: https://dart.dev/articles/libraries/dart-io. This has in it: "Dart is a single-threaded programming language".

I think we need to clean up our messaging around this in general.

I suggest we:

1. [ ] Add a new Q/A entry in https://dart.dev/faq under "Native execution" for "Is Dart single-threaded" and a good answer. The answer should link to https://dart.dev/guides/language/concurrency

2. [ ] Maybe also add a Q/A entry in the FAQ under web explaining that the limitations are

3. [ ] Determine if any content from https://dart.dev/articles/libraries/dart-io is still relevant, and if so move that elsewhere. Then take down that page entirely.

4. [ ] Mention on https://dart.dev/guides/language/concurrency what the limitations are on the web platform

[mit-mit]

thoughts @mraleph @johnpryan @sigmundch @vsmenon ?

[johnpryan]

This makes sense to me

[johnpryan]

For 3, the introduction to the dart:io page is better covered in the library tour and the new concurrency docs.

[sigmundch]

Agree, makes sense to me too!

[atsansone]

@mit-mit : Would this issue be better served by splitting 1-4 as separate issues or should this all be done as one effort?

[mit-mit]

I think a single issue is fine? I updated the top to have check-boxes!

[mit-mit]

Making this P1 as I think it has the potential to cause confusion over Dart's architecture.

[mit-mit]

cc'ing @craiglabenz who just did a talk on this topic and might have some ideas for how to phrase this?

[MaryaBelanger]

fyi this blog also says Dart is single-threaded

Questions about each of the work items:

1. FAQ

@mit-mit Dart is single-threaded, isn't it? Would the answer here be something like:

Dart is single threaded, but supports concurrent programming in multiple ways

Or if we want to provide more information, this sentence (mostly copied right from the language tour):

Dart is single threaded; shared-state concurrency is error prone and can lead to complicated code.

Instead of threads, all Dart code runs inside of isolates. Each Dart isolate has a single thread of execution and shares no mutable objects with other isolates.

2. FAQ - web limitations

@sigmundch The first note on the concurrency page already says:

All apps can use async-await, Future, and Stream. Isolates are implemented only on the Dart Native platform; Dart web apps can use web workers for similar functionality.

Is more info necessary to explain the limitations?

3. dart:io page

@johnpryan confirming your earlier comment: everything important from the dart:io page is already updated in the newer pages? I'll do a quick crosscheck and then redirect/remove the dart:io page.

~(possibly unrelated): does the same go for Creating Streams?~

4. Concurrency - web

@sigmundch Same as #2

[sigmundch]

I sense part of the confusion here is that when we say "Dart is single-threaded", people may hear "Dart doesn't support concurrency". Even if we try to clarify it on the same sentence, as your example above:

Dart is single threaded, but supports concurrent programming in multiple ways

May I suggest that instead of attributing "single-threadedness" to Dart, we attribute it directly to isolates?

For example, instead of the sentence above, what if we say:

Dart supports concurrency through a combination of single-threaded isolates (or web workers on the web) and asynchronous features such as async-await, Futures, Streams, and Zones.

?

Regarding your questions above:

• Re: FAQ on the web - I think that note is good, but often folks only find the info from the FAQ, so I'd make a redundant entry in the FAQ to make it very clear.

• Re: web details in the article - I think we need a more expanded section. The sentence implies a difference, but doesn't quite illustrate why this is so different, and what that means for developers. For instance, the way you create a worker or an isolate is completely different. Also, the capabilities are different. For example, on the native platform we provides 2 ways to create isolates: cloning the current isolate and running a single function in parallel, or starting a different isolate with different sources. The former can be part of a single isolate group and as a result are more lightweight. On the web, we don't have the former at all, you can only create new isolates by declaring a separate program entrypoint and compiling that separately.

[MaryaBelanger]

Thank you @sigmundch! I thought the issue was saying that Dart is not single-threaded, but now I understand that though it technically is single-threaded, we shouldn't lead with that because it functions like it's multithreaded (with all the benefits, and none of the issues). I'll try to incorporate that nuance into the FAQ.

I'll also add a FAQ for the web, and try to incorporate the web details into the right place (I might reach out for more info but I'll start with what you wrote here)

[johnpryan]

@johnpryan confirming your earlier comment: everything important from the dart:io page is already updated in the newer pages? I'll do a quick crosscheck and then redirect/remove the dart:io page.

Yes, the library tour has a dart:io section and the Concurrency in Dart page is a better overview

[mit-mit]

Yes, this issue was filed to state that "Dart is NOT single-threaded". While there is some variance about what constitutes single/multiple threading, I think it's common to take single-threaded to mean a "single unit of execution at any given time". That is not the case for Dart, at least on native targets (on web, we're mostly single-threaded).

On native, async and isolate.spawn will cause multiple threads of execution, and the Dart VM will use several cores on a multi-core processor, to be able to run multiple threads. We talked about this here: https://youtu.be/yUMjt0AxVHU?t=466

[domesticmouse]

On native, async and isolate.spawn will cause multiple threads of execution

This specific line causes me DevRel conniptions. I totally agree isolate.spawn creates threads of execution on native.

The part of this that I am being nit-picky on is async. We need to differentiate concurrency and parallelisation. Most developers have difficulty understanding that async, await and friends don't involve threading directly, but instead convert code into re-entrant state machines tied to a queue of tasks. IIUC.

Context: https://www.youtube.com/watch?v=oV9rvDllKEg

[mit-mit]

The part of this that I am being nit-picky on is async. We need to differentiate concurrency and parallelisation.

Sure, I agree that that is a very helpful differentiation. But I don't think all our customers necessarily make that distinction, so it'd be helpful to have a broad take on the question part of this Q-A entry, and then in the answer talk about that difference.