I've tried -- and failed -- to replicate what Elixir does in this regard, in several other programming languages. Age those tries incurred hundreds of coding lines. Only Rust came close, although it's a bit verbose, but the code still did the job.
I've tried -- and failed -- to replicate what Elixir does in this regard, in several other programming languages. Age those tries incurred hundreds of coding lines. Only Rust came close, although it's a bit verbose, but the code still did the job.
Scala's parallel collections handled this cleanly. I believe they've been removed from the built in libraries (still available as a JAR though), but the idea was that you'd just add a .par call in your data processing chain and it would use a parallel collection instead of a regular sequential one.
These examples from the documentation (https://docs.scala-lang.org/overviews/parallel-collections/o...) show how to turn a regular sequential computation:
val list = (1 to 10000).toList
list.map(_ + 42)
Into a parallel one list.par.map(_ + 42)
Oftentimes, for data processing, being able to parallelize parts of the computation makes it fast enough that one does not need to go beyond a single machine. Spark's RDDs are basically a distributed version of Scala's collection library.One of the areas where Elixir and Erlang shine is distributed applications.
For anyone who has written socket code, the ability to easily send regular Elixir data structures as messages to processes that may run locally or remotely is pretty awesome. And once you realize that you can also send closures over the network (ie. one node can send a snippet of code to another node and it'll be executed there), mind blown.
Do you have any insight on the underlying thread pool? Can you control the size? Is it automatically determined?
Erlang/Elixir default to CPU threads but the number of parallel thread schedulers can be manually changed as well.
I’d like to ask the same question about observables in JS (e.g. RxJS)
As a fairly experienced dev I prefer the technology to slap me hard on the cheek and not make me triple check things.
But Golang's concurrency is definitely a big step up from all the naked multithreading we had to endure and groom for decades -- that is unequivocally true!
I still find Erlang/Elixir's message passing paradigm superior though. Plus every "process" there (a fiber / green thread basically) is being transparently parallelized on another CPU core without you thinking about it at all.
As a personal scoreboard:
1. Erlang/Elixir's messages.
2. OCaml's "domain" effects (mutable shared state managed by multiple threads in a safe manner).
3. Golang's channels and messages.