My thoughts on OCaml

https://osa1.net/posts/2023-04-24-ocaml-thoughts.html

by ghuntley • 3 years ago

185 201 3 years ago

osa1.net

xvilka• 3 years ago

Building, LSP server, and immutability are definitely better in 2023 than author describe in their article.

nequo3• 3 years ago

In what sense is immutability better? What changed?

ronnier• 3 years ago

Why would a company use ocaml?

I’ve worked in software now for most of my life, from small to the biggest companies. I’ve watched teams with senior developers use non mainstream languages to build services and just about every time those devs get board again, leave the team, leaving them stuck with this system that’s hard to develop and different from the rest of the orgs, eventually resulting in a complete rewrite.

At companies I try to be boring, not weird, and efficient. Which usually means for me, writing in a very mainstream language that is easy to hire for.

decafninja3• 3 years ago

I'm sure some companies out there might find a competitive advantage for using exotic languages and tech stacks.

But I get the impression the more common scenario is that the engineers were bored and given the chance, wanted to play with something new and shiny.

It also depends on the company's prestige. A company like Jane Street using OCaml? Considering both their prestige and the amount they pay, I'm sure they will have no problems hiring. Nor will their alumni have problems getting hired elsewhere.

Some no name startup or even some "innovation lab" inside a boring cludgy Fortune500? Yeah, no thanks.

felixyz3• 3 years ago

Jane Street wasn't all that prestigious when they started using OCaml. The way they put it is "it was easier to find great programmers in the empty set of people who know OCaml than in the huge set of other programmers" (roughly). So, on the contrary, I think it might help boring cludgy company find quality talent.

I think there is a fallacy being repeated in this thread, namely that the choice is between mainstream and weird, or between old-and-tested and new-and-shiny. No, that's not the choice. The choice is between tools and abstractions that are helpful and productive, and those that aren't. Some of the helpful and productive things are old, some are new, some are mainstream, some are niche.

I don't fully understand how someone wants to spend their career in programming and not actively seek out what is helpful and productive, rather than what currently gets the most questions on Stack Overflow or has a big pool of people who put it on their CV. It's not like all languages are equally good. It's a wasteful approach.

tikhonj• 3 years ago

I worked on a team using Haskell at Target for a few years and we had a massively easier time hiring compared to the other data science/ML teams. I figure it came down to two things:

1. People are actively interested in using Haskell and working with others interested in Haskell/PL/FP/etc. More people want to do Haskell than there are Haskell jobs and Haskell openings get massive word-of-mouth advertising.

2. It's a way to show that we're willing to do something different and interesting. Everybody says they are, but how do you actually demonstrate it? I remember one of the first great hires we had was an OR professor who didn't even know about Haskell—but joined in part because what we were doing was different and innovative.

If I ever end up starting my own company, I'm going to use Haskell because it's so much easier to hire for it—completely opposite to the superficial "common knowledge" that guides executive decisions at large companies.

anthk2• 3 years ago

MirageOS and microkernels.

jlouis• 3 years ago

A language like ocaml excels when the input and output are program-like, and the problem can't be number-crunched by hardware. The typical example would be a compiler. Other examples would be model checkers, code generators for number crunching libraries, proof assistants, and so on. Complex problems, where you need to explore different avenues of approach quickly, and where symbolic manipulation is at the heart of the problem.

Thus, ocaml is best used as a "kernel" or "module". The contextual part of your system uses the part written in ocaml as a service.

But ocaml doesn't excel at problems which are common to a typical company. The people who are in the intersection of wanting to solve those problems, and ocaml developers are few. The same intersection with a more mainstream language is far larger.

However, if you find yourself with a problem at which ocaml excels, chances are the mainstream languages ends up falling short very quickly, because they tend to lack the abstraction features necessary for correctly handling the complexity.

riku_iki3• 3 years ago

The question is if modern versions of popular languages (java, c#) caught up on ocaml's syntax sugar, or maybe this syntax sugar is trivially replaceable by some utility functions.

Maybe you could bring any example of such ocaml functionality?

lallysingh• 3 years ago

.. that's a complaint for all new languages. You don't know which ones will stick until you try.

Code in a strongly-typed functional language is easier to maintain because of the features of the language. The functional part gives great abstraction, and the strongly-typed part gives enough structure to make the whole thing tractable.

rashkov• 3 years ago

Absolutely agreed. I'm lucky to work on a ReasonML front-end codebase and the type system and immutability are a real pleasure to work with. The strong typing lets you code against the compiler, and there are many instances of "if it compiles it works" that crop up throughout development. There's no fear of refactoring code that you didn't write, because the compiler will warn you about consequences on the far end of the codebase that you didn't even know existed.

As a result of all of that, the app feels very solid to use and has comparatively few runtime errors.

the_af2• 3 years ago

Why would a company use ocaml?

PG claims using Lisp was the "secret sauce" to his early success. Whether this is true or not, and whether this is still true for companies today, remains to be seen. But it's an argument for things like OCaml.

kaba0• 3 years ago

It won’t really answer your question, but I found the Signals & Threads podcast fantastic, and it made me appreciate OCaml much more (it is produced by someone working at Jane Street).

I personally found the MirageOS, build systems and language design episodes terrific.

yafbum2• 3 years ago

Back when I tried it, there seemed to be a few verticals where Ocaml abstractions made Ocaml very productive to work with.

Once a colleague and I did a programming race between two languages, to see how long it would take to implement a small cryptanalysis program using Ocaml vs C++. I wrote it in a day, and it took my desk neighbor who was doing the same in C++ a couple of weeks.

What made the difference: - There were a lot of things I didn't have to worry about. For example, I was working with nontrivial structures but didn't have to write any boilerplate functions for deep equality or lex ordering. - Immutable structures with GC made it much more direct to translate the math into a working program. Ditto with guaranteed tail recursion optimization. - The match syntax caught many issues at compile time by forcing me to reason about every case. As a result I had many less runtime bugs to deal with, while my colleague needed to troubleshoot memory and correctness issues half the time.

Ymmv. This was for research and didn't end up in production use. The C++ implementation was also much "closer to the metal" so was able to wring out more performance. Still the difference in initial velocity was striking and there could've been a case that this would've been a better choice based on dev velocity in that vertical.

substation13• 3 years ago

Why would a company use ocaml?

Why wouldn't a company use Brainfuck?

lmm4• 3 years ago

OCaml is pretty much the most "boring", "mainstream" language that isn't awful. It's been around for decades. It's got an established library ecosystem, development tools and all that. And pretty much every bigger/more popular language is missing one or more basic feature that's been common-sense since the late '70s (e.g. sum types or pattern matching).

nu11ptr• 3 years ago

I like OCaml, but if I were to start a new project with an ML I'd probably lean towards F# to take advantage of all the .NET libs

JaggerJo7• 3 years ago

We use F# in prod. Could not be happier.

dimitrios13• 3 years ago

Completely ignorant here:

- I really want to do a project in an almost "pure" functional language. I tried with Elixir and Phoenix, and while they are certainly great, and I wouldn't mind using it again, Elixir, and subsequently Erlang didn't feel like FP a lot of times, it felt like the warty Elixir/Erlang way to do FP, so it didn't scratch that itch for me (but again, still a great experience overall)

- is there a way to do this openly? I.E. with dotnetcore, running on linux containers, no windows what so ever, etc? Guessing yes but wanted to make sure from people who have actually done it

- What exactly about the .NET libraries that has everyone so hyped up about? I remember from my C# .NET days, they always felt to be lacking.

lysecret2• 3 years ago

Same, big fan of f#.

s-zeng• 3 years ago

A significant amount of these issues are solved by sticking to Core, Dune, and avoiding imperative blocks

anthk2• 3 years ago

Ocaml5 is multithreaded. MLdonkey would run much better. Compared to the classical Amule, a monstruosity writen in C++, at least it doesn't leak memory like some youngster with a constipation.

JaggerJo7• 3 years ago

I think you should give F# a shot instead.

1. No standard and easy way of implementing interfaces

No problem in F#, you have interfaces, abstract classed, ...

2. Bad standard library

In F# you have access to the full .NET standard library and ecosystem. There are also quite a lot of libraries that are especially designed to take advantage of F# (SQL libs for example).

3. Syntax problems

3.1 OCaml doesn’t have a single-line comment syntax.

It's `//` for single line and `(* comment *)` for n line comments in F#.

3.2 It has for and while, but no break and continue. So you use exceptions with a try inside the loop for continue, and outside for break.

Same in F#, use recursion.

Generally F# solves some of the issues but definitely not all of them. Some are just in the nature of the Standard ML syntax I guess.

4. Rest of the package is also not that good

- NuGet is a decent/good package manager. - Easy to install a complete dev env. - sane build system (MSBuild) - Great out of the box support in JetBrains Rider/ Visual Studio (for Mac/ Windows) or via a VS Code plugin (Ionide).

ecshafer• 3 years ago

F# is such a great language.

The fact Microsoft seems to pretend it doesn't exist is bewildering. Surely the .Net ecosystem can have two languages being promoted.

pjmlp3• 3 years ago

Before F# came into VS 2010, we already had C#, VB, C++/CLI (nee Managed C++), IronPython, IronRuby, and all the third parties targeting the CLR.

It is really not having a clue what purpose they want for F#, I bet they have repented to ship it on VS2010.

First it was for libraries only, then during the VS Express days it was for Web development, now they are trying to pivot it into data analysis and ML, while DevDiv manages to bring Guido out of retirement and finally manages to pursuade CPython core team about improving its performance.

pyjarrett2• 3 years ago

F# is such a great language.

I very much feel this, I found it productive, but it feels like a complete ghost town. I'm considering swapping to Go over using .NET for tooling/scripting.

hpstewed• 3 years ago

I use F# at work. Really love the language but the connection to the dotnet ecosystem is a curse as much as a blessing. Having to operate in a world of nulls and exceptions can reduce/nullify the amazing benefits of discriminated unions. Often you are back to relying on the due dilligence of other developers as a result.

I use a lot of rust in my spare time. The runtime guarantees it offers make other languages feel like a house of cards in comparison, including F#. I coincidentally picked up an ocaml book yesterday seeking a more 'robust' alternative to F#. Unfortunately it seems as though ocaml is even more niche than F# (I doubt I'll be working for jane street any time soon)

ragnese• 3 years ago

Having to operate in a world of nulls and exceptions can reduce/nullify the amazing benefits of discriminated unions.

I've been saying this about Kotlin on the JVM for ages. Using a Java dependency is an absolute last resort for me for those same reasons you mention about .NET from F#.

WorldMaker• 3 years ago

The C# compiler got a ton of new smarts around reference type nullability and almost all of the BCL (.NET standard library) got annotated for it. I don't know when F# will finally pick up all the new compile-time smarts for Nullable Reference Types, but it has been proposed and prototyped, at least [1].

[1] https://github.com/fsharp/fslang-design/blob/main/RFCs/FS-10...

HdS842• 3 years ago

I really wish to like F# but the line noise kills me every time. I would kill for a "visual basic" f# where the absurd terseness is replaced with a little less noise. E.g. instead of seq use sequence, instead of abstract one letter symbols use words.

JaggerJo7• 3 years ago

what noise?

I get your example of ‘seq { 1; 2; 3; }’ but list, array are not even shortened.

vips7L• 3 years ago

This is my exact issue with many "modern" languages. The code is not meant to be read later.

JackMorgan• 3 years ago

Perhaps you mean mix a little more noise into the dense signal? There's very little noise in F#, it's almost entirely dense signal.

One good thing is the ability to bind new operators, so if you don't care to learn to read <> you could make it something else. Or you could have a local binding for Sequence so you don't have to use just Seq.

It's also possible to avoid almost all operators if you don't like them. There's nothing wrong with using a limited pool as long as you can get done the job!

I also prefer to name variables, functions, and parameters with nice clear names, and I've not found F# to get in the way of that.

veec_cas_tant• 3 years ago

Wanted to add my experience here: after writing C# code most of my professional life, F# is a breath of fresh air. The type system makes so many issues and annoyances I've lived with in C# just disappear. Much like Rust, the compiler is capable of providing so much more value when the type system is so expressive. You can bang out a lot of code quite quickly and be pretty darn sure it will work just because it compiles.

daxfohl• 3 years ago

NuGet is a decent/good package manager

I remember F# designed its own package manager (paket) because of NuGet's deficiencies. I haven't been on that ecosystem for a while now. Have things changed? (My memory is that paket added friction and I eventually dropped it for nuget on my personal projects).

debugnik2• 3 years ago

F# has largely moved back to PackageReference, since package versions can now be managed centrally across projects, and F# scripts can now reference NuGet dependencies directly.

xigoi5• 3 years ago

I don't want to trust anything made by the Embrace, Extend, Extinguish company.

WastingMyTime8910• 3 years ago

The last paragraph show this article for what is is. That's an Haskell fan trying to discredit Ocaml and doing it very poorly.

It takes a special kind of writer to write an incorrect sentence about the expression syntax while quoting the actual definition from the specification which contradicts what's written just after.

I generally disagree about the complaint regarding the syntax. If you indent the code properly and use parentheses as you should and the language invites you to do, none of this is ambiguous. That's bad code not bad language design.

boxed7• 3 years ago

"the language invits you to do"? What does that mean? If it's the right thing to do it shouldn't be in invitation surely, but a syntax requirement?

WastingMyTime8910• 3 years ago

What does that mean?

That's a best practice. Like always using braces in C or Java or not using ternary operators in hard to read way.

The syntax is unambiguous but non obvious to read if you don't know precedence rules as it is for most languages. You can make it explicit using parentheses which you should.

I personally agree that parentheses around tuples should be mandatory but it's fairly easy to just put them.

Verdex• 3 years ago

I agree, but the languages that actually do this are in a hyper-minority, I feel. Nearly every language allows you to do the wrong thing and then only lets you discover this at runtime via exception OR sometimes even just by careful examination of subtly incorrect output.

As such, this doesn't really feel like the best argument against ocaml (and I believe arguments against ocaml do exist and on a much more accessible level).

ubertaco2• 3 years ago

Another example is the sequencing syntax <expr> ; <expr> and productions with <expr> as the right-most symbol:

    let test1 b =
      if b then
        print_string "1"
      else
        print_string "2"; print_string "3"

> Here print_string "3" is not a part of the if expression, so this function always prints “3”.

Well, yeah. Here's the equivalent Java code:

    void test1(bool b) {
        if (b) print_string("1");
        else print_string("2");
        print_string("3");
    }

You've chosen to use a single-statement "else" form _without_ "bracketing" it with `begin` and `end`:

    let test1 b =
        if b then
            print_string "1"
        else begin
            print_string "2";
            print_string "3"
        end

...which is equivalent to this Java code, where you _also_ would have to "bracket" the else-block:

    void test1(bool b) {
        if (b) print_string("1");
        else {
            print_string("2");
            print_string("3");
        }
    }

You could argue that Java (and C, and C++, and Javascript, and...) has the same "ambiguous parsing problem", then -- except that it doesn't, and the author is just thrown off by `begin`/`end` as block delimiters instead of curly braces, which might be a sign that they've also never seen Ruby before, or Elixir, or Pascal, or....

yodsanklai5• 3 years ago

It's a non-issue IMHO. Just use parenthesis if you're unsure, then auto-format. You'll catch any issue that wan't caught by the typechecker by reading the diff.

charlesetc• 3 years ago

Yeah auto format solves a lot of the syntax problems. Dangling else for instance is not at all ambiguous when you have automatic indentation.

yakubin• 3 years ago

You could argue that Java (and C, and C++, and Javascript, and...) has the same "ambiguous parsing problem", then -- except that it doesn't

The author didn’t claim there’s any ambiguity in parsing, only ambiguity in reading as a human. And I would agree that all the languages you mentioned have the same problem. And this is a real problem as long as people use this form of if (which they do). New languages avoid this pitfall by mandating the use of braces, in return dropping the parens, and I think that’s great.

electroly• 3 years ago

Agreed except for the part at the end: Java, C, C++, and JavaScript definitely do have the "dangling else" problem! It's a manifestation of the same basic issue. Who is saying they don't? You just showed how they do! It is a real problem and they all have it. The takeaway here isn't that those languages don't have the issue. They do. It's just really common in language design, that's all; certainly not something to single out OCaml about. Apple's infamous "goto vulnerability" was directly caused by this language design issue in good old C.

https://en.wikipedia.org/wiki/Dangling_else (just to show that this is something people commonly consider to be a problem with Java, C, C++, and JavaScript)

ubertaco2• 3 years ago

Java, C, C++, and JavaScript definitely do have the "dangling else" problem! It's a manifestation of the same basic issue. Who is saying they don't? You just showed how they do! It is a real problem and they all have it.

Yeah, that's actually exactly my point: it's not some new weird novel horrible broken parsing problem that only OCaml has; rather, it's a common parsing rule that many languages (including Java, C, C++, and JavaScript -- and yes, OCaml) have.

Arnavion• 3 years ago

Now keep reading on to literally the next sentence.

The article's point is that the `if-else` behavior is inconsistent with `match`. And based on the part about double quotes in comments, the parser seems to be fucked up something fierce in other ways too.

cies2• 3 years ago

ReasonML and ReScript are a (more or less the same) new syntax on top of OCaml. ReScript only targets JS, while ReasonML targets both JS and the native archs OCaml supports. Facebook and Bloomberg are using ReScript internally, afaik. Messenger.com is written in it. Facebook also maintains React bindings to ReScript.

https://rescript-lang.org/

https://reasonml.github.io/

giraffe_lady3• 3 years ago

Rescript is completely excellent imo. I have used ocaml for years and while I like it more than most languages it's also weird and frustrating sometimes. Rescript uses the best parts of ocaml (type system & exhaustive pattern match, first class modules) to patch over the worst parts of js. It's almost alarming how effective it is to combine these two gnarly hostile languages like this.

I also work in typescript a lot and it's the obvious comparison/competitor there. While it has objectively "won" it's so so much worse than rescript. Its type system is much more complex, untrustworthy inference, and ultimately is still unsound lol. Ocaml's type system is truly a wonder. Extremely practically helpful, complex enough to express anything without becoming a full blown language in its own right like eg typescript and haskell.

Rescript compiles to very reasonable js and writing bindings is not particularly exhausting once you get the hang of it. I've been using it for a number of projects including completely irresponsible cases like deno fresh and it's been wonderful. What typescript could and should have been.

frou_dh2• 3 years ago

How does that work with Fresh? Just not using its built-in "Islands" machinery at all? Or smuggling stuff in that as far as Fresh is concerned are more orthodox React components?

Taikonerd• 3 years ago

Is ReasonML dead? Their last blog post is from August 2018... https://reasonml.github.io/blog/

cies2• 3 years ago

Quieted down, but I depend on projects with worst graphs:

https://github.com/reasonml/reason/graphs/contributors

illiarian4• 3 years ago

The rescript-reason split killed both IMO. ReasonML was a very tiny language to begin with. Splitting it into two split the already tiny language and community into two minuscule ones.

And for no good reason (pun not intended).

And they were doing quite well, and influencing OCaml in good and meaningful ways (like improving error reporting).

yodsanklai5• 3 years ago

1. To print values, nowadays you just derive pretty printers automatically.

2. Syntax? yes, it's not C-like... you'll get used to it in a few days.

3. Lack of interface? would be helpful to see a concrete example of what the author finds limiting. You have modules, functors, includes, objects, first-order modules... Personally, I find that plain modules are simple and go a long way.

It's not perfect, but I find that nowadays Core/Dune/Opam/Merlin gives you a very decent developer experience.

the_af2• 3 years ago

2. Syntax? yes, it's not C-like... you'll get used to it in a few days

Since the author mentions Haskell as a positive example multiple times, I don't think a lack of C-like syntax is the problem for them here.

Also, the author claims:

Since 2013 I’ve had the chance to use OCaml a few times in different jobs, and I got frustrated and disappointed every time I had to use it.

So it's safe to assume "in a few days" their dislike for OCaml syntax won't go away.

For the record, I don't think syntax is a big issue.

yodsanklai5• 3 years ago

Incidentally, I find Haskell syntax more confusing, specifically the semantic indentation. But maybe I'm like the author, I don't use Haskell regularly enough so that the syntax sinks in.

spqr2332• 3 years ago

I don't the author really gave Ocaml a chance. He argues that every language needs to have interfaces. I agree somewhat with that statement, but I think the truer statement is to say that every language needs to have some way of defining composition at a structural level.

An interface allows you to pass different "structures" to the same function so long as they adhere to the same spec. In Ocaml this is accomplished through modules, functors, and module signatures. Ocaml's module signature can play the same exact role as interfaces in Haskell, Rust or F#.

The module system is arguably more expressive than what can be accomplished to interfaces. To give an example, Ocaml suffers from the same problem as rust does with having two standard implementations of a async runtime. Just like rusts: tokio and async-std, ocaml has Lwt, Async, (and newly added to the mix Eio).

Whereas in rust most libraries just implement one of these systems, and you'll have to use compiler directives to support both. Ocaml's module system means that you can describe the async runtime as a signature and make your entire library generic to the async runtime it runs on top of. Most of the well-used libraries do this, and so you don't have to worry too much about which runtime you decide to use.

Clearly, a language that can do that must have in some place a system that can replace interfaces.

boxed7• 3 years ago

To me it seems he gave it a lot of chance in order to find this many problems.

It does sound to me like you stopped reading after the first point. Maybe you didn't give the post a chance?

spqr2332• 3 years ago

It's more that only really strongly disagreed with that point. Frankly, there are some cons with using Ocaml. In practice, I think the library support for ocaml isn't completely there given the small community.

WastingMyTime8910• 3 years ago

To be honest, anyone who used Ocaml understands immediately that the author gave it no chance and went looking for problems. It’s obvious because the post lingers a lot about things which are not actually issues like type conversion but don’t talk about the very real issues Ocaml has (opam is not great, dune is weird).

actionfromafar3• 3 years ago

Ocaml's module system means that you can describe the async runtime as a signature and make your entire library generic to the async runtime it runs on top of

So ... can you ELI5 to me how that is different from how you can for instance compile a C program against different libc implementations?

kajaktum2• 3 years ago

I mean…you can technically have a function that take void* and return void* be the interface. But you wouldn’t be able to represent things like iterator and chain them together without care. In C you would be tripping all over the slight details like forgetting to check errno or something.

v0idzer0• 3 years ago

Came here to make this exact point. But I totally agree with all of his other complaints. It’s a good list of the cons, but ignored the many pros

hardwaregeek5• 3 years ago

Politely, I feel like this is the issue with OCaml as a community. You gave a beautiful answer about programming language design and composition. But how does it feel to write the language? How can you print a user defined data type? From reading around, it seems like your options are: explicitly pass a print function for that specific type, use a third party library for printing, or (my "favorite") don't. Or how does it feel to write a function that takes a generic that can be printed, checked for equality, and read? Or to convert one type into another type?

And we're still talking about semantics here. How does it feel to use the language server? How does it feel to read the code? To build the language? Ultimately that's what users judge a language on. Yes, Rust in some ways has a worse form of abstraction. It is global, not fully generic and doesn't allow for overloading. But it creates a user experience that is nicer. It lets a user print something and compare two variables and do type conversions without having to scratch their head, read a forum post and import a library.

yodsanklai5• 3 years ago

How can you print a user defined data type?

Pretty much the same way you'd do in Haskell or Rust: you add a `[@@deriving show]` directive to your datatype.

ywei34105• 3 years ago

You gave a beautiful answer about programming language

You do the same thing as in Rust, Scala or Haskell and derive the printer [1]. Then at the callsite, if you know the type then you do `T.show` to print it or `T.eq`. If you don't know the type, then you pass it in at the top level as a module and then do `T.show` or `T.eq`.

Or to convert one type into another type?

If you want to convert a type, then you have a type that you want to convert from such as foo and bar, then you do `Foo.to_bar value`.

We can keep going, but you can get the point.

You _can't_ judge a language by doing what you want to do with one language in another. If I judge Rust by writing recursive data structures and complaining about performance and verbosity that's not particularly fair correct? I can't say that Dart is terrible for desktop because I can't use chrome developer tools on its canvas output and ignore it's hot-reloading server. I can't say Common Lisp code is unreadable because I don't have type annotations and ignore the REPL for introspection.

[1] https://github.com/ocaml-ppx/ppx_deriving

maleldil• 3 years ago

Ocaml's module system means that you can describe the async runtime as a signature and make your entire library generic to the async runtime it runs on top of

Is this the program describing the interface it expects, and the compiler matching that with the implementations structure (e.g. Go interfaces, Python Protocols), or is it something someone declares and the libraries implement?

yawaramin13• 3 years ago

Mostly the former. The compiler infers the type of the implementation and ensures it conforms to the interface. But, you can further restrict the interface's type to hide details from the outside world.

ywei34105• 3 years ago

I don't think this list is fair at all.

No standard and easy way of implementing interfaces

Firstly another commenter has mentioned [1] modules as interfaces. There is also the object system [2] which I've seen used to great effect in similar scenarios.

Typeclasses and modular implicits are fantastic - being a heavy user of Scala and Rust; but I've always found that they tend to be best when used as an alternative to macros, for derivation purposes.

The interface and code split in OCaml is also really nice for value types and comes with no limitations; for years, we had issues in Scala because of the host platform, and in Rust exposing functions for your newtype can be oddly boilerplate heavy.

Bad standard library

The OCaml standard library is (infamously) anemic and obviously is not as fully-featured as something like Java or Python, but since alternative libraries tend to be compatible with the bundled StdLib (both use the same `option` and `list` type), it means that having libraries dependent on different ones is not a huge issue. Learning resources, can be confusing though.

I'm not sure why it's a problem certain data structures are mutable and some are persistent; the documentation is usually fairly clear and you usually have a performance characteristic in mind when selecting your data structure.

Universal equality and hashes are indeed a little annoying (here an `Eq` typeclass would be great!) but I do understand the original decision to have them inside. At the very least, it's not pointer based equality and since records and most types don't have subtypes, you don't run into as many issues. You can of course use the equality methods on the modules themselves and since `Hashtbl` and co have functors, you aren't penalized for it.

Strings are a problem-ish (what older language doesn't have string issues ha!), but there is utf-8 support now with [3].

but just two years ago it was common to use Makefiles to build OCaml projects

It is true that OCaml has a unix-y flavour, but honestly I don't really understand the snipe at make. Sure there are alternatives, but make is bundled on most distros, has a quick startup time and a lot of people are familiar with it.

More of the community is moving towards dune as well, which is pretty good; the docs could do with better indexing but there are some features such as promotion which are really nice.

was no standard way of doing compile-time metaprogramming

I haven't used ppx much so I can't really comment here.

Finally they've missed the biggest reasons to /use/ OCaml.

[1] https://news.ycombinator.com/user?id=4ad [2] https://ocaml.org/docs/objects [3] https://v2.ocaml.org/api/Stdlib.String.html#utf_8

boxed7• 3 years ago

Finally they've missed the biggest reasons to /use/ OCaml.

You missed writing what they are :P

Joker_vD• 3 years ago

It also has the “dangling else” problem:

God I hate this term because it's not even a problem. For a human reader, it's pretty obvious that an "else" should belong to the closest "if"; and it's quite difficult to write a mechanical parser that would match "else" with the furthest "if" instead. So what is, exactly, the problem? That the grammar is technically ambiguous? Who cares? The authors of LR-generators? They don't, they have been resolving shift-reduce conflicts by default in favour of shifting for half a century already.

kajaktum2• 3 years ago

Any language that have exceptions are trash imo. It is clearly a relic of the old day. It works for CPUs but not people.

Miltnoid• 3 years ago

I used OCaml as my daily driver in grad school and my postdoc, and recommend my students use it. I think the main benefits of OCaml are:

Functional Has mutable references Not lazy

Haskell's type system is just better. But for large, complex systems that require performant code, it can be quite difficult to track the laziness, and sometimes life is just easier if I can use a mutable references.

The author is completely correct that there's a big failure in the lack of a type-class-like system. This is why people ask so much for modular implicits. Core is also a decent standard library (though I don't know why they require sexp_of_t and t_of_sexp on like all their data structures).

So I'd gladly use a different functional language with mutable references and strict evaluation. But there isn't any besides F#, and I have a Mac and don't personally want to figure out .NET on Mac.

ywei34105• 3 years ago

They require `sexp_of_t` and `t_of_sexp` because of their workflow being based on them; such as expectation testing [1] and tools such as [2]. It's a less noisy alternative to json for many people.

[1] https://blog.janestreet.com/testing-with-expectations/ [2] https://github.com/janestreet/sexp

owenm• 3 years ago

Starting with F# on Mac is worlds away from what it was in the past, I bet you could be up and running in 5 minutes:

  brew install dotnet-sdk
  dotnet new console -lang F# (in your project directory)

Start VS Code in that directory, install ionide via extensions, write code…

  dotnet run

JaggerJo7• 3 years ago

Exactly. And you can even pick between 3 IDEs

- JetBrains Rider (best IMHO)

- Visual Studio for Mac

- VS Code with Ionide

yawaramin13• 3 years ago

I think looking at it as a 'failure' or 'deficiency' is the wrong mindset. OCaml makes a different tradeoff than Haskell. In exchange for not having ad-hoc polymorphism, OCaml's functor system allows much quicker compilation and easier-to-understand type errors. Like everything in tech, it's a tradeoff.

hajile4• 3 years ago

What about StandardML?

frou_dh2• 3 years ago

Knowing the virtually dead Standard ML is a curse when it comes to appreciating the aesthetics of OCaml. The two languages have similar syntax, but in just about every way they differ, OCaml syntax took the ugly road :(

atbpaca• 3 years ago

I learned OCaml two decades ago. It was great to learning algorithmics but I already had the feeling the language was old and awkward. Today there is Scala, Haskell, Rust, F# etc.

yawaramin13• 3 years ago

All of which are, incidentally, either directly or indirectly inspired by OCaml or its ancestor ML :-)

kthielen• 3 years ago

This piece focuses on complaints about ocaml, and the last half seems to just be syntax complaints (which I mostly ignore just because every language seems to have awkwardness in its syntax -- certainly Haskell, a language otherwise held up as an example, can be shown to accept some really weird text).

Good things about ocaml that I think should be mentioned are Hindley-Milner type inference (some might argue this, but it's a very effective system for inferring types), and also straightforward semantics (it's usually pretty easy to look at some code and make a reasonably accurate guess about what it will do on real hardware -- compare with Haskell).

I'm sympathetic toward the initial complaints here, which I also think are the most substantive. Type classes and qualified types, as in Haskell, would be very useful in ocaml/ML. The examples offered (show_of_int, show_of_double, ...) are valid, and also the related complaint that dishonestly broad types like structural equality (where runtime errors are raised for cases where the types are actually not supported) also make a compelling case for qualified types in ML.

I made this project ~10 years ago after making similar observations: https://github.com/morganstanley/hobbes

Things like structural equality and ordering are user functions here rather than magic internal definitions (e.g. equality is defined as a type class, and type class instances can deconstruct algebraic types at compile time to decide how to implement instances). But evaluation is eager by default, so it's pretty easy to reason about performance. And data structures can be persisted to files and/or shared transparently in memory with C/C++ programs without translation, also very convenient for the places where this was used. Actually we built some very big and complicated time series databases with it, used in both pre and post trade settings where ~15% of daily US equity trades happen. So I think these observations are useful and have passed through some pretty significant real tests.

KingOfCoders• 3 years ago

I found that one hilarious

"The regex module uses global state: string_match runs a regex and sets some global state. "

debugnik2• 3 years ago

The builtin `str` regex library is obsolete anyway, most people use `re`[1], or sometimes bindings for pcre or Google's re2.

[1] https://ocaml.org/p/re/latest

crop_rotation• 3 years ago

The biggest problem I have with Ocaml is not the language, but the tooling and the libraries. The library ecosystem is not even remotely comparable to go or even rust. Jane street core is mentioned as a good option, but that library is the most popular undocumented library I have ever seen. There is not even some normal default structure every library follows (e.g go io.Reader).

Compare this to languages with supposedly "worse" type systems like Java, which has a library for everything and high quality well documented libraries like guava and apache commons. I find it fine to use ocaml for a random weekend whim project, but wouldn't touch it with a 10 feet pole for professional work.

oslac• 3 years ago

It is for these (tooling / library) reasons it is almost impossible to recommend it for any project, almost like Nix in that regard for me.

illiarian4• 3 years ago

like Java, which has a library for everything and high quality well documented libraries

Unless it's a library that has been around for a while and is probably hosted at Apache.

There was a marked shift in 2010s in expectations, and now we expect libraries and code to be somewhat well-documented. For older libraries... well, it's often "here's a dump of autogenerated reference files with maybe a blob of prefacing text at the top. Good luck."

mjdowney• 3 years ago

My OCaml:

    let foo (x: bar): baz =
      (\* Is this quuxable? *)
      match is_quuxable x with
      | Yes ->
         (* Then, we have to ... \*)

All the OCaml I see in the wild:

    qlet%bind f = 's 't  'a 'b (fun ꙮ -> ꙮ ((<_<')) ꙮ)
    [@@ppx_gov_backdoor (~b~e~p~i~s)]

jimsimmons• 3 years ago

Functional programming community likes this stuff. They go into the classical mathematicians’ trap of writing more and more general versions of something even though it’s not necessary.

nequo3• 3 years ago

I think this is partly because of the syntax.

When we write human languages (that use a Latin script), we use punctuation to delineate the beginning and end of terms. In a language like C or Rust, terms are surrounded by commas, parentheses, angle brackets, and so on. In OCaml and Haskell, many things that there is syntax for in C-style languages are done as ordinary function calls, which separate terms by only whitespace.

It is easier to read this (Rust):

  let value = some_long_ass_function_name(some_quirky_parameter, another_one);

  another_function(value)

than this (Haskell):

  let value = someLongAssFunctionName someQuirkyParameter anotherOne
  in anotherFunction value

or this (OCaml):

  let value = some_long_ass_function_name some_quirky_parameter another_one in
  another_function value

Individual terms in camel case are difficult to read if they consist of more than a couple words. Consecutive terms in snake case are difficult to read because underscores and whitespace look alike visually.

Haskell and OCaml's idiomatic solution is to use extremely terse names for arguments, type variables, and local variables, out of what seems to be syntactic necessity.

yawaramin13• 3 years ago

I don't think this is correlated to functional programming. Programmers in general tend to over-architect because we're often learning as we're going and sometimes it's more fun to use some cool concepts. Since design patterns started becoming en vogue back in the day, OOP codebases got filled with those patterns. Now we are left picking up the pieces with things like `AbstractProxyFactoryBean` or whatever. Same thing with JavaScript where that ecosystem is infamous for using tons and tons of npm packages to recreate simple functionality, e.g. 'left-pad a string'. Arcane mathematics-heavy FP code is just how that expresses in FP languages. And in fact, OCaml is actually an antidote to that (for the most part), because it deliberately offers a lower level of abstraction than Haskell. I frequently say that OCaml is like a cross between Haskell and Go.

still_grokking• 3 years ago

Until they get enlightened.

actionfromafar3• 3 years ago

The latter code looks totally quuxable.

gjm11• 3 years ago

Nah, I think it's already been quuxed up.

mcguire3• 3 years ago

Hmm. I haven't seen the latter in OCaml as much. More the opposite; when I first used it, things like list length in the standard library weren't tail recursive. 8-|

Now, Haskell and shudder Scala shudder, on the other hand.

WastingMyTime8910• 3 years ago

Compared to Haskell, OCaml developers are generally not to fond of custom operators which shield you from some of the worst cases unless you are reading code an Haskeller wrote in OCaml which happens.

For a long time, most of the users were either writing compilers or static analysers for low level languages and a fair share was very knowledgeable in C and system programming. It had a huge impact on what was seen as idiomatic. You can still find trace of it in for exemple the system library which looks more like the C stdlib than a modern standard library or how the compiler finds libraries.

Generally the community used to have a very different "flavour" than the Haskell one (it was also very French to be fair). I think I t’s less true nowadays. Still I would fall from my chair if I ever encounter someone working on the OCaml compiler writing a disparaging disingenuous post on Haskell. Meanwhile, we are here which reflects exactly my general experience with the Haskell community.

Ppx are used more and more often however and it did make code harder to read.

lysecret2• 3 years ago

Thanks! Whenever I see a generic type i cry a bit.

reikonomusha4• 3 years ago

Coalton [1] is an OCaml-like dialect of ML: it's strictly evaluated, has imperative features, and doesn't force a purity-based development philosophy. However, Coalton has S-expression syntax and integrates into Common Lisp. It works, and is used "in production" by its developers, but it's still being developed into a 1.0 product.

Coalton made a lot of design decisions to work away from issues that this post describes.

- Coalton dispensed with ML's module system of structures, signatures, and functors. No doubt a beautiful concept, and sometimes satisfying to write, but almost always unsatisfying to use due to how explicit one tends to need to be. Like the author suggests, the "interface-style" of type classes or traits has always felt more intuitive, despite losing the ability to have multiple implementations of an interface for a single type. (However, I've come to appreciate that different interfaces should require different types—as opposed to one type having many interfaces.) Coalton uses type classes.

- Coalton has S-expression syntax. No indent rules. No precedence rules. No expression delimiters. All of the "tradition" of ML syntax is dispensed with into something that is a lot easier to read and write for complex programs... yes, provided you use ParEdit or similar

- It should be no surprise that with S-expressions, you get Lisp-style macros. Macros in Coalton are just Common Lisp macros. No separate pre-processors. No additional language semantics to deal with. Arbitrary compile-time computation and/or codegen, completely integrated.

- Because it's built on Common Lisp, Coalton gets something few (if any?) other ML-derivatives get: Truly incremental and interactive development. You can re-compile types, functions, etc. and try them out immediately. There's no separate "interpreter mode"; just a Lisp REPL.

Coalton's language features are still settling (e.g., records are being implemented) and the standard library [2] is still evolving. However, it's been used for "serious" applications, like implementing a compiler module for quantum programs [3].

[1] https://github.com/coalton-lang/coalton

[2] https://coalton-lang.github.io/reference/

[3] https://coalton-lang.github.io/20220906-quantum-compiler/

wk_end• 3 years ago

This looks excellent! I have a soft-spot for the elegance of Lisp but can't live without a robust type system. A few questions I didn't see immediate answers to on the GH page (sorry if I missed something/could've found those answers if I digged a little deeper):

1. Beyond the typeclasses you mentioned, how powerful is the type system beyond standard HM stuff? Are there GADTs/existential types? Any other interesting features?

2. The lack of records sounds like it might be a deal-breaker for current use. Is that as bad as it sounds? Is it something that is expected to be addressed soon? Are there any other large omissions?

3. How does it integrate into the existing Common Lisp ecosystem, if at all? Is there any friction there?

4. On that note: in the REPL example it looks like you need to wrap your expressions with (coalton ...), which feels like it'd get frustrating. Is there any way around that? I guess even a reader macro would help...but still wouldn't be ideal.

5. Is Coalton backed by any kind of corporate funding? And (assuming you're involved in Coalton in a professional capacity) ...you guys hiring?

reikonomusha4• 3 years ago

1. There are functional dependencies and multi-parameter type classes. No GADTs (yet?) or existential types (yet?).

2. Records are being implemented but it's far from being a dealbreaker, in the sense that thousands of production lines of Coalton have been built without needing them. It's just not ergonomic to shuffle around and pattern match against record-like data. With pattern matching in function arguments, things are at least easier.

3. All Coalton functions compile to Lisp functions. There's a guide that describes what is promised about interop (https://github.com/coalton-lang/coalton/blob/main/docs/coalt...).

4. Since Coalton functions are Lisp functions, you can call (unconstrained) functions directly. However there's a lot of room for improvement. There's an open issue to make a dedicated Coalton REPL that can show types and not require COALTON to be typed.

5. Coalton is developed as an open source project to build tools at HRL Laboratories, so it does receive sponsorship. Yes, HRL is hiring. Feel free to send me an email to the address in my profile.

As seems to be the case with any "serious" programming language, there's always another thing to do—seemingly perpetually—to make said language useful enough for "serious" use. :)

justinpombrio• 3 years ago

Coalton [1] is an OCaml-like dialect of ML: it's strictly evaluated, has imperative features, and doesn't force a purity-based development philosophy.

OCaml is also strictly evaluated, has imperative features (e.g. ref), and doesn't force a purity-based development philosophy.

What makes you call Coalton a "dialect of ML"? ML's module system is its defining feature, beyond that there's really not much unique about it (by design). Would you call any language with algebraic data types a "dialect of ML"?

EDIT: I'm picking on this one sentence, but the rest of your comment is a good overview of the language, thanks.

reikonomusha4• 3 years ago

That's why I said it's "OCaml-like" followed by a colon: to highlight the similarities.

As for why it's an ML dialect, maybe (maybe not) it's more fair to call it "ML-inspired". Nonetheless, it's similar enough to the ML family to be understood by ML programmers. But yes, one of the major pillars of ML—the module system—is conspicuously absent in favor of Haskell-like type classes.

networked3• 3 years ago

Coalton has S-expression syntax. No indent rules. No precedence rules. No expression delimiters.

This is a great selling point for a language in the ML family. Programmers can't abuse infix operators when there are none. :-)

Besides this, Coalton looks appealing. A highly interactive statically typed language is something I have thought of. I am sure I am not the only one. It is also a good sign that you are using it as it is being developed.

xigoi5• 3 years ago

Why does Coalton require two different implementations of Lisp to be installed?

reikonomusha4• 3 years ago

Why do you say that? You just need a single (supported) Lisp implementation, like SBCL.

amyjess• 3 years ago

OCaml is one of those languages (like Raku and Nim) that I really want to learn and do something in at some point but usually end up not bothering because it's easy for me to just start up new personal projects in Python like I'm used to.

belmont_sup3• 3 years ago

But you can always just try ocaml for the sake of it, for the fun of it!

xigoi5• 3 years ago

Maybe try Nim next time you have something performance-sensitive, or OCaml when your problem can be elegantly expressed in a functional way.

yawaramin13• 3 years ago

And it's easier for people who know OCaml to set up new personal projects in OCaml like they're used to ;-)

aaws11• 3 years ago

Almost all modern statically typed languages have closures, higher-order functions/methods, lazy streams, and combinators that run efficiently. Persistent/immutable data structures can be implemented even in C.

Also, OCaml has no tracking of side-effects (like in Haskell), and the language and the standard library have lots of features and functions with mutation, such as the array update syntax, mutable record fields, Hashtbl, and the regex module.

The only thing that makes OCaml more “functional” than e.g. Dart, Java, or Rust is that it supports tail calls. While having tail calls is important for functional programming, I would happily give up on tail calls if that means not having the problems listed above.

When you mix imperative and functional styles tail calls become less important. For example, I don’t have to implement a stream map function in Dart with a tail call to map the rest of the stream, I can just use a while or for loop.

In my opinion there is no reason to use OCaml in a new project in 2023.

hencq• 3 years ago

You might want to make it clearer that this is a literal quote from the last paragraph of the article. Are you posting this because you agree/disagree?

choeger• 3 years ago

Simply put, OCaml is very principled. There is a good reason for pretty much every design decision.

The only thing one could argue is the lack of type classes, i.e., overloading. (Calling it "interfaces" is somewhat wrong.)

manymanydots• 3 years ago

No standard and easy way of implementing interfaces.
In Haskell, this is done with typeclasses ...
In OCaml there’s no way to do this. I have to explicitly pass functions along with my values, maybe in a product type, or with a functor, or as an argument.

Haskell is a mixed community / paradigm language too.

I routinely program in "Braindead Haskell" (keep stuff simple and direct as much as possible). Funnily, in that programming style, using typeclasses for _all_ interface types is bad style.

Instead, the Handle pattern [0] can be used. Which really is just shoveling functions in a product type. And imagine - it works worderfully.

Everyone has to find their own style I guess.

[0] https://jaspervdj.be/posts/2018-03-08-handle-pattern.html

Jeff_Brown• 3 years ago

the Handle pattern

I love this so much.

mcguire3• 3 years ago

"Lack of widely used operations such as popcount for integer types, unicode character operations."

popcount is widely used?

jorkadeen2• 3 years ago

An alternative to OCaml is Flix (https://flix.dev/) which attempts to address some of the critiques in the post. For example:

Bad standard library

A particular goal of Flix is to have a consistent standard library based on type classes.

Standard types are sometimes persistent, sometimes mutable. List, Map, and Set are persistent. Stack and Hashtbl are mutable.

In Flix immutable types are named List, Set, Map, etc. and mutable collections are prefixed with Mut, e.g. MutSet, MutMap, etc. Mutable data types also carry a region.

Also, OCaml has no tracking of side-effects (like in Haskell)

Flix has an effect system that tracks purity/impurity.

(I am one of the developers of Flix)

weatherlight• 3 years ago

Complete Feature List

    algebraic data types
    pattern matching
    first-class functions
    extensible records
    parametric polymorphism
    type classes
    higher-kinded types
    light-weight polymorphic effects
    type aliases
    Hindley-Milner type inference
    CSP-style concurrency
    buffered & unbuffered channels
    first-class datalog constraints
    polymorphic datalog predicates
    constraints with lattice semantics
    stratified negation
    interoperability with Java
    unboxed primitives
    keyword-based syntax
    redundancy checks
    monadic let\* expressions
    expressions holes
    compilation to JVM bytecode
    full tail call elimination
    core standard library
    parallel compiler architecture
    human friendly errors
    interactive mode
    Visual Studio Code support

Nice!

pdimitar• 3 years ago

I know some of those words.

networked3• 3 years ago

I have been keeping an eye on Flix. Thanks to you and rest of the Flix team for working on a bold but practical language. I wish you success. I think Flix is one of the most promising languages in the ML family. (Do you consider it an ML?) I love that it has embedded Datalog.

I know it is pre-1.0, but I would still like to ask about adoption. Are there notable third-party open source projects in Flix yet? By "third-party" I mean created outside of Aarhus University and the University of Waterloo.

jorkadeen2• 3 years ago

Thanks for the kind words.

Yes, I would definitely consider it a language in the ML-family. Its core is based on Hindley-Milner (like StandardML, OCaml, and Haskell) which I think is the hallmark of ML-family languages. Flix sits neatly between Ocaml and Haskell in that it allows side-effects (like Ocaml, unlike Haskell) but they are tracked by the effect system. Hence one can program in the spectrum between those two languages, but get strong guarantees from the compiler.

In terms of adoption, we see a lot of people trying it out, and there are some packages out there already, but nothing too big yet. We recently added support for package management, so hopefully that will help the community grow.

xigoi5• 3 years ago

It pains me every time I find a great programming language and then find out that it runs on the JVM.

omoikane• 3 years ago

Int.abs can return a negative number.

The documentation for abs[1] explains: "Warning. This may be negative if the argument is Int.min_int."

I think that's just the nature of two's complement and not necessarily a fault of OCaml. C++ is also like that[2].

[1] https://v2.ocaml.org/api/Int.html

[2] https://gcc.godbolt.org/z/34b3GbvvT

anderskaseorg• 3 years ago

In C and C++, abs(INT_MIN) is undefined behavior. (C17 §7.22.6.1: “The abs, labs, and llabs functions compute the absolute value of an integer j. If the result cannot be represented, the behavior is undefined.” Footnote: “The absolute value of the most negative number cannot be represented in two’s complement.”)

yawaramin13• 3 years ago

Honestly the way OP just throws out a scary-sounding 'well this is an obvious bug that abs can return a negative number', without giving the context that it's for the minimum value of a machine int type, really says it all. He doesn't have an interest in evaluating it fairly, he's just doing a hit piece.

b33j0r• 3 years ago

Everyone I’ve met, including on the steering committee, has been funded by high-frequency trading.

Heck, I almost took a job on a handshake in manhattan on this premise.

But it just seems, even now, archaic for the task. As the author mentions, the community is small, the integrations are weak. You will be working on legacy systems if anyone pays you well.

Same with certain parts of national defense, but we’ll make fun of PDP-11’s and FORTRAN another day.

Proactive thought: why don’t we fund a B-team to say, try using Julia? Even ERLANG has some superior qualities for these real-time audited tasks. (And hey, if you want employees for some reason, just use python).

pauldirac137• 3 years ago

The author says: "If you have a reason to think that OCaml is the best choice for a new project please let me know your use case, I’m genuinely curious." I think it's overwhelmingly the best language for writing an interpreter or a compiler. I'm sure Haskell is also a good language for writing compilers, but whenever I tried writing interpreters in Haskell, I found myself fighting the laziness. Most of the criticisms listed strike me as things that bother people starting out in the language (syntax etc.) but which quickly become non-issues with more experience. And my experience with opam/dune has been _much_ more pleasant than with Cabal in Haskell (though ghcup has certainly improved matters). I think the infrastructure in OCaml, which admittedly used to be quite poor, is now on par with any other language, if not better. However, if your application domain is one in which few OCaml libraries exist (e.g. web programming) you probably should look elsewhere.

cdaringe• 3 years ago

My friends. Algebraic effects in ocaml 5! I did protohackers and AOC with effects and it was a blast! Im not a daily ocaml driver so my code can be a bit clunky, but i love the patterns effects unlock, especially around module coupling.

toastal• 3 years ago

I just wish the source code supported Unicode and the formatters supported tabs dispute the compiler accepting it.

My thoughts on OCaml

Related Stories