7 ms·

I like Ocaml and it would be a good choice of language for most kinds of projects, especially if good performance is desired. OCaml is dead simple to learn (I a

by smabie 6y ago

I like Ocaml and it would be a good choice of language for most kinds of projects, especially if good performance is desired. OCaml is dead simple to learn (I always recommend it as the first FP language they should learn) and eminently practical. If you're coming from Haskell or Scala though, OCaml's type system is going to come off as pretty primitive. And in many ways it is primitive, the idea of "type-level" programming isn't really a thing in the OCaml community. My favorite part of OCaml though is that the compiler generates fast, native binaries, which in my opinion is reason enough to choose it over Scala or F#. The language is on par with F#, but notably less expressive than Scala. But if you want a simple language that anyone can pick up quickly, one with a well defined performance profile and a practical, concrete ecosystem, OCaml might be the perfect choice. Just don't expect a Haskell or Scala like experience.

michaelcampbell 6y ago
> The language is on par with F#, Isn't F# an Ocaml derivative?
- smabie 6y ago
  I wouldn't call F# an OCaml derivative, but rather they are both ML derivatives.
  - brmgb 6y ago
    F# literally started as a Caml port to .Net by Don Syme. It's hard to be more derivative than that. It's right there in the historical acknowledgements part of the F# website [1]. [1] https://www.microsoft.com/en-us/research/project/f-at-microsoft-research/?from=http%3A%2F%2Fresearch.microsoft.com%2Fen-us%2Fum%2Fcambridge%2Fprojects%2Ffsharp%2Fack.aspx https://www.microsoft.com/en-us/research/project/f-at-micros...
  - atombender 6y ago
    It's more fair to say that F# originated as a heavily OCaml-influenced Caml implementation. It was originally called Caml.net [1], after all: "The early conception of F# was simple: to bring the benefits of OCaml to .NET and .NET to OCaml: a marriage between strongly typed functional programming and .NET. Here 'OCaml' meant both the core of the language itself, and the pragmatic approach to strongly-typed functional programming it represented. The initial task was relatively well-defined: the author would re-implement the core of the OCaml language and a portion of its base library to target the .NET Common Language Runtime. The implementation would be fresh, i.e. not using any of the OCaml codebase, for legal clarity. The first lines of the F# implementation were written in December 2001, a front-end for a re-implementation of the core Caml syntax targeting ILX as a back end, and thus to .NET. The initial compiler was written using OCaml." The initial version of F# was very much OCaml without functorial modules or object extensions. [1] https://fsharp.org/history/hopl-draft-1.pdf https://fsharp.org/history/hopl-draft-1.pdf
- deleted 6y ago
  [deleted]
karmakaze 6y ago
> compiler generates fast [...] reason enough to choose it over Scala or F# Is the edit/compile/run cycle faster than F#? If either OCaml or F# produce a sufficiently fast program which compiles faster? Also how seamless is multithreaded operations compared to F#? I have some limited experience with F# (on Mac) and the biggest drawback was getting the environment correctly set up after which most everything seemed very natural.
- smabie 6y ago
  I've never used F# in any serious capacity, but OCaml compilation time is really fast. Ocaml multicore is going to drop soon, so mainline OCaml should finally have a real concurrency story soon. The effects system looks pretty interesting.
  - deleted 6y ago
    [deleted]
  - scns 6y ago
    It has concurrency allready, LWT and a solution from Jane Street. Parallelism is dropping soon.
- dwohnitmok 6y ago
  OCaml's compile speed is very very fast. I think it's actually quite a bit faster than Go's compile speed.
- yawaramin 6y ago
  OCaml has really good libraries for concurrency–e.g. check out https://github.com/ocsigen/lwt https://github.com/ocsigen/lwt There is a GIL (like Node/Python) that means only one thread runs at any moment in time, but multiple threads can still be started. Lwt's Promise abstraction is very similar to Node's, except it's at the library level, not at the runtime level.
gameswithgo 6y ago
The performance of F# and OCaml would be interesting to compare in depth. I imagine F# has a higher performance ceiling these days, with .NET Core 3.1 and higher, but what about idiomatic code? Not so sure, since F# has some overhead in it's sequences and a few other things.
- systems 6y ago
  There is was post about this not so long ago https://discuss.ocaml.org/t/significant-performance-difference-between-ocaml-and-f/5977 https://discuss.ocaml.org/t/significant-performance-differen...
millimeterman 6y ago
I don't know if I'd call OCaml dead simple. It's full of inconsistencies and bolted-on features that are practically useful but definitely not simple or elegantly designed. It's kind of like the C++ of ML derivatives in that sense. I'd say Standard ML better fits the bill of "dead simple". The only issue is that tooling and learning resources are nearly nonexistent.
- deleted 6y ago
  [deleted]
- yawaramin 6y ago
  The main issue with Standard ML is that it's a dead language–it can't evolve beyond its current state. OCaml by comparison is steadily evolving.
  - bctnry 6y ago
    That's effectively not true[1]. [1]: https://github.com/SMLFamily/Successor-ML https://github.com/SMLFamily/Successor-ML
    - yawaramin 6y ago
      That repo is a bunch of TeX files (not even an implementation) that haven't been touched since 2018. I stand by my statement. By the way, the Successor ML wiki says[1]: > Standard ML, being incapable of evolution, is dead. The purpose of successor ML, or sML for short, is to provide a vehicle for the continued evolution of ML, using Standard ML as a starting point. The intention is for successor ML to be a living, evolving dialect of ML that is responsive to community needs and advances in language design, implementation, and semantics. Again, I stand by my statement that Standard ML is dead. [1] https://smlfamily.github.io/successor-ml/OldSuccessorMLWiki/Successor_ML.html#Successor_ML https://smlfamily.github.io/successor-ml/OldSuccessorMLWiki/...
    - millimeterman 6y ago
      Let's be real - Successor ML is never happening. I just don't think there's enough interest.
yodsanklai 6y ago
> OCaml is dead simple to learn I would say, the core of OCaml is dead simple to learn. But the language and the libraries/tools that make it usable for real-world projects have evolved a lot. Some projects can be quite intimidating. Just like in C++, I think it takes some discipline from the programmers to keep things simple.
brmgb 6y ago
From your post, I gather you are not very familiar with Ocaml module system. It's both where type-level programming happens and what F# doesn't have. You might be confusing your lack of knowledge of the languages with lack of the language. From my point of view, Ocaml is a lot nicer than Haskell (let's not talk about Scala).
- smabie 6y ago
  I'm very familar with the OCaml module system. If modular implicits were a thing, I'd say OCaml would be great. But functors are a poor substitute for typeclasses, atleast without modular implicits. Why would you assume that I'm not aware of a core feature of OCaml? Why would I even post about OCaml if I knew nothing (or hadn't written production code in it) about it?
  - momentoftop 6y ago
    Functors are indeed a poor substitute for typeclasses if I want ad-hoc polymorphism. If I want ad-hoc polymorphism, I want typeclasses. I find Scala's implicits to be a poor substitute (though not as poor as functors), and I'm sceptical that modular implicits are going to compare to typeclasses. But that's not why I care about functors. I use functors to package a bunch of types and values in a way that depends on a package of other types and values, which was their purpose from the beginning. In Haskell, I often want to do just this, but I find typeclasses (and associated types etc) to be a poor substitute for functors. For this reason, I keep an eye on backpack.
  - brmgb 6y ago
    > the idea of "type-level" programming isn't really a thing in the OCaml community. > I'm very familar with the OCaml module system These two statements don't seem compatible to me. > functors are a poor substitute for typeclasses, atleast without modular implicits. First, there are more than functors to Ocaml module system. First-class modules are a thing. Then, how are functors a poor substitute to type class ? Modular implicits is mostly sugar to avoid explicitly mentioning modules. That doesn't directly add anything to Ocaml capabilities.
pasabagi 6y ago
I liked Ocaml last time I had a go, but after getting to the point I could fumble my way around (can write a toy ray-tracer level proficiency) I couldn't really work out what I was supposed to do with it. The reason why a lot of people write C++, for instance, is not because they like it or think it's a particularly good language, but it's because an amazing amount of (for instance) graphics and maths libraries are written with the C++ developer in mind. It seems to me that the pain of working with a language you don't particularly like is way less than the pain of working with no libraries, or doing awkward FFI everywhere.
- smabie 6y ago
  What libraries did you feel were missing? I would say that OCaml has a pretty respectable ecosystem.
- ernst_klim 6y ago
  OCaml has a nice amount of system programming libraries, thanks to mirage project and jane street. It's a breeze to make system daemons with it for the most part, and compilers of course.
yawaramin 6y ago
I would correct a couple of things here. > The language is on par with F#, It's on par in some ways, and fairly they're different in other ways. E.g. F# has reified generics while OCaml erases all types at runtime. > notably less expressive than Scala. Personally I find it super difficult to express a lot of things in Scala that I can bang out in a few simple lines of OCaml. One of the simplest possible things for an FP language, try writing a sum type that type-checks properly when you put it in a list. Scala: scala> sealed trait PaymentMethod object PaymentMethod { case object Cash extends PaymentMethod case class CreditCard(name: String, number: String, expiry: String) extends PaymentMethod } scala> Seq(PaymentMethod.Cash, PaymentMethod.CreditCard(name = "Bob", number = "1111111111111111", expiry = "10/21")) res0: Seq[Product with PaymentMethod with java.io.Serializable] = ... OCaml: # module PaymentMethod = struct type t = | Cash | CreditCard of { name : string; number : string; expiry : string } end;; # [Cash; PaymentMethod.CreditCard { name = "Bob"; number = "1111111111111111"; expiry = "10/21" }];; - : PaymentMethod.t list = ...
- smabie 6y ago
  This is true, but Scala 3 solves this with enums. And with the new optional brace syntax, Scala is starting to look more like OCaml every day. In Scala 3: enum PaymentMethod case Cash case CreditCard(name: String, number: String, expiry: String) Seq(Cash, CreditCard("Bob", "1111111111111111", "10/21"))
  - yawaramin 6y ago
    That's unfortunately another one of Scala's cons, there will be a large breaking change in a few years and the ecosystem will be split again.
  - pjmlp 6y ago
    Java is slowly getting good enough for those of us that have to deal with mob development while wanting to enjoy a little bit of FP programming in the process, if the optional brace syntax goes through, that might that be the final straw for those that haven't yet moved back to Java or started to find new loves like Kotlin.

by smabie 6y ago

michaelcampbell 6y ago

> The language is on par with F#, Isn't F# an Ocaml derivative?

smabie 6y ago
I wouldn't call F# an OCaml derivative, but rather they are both ML derivatives.
- brmgb 6y ago
  F# literally started as a Caml port to .Net by Don Syme. It's hard to be more derivative than that. It's right there in the historical acknowledgements part of the F# website [1]. [1] https://www.microsoft.com/en-us/research/project/f-at-microsoft-research/?from=http%3A%2F%2Fresearch.microsoft.com%2Fen-us%2Fum%2Fcambridge%2Fprojects%2Ffsharp%2Fack.aspx https://www.microsoft.com/en-us/research/project/f-at-micros...
- atombender 6y ago
  It's more fair to say that F# originated as a heavily OCaml-influenced Caml implementation. It was originally called Caml.net [1], after all: "The early conception of F# was simple: to bring the benefits of OCaml to .NET and .NET to OCaml: a marriage between strongly typed functional programming and .NET. Here 'OCaml' meant both the core of the language itself, and the pragmatic approach to strongly-typed functional programming it represented. The initial task was relatively well-defined: the author would re-implement the core of the OCaml language and a portion of its base library to target the .NET Common Language Runtime. The implementation would be fresh, i.e. not using any of the OCaml codebase, for legal clarity. The first lines of the F# implementation were written in December 2001, a front-end for a re-implementation of the core Caml syntax targeting ILX as a back end, and thus to .NET. The initial compiler was written using OCaml." The initial version of F# was very much OCaml without functorial modules or object extensions. [1] https://fsharp.org/history/hopl-draft-1.pdf https://fsharp.org/history/hopl-draft-1.pdf
deleted 6y ago
[deleted]

karmakaze 6y ago

> compiler generates fast [...] reason enough to choose it over Scala or F# Is the edit/compile/run cycle faster than F#? If either OCaml or F# produce a sufficiently fast program which compiles faster? Also how seamless is multithreaded operations compared to F#? I have some limited experience with F# (on Mac) and the biggest drawback was getting the environment correctly set up after which most everything seemed very natural.

smabie 6y ago
I've never used F# in any serious capacity, but OCaml compilation time is really fast. Ocaml multicore is going to drop soon, so mainline OCaml should finally have a real concurrency story soon. The effects system looks pretty interesting.
- deleted 6y ago
  [deleted]
- scns 6y ago
  It has concurrency allready, LWT and a solution from Jane Street. Parallelism is dropping soon.
dwohnitmok 6y ago
OCaml's compile speed is very very fast. I think it's actually quite a bit faster than Go's compile speed.
yawaramin 6y ago
OCaml has really good libraries for concurrency–e.g. check out https://github.com/ocsigen/lwt https://github.com/ocsigen/lwt There is a GIL (like Node/Python) that means only one thread runs at any moment in time, but multiple threads can still be started. Lwt's Promise abstraction is very similar to Node's, except it's at the library level, not at the runtime level.

gameswithgo 6y ago

The performance of F# and OCaml would be interesting to compare in depth. I imagine F# has a higher performance ceiling these days, with .NET Core 3.1 and higher, but what about idiomatic code? Not so sure, since F# has some overhead in it's sequences and a few other things.

systems 6y ago
There is was post about this not so long ago https://discuss.ocaml.org/t/significant-performance-difference-between-ocaml-and-f/5977 https://discuss.ocaml.org/t/significant-performance-differen...

millimeterman 6y ago

I don't know if I'd call OCaml dead simple. It's full of inconsistencies and bolted-on features that are practically useful but definitely not simple or elegantly designed. It's kind of like the C++ of ML derivatives in that sense. I'd say Standard ML better fits the bill of "dead simple". The only issue is that tooling and learning resources are nearly nonexistent.

deleted 6y ago
[deleted]
yawaramin 6y ago
The main issue with Standard ML is that it's a dead language–it can't evolve beyond its current state. OCaml by comparison is steadily evolving.
- bctnry 6y ago
  That's effectively not true[1]. [1]: https://github.com/SMLFamily/Successor-ML https://github.com/SMLFamily/Successor-ML
  - yawaramin 6y ago
    That repo is a bunch of TeX files (not even an implementation) that haven't been touched since 2018. I stand by my statement. By the way, the Successor ML wiki says[1]: > Standard ML, being incapable of evolution, is dead. The purpose of successor ML, or sML for short, is to provide a vehicle for the continued evolution of ML, using Standard ML as a starting point. The intention is for successor ML to be a living, evolving dialect of ML that is responsive to community needs and advances in language design, implementation, and semantics. Again, I stand by my statement that Standard ML is dead. [1] https://smlfamily.github.io/successor-ml/OldSuccessorMLWiki/Successor_ML.html#Successor_ML https://smlfamily.github.io/successor-ml/OldSuccessorMLWiki/...
  - millimeterman 6y ago
    Let's be real - Successor ML is never happening. I just don't think there's enough interest.

yodsanklai 6y ago

> OCaml is dead simple to learn I would say, the core of OCaml is dead simple to learn. But the language and the libraries/tools that make it usable for real-world projects have evolved a lot. Some projects can be quite intimidating. Just like in C++, I think it takes some discipline from the programmers to keep things simple.

brmgb 6y ago

From your post, I gather you are not very familiar with Ocaml module system. It's both where type-level programming happens and what F# doesn't have. You might be confusing your lack of knowledge of the languages with lack of the language. From my point of view, Ocaml is a lot nicer than Haskell (let's not talk about Scala).

smabie 6y ago
I'm very familar with the OCaml module system. If modular implicits were a thing, I'd say OCaml would be great. But functors are a poor substitute for typeclasses, atleast without modular implicits. Why would you assume that I'm not aware of a core feature of OCaml? Why would I even post about OCaml if I knew nothing (or hadn't written production code in it) about it?
- momentoftop 6y ago
  Functors are indeed a poor substitute for typeclasses if I want ad-hoc polymorphism. If I want ad-hoc polymorphism, I want typeclasses. I find Scala's implicits to be a poor substitute (though not as poor as functors), and I'm sceptical that modular implicits are going to compare to typeclasses. But that's not why I care about functors. I use functors to package a bunch of types and values in a way that depends on a package of other types and values, which was their purpose from the beginning. In Haskell, I often want to do just this, but I find typeclasses (and associated types etc) to be a poor substitute for functors. For this reason, I keep an eye on backpack.
- brmgb 6y ago
  > the idea of "type-level" programming isn't really a thing in the OCaml community. > I'm very familar with the OCaml module system These two statements don't seem compatible to me. > functors are a poor substitute for typeclasses, atleast without modular implicits. First, there are more than functors to Ocaml module system. First-class modules are a thing. Then, how are functors a poor substitute to type class ? Modular implicits is mostly sugar to avoid explicitly mentioning modules. That doesn't directly add anything to Ocaml capabilities.

pasabagi 6y ago

I liked Ocaml last time I had a go, but after getting to the point I could fumble my way around (can write a toy ray-tracer level proficiency) I couldn't really work out what I was supposed to do with it. The reason why a lot of people write C++, for instance, is not because they like it or think it's a particularly good language, but it's because an amazing amount of (for instance) graphics and maths libraries are written with the C++ developer in mind. It seems to me that the pain of working with a language you don't particularly like is way less than the pain of working with no libraries, or doing awkward FFI everywhere.

smabie 6y ago
What libraries did you feel were missing? I would say that OCaml has a pretty respectable ecosystem.
ernst_klim 6y ago
OCaml has a nice amount of system programming libraries, thanks to mirage project and jane street. It's a breeze to make system daemons with it for the most part, and compilers of course.

yawaramin 6y ago

I would correct a couple of things here. > The language is on par with F#, It's on par in some ways, and fairly they're different in other ways. E.g. F# has reified generics while OCaml erases all types at runtime. > notably less expressive than Scala. Personally I find it super difficult to express a lot of things in Scala that I can bang out in a few simple lines of OCaml. One of the simplest possible things for an FP language, try writing a sum type that type-checks properly when you put it in a list. Scala: scala> sealed trait PaymentMethod object PaymentMethod { case object Cash extends PaymentMethod case class CreditCard(name: String, number: String, expiry: String) extends PaymentMethod } scala> Seq(PaymentMethod.Cash, PaymentMethod.CreditCard(name = "Bob", number = "1111111111111111", expiry = "10/21")) res0: Seq[Product with PaymentMethod with java.io.Serializable] = ... OCaml: # module PaymentMethod = struct type t = | Cash | CreditCard of { name : string; number : string; expiry : string } end;; # [Cash; PaymentMethod.CreditCard { name = "Bob"; number = "1111111111111111"; expiry = "10/21" }];; - : PaymentMethod.t list = ...

smabie 6y ago
This is true, but Scala 3 solves this with enums. And with the new optional brace syntax, Scala is starting to look more like OCaml every day. In Scala 3: enum PaymentMethod case Cash case CreditCard(name: String, number: String, expiry: String) Seq(Cash, CreditCard("Bob", "1111111111111111", "10/21"))
- yawaramin 6y ago
  That's unfortunately another one of Scala's cons, there will be a large breaking change in a few years and the ecosystem will be split again.
- pjmlp 6y ago
  Java is slowly getting good enough for those of us that have to deal with mob development while wanting to enjoy a little bit of FP programming in the process, if the optional brace syntax goes through, that might that be the final straw for those that haven't yet moved back to Java or started to find new loves like Kotlin.