I wonder how come people working in PL research aren’t more interested in concurrency. Typeclass, monads, etcs are great but they still haven’t reach the point were everyday people could expect to write proved safe program ( unless the code base is extremely small and you’re using special software such as Coq), and while they make programs more concise and expressives, i think concurrency remains the elephant in the room.
Rust is the first PL i’ve heard in a long time that tries to actually do something in that area since erlang ( that opted for strict message passing and let it crash philosophy, but gave you the tool to deal with that approach).
Is it because it’s too « down to earth » for PL purist, or is it simply because they don’t have the mathematical or logical tools to deal with the problem ?
Quite a lot of things have been tried since Erlang (1986). Concurrency has been a fairly well funded sector of compiler and PL research to the point of starving other arguably more important areas.
Futhark is one of the more interesting recent parallel languages IMO since GPU languages were in such a lull for a while. Too bad everyone is stuck with emitting opencl or going vendor specific though.
> Concurrency has been a fairly well funded sector of compiler and PL research to the point of starving other arguably more important areas.
Concurrency is enormously important in a world where instruction speed has saturated. Many problems are highly data-coupled, so you can't just separate these problems into loose tasks that you connect with a slow message pipe.
Of course, if you're just writing a web server or a chat server, then you might be lucky and you can get away with it. But please don't assume this holds for everybody.
Yeah, but it's "just" speed of execution, while for most things the bottleneck of making something possible is correctness and ease of developing while keeping complexity in check. So yes it's important but still mostly less important than some others :)
Tensorflow is interesting in this respect. Leveraging a lot of parallelism and using a parallel pl under the good, while presenting itself as a dev friendly Python lib on the surface.
The problem is that engineering an efficient concurrent garbage collected runtime environment is hard. It may even be harder than writing the compiler itself, especially if you rely on llvm for the back end.
Rust is the first PL i’ve heard in a long time that tries to actually do something in that area since erlang ( that opted for strict message passing and let it crash philosophy, but gave you the tool to deal with that approach).
Is it because it’s too « down to earth » for PL purist, or is it simply because they don’t have the mathematical or logical tools to deal with the problem ?