This quote from Joe Armstrong explains the difference better than I can. There are other factors than just this in play of course.

> [Erlang] is a concurrent language – by that I mean that threads are part of the programming language, they do not belong to the operating system. That's really what's wrong with programming languages like Java and C++. It's threads aren't in the programming language, threads are something in the operating system – and they inherit all the problems that they have in the operating system. One of the problems is granularity of the memory management system. The memory management in the operating system protects whole pages of memory, so the smallest size that a thread can be is the smallest size of a page. That's actually too big.

> If you add more memory to your machine – you have the same number of bits that protects the memory so the granularity of the page tables goes up – you end up using say 64kB for a process you know running in a few hundred bytes.

Great point! However, I've found that the implementations of user space, preemptive threads (UPT) have friendlier APIs than the implementations of kernel space, preemptive threads (KPT). Also, UPT APIs generally come with really nice synchronization primitives (like STM in Haskell) or designs that remove the need for them (like message passing on BEAM). Also, I really like not worrying about creating too many threads and having to use a thread pool because the overhead of UPT is generally so much lower.

While it can be a little unclear what people mean, the Wikipedia take on threads is:

"Multiple threads can exist within one process, executing concurrently and sharing resources such as memory"

Whereas Erlang/Elixir processes don't share memory and have their own independent heaps and garbage collection.

Shared memory can lead to complicated effects if two threads try to change the same bit. You don't have that with Erlang processes.

That is like saying queues are basically the same as lists!

size, scheduling and the lack of shared state add up to vast differences. Also the message parsing primitives are way more lightweight than the thread based equivalents.