I agree. OCaml is alive and kicking with some ferocity. Mirage and Jane Street come instantly to mind as major community drivers. Upcoming OCaml versions include patches aimed at giving more precise control to the GC and having inlining as aggressive as Haskell’s. There was a recent massive rejiggering of OCaml metaprogramming techniques to be a bit friendlier and js_of_ocaml seems exciting if a bit sparse.

I don’t think the ML standardization process is moving forward, no, but OCaml as a language and platform seems to be continuing to move.

I did not watch the talk, however I support Makefile’s. Makefile’s have a lot of problems with them, however, they are agnostic as to what they act on, they support parallelism if you create them right, and they interact well with other things. Many languages have language-specific build systems and it almost always is easy in the basic case but calls apart under any serious usage. In the end, I usually just want a build system to produce a Makefile for me so I can run it. This is what a build system I’ve built for Ocaml does. While it’s Ocaml specific, it just produces a Makefile and you can connect it to other Makefile’s easily to build non-Ocaml tooling as well. The Ocaml-specifics are just in how to build the Makefile, not how to build the entire project.

Sure (and in reality I personally use Scala which is pretty similar to OCaml). But I don’t think it’s entirely unreasonable to prefer Python to OCaml, even if one dislikes exceptions - the OCaml syntax is a bit ugly, Python’s OO support is actually quite nice, and while OCaml has become a lot more popular of late there’s still a bigger community/ecosystem around Python, particularly for the web or science.

I’ve programmed a bit in both, and I would say either one would do. Personally I’m doing a bit more with Haskell lately, and typeclasses are a nice feature (as others have mentioned). On the other hand, perhaps the very rigid way in which Haskell deals with effects can be a little overwhelming at times, and OCaml would be a little less rigid on this front. Two other things I can think of which might also push you towards OCaml may be the recent excellent O'Reilly book Real World OCaml by Minsky et al (the same author as the blog post), and the similarity between OCaml and other ML'ish languages such as F#. F# is a fully open-source project and Visual F# is a first-class citizen within the .NET ecosystem, if that happens to be of interest to you. In short I would say you are choosing between two excellent and well-designed languages and really can’t go too wrong. You’ll probably want to check out the “other one” (as I have) irrespective of which way you step now. Good luck!

In my defense, I don’t think I’ve ever explicitly said anything against inlining in regards to Ocaml vs Haskell. I have spoken about the runtime and compilation being easier to understand and reason about, but that is mostly a result of laziness, IMO. I don’t know how much flambda affects ones ability to understand what Ocaml code turns into on the machine and predict its performance. I’m excited for flambda, and hope it doesn’t make programs significantly harder to understand. I am excited that functor’s will become less expensive, I’m a fan of functors and use them quite a bit.

Yes, parallelism/concurrency will probably be in the next release of Ocaml, which is pretty exciting, assuming they can keep the memory model sane. ref’s, what a bummer when it comes to trying to add parallelism to a language.

EDIT: By “next release of Ocaml” I mean the release after the one described in this post.

site:lobste.rs haskell 1,300 results

site:lobste.rs ocaml 916 results

site:lobste.rs sml 129

site:lobste.rs “standard ml” 59

It’s not that far apart between Haskell and OCaml. Haskell and OCaml each effectively have their own tag, with the remainder of the ML family being a weak case for having their own.

For comparison, “react” has over 600 results, still doesn’t have its own tag. Ends up falling under a mix of browser/mobile/web/js. “ml” is a better fit for ocaml-alikes like bucklescript too.

I remember asking someone if he used OCaml for a ultra-high-reliability system (with hard deadlines) that he was building, and he said that he preferred to use C, proven when possible. If you use OCaml, you may be less likely to have errors in user code (or, it is more likely to say that some very-low user error rate deemed acceptable is achieved more quickly in C than in OCaml) but you’re also sitting on top of a very good but complex runtime. Often, they don’t even like to use dynamic memory management, and malloc/free is a much simpler runtime than what Ocaml or Haskell provides.

I think that functional languages are very good when you need regular high reliability (e.g. six 9s, not “never goes down”) and your time budget supports a merely-long thorough project, but when you need near-absolute reliability and have an almost unlimited time/resource budget, proven C (or, at least, C that has been checked and discussed and viewed by many pairs of eyes, as I’m not aware of formally-proven numerical algos being a thing beyond trivial cases) still wins.

I’m in the middle of first project with Rust. It’s a small compiler for a tiny functional language. I recently got the parser (handwritten recursive descent) working. Including tests, the project is currently ~650 LOC. I haven’t written anything significant in Rust outside of this.

Full algebraic data types + pattern matching add so much to compiler code. It provides a very natural way to build and work with ASTs and IRs. I’ve the experience Rust to be roughly on par with the ADT experience in OCaml. I will say that pattern-matching on Boxes is a little annoying. (Though this is probably a product of my inexperience writing Rust). I like having full ADTs much more than templated classes/structs in C++.

Also, the build system and general environment for Rust has been great. I have a single C++ project that’s nicely set up, and I usually just copy that directory over, rm a bunch of stuff, and start fresh if I need to start something in C++. Getting anything nontrivial working in OCaml is also a huge pain. I believe every time I’ve installed OCaml on a machine, I’ve needed to manually revert to an older version of ocamlfind. Cargo is an incredible tool.

I chose to use Rust because I felt like compilers are a good use-case for Rust + I wanted to learn it. It’s really nice to have pattern matching + for loops in the same language. (Yes, OCaml technically has for-loops as well, but it really doesn’t feel the same. It’s nice to be able to write simple imperative when you need to).

This all being said, I’ve had plenty of fights with borrow-checker. I still don’t have a good grasp on how lifetimes + ownership work. I was a bit stuck on how to approximate global variables for the parser, so had to make everything object-oriented, which was a bit annoying. I would also love love love to be able to destructure Boxes in pattern matching without having to enable an experiment feature (I understand that this can cause the pattern matching to be expensive, as it’s a dereference, but I almost always wind up dereferencing it later in the code).

For OCaml I made “must be in the Changelog” part of the continuous integration testing; our Travis checks fail if the Changelog file is not touched by a PR, unless the magic words “(no change entry required)” occur in one of the commit messages. I find this fairly useful, but some people dislike it. (But they dislike it the most in case where it flags their PRs, and in general it’s actually a good thing.) I think Changelog are super important and (for the OCaml project) we still have some progress to do on how to handle them.

The issue I’ve been noticing is that weaker versions of monads are making it into languages, like Kotlin and Swift which have this ? version of bind. So they have recognized that there is value in the abstraction but only offer the programmer a specialization. But this is a problem because this style of controlling sequencing opens up a lot of doors. For example, while everyone loves to talk about the Maybe monad, that’s actually so 5 years ago. I use the result or Either monad almost exclusively over Maybe. I want to be able to encode the error that happened so I can give the user a more valuable response than “something bad happened”. I use Ocaml and, while not as powerful as Haskell in this regard, I can just switch over to the result monad and get the same pretty code that I had with the Maybe monad (option in Ocaml). You can’t do that in Swift or Kotlin. I’m sure you could hack something in there but in Ocaml and Haskell it’s not a hack, it’s equally elegant no matter what monad you want to use.

For Ocaml, since we don’t have type classes, you explicitly pick the monad you want to use in a function so the function type doesn’t change but the implementation does. I think the functions I use the result monad on would be significantly harder to understand without being to redefine the sequencing operator so it is a net win.

Ohh ok I get the exception thing. I do not believe the Ocaml runtime supports this. Given my shallow understanding of how exceptions are implemented I think it might be possible. My understanding of exceptions in Ocaml is that they do not do stack unwinding but are implemented as an escape closure. This is why attempts to implement the Ocaml code generator in LLVM have been met with limited success: the exception implementation is not fast enough.

I don’t know how exceptions work in JavaScript, but does this abort thing if you are not in any try block? What about the case where you are in a try block but it doesn’t handle the exception being thrown? In Ocaml, like in Java, you can match on the type of exception.

IME, at least, though, my production programs only use exceptions for very exceptional cases such as out of memory.

I’m not sure exactly, but here is a slidedeck on how Printf works in Ocaml once it was moved to GADTs:

https://ocaml.org/meetings/ocaml/2013/proposals/formats-as-gadts.pdf

EDIT: Sorry that’s not a slide deck it’s a short paper. And I think the Ocaml versions still requires the compiler to do some preprocessing, but now it turns it into what you would have to write by hand for the GADTs to work rather than doing all of the formatting type check logic in the compiler.

Thanks for the response! And I understand the desire for debuggability. Out of curiosity, did you get any response from the community on why these things are not in Ocaml and the possibility of getting them in it?

Also, I don’t quite understand one aspect of the uncaught exception thing. The async libraries I’m aware of always have a catch-all for exceptions when executing callbacks so that the entire system does not get stopped due to one stray exception. Does Node.Js not do this? Can a single uncaught exception stop the entire program in Node? Or do you do a lot of sequential programming in JS where you don’t have these callback handlers? Or do you rip out any catch-all exception so a stray exception can kill the system?

Similarly, while I can understand the desire for abort-on-uncaught-exception, IME this issue isn’t really present in Ocaml programs. The convention is that exceptions should not cross API boundaries, so they should be elevated to something in the type system (such as option or result). I don’t think I’m nearly as thorough as Joyent and I can’t remember the last time I had a stray exception. But Joyent is doing more complicated work than I do so that may or may not make one feel better. Not that this is the only issue with Ocaml for you. But hey, happy to offer consulting hours to make Ocaml Joyent-approved :)

Do you know how Golang fits into the Joyent model (@bcantrill mentions it in his talk as an option)? It seems to be its own strange beast from what I understand but maybe it’s closer to workable.

Thanks again for the response. I get great joy out of Joyent’s products and I feel a pang knowing they are written in JavaScript…and possibly Golang :) I’m not all negativity, though, I’m hoping Joyent does some cool stuff with Rust and look forward to seeing it.

When there are new releases of OCaml, usually the first comment is about multicore and modular implicit. They are not yet there, but things will start changing soon. Refer to [0, 1] for more information.

[0]: Ocaml-multicore: report on a June 2018 development meeting in Paris https://discuss.ocaml.org/t/ocaml-multicore-report-on-a-june-2018-development-meeting-in-paris/2202

[1]: Modular implicits https://discuss.ocaml.org/t/modular-implicits

The JVM exists to be a Java bytecode interpreter. It’s counterproductive to assign any more labels to it – write once, run anywhere is hardly its main focus these days.

I would argue, basing on what most Java software is built for, that the JVM exists to be the best abstract bytecode interpreter there is. It’s not particularly great for small-scale algorithmic benchmarks like the alioth benchmark games, but where it shines is long-running processes. Servers.

The TechEmpower benchmarks demonstrate this. JVM languages occupy a significant portion of the top 10 in every segment.

Comparing the JVM to OCaml/Go runtimes is not fair. The JVM is a much more complicated beast, given that it supports some very advanced features like:

• AOT and JIT evaluation (fair enough, AOT support is experimental, but it is there)
• An extremely sophisticated garbage collector which is user-tuneable (this does not exist in Go/OCaml)
• A user-configurable concurrency model (native threads, fibers, green threads) - OCaml concurrency support is blah and Go only has green threads
• Code hot swapping and dynamic class loading
• Direct native code interface (OCaml is better in this regard, but with Go you need SWIG)

And the new Graal compiler is really cool.

And HotSpot is just one implementation. There are several enterprise-grade JVMs out there that include crazy things like real-time support (PTC Perc, JamaicaVM), AOT (ExcelsiorJET) and native execution (IM3910.

I think your citation of the expiry of the write-once, run-anywhere paradigm is anecdotal. I develop on OSX and run my .jars on Linux and Solaris v11.

As I said, the comparison is not fair. The JVM has about 25 years of engineering behind it. For that reason alone, it is extremely unwise to downplay it as outdated.

I read the examples thinking, hey, this looks and works a lot like ocaml with different syntax — even the way it handles mutability is the same. And it turns out it is built in ocaml! Nice. I didn’t look further to see if it’s compiling to ocaml and then to wasm under the hood, but I wasn’t aware ocaml had a wasm target so perhaps it’s all just a coincidence.

ReasonML is both a syntax and a default build chain relying on Bucklescript. You can use the syntax rewriter to build normal, binary libraries and executables via ocamlc and your build tool of choice.

Bucklescript heavily integrates with the Javascript runtime - depending on your needs, you can cast directly between a javascript object and a type safe OCaml value. This is why ReasonML uses Bucklescript as the compiler: it makes it much easier to interop with existing JS. Compare to js_of_ocaml which compiles the OCaml runtime to JS (more or less) and makes no attempt to reconcile the difference.

The only feature specific to ReasonML is the JSX rewriter (AFAIK) - that only works on ReasonML source, not OCaml.

OCaml + Bucklescript + npm = (default ReasonML toolchain) - jsx

Your statement was:

But this approach would be difficult to reconcile with the goals of Go. Go is positioned as a systems programming language (to program application servers, not operating systems). Using boxing almost everywhere is not an option here.

To which I demonstrated that Java, a language which boxes (almost) everything by default, competes very successfully in the same space as Go. And Disruptor also handles a significant number of transactions per second.

Is it enough “evidence” for you that boxing can be a problem?

That will help get more performance out of it, sure. But that is a different argument than the one I am making. I am claiming that Java, with boxed values, already has ridiculously good performance given its near ubiquitous position in the world, as such my statement is that your claim that being boxed everywhere is at direct opposition to being a systems language lacks evidence. It would be nice to know what the actual run-time targets are, as well. How can one state that the run-time costs would be too expensive if the actual target doesn’t exist? Perhaps I’m missing it but snooping around the Go forums did not turn up anything for me.

No, for sure. And Google, where Go was designed, is obviously not one of them… Don’t you see how ridiculous this argument is?

Yes, that is a fair point. But I think my point was communicated poorly. Again, you are saying that because of the domain Go is aiming at, boxing is unacceptable. However, Disruptor does an insane number of tps, so your statement doesn’t hold up to the evidence. My claim that most Go developers won’t experience a comparable tps was really a red herring and I should have left it out.

I have shown you that Java and Ocaml, languages that box everything by default, can have performance as good as Go’s.

No, you have not.

I provided a link to the language shootout showing Ocaml about equal to Go. So yes, I have. If your statement is actually that I have shown you evidence but you question the quality of it, well that is a matter of perspective and I can’t really argue with that.

several paragraphs of attacks against me and my character

From my perspective the following claims have been made:

• The compilation-time cost would be too expensive
• The run-time cost would be too expensive

In response I have:

• Shown that Java, a language with generics and boxes everything, has solid performance. Disruptor being able to hit tps of around 25million.
• Ocaml, a language with generics and boxes everything can have performance on par with Go.
• Asked what the actual targets for compilation-time and run-time are, with no answer. This point in particular makes any discussion almost impossible. Without an actual target it’s impossible to know if a proposal is too expensive or not.
• Suggested an implementation that would have the compiler create code that is the exact same as what Go developers would write now (casting to interface{} and back), providing no extra run-time cost, but clearly at some (unknown) compile-time cost.

Given the above, I feel that I have made an effort to understand why Go does not have generics and provided counter evidence to existing claims as to why it doesn’t. IMO, the responses I’ve received have only been authoritarian: “the authors of Go don’t see a solution they like” but without providing any specifics beyond that.

If you have provided a linked which goes into details what the requirements are for the authors to add generics to the language then I’m sorry that I have missed it, please link me again.

For the record, my name is Nicolas Grilly. If you ever had the opportunity, one day, to recruit me in your team, please don’t. I would probably hate engineering something with you.

I’m sorry you feel that way, but that is a disrespectful and unneeded comment to make. At no point have I insulted you, speculated as to what it would be like to work with you, or made hypothesis about your character. In my opinion this thread has been full of great discussion and healthy disagreement and I’m happy to have been a part of it.

Both, but start with OCaml.

Both haskell and ocaml are very similar in many ways. Type signatures, HM-like type inference, etc. However, in Haskell, many things are more “magic”, whereas in OCaml, code is typically more explicit.

This page might be useful for those of you who already know OCaml: Reason and OCaml: A quick reference for OCaml Programmers