While I'm always down with research into applied restricted languages, I'm not sure this is the path to mainstream parallel programming. It's one thing to iden

While I'm always down with research into applied restricted languages, I'm not sure this is the path to mainstream parallel programming. It's one thing to identify that parallel execution is safe, and it's quite another to exploit that parallelism efficiently. E.g. in a pure functional language, you can automatically extract an enormous amount of parallelism, but doing so eagerly and naively will lead to a very slow program, as the communication and synchronisation overheads will dwarf any performance benefits of parallel execution. In practice, it appears that programmers don't find it problematic to explicitly indicate when things should run in parallel, and the main task of the language is to impose restrictions to avoid accidental sharing and race conditions. Rust is probably the most hyped example of such a language, but it's by no means the first or only one. Also, the elephant in the room is that in many common cases, the programming model is such that you get massive parallelism almost for free - e.g. when writing server-side web programs, where parallelism inside of one request may not matter (and often the database will take care of it when it does), because you have thousands of concurrent requests anyway.