Wait I’m confused. You said that concurrency is a lie and that’s it’s parallel but not concurrent. But it is parallel (meaning it’s also concurrent). I’m missing something but not sure what.
sb8244
Author of Real-Time Phoenix
dimitarvp
Concurrency can be achieved on a single-core machine. People did it for decades, long before multicore CPUs existed. Hell, I did it on my Apple IIc when I was a teen (switching between several programs with strategically placed interrupt CPU commands).
Parallelism means to literally and physically have separate programs working in parallel (not emulated via insanely fast switching like a single-core CPU concurrency does).
That’s how I understood it at least.
3
wanton7
Concurrency = giving time slices to different processes from same CPU core.
Parallel = processes running on different CPU cores.
If I’ve understand Erlang’s VM BEAM correctly it decides how processes are run they could run concurrently or parallel. But usually they are running processes concurrently with other processes because you quite likely have so many of them that they exceed double amount of CPU cores.
1
hauleth
kjwvanijk
sb8244
Author of Real-Time Phoenix
JeyHey
Well said. This is a central point to understand I think. I.e. if you are unhappy with the speed of Erlang and choose C or Rust then you’ll not get the preemptive concurrency. This is fine unless you start getting unhappy with C/Rust/[…] and try to bring preemptive concurrency into them. If you try so you will end up with a buggy slow own implementation of Erlang. Yet put into other words that means that if you are looking for the features that Erlang gives you, you cannot find a faster and more reliable implementation.
3