Hacker News Reader

Comment by smabie | Hacker News Reader

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.

View on HN

> 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.

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 = ...

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"))

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.

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.

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.

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.

That's effectively not true[1].

[1]: https://github.com/SMLFamily/Successor-ML

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/...

Let's be real - Successor ML is never happening. I just don't think there's enough interest.

Yup. Realistically, the successor of ML is in fact OCaml.

SML/NJ, as I understand it, is implementing Successor ML features, so one of three things is true:

(1) Successor ML is happening,

(2) Standard ML is alive and evolving,

(3) SML/NJ isn’t just an implementation but a distinct language which is a successor to Standard ML and which incorporates what was described as “Successor ML”.

>full of inconsistencies and bolted-on features that are practically useful but definitely not simple or elegantly designed

Care to elaborate? What are you referring to?

Just some examples:

- First-class modules don't feel very first class, with how clunky it is to use modules at the value level

- Records are very clunky and hacky to use

- Generative functors are a hack

- Special language-level equality magic is awful (although SML also has this problem)

- Special `let` forms (whether via ppx or integrated into the language) feel really hacky

- GADTs require too much handholding of the typechecker

- All the "Objective" parts have very few redeeming qualities and should probably never have existed

- The way infix operators work is really half-assed

I don't think OCaml is a _bad_ language - it's very practically useful. It's just not simple or elegant.

Words like "clunky" and "hacky" are evaluation judgments, not objective criticism.

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.

What libraries did you feel were missing? I would say that OCaml has a pretty respectable ecosystem.

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.

> 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.

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.

It has concurrency allready, LWT and a solution from Jane Street. Parallelism is dropping soon.

OCaml's compile speed is very very fast. I think it's actually quite a bit faster than Go's compile speed.

OCaml has really good libraries for concurrency–e.g. check out 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.

> The language is on par with F#,

Isn't F# an Ocaml derivative?

I wouldn't call F# an OCaml derivative, but rather they are both ML derivatives.

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-micros...

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

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.

There is was post about this not so long ago

https://discuss.ocaml.org/t/significant-performance-differen...

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).

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?

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.

> 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.

First place modules and higher order modules are a hack to get around the limited polymorphism that OCaml provides. Like, just compare OCaml code to Haskell code. Haskell is way more concise, way more powerful, and less messy.

Like we can't have real monads in OCaml, because no HKT. And the module system isn't a solution. We have to be careful to import the right stuff, because >> and >>= exist for each separate monad. So now we have to write code that's not general, not polymorphic, and just ugly.

Haskell is a more powerful language than OCaml, full stop. OCaml programmers always talk about the module system, but it's honestly not very impressive. Typeclasses are a much more elegant solution.

I want to just be able to fmap things, and bind things, I don't want to have to think about the concrete types I'm working with. Also the lack of function polymorphism is super shitty.

And I think most agree that using different functions for arithmetic on floating points is stupid, inelegant, and a waste of time.

Modular implicit could solve this problem, and allow typeclasses like programming in OCaml.

> First place modules

First-class modules.

The points that you're bringing up are points that 99% of programmers don't care about. You're fighting about OCaml vs Haskell features but the really is that most people looking at alternatives in this niche are just going to go with Go or Rust (neither of which has higher-kinded types).

The reality is that OCaml offers a very simple and elegant base language, a powerful module system, a limited amount of type-level programming support (locally abstract types, GADTs, etc.), and probably the biggest draw of all: super-fast compile times. Seriously, no matter how impressive the Haskell compiler is–ocamlc and ocamlopt and BuckleScript all run rings around every variant of Haskell compiler.

You are criticizing OCaml on criteria that it honestly did not choose to optimize in. Would you criticize Haskell on its lack of a powerful module system, on its lack of strictness by default, on its complex runtime, on its confusing error messages that arise from ad-hoc polymorphism, and on its slow compiles? Sure you could, but it didn't choose to optimize for those. It doesn't make sense to fixate on things that were never a goal in the first place. If those things are your goals then you would simply find a compiler that offers them.

> > First place modules

> First-class modules.

I think smabie might have meant "In the first place, module and higher-order modules ...".

And as much as I like both, at the end of the day I will be delivering projects in Java, C# or C++, because costumers don't care how their pizza selling app looks like inside.

Reply on news.ycombinator.com