All of that barely matters to me. Where's the transparent parallelization? 2022 is going to be over soon, no language has any excuse to lack an easy way to do message passing and automatic thread pool management like Erlang and Rust's `tokio` do.
There is a good excuse: Not having multi-{m,b,t}illion-dollar corporate entities working on the language full-time is a good reason for something to not exist.
Not having a corporation back the development of a language has tons of downstream effects, including:
- lack of support opportunities
- lack of employment opportunities
- lack of evolution and development of an ecosystem
- higher churn and/or attrition
- fewer opportunity to do long-term design and implementation projects
Yes, sometimes there are FOSS miracle workers who are so extraordinarily productive without being paid, but they're few and far between.
(Aside from that, not all users need such functionality.)
Honestly, there are way too many programming languages already. Even though a chunk of them are interesting as thought experiments and potential future investments (like that one that content-addresses its own AST; forgot the name), I believe it's high time we all focus on more practical aspects.
Parallelism is one of those. Only microcontrollers are single-core these days, and not even all of them.
I sympathize with the people who have fallen in love with their own idea and are sad that others "don't see the light" and don't support them -- but our world is an imperfect system and that's a fact of life.
F.ex. I'd kill for a LISP with strong(er) static typing plus Erlang's transparent parallelism and runtime but yeah, we don't have that. So Elixir and Rust it is for me.
Wow, I did a double take, you sound like me. When I said something similar praising Haskell's effortless parallelism, someone made a reply that lead to my learning Clojure.
Racket /also/ has `thread` which is a co-routine but afaik you cannot pass the co-routine off to another native thread and there are certain constraints passing data between different threads, similar to transferring ownership.
Transparent parallelization needs a new generation of languages that are designed to let compiler do parallelization transformations. Like Futhark.
Hopefully we can get better integration than in the procedural language side where the parallel languages are completely separate from host app languages and are called via FFI.
Well, I am likely misguided since I never wrote a compiler in my life -- but to me it feels the "purer" a language is, the easier it is to make automated analysis on how to parallelize its code fragments? Hence FP languages are better candidates, I'd think?
It can be a helpful feature together with other language design features supporting parallelism but it's not a silver bullet. Existing old sequential world PLs have proven hard to auto parallelize, FP or not.
