6 ms·

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.

by lifty 7y ago

rwmj 7y ago
Use multiple processes, and then your code works across multiple machines too (and better across NUMA machines). Threads are simply a bad idea.
- dna_polymerase 7y ago
  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.
- lifty 7y ago
  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.
- newen 7y ago
  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?
  - rwmj 7y ago
    I used shared memory concurrency all the time, you're simply wrong.
  - pjmlp 7y ago
    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.
    - amelius 7y ago
      There are many applications where these kind of security issues don't apply.
      - pjmlp 7y ago
        Such as? Every application should strive for proper quality, just like in other industries.
        amelius 7y ago
        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.
        pjmlp 7y ago
        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.
        amelius 7y ago
        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).
    - newen 7y ago
      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?
- amelius 7y ago
  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.
Hsbfufbrtfd 7y ago
Wouldn't functional programming also bend itself particularly well to concurrent programming?
- mseri 7y ago
  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
bjoli 7y ago
Like Python?
- lostmsu 7y ago
  Python got adopted, IMHO, because of the hype around deep learning.
  - new4thaccount 7y ago
    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.
    - iLemming 7y ago
      > 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.

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.

by lifty 7y ago

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.

rwmj 7y ago

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

dna_polymerase 7y ago
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.
lifty 7y ago
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.
newen 7y ago
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?
- rwmj 7y ago
  I used shared memory concurrency all the time, you're simply wrong.
- pjmlp 7y ago
  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.
  - amelius 7y ago
    There are many applications where these kind of security issues don't apply.
    - pjmlp 7y ago
      Such as? Every application should strive for proper quality, just like in other industries.
      - amelius 7y ago
        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.
        pjmlp 7y ago
        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.
        amelius 7y ago
        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).
  - newen 7y ago
    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?
amelius 7y ago
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.

Hsbfufbrtfd 7y ago

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

mseri 7y ago
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

bjoli 7y ago

Like Python?

lostmsu 7y ago
Python got adopted, IMHO, because of the hype around deep learning.
- new4thaccount 7y ago
  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.
  - iLemming 7y ago
    > 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.