There's a set of different aspects we can document

• Semantically one can run only into trouble if N>limit isolates try to synchronously communicate with each other (e.g. by stepping out of the pure Dart safety zone with FFI)
• If one stays in the pure isolates world: isolates communicate via message passing and run async code / often yield to event loop (which is needed to e.g. receive messages), then there's no risk of deadlocks etc. One can have thousands of isolates in that case.
• A dart program cannot take advantage of more cores than this limit. Though as a language focused more on the client-side, it's currently also not a goal to scale to 100s of cores.
• If there's oversubscription: more isolates want to run than the limit, they do schedule round-robin and we're not guaranteed to distribute CPU fairly among them. If there's no oversubscription (number if isolates ready to run is less that the limit), then we run all ready isolates in parallel and OS distributes CPU cycles (hopefully fairly) among them.

A dart program cannot take advantage of more cores than this limit. Though as a language focused more on the client-side, it's currently also not a goal to scale to 100s of cores.

It might not be goal to scale to 100s of cores, but neither it is a goal to make it impossible to discover why you hit a scalability issue.

We would like to see Dart used more and more outside of client-side context - so it makes sense to avoid adding hidden limitations like this or at least make them easier to discover.

@mraleph Yes, the list I wrote above is what we can/should document. We can of course phrase it differently and just point out it's due to a technical limitation.

\cc @ericwindmill Just so you're aware of the discussion and possibilities here :) - Perhaps you have some thoughts too!

I would like to repurpose this issue to investigate if we could simply lift this limitation. So I am retitling this accordingly.