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 ?

OCaml concurrency story is great, there are Lwt [1] and Async [2] for that.

Multicore is slowly incoming as well, bits are landing in mainline.

[1] https://ocsigen.org/lwt/4.1.0/manual/manual

[2] https://opensource.janestreet.com/async/

Oz and AliceML had a lot of work in concurrency, and AFAIR are both younger than Erlang.

Also, maybe not very original but Go seems to have put concurrency up front as one of its selling points

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.

Wp has a list at https://en.m.wikipedia.org/wiki/List_of_concurrent_and_paral...

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.

Pony also offers some nice ideas about concurrent programming as well as Occam.

OCaml would have seen so much more adoption if it had a solid multicore story. It really is a shame, because it's a nice language.

Like Python?

Python got adopted, IMHO, because of the hype around deep learning.

Python was already in the top 5 well before the whole AI craze and before pandas was out.

Python has a huge amount of introductory learning material that assumes it is your first language, while most FP languages (Ex: Clojure, Haskell, F#, Scala, OCaml) really struggle in this area. I really like FP, but there is a bit of a steep plateau when learning. If you look at some of the questions people ask in the Python stack exchange, you get the impression that millions are learning it as the defacto first language (I was one of those nearly a decade ago). I try to find similar paths to FP and everything from the tooling to lack of thorough introductory material keeps killing it for me.

Another issue is that from a pedagogy perspective all the "building blocks" in FP are different to what many people already know. If you're used to the imperative/OO paradigm you can move between languages by just learning the syntax to (lists, dictionaries, while and for loops, branching, array access, file IO, and classes). When learning FP you have to learn similar, but different concepts (pattern matching, monads, currying, discriminated unions...etc).

The beginner books that do exist (ex: learn you a Haskell) are nice, but I've talked to many (myself included) that when they finish say "I still have no clue how to program in Haskell". To give another example, I spent two weeks reading a Python book on building text games and when I was finished I was like "OMG I can do stuff". That book covered how all the main data structures could be used with short and fun programs. It also included reading text files, string operations, pickling data, classes, modules..use of the included IDLE IDE. It was great.

> Python has a huge amount of introductory learning material that assumes it is your first language, while most FP languages (Ex: Clojure, Haskell, F#, Scala, OCaml) really struggle in this area

I don't know how long ago have you tried Clojure, but it is a lot easier to start with than Haskell or Scala. There are now more than a dozen of books available (for the beginner and for the advanced levels). Clojure is much better than Python - it has extremely nice, consistent standard library; It has "true" REPL - with it you can evaluate almost any chunk of your code with no preliminary ritual, even much praised Jupyter doesn't feel as nice; Clojure not statically typed but it has Spec, which is totally awesome - the way how you can derive property based tests is almost mind-blowing; Clojure's stability is almost legendary; It makes concurrency simple; It makes dealing with dependencies less painful; It can seamlessly run on both: front-end and back-end, having live-updates in your browser and REPL connected to it feels like magic. Honestly, transforming data using Clojure is a pure joy.

I have a few Clojure books, but not knowing Java and the JVM very well and then having to learn Emacs/Cider and all the other tools really kind of killed it for me. In short, some of the Clojure REPL advantages are better than Python, but not by enough to justify learning the ecosystem.

I might try again later. I have "Clojure for the Brave and True", Carin Meiyer's book, and one of Fogus' books.

I really want to learn Clojure, but just need to sit down and put the time in. It's also discouraging to see people comment about some of these languages (Clojure and F#) as being on life support.

> (Clojure and F#) as being on life support

I can't say anything about F#, but Clojure is doing quite alright. It gathers more conferences and meetups around the world (more than Haskell, OCaml, F#, Elm or Elixir). Has more podcasts (defn, the REPl, Clojurescript podcast, Apropos, Cognicast), there are other podcasts created and run by people actively using Clojure, where they talk not only about Clojure. Clojurians Slack and clojureverse.org are very active. New libraries and books coming out regularly. My company recently was hiring and I shout out on Twitter and I got DM request from all over the world: Chile, Mexico, Brazil, Japan, India, Bangladesh, Jordan, Poland, Latvia, Ukraine, Russia, UK, Germany, US and other countries, people want to write Clojure full-time. So, yeah. I don't know where you read that Clojure is dying or whatever. It is not as big as Python or Javascript, but it's slowly, steadily growing.

I think Python has become so popular because Google started using it, but then later they switched to Golang. But the Python train was unstoppable at that point, even MIT swapped Scheme with it in their CS 101 course.

Use multiple processes, and then your code works across multiple machines too (and better across NUMA machines). Threads are simply a bad idea.

What is it called when you live in an environment where X is not available and so you convince yourself that X is a bad idea?

Modern security exploits and application crashes due to state corruption have proven that while threads were an enticing idea, they aren't something that we should keep around if we care about security and application stability.

This applies to all programming languages, not only OCaml, hence why everyone is moving away into other concurrency models anyway.

You have two matrices, with allocated memory A and B, that you want to multiply and store to allocated memory C, as efficiently as possible using 8 cores. How do you do this without threads exactly?

>You have two matrices, with allocated memory A and B, that you want to multiply and store to allocated memory C, as efficiently as possible

If matrices are small, 1 core would be more efficient. If matrices are big, GPU would be more efficient.

Vector instructions or GPGPU.

Assume no GPU. Vector instructions will only use one core at a time.

We are in 2019, even low level microcontrollers have dumbed down GPUs.

Plus I already answered your questions, not moving goal posts here.

I wanted an efficient no threads solution to a very common problem of matrix multiplication using multiprocessor CPUs. You gave me nonsense answers like vector operations (uses only one CPU at a time) and GPUs (memory transfer bottleneck, need to copy arrays, significantly less RAM compared to CPU RAM, and GPUs make it a completely different game). So no, I'm not moving goalposts.

You did not define what efficient means.

For example, a SIMD implementation will outperform a multithreaded implementation on a CPU without support for hardware threads.

My nonsense answer just happens to be what HPC is moving into, and when HPC wants to scale it uses MPI coupled GPUs, not plain old threads.

And will spend more time shuffling data through their horribly bottle-necked memory interfaces than the CPU would take handling the matrix operation, especially if the GPU is already used for graphics.

Multi-core systems and tools that can use them are valuable and very much reality right now.

Yep, CUDA and Vulkan Compute are such a waste in HPC, thankfully ML research is doubling down on threads.

You were the one who introduced GPUs on low-end embedded chips as an argument. HPC is a slightly different world.

Nah, you are the one that moved the goal posts after my first answer.

That was my first reply to you today...

As much as I often appreciate your no-nonsense perspective on things and you posting it, things like this don't really do you a favor.

EDIT: tweaked last line to be a bit less snippy

I don't always look at nicks.

There are many applications where these kind of security issues don't apply.

Such as?

Every application should strive for proper quality, just like in other industries.

For example: embedded applications, or when I'm the only one running trusted code on my computer. Think also of scientific computing.

If you insist on networked solutions: database servers.

Also: "multicore + purely functional style" is just as clean as "multiprocess + purely functional style", but ... the latter is less efficient because of communication overhead.

Unless you manage to do any kind of work without IO, there is always a security risk.

And if that is irrelevant to you, there is still the application stability and memory consistency to ensure data is being handled in a memory consistent state.

Fortran is a good example on how to do scientific computing without low level threads.

Yes threads should be used with extreme caution, that's why I advocate using a functional programming style. But you still want the performance of multicore. It's not one or the other (but with OCaml it unfortunately is).

I used shared memory concurrency all the time, you're simply wrong.

Correctly implemented concurrency/parallelism primitives are not a bad idea. I am thinking along the lines of Clojure/Erlang/Go. They make life more enjoyable.

One of the strengths of functional programming is using structurally shared immutable data structures. You can't use this approach efficiently if you don't share a heap with other processes. Converting everything to a shared byte array (or similar) mostly ruins the usefulness of the programming language, and also makes GC impossible.

Shared memory is still an issue though. To my knowledge there is no convenient way to share memory between processes in OCaml. That said, you are right, threads are horrible.

Wouldn't functional programming also bend itself particularly well to concurrent programming?

Concurrent programming in OCaml is fine though. Multicore is more about parallelism and the ability to use multiple cores without the need to rely on threads and multiple processes