Come on now. Unless you have a strict one-thread-pinned-per-core runtime then you can’t claim it for any runtime, Golang’s and Rust’s tokio’s included.

Fact is that most parallel runtimes do parallelization on a best-effort basis and they do a damn good job at it. There was a rather hilarious article a while ago reposted on HN how the Linux kernel never used more than 4 (or 8?) cores for a while, some years ago. What can a runtime do if the kernel is lying to it? But that’s a separate topic.

So… 100% guarantee? No, but it’s at least 90%.

No as long as you stay in the same process then you do not care, basically, as the data is not copied. The closure will use the same pointer to the data as the parent scope does.

Using the term parallel in this context is incorrect, the correct term would be concurrently and this has some very important implications:

1. You are not guaranteed that the spawned tasks will be running on a separate physical core, as this is decided by the scheduler, there are ways to configure this manually, however you will be breaking the abstraction level of concurrency used in elixir and potentially introduce locks;
2. As the scheduler switches context between running processes, every process will get a slice of execution time, naturally having more processes on the same thread will make them run slower.

To be fair, that wasn’t very surprising. Parallelizing in such a manner only saves time when (1) there’s lots of it (not just 3 tasks) and (2) the data is not being carried around but is crunched into much smaller pieces and/or sent off to other systems (Kafka, Postgres et. al.).

But the article was informative and interesting, and I thank you for it.

Unbounded parallelism is generally not a good tactic. Your workload and underlying hardware capabilities should be well understood to help determine how concurrent you want a set of tasks to go.