1. 57
  1. 10

    I had a brief opportunity to use OCaml around 9 years ago and came up with a really similar reaction, coming from roughly the same direction: https://technomancy.us/170

    Back then Dune didn’t exist, and Strings were still mutable (the latter which I had a hard time believing; I’m very glad they fixed this enormous design bug). The #1 gripe by far was the documentation around how to do builds; at the time it all assumed you were a seasoned OCaml user who just wanted to learn the new tools. Hopefully it’s improved since then. The #2 gripe was that the operator precedence rules were difficult to understand and caused weird errors. I felt like I had to spam parens everywhere to get the binding I wanted. Operator precedence in general is a big design bug shared by most languages, but at least in OCaml the unexpected behavior causes compile-time errors instead of hiding latent like they do in Ruby.

    1. 1

      Interesting, I just took a look at the post and read about Grenchman, can you send me the source code?

      1. 2

        Sure; it’s archived here: https://github.com/technomancy/grenchman

        I don’t have any plans to continue development since nowadays Fennel is a much better fit for that particular problem space.

        1. 1

          Thanks! Just want to study the code.

    2. 7

      I’ve recently been (slowly) working through the Cornell class since it came up on Hacker news a couple months back. Your experience mirrors my own. OCaml is a lovely language with lot of cruft built up over time: the equivalent of finding an old muscle car in an estate sale. Sure the oil hasn’t been changed in 20 years, but boy would it fly with a little love!


      I looked through the workflow thread that you posted and I didn’t see anyone mention how you can use shift + enter to send highlighted code to utop. I can’t remember if there was any extra config. Might not be super helpful given your emacs background though.


      Given how you like Clojure and have bounced off of Erlang a couple times I was wondering if you had tried out Elixir. The creator worked with Ruby and had a soft spot for Clojure. Might be right up your alley.

      1. 3

        Yeah, I did play with Elixir for a while and it definitely got many things right. It has great dev tooling and a much better standard library than Erlang, but for some reason I’ve always found it more enjoyable to program in Erlang. :D Funny enough, despite my Ruby background I never considered the Ruby-like syntax an improvement. We did a couple of small projects in Elixir on the job and generally the team was happy with Elixir, but we didn’t have use-cases where we could leverage fully its strengths (or rather the strengths of BEAM and OTP).

      2. 6

        OCaml is a very pretty language, and surprisingly practical to boot. I find it easier to write performant code in than most other high-level languages. Overall, the community is helpful and full of smart people.

        Unfortunately it’s in a similar situation to Java where the tooling around it is pretty crufty, and the community is actively hostile if you point this out. If you ask the average enterprise Java programmer, they’ll say Maven and Gradle are fine, and it’s actually NPM and Cargo that suck. If you ask an OCaml programmer, they’ll say all the other language package managers are either worse, or just straight crap. That’s verbatim.

        The situation is improving, but beware that many libraries are essentially research prototypes. Because they’re written by researchers. For example, the most popular HTTP library had poor performance from 2015 until this year.

        There’s also a strange situation where the community is split between multiple I/O frameworks, Async and Lwt. Each has its own subtleties; maybe the situation has changed, but a few years ago I had to regularly refer to the actual source code to figure out how e.g. lower-level errors would be handled because this wasn’t documented.

        For tooling, people have started using esy, which is an NPM-like wrapper around OPAM. It’s a definite UX improvement. The dune build system is also a great improvement, and it looks like in the past few years the community has started caring more about practical problems like distributing OCaml code to non-OCaml users, e.g. by documenting how to statically link things

        If it wasn’t obvious, I ran into all four of these issues previously while trying to use OCaml for a project: package management, Lwt/Async subtleties, serving HTTP, and distribution.

        1. 4

          Just a nitpick, your “actively” hostile link is from 2016.

          1. 4

            And it is two people saying something?

            Yes, OPAM isn’t great. Back when it came out it was fine and indeed kickstarted the revival of OCaml. Over the years a lot of improvements have been implemented, which leads to a number of kludges in its UI. People working on it are aware of it and there are plans for a revised version learning lessons from OPAM and other package managers but it’ll be a bit of a process.

            1. 1

              Has anything come out of the discussions to make a cargo-like tool to integrate dune and opam? I remember reading something about it on the forums and I took a look at drom a while ago but I haven’t been following the discussions since. I just use OCaml for a couple personal projects so I always forget how to set up opam switches when I get back to those projects…

              1. 1

                There are some discussions how OPAM 3 could look like and how it will integrate with dune will be definitely part of the considerations.

                But as of actually existing software that could be used today? Not yet.

        2. 5

          I think OCaml’s syntax won’t present much of a challenge for any seasoned programmer, especially for someone with a passing knowledge of a similar language like Haskell.

          I find the hardest part of OCaml is remembering the syntax :). I made https://ocamlsyntax.com because there are certain constructs that just will not stick in my brain and I have to look them up every time I need them (looking at you, polymorphic abstract type variables). And that doesn’t even include any of the object-oriented stuff! That’s a whole other mirror universe of different syntax on top of the rest of the language.

          no syntax for list comprehensions (I often use those in Clojure, Haskell and Erlang, although I’m well aware they are not something essential)

          Definitely a personal style thing – even in Haskell I prefer an explicit do to list comprehensions, which OCaml… sort of has… if you install a syntax extension… okay yeah not great.

          the compiler is super fast, but that was expected given that OCaml is famous for it.

          Really?? That’s fascinating. My only significant experience with OCaml was working on a large-ish codebase, and the unbelievable slowness of even incremental recompilation was one of my biggest gripes with the language. And doing an optimized build, especially post-flambda… is it really famous for being a fast compiler? (Is this a “compared to GHC” situation?)

          I was amused to see that the popular book Real World OCaml directly recommends replacing the standard library with a third-party alternative.

          For context, one of the co-authors of Real World OCaml wrote the third-party alternative that the book advocates. (I mean, he didn’t literally write it all by himself, but you know what I mean.)

          There’s also support to target JavaScript from OCaml sources, which looks interesting, but I haven’t tried it yet.

          For the curious, I think js_of_ocaml is shockingly good. It really does what it says on the tin. The generated output isn’t slim – I don’t know if there’s some kind of tree-shaking thing you can do to improve that – but if you can afford to serve 1mb .js files, you really can write a webapp in OCaml.

          1. 1

            My only significant experience with OCaml was working on a large-ish codebase, and the unbelievable slowness of even incremental recompilation was one of my biggest gripes with the language.

            With a large codebase surely the build time is mostly influenced by what build tool is used and how the build is done. Was the build optimized properly i.e. were modules being rebuilt that didn’t need to be? And were the correct settings used to optimize for dev workflow for incremental compilation e.g. the -opaque flag?

            1. 2

              I don’t know! It was a long time ago, and I never tried to dig into the build system to see if I could speed it up. There was a team dedicated to build performance (and tooling), and I trust that they knew what they were doing, but I can’t make any more intelligent claims than that. Incremental recompilation was definitely much faster than not-incremental recompilation, and they built a system to make almost all builds into incremental builds with a shared artifact cache, so I assume they were doing all the right things. But I couldn’t swear to it. We had knobs to compile modules without linking anything, which made incremental rebuilds tolerably fast, but that meant no tests… so yeah.

              Anyway I am genuinely asking about that point, because I know very little about OCaml outside of my bubble. And because this was the largest codebase I have ever worked on in any compiled language, I have no intuition for what a “fast” or “slow” compiler feels like at that scale.

              1. 2

                If it was a few years ago it may have also changed drastically. The compiler has always been very fast, but the build tools need to exploit it (and parallelize and avoid rebuilds where possible). Anecdotally, I worked on a project that counted about a million lines of ocaml. It used to build with omake, which would take about 10 minutes (not including tests). When we ported it to jbuilder/dune, we could build the full toolstack (so the huge project + all its related libraries and extra components + tests components) in less than two minutes, with rebuilds (usually) in the order of seconds.

          2. 5

            That’s a nice piece, and one that shows how much OCaml has improved on that side. Thanks for sharing your experience!

            I am really curious to see what OCaml will look like in 2 or 3 years, with OCaml 5 well established.

            1. 4

              Same here! :-) I’m really excited about OCaml 5 and what lies beyond it!

              1. 3

                I listened to this podcast and found it to be very interesting - What is an Operating System? (Signals and Threads) on OCaml and friends. Might be of interest to others in this thread, if a bit late!

              2. 5

                For me the most interesting aspect, and actually a killer app, of OCaml is MirageOS. I haven’t done anything with it yet, but it seems insanely cool.

                1. 2

                  I always had a bit of a soft spot for OCaml but the MOOC really made me enjoy the language.

                  1. 2

                    If anyone is looking for a book to recommend to programming newcomers, there’s a free online OCaml book targeted at just that audience: OCaml from the Very Beginning.