6 ms·

Quick question for the ocaml crowd: what keeps you with ocaml when you have a very similar and more easily parallelized f# available? I ask as an outsider to bo

Quick question for the ocaml crowd: what keeps you with ocaml when you have a very similar and more easily parallelized f# available? I ask as an outsider to both, but a fan of ML-ish languages in general. Would Jane Street ever be open to using F# or Haskell or Rust or Scala?

mercurial 12y ago
I'm only a recent dabbler in OCaml, so take my opinion with a grain of salt. First off, it depends on what kind of problem you are working on. Support for concurrency is good (through Lwt and Async), so the situation is not worse (actually, better, because monadic concurrency is vastly superior to callbacks) than in a popular language like Javascript, or Python with its GIL. Secondly, work started on a parallel runtime a few months ago, and seems to progress at a steady pace, so we should get parallelism and cheap fibers at some point. Regarding other functional languages, you are mixing some oranges in your apples. I find Rust appealing, especially with the amount of thought that goes into crafting it, but when it comes down to it, it is intended to replace C++. You are trading the convenience of a garbage-collected runtime for more control over memory allocation, and this comes at a cost. I could imagine OCaml calling Rust code for performance-critical sections, though. Regarding F#, it's no doubt a nice language and works as an incubator for ideas which trickle down to C# eventually, but I for one have little interest in the .Net ecosystem. Scala I find too scattered in terms of features, it doesn't make for a very elegant language. Also, the JVM is performant, but it's a pig in terms of memory. As for Haskell, many OCaml developers have been moving to it in the last few years. On the other hand, you don't switch to language with a lazy runtime with impunity (debugging Haskell is not particularly fun). I find the average complexity of Haskell programs higher, and a combination of syntactic features, popularity of custom ASCII operators and one-letter variable names make for sometimes barely readable code. Not to mention that OCaml is more pragmatic: sometimes it is convenient to write a for loop.
- adamnemecek 12y ago
  Rust actually has an optional GC. Also, even non-GC code in Rust is a lot different than say in C++ since the compiler can point out a lot of memory leaks to the programmer.
  - mercurial 12y ago
    I'm well aware of that. However, using GC fattens considerably Rust type signatures (want a garbage-collected list of garbage-collected Foos? Enjoy writing Gc<List<Gc<Foo>> everywhere). It's just not particularly idiomatic. And Gc types are not Send types, so you can't share them across tasks, which is unfortunate since we were precisely discussing the lack of parallelism in OCaml :) It's not a dig at Rust, which I think is very well designed, but IMHO, it is in a different niche compared to the other functional languages listed above.
    - mcguire 12y ago
      "...writing Gc<List<Gc<Foo>> everywhere..." Rust, unlike Java, has type definitions[1]; there's no need to use the full expansion everywhere. (I don't believe it's even necessary in Java, but creating subclasses has its own downsides.) [1] http://doc.rust-lang.org/0.11.0/rust.html#type-definitions http://doc.rust-lang.org/0.11.0/rust.html#type-definitions
      - mercurial 12y ago
        Yes, you can do that, but it's pretty obvious that if you want garbage collection everywhere, you're not going to use a language with linear types and optional, pretty much discourage GC, and write type synonyms all over the place (or fat signatures), you're going to go for a language where it's natural.
  - LeonidasXIV 12y ago
    > Rust actually has an optional GC. Last time I checked (0.10 or so) it did not. Gc pointers were the same as Rc pointers with a proper GC to come soon.
    - mcguire 12y ago
      Rust has roughly the same problem as C/C++: without compiler support for garbage collection, you quickly get off into the unappealing-option weeds. In this case, either "conservative" collection, or smart-pointer based collectors, which have performance issues compared to "proper GC's". (As far as GC features go, you can get pretty far with smart pointers: http://maniagnosis.crsr.net/2014/03/automatic-memory-management-hybrid.html http://maniagnosis.crsr.net/2014/03/automatic-memory-managem... .)
mattlam 12y ago
At 48:10, the presenter briefly talks about the plausibility of using F#, Haskell, and Scala at Jane Street.
- hoggle 12y ago
  Very interesting, in terms of pragmatism OCaml was the best choice for them at the time but now Minsky would also consider using Haskell or Scala. I guess Scala might arguably be the most pragmatic of the lot (access to tons of high-quality Java libraries, etc)?
jordwalke 12y ago
OCaml is not my primary programming language, but I have been looking at it among many other options including all of the ones you mentioned. The module system of OCaml is very powerful, and a similar module system is not present in F#, or anything else besides some variants of StandardML as far as I know. I was able to accomplish many things using Functors that I have not been able to accomplish in any other languages. Here's a link to one of my previous comments regarding some of OCaml's compelling or unique features: https://news.ycombinator.com/item?id=7861033 https://news.ycombinator.com/item?id=7861033 At the time of writing that, there were a couple of reasons why you still might consider Haskell instead of OCaml (assuming you were willing to accept complete purity and were willing to adapt to lazy evaluation). Those two primary reasons were type classes and a multi-core runtime (where immutability would really shine). I don't know much about Haskell, but this is what I've heard from other well informed people. I'm sure there's many other great reasons to use Haskell over OCaml, but these were the main ones from what I could tell. But since then, it looks like there's been great progress on an OCaml multi-core runtime, and also something very similar to type classes (module implicits). We'll have to see how those develop but it's definitely exciting. Also since then, Jeffrey Scofield has accomplished a lot to get OCaml working on modern iOS systems so you can build native iOS apps with OCaml: http://psellos.com/ocaml/compile-to-iphone.html http://psellos.com/ocaml/compile-to-iphone.html I've been building a small project in OCaml for a while now, and my experience hasn't left me wanting any core language feature that some other language has, aside from possibly a multi-core runtime (I haven't actually needed it yet, but I will soon). Most of the things I wish were different are very superficial syntactic gripes - but OCaml supports arbitrary syntax via ppx extensions so I can just stop complaining and build the syntax I want to program in. (Haskell-inspired syntax? Swift-inspired syntax?). The only other feature I'd like to see is a unification of the object system and record system: You could describe that as "row polymorphism" built into records (complete with pattern matching). No other major contenders support this, so it doesn't effect my language decision, yet it would be a welcomed feature.
- frowaway001 12y ago
  > The module system of OCaml is very powerful, and a similar module system is not present in F#, or anything else besides some variants of StandardML as far as I know. Scala's module system is very similar to ML's. Object ≅ Structure Class ≅ Functor Trait ≅ Signature Abstract Type ≅ Abstract Type Refinement ≅ Sharing Constraint
tomp 12y ago
F# runs on CLR. I use a Mac. (Yes, I know about Mono, but I'd rather use something officially supported). Also, I don't see a real difference between CLR and JVM, and I won't support another VM that purposely breaks up the ecosystem. (On the other hand, if MS continues the current trend and goes completely open source/free software (edit: and adds an ahead-of-time compiler), I'll probably change my mind.)
- guiomie 12y ago
  I believe F# runs on Mono, thus mac and linux.
edwintorok 12y ago
F# can only create .Net code AFAIK, and according to wikipedia it supported Linux only since 2010. I have already decided to learn/experiment with OCaml by that time, and I haven't payed much attention to languages that can only run on .Net/Mono because Linux will probably always be a second-class platform for them.
jlouis 12y ago
Somewhat haphazardly: * You don't have the C# baggage * You have a modern module system, which is only paralleled in Standard ML. This is very important for large developments where the need to split your code base into manageble chunks is extremely important. * The sequential code generator is very good. * Compilation times are fast. Not Go-fast, but reasonably fast. Building OCaml itself with OCaml can be done in around 1 minute on a fast machine. * The language is strict! This makes some gotchas w.r.t memory behaviour much easier to reason about, and is a definining distinction towards Haskell * The language is rather small in the core. In contrast to Scala. * The Garbage Collector is state of the art. It is fast. It has small pause times. It doesn't overuse memory. * The language is mature, which Rust isnt'. When Janes Street started, Rust did not even exist.

mercurial 12y ago

I'm only a recent dabbler in OCaml, so take my opinion with a grain of salt. First off, it depends on what kind of problem you are working on. Support for concurrency is good (through Lwt and Async), so the situation is not worse (actually, better, because monadic concurrency is vastly superior to callbacks) than in a popular language like Javascript, or Python with its GIL. Secondly, work started on a parallel runtime a few months ago, and seems to progress at a steady pace, so we should get parallelism and cheap fibers at some point. Regarding other functional languages, you are mixing some oranges in your apples. I find Rust appealing, especially with the amount of thought that goes into crafting it, but when it comes down to it, it is intended to replace C++. You are trading the convenience of a garbage-collected runtime for more control over memory allocation, and this comes at a cost. I could imagine OCaml calling Rust code for performance-critical sections, though. Regarding F#, it's no doubt a nice language and works as an incubator for ideas which trickle down to C# eventually, but I for one have little interest in the .Net ecosystem. Scala I find too scattered in terms of features, it doesn't make for a very elegant language. Also, the JVM is performant, but it's a pig in terms of memory. As for Haskell, many OCaml developers have been moving to it in the last few years. On the other hand, you don't switch to language with a lazy runtime with impunity (debugging Haskell is not particularly fun). I find the average complexity of Haskell programs higher, and a combination of syntactic features, popularity of custom ASCII operators and one-letter variable names make for sometimes barely readable code. Not to mention that OCaml is more pragmatic: sometimes it is convenient to write a for loop.

adamnemecek 12y ago
Rust actually has an optional GC. Also, even non-GC code in Rust is a lot different than say in C++ since the compiler can point out a lot of memory leaks to the programmer.
- mercurial 12y ago
  I'm well aware of that. However, using GC fattens considerably Rust type signatures (want a garbage-collected list of garbage-collected Foos? Enjoy writing Gc<List<Gc<Foo>> everywhere). It's just not particularly idiomatic. And Gc types are not Send types, so you can't share them across tasks, which is unfortunate since we were precisely discussing the lack of parallelism in OCaml :) It's not a dig at Rust, which I think is very well designed, but IMHO, it is in a different niche compared to the other functional languages listed above.
  - mcguire 12y ago
    "...writing Gc<List<Gc<Foo>> everywhere..." Rust, unlike Java, has type definitions[1]; there's no need to use the full expansion everywhere. (I don't believe it's even necessary in Java, but creating subclasses has its own downsides.) [1] http://doc.rust-lang.org/0.11.0/rust.html#type-definitions http://doc.rust-lang.org/0.11.0/rust.html#type-definitions
    - mercurial 12y ago
      Yes, you can do that, but it's pretty obvious that if you want garbage collection everywhere, you're not going to use a language with linear types and optional, pretty much discourage GC, and write type synonyms all over the place (or fat signatures), you're going to go for a language where it's natural.
- LeonidasXIV 12y ago
  > Rust actually has an optional GC. Last time I checked (0.10 or so) it did not. Gc pointers were the same as Rc pointers with a proper GC to come soon.
  - mcguire 12y ago
    Rust has roughly the same problem as C/C++: without compiler support for garbage collection, you quickly get off into the unappealing-option weeds. In this case, either "conservative" collection, or smart-pointer based collectors, which have performance issues compared to "proper GC's". (As far as GC features go, you can get pretty far with smart pointers: http://maniagnosis.crsr.net/2014/03/automatic-memory-management-hybrid.html http://maniagnosis.crsr.net/2014/03/automatic-memory-managem... .)

mattlam 12y ago

At 48:10, the presenter briefly talks about the plausibility of using F#, Haskell, and Scala at Jane Street.

hoggle 12y ago
Very interesting, in terms of pragmatism OCaml was the best choice for them at the time but now Minsky would also consider using Haskell or Scala. I guess Scala might arguably be the most pragmatic of the lot (access to tons of high-quality Java libraries, etc)?

jordwalke 12y ago

OCaml is not my primary programming language, but I have been looking at it among many other options including all of the ones you mentioned. The module system of OCaml is very powerful, and a similar module system is not present in F#, or anything else besides some variants of StandardML as far as I know. I was able to accomplish many things using Functors that I have not been able to accomplish in any other languages. Here's a link to one of my previous comments regarding some of OCaml's compelling or unique features: https://news.ycombinator.com/item?id=7861033 https://news.ycombinator.com/item?id=7861033 At the time of writing that, there were a couple of reasons why you still might consider Haskell instead of OCaml (assuming you were willing to accept complete purity and were willing to adapt to lazy evaluation). Those two primary reasons were type classes and a multi-core runtime (where immutability would really shine). I don't know much about Haskell, but this is what I've heard from other well informed people. I'm sure there's many other great reasons to use Haskell over OCaml, but these were the main ones from what I could tell. But since then, it looks like there's been great progress on an OCaml multi-core runtime, and also something very similar to type classes (module implicits). We'll have to see how those develop but it's definitely exciting. Also since then, Jeffrey Scofield has accomplished a lot to get OCaml working on modern iOS systems so you can build native iOS apps with OCaml: http://psellos.com/ocaml/compile-to-iphone.html http://psellos.com/ocaml/compile-to-iphone.html I've been building a small project in OCaml for a while now, and my experience hasn't left me wanting any core language feature that some other language has, aside from possibly a multi-core runtime (I haven't actually needed it yet, but I will soon). Most of the things I wish were different are very superficial syntactic gripes - but OCaml supports arbitrary syntax via ppx extensions so I can just stop complaining and build the syntax I want to program in. (Haskell-inspired syntax? Swift-inspired syntax?). The only other feature I'd like to see is a unification of the object system and record system: You could describe that as "row polymorphism" built into records (complete with pattern matching). No other major contenders support this, so it doesn't effect my language decision, yet it would be a welcomed feature.

frowaway001 12y ago
> The module system of OCaml is very powerful, and a similar module system is not present in F#, or anything else besides some variants of StandardML as far as I know. Scala's module system is very similar to ML's. Object ≅ Structure Class ≅ Functor Trait ≅ Signature Abstract Type ≅ Abstract Type Refinement ≅ Sharing Constraint

tomp 12y ago

F# runs on CLR. I use a Mac. (Yes, I know about Mono, but I'd rather use something officially supported). Also, I don't see a real difference between CLR and JVM, and I won't support another VM that purposely breaks up the ecosystem. (On the other hand, if MS continues the current trend and goes completely open source/free software (edit: and adds an ahead-of-time compiler), I'll probably change my mind.)

guiomie 12y ago
I believe F# runs on Mono, thus mac and linux.

edwintorok 12y ago

F# can only create .Net code AFAIK, and according to wikipedia it supported Linux only since 2010. I have already decided to learn/experiment with OCaml by that time, and I haven't payed much attention to languages that can only run on .Net/Mono because Linux will probably always be a second-class platform for them.

jlouis 12y ago

Somewhat haphazardly: * You don't have the C# baggage * You have a modern module system, which is only paralleled in Standard ML. This is very important for large developments where the need to split your code base into manageble chunks is extremely important. * The sequential code generator is very good. * Compilation times are fast. Not Go-fast, but reasonably fast. Building OCaml itself with OCaml can be done in around 1 minute on a fast machine. * The language is strict! This makes some gotchas w.r.t memory behaviour much easier to reason about, and is a definining distinction towards Haskell * The language is rather small in the core. In contrast to Scala. * The Garbage Collector is state of the art. It is fast. It has small pause times. It doesn't overuse memory. * The language is mature, which Rust isnt'. When Janes Street started, Rust did not even exist.