How many people use ocaml

A Substack blog post at the weekend argued for the obscurity route. We've already looked at the value of languages like K and Q for finance jobs, but there's also merit to learning functional programming languages like Clojure, F , Scala, Elixir, and Jane Street's revenues in the first quarter alone of were greater than Citadel Securities' for the entire year. Jane Street uses OCaml as its primary development language. In a YouTube video posted six years ago that's had over 62, hits and counting, Yaron Minsky, Jane Street's head of technology and the man who convinced the firm to use OCaml in the first place, said the language is "in a kind of sweet spot in the design space.

At one point, Minksy said Jane Street thought of using C , but that OCaml was much more concise and easy to read, making it less prone to errors. Separately, Minksy observed that Python is, "crushingly horribly insanely slow.

Because OCaml is so flexible, Minksy said Jane Street uses the language for everything from little scripts to automate small tasks, to big trading systems trading billions of dollars a day. It's a "single tool that works for a large variety of applications. The only problem with OCaml is that not many people know how to code in it, and therefore not many people use it. At Github just 0. Moreover, OCaml is becoming less rather than more popular - in , 0.

Maybe this doesn't matter. On this basis, your value as a developer is partly defined by your commitment to learning obscure languages. And although Jane Street doesn't actually mandate knowledge of OCaml for its interviews, if you can code in its pet language, it will show a lot more interest in the role than if you can't. As multiple forum posts attest, OCaml isn't easy to learn. A multicore friendly version of OCaml is about to be released. The latest version of OCaml also includes many great new features such as lazy patterns and dynamically loaded native code OCaml libraries.

I think part of the problem is that functional programming is just not a natural way for most people to think and I say this as someone who has a great interest in, and appreciation for, functional programming. This is compounded by the fact that the vast majority of programmers today started out learning procedural programming most popular OOP languages are still procedural at heart and so functional languages are hard to adjust to initially.

I was far from an expert but had reached the slightly naive conclusion that all programming languages were basically the same with slightly different syntax.

Our introduction to programming course used ML which rapidly disabused me of that notion. I had trouble getting my head around ML at that stage of my programming career and didn't really see the point of functional programming.

I think it takes a bit more experience with some of the problems of procedural programming to really appreciate the benefits of a functional approach. Our ML lecturer often claimed that expressing problems recursively was more 'natural' and easier than using loops or other procedural concepts.

I was never convinced by that claim and still don't buy it. Recursive functions can sometimes provide particularly elegant and concise solutions to problems but I still find it an unnatural way to think about problems. Perhaps if you have a very strong mathematical background it seems more intuitive but I don't think it is easy for most people to think recursively. Given the centrality of recursive functions to the functional programming paradigm I think this may also be a reason for the lesser popularity of functional languages.

There is also a feedback effect to language popularity. When I started programming I wanted to know how to program graphical effects and games.

Nowadays some new programmers might want to know how to produce web applications and so will gravitate towards learning PHP, Ruby or C. There are very few application areas for self motivated beginner programmers where the answer to 'what is the best language to learn to program something like X' will be 'Ocaml'.

Many of the practical reasons given for Ocaml's limited popularity lack of mature libraries, debuggers, IDEs, etc. NET language. It will be interesting to see if F helps bring about a greater level of popularity for functional programming.

I believe the core of the problem is politics. The Ocaml developers are principally interested in research and do not have the resources to provide and maintain a rich library. However they're also unwilling to release control of the product to the community which does have these resources, the result is that several attempts to solve this problem relied on non-existant cooperation and funding of third party libraries and these attempts failed.

Batteries will fail for the same reason, unless the Ocaml developers change their attitude. I use Ocaml to develop my product, and I have a simple rule: minimise dependence on third party code. When a third party item is useful, if at all possible, incorporate the source codes directly in the package. For example OCS Scheme and Dypgen are essential parts of the Felix parser, so they're copied into our sources so we have some control over them.

The control is somewhat illusory since Dypgen at least is so complex it is unlikely we could maintain it, but at least we have a copy we think works :. I won't use batteries because the licence is restrictive, so I can't copy the source, and I have no faith in the long term viablility of it as a stand alone product: the only way I could use it is if it were incorporated directly into the standard distribution of Ocaml. Ideas developed and tested in Boost become the kind of existing practice that can be standardised, and the standards process is open enough to allow community participation.

Ocaml has obtained the popularity it actually has because it is such a fine product, but that is not enough to allow it to become a mainstream language. Java is crud, it was made popular with billions of dollars of marketing and library development, but in the end had to be released to the community to survive at all. I have enjoyed coding in both ML and C for a wide variety of projects.

The thing preventing me from using ML in embedded projects most of which have real time constraints, and require validation is garbage collection. There is research into memory management with regions see MLKit but the complexity of the implementations and training required to use them properly and attendant risks have been an impediment to using them.

IMHO, I think a big problem of OCaml it's not in the language that is great but in the people that develops it and by consequence, his license:. They use the Q Public license for the compiler! Yes, the license ex-Trolltech used for Qt libraries! Forget about getting any contribution with such a license.

In the while, other languages like Haskell got a better compiler due to a different community approach, I suppose and now OCaml speed of execution is not so great as in the past. Well if it is about money as jrockway says, we'll see if F will gain the popularity like java or C. For me I guess developpers don't feel confortable with the functional way of doing things that's from the F session in techdays where about 10 people said they know functional programming among almost persons.

It wasn't the constructs that made it look hard, those actually looked really neat. It was trying to learn an entirely different meaning for '! Lisp at least looks so different that it's easy to avoid misinterpreting small pieces of it as c. If you want a language to use in real-time embedded systems, you need pointers and you can't afford a GC. And when talking to other developers those who heard something about Ocaml I always get the impression that they think of OCaml as an "education-only" language I like O'caml a lot I've implemented a bunch of things using it, compiler, interpreters, system to communicate with C Sign up to join this community.

The best answers are voted up and rise to the top. Stack Overflow for Teams — Collaborate and share knowledge with a private group. Create a free Team What is Teams? Learn more. Why isn't OCaml more popular? Ask Question. Asked 12 years, 10 months ago. Active 8 years, 6 months ago. Viewed 65k times. Juliet Juliet 2, 6 6 gold badges 25 25 silver badges 23 23 bronze badges.

Active Oldest Votes. With that disclaimer, here are some points that are suggestive, most important first: The first mature C compiler appeared in ; the first mature OCaml compiler appeared in the late s.

Norman Ramsey Norman Ramsey 2, 1 1 gold badge 17 17 silver badges 15 15 bronze badges. OCaml is a relatively recent ML dialect, born about same time as Java. ML dialects found a niche in theorem proving and research, but have since been the industry standard in financial institutions.

I wouldn't call ML the "industry standard in financial institutions. Companies like Jane Street are the exception, not the rule. Perl is a "software artifact" - the only definition of Perl is "the language that perl 1 interprets" - and yet it's rather popular. Python and Ruby were "software artifacts" for a long time. Chris: IMO this is one reason that Perl is losing mindshare. As to predictability, I think OCaml actually beats C in that realm, with the level of optimization that is expected of C compilers, and the fragility of many of those optimizations.

OCaml's compiler is very literal about what it compiles your code into. Show 5 more comments. The result was popularity. Money can solve a lot of problems. This was maybe true 10 years ago. Let me know when I can "cabal install" an OCaml library. Anyway, just because I said something bad about your favorite languages doesn't mean you have to stop using it. So no need to get emotional. No, I meant programming in general. If you can't understand functional programming, you probably can't understand the other concepts either.

I don't buy this. OCaml has plenty of libraries for basic day-to-day programming stuff, and if it became more popular, people would write more. On Rust's side, you usually have to write wrappers around your C FFI functions in order to do any type translation and to add any necessary safety, but those are at least written in Rust and are not actually necessary to call C, just necessary to provide a safe idiomatically-correct Rust API; you could just vend the C FFI functions directly if you wanted to.

Dewie on July 17, root parent prev next [—]. It isn't a given, from what I've read, that their product would need a language that could be realistically used everywhere. A lot of applications can get away with technology that is more "limited" in that sense. And being "limited" can be a plus. Turns out that they didn't really need the dynamicity of Python after all. These are all features, or burdens, depending on your application area.

But why would they be features, in this context? It boils down to fine-grained control over performance, I guess. But, again, I don't see how that is a plus in this context. It can also be a burden, hence all the languages that deliberately do not let you have explicit control over memory - it makes for less stuff in the language, hence less complex language overall, or perhaps more room for other stuff that might be relevant to the application of the language.

I don't get the apparent attitude of "it has all the features of OCaml, plus all this other stuff ". More stuff is not necessarily good, and can be a burden if you don't really need it. I have no idea. Note here that "full memory safety" in Rust includes data shared between multiple threads, and includes protection against data races.

Garbage collectors help avoid referencing free'd data, but if OCaml lets you share mutable data between two threads, then I doubt it's fully memory-safe at the very least that suggests you can get data races. What, in the context of server-side software? I don't know if it necessarily is, but it's definitely problematic in other contexts.

And I do know that there have been issues with other languages causing unpredictable performance on servers because of garbage collection, e. I hope OCaml doesn't have that problem, but I don't know. I'm not sure what specifically you're referring to in that second sentence. Just the general ability to have better control over performance? Having that ability typically is a plus even in the context of server-side software because it means you don't need to change languages just to write the performance-critical aspects of your software.

Of course, using the same language is only a good idea if the language is also a good choice for the parts of the software that aren't performance-criticial. My claim is that Rust is indeed suitable for the rest of the program too. I learned a lot about OCaml from that series of posts. For more comparisons between OCaml and other langages, see the first two posts in the series. He chose OCaml after that, obviously.

A bit surprised F was not even mentioned. I guess they are hardcore meta-programming users? F is an ML without any of the things which make ML good modularity. It's a breath of fresh air if you're on a Microsoft platform, but if you can use OCaml, it is superior.

JamesBarney on July 16, root parent next [—]. I want to know what I'm missing out on. Where Ocaml is better : - Single Core Speed Ocaml is fast - native compilation without requiring some installed runtime - Polymorphic Variants Last I read, to be used only when regular variants are not sufficient - Modules and Functors there's a proof of principle for F supporting these - GADTs allow for richer more expressive types, much more flexibility than regular algebraic data types - camlp4 - more pervasive structural typing, higher kinded types They seem like dumbed down metaprogramming at first but it's one of those cases where constraints benefit creativity.

Although you could certainly do what they provide and more easily at times with metaprogramming, I've never seen metaprogramming used that way before. And especially with the proliferation of APIs, stuff like json inference makes going to a language without them like going from 3 monitors to one. F syntax is a tiny bit cleaner and surprisingly close to Python at times. The core of both languages are the same, so much of the time and ignoring library choices, you won't be seeing many differences between F and OCaml.

It's more like Portuguese vs Spanish than English vs German. I'm surprised you mention camlp4 as an advantage over F. It is being removed from the official distribution due to the problems that it causes[1], to be replaced with extension points[2]. We use camlp4 a bit at Red Lizard Software and we are eagerly looking to move to extension points as soon as they are released.

Thanks for the great comparison! I'm not familiar enough with F to say—is this also possible in F? F allows null values, it seems, while you would need to use an Option type in OCaml. Thanks, this was super helpful. I'll have to spend the time going through functors this weekend to try to grok them. But also F doesn't allow null values, it uses the Option type as well.

MichaelGG on July 16, root parent next [—]. F most definitely allows null values. They might not be encouraged, you can't always assign a literal null to a type, but null is very much a first class concept in F. You're far less likely to run into them in F code compared to C , though. Jon mentioned modularity, so what I imagine he's talking about is functors. They have a scary name and no relation to Haskell functors so you might rather call them parametric signatures and they allow one signature to depend upon a previously defined one.

Ultimately that means that you can decompose signatures into constituent, reusable parts which is nifty sounding but transformative in how you express APIs. Functors are not parameterized signatures: they do not allow a signature to depend upon another signature, but rather a structure to depend on another structure. How is it that they have no relation to Haskell functors? Are they not at least the same Functor as in Category Theory? Well, they're related at that level.

Many, many things are category theoretic functors, though. It's a very general idea of a structure-preserving map between structures. Functors also known as parameterized modules. Hey James, I know that most. I'm actually more surprised that SML seems to be completely restricted to academia nowadays.

Standardized language, several decent compilers available, used in introductory books LeonidasXIV on July 16, parent prev next [—]. Or maybe they started off from an existing older codebase that was started before F existed. Many possible reasons. Why would they? They neither mention other close cousins like Standard ML, second cousins like Haskell or distant relatives like Scala.

What are some advantages of OCaml over Haskell? Haskell uses lazy evaluation by default, which makes it hard to reason about the space usage or termination of a particular program.

OCaml on the other hand is not lazy by default but supports it if you need it. At least that is one of the reasons why I chose to learn more OCaml than Haskell. Why do you think termination is easier to reason about in eager languages? I think it's quite the opposite: in lazy languages functions compose, in strict ones they don't necessarily. For example, you cannot compose a "take ten values" and "square all elements" function in a strict language if the argument you apply their composition to has infinite length e.

With a lazy language its not always obvious if a certain expression needs to be evaluated now or not. In particular I was writing some list comprehensions in Haskell, trying to solve some of the project Euler problems, and when I introduced a bug I got an infinite loop.

When I fixed the bug I got the correct answer thanks to lazy evaluation, but the buggy code and the correct code looked awfully similar. Maybe it is just my inexperience with lazy languages that caused trouble I came from C , and learning two radically new concepts: functional programming and lazy evaluation was too steep of a learning curve.

Or perhaps list comprehensions aren't really supposed to be ab used like that. Unfortunately I don't have that code anymore, it would've made it more clear what I'm refering to Maybe it is because you didn't show an example, but that doesn't seem like something caused by lazy evaluation. It is pretty easy to get into infinite loops due to logic errors in Project Euler type problems even when using imperative loops.

Because I can walk through a strict program in my head or on paper , and see every value, what is being calculated, and what is being stored. With a lazy language, I can't necessarily do that. The entire memory of my program can quickly fill up with thunks. The optimizer determines when things actually get calculated, and I need a much deeper understanding of my code to figure out the space constraints.

Just writing code? I guess I can agree that lazy evaluation makes it easier, but performance still needs to be considered. The eager vs. There are some programs that under eager application semantics will not terminate, but under lazy application semantics they will, and vice versa. What complicates reasoning about termination is the presence of mutation.

In a lazy language, you'll never have mutation so you don't have to worry about those complications. You could have an eager language with no mutation e. I don't think that's right.

There is a basic theorem in untyped lambda calculus that says that if a term has a normal form, then any evaluation strategy, including strict and non-strict, will reduce that term to that normal form. Since non-strict evaluation can "skip" arguments that may have no normal form, there are expressions in non-strict languages that terminate while their strict counterparts don't.

The opposite scenario does not exist: if a term has to be evaluated, it has to be done in both the strict and non-strict versions. And in simply typed lambda calculus, all reduction sequences terminate. Under eager application semantics it will. It doesn't necessarily have to be that way. You can have both composable functions and non-wasteful semantics without turning the whole language into a lazy mess.

Note that this approach will also allow you to abstract over different data sources more easily. I've used Haskell to build JavaScript tools and analyses[0], among other things[1], and have been using OCaml for the past nine months to develop a software-defined networking controller called frenetic[2]. Off the top of my head, here are a few areas where OCaml has an edge on Haskell: 1.

The module system. OCaml's module system is a language in and of itself. It not only allows you to define modules that export certain identifiers and types, it also allows you to write functors, which are essentially functions in the module language that can take a module as an argument and produce a new module as a result.

This is a great way of reusing code in a project as well as defining external APIs in a general but natural way. OCaml's module system the closest I've seen to realizing the dream of building software by taking some modules from here or there and composing them together. Unlike Haskell, OCaml allows mutation.

Specifically, OCaml allows value mutation in certain contexts, while both Haskell and OCaml do not allow variable mutation. What this means is that in both languages, if you have an identifier, you cannot change the value that the identifier points to; you can only shadow the identifier with a new binding.

But in OCaml, you can declare certain fields of your types to be mutable. You can also wrap values in a "box" which allows you get the same feel that you would out of variable mutation. While in general it's a good idea to limit your use of mutation, sometimes you know it's ok and you just want to do it. OCaml lets you do that, but it requires you to be explicit about it rather than just letting you do it willy-nilly.

If you know how to use gdb and even valgrind I believe , you can use it to debug your OCaml programs. If you try and use these tools with Haskell, you will get nothing but nonsense until you learn how to read the matrix. This fact by itself for some people will make OCaml a candidate for systems programming over Haskell. Certain features of OCaml's type system allow you to do subtyping, complete with type variable annotations to indicate covariance or contravariance.

This is a feature that Haskell's type system does not have, so in a sense this is a strength of OCaml. However in my experience, this feature of the type system is hard to use and reason about, and I've seen little maybe no? All that being said, Haskell's still my hobby language of choice. But for building real systems, I'm warming to idea of OCaml as a viable candidate language. One more thing: OCaml is strict by default, Haskell is lazy by default. The later allows for some nice code idioms[0], but makes reasoning about performance and memory characteristics very difficult[1].

Yea, I didn't do that just to make it clearer: if you aren't used to ML, I Imagine that this would be very confusing. Neat reply, thanks. In regards to 2, this sounds like the ST monad, are they comparable at all?

OCaml allows you to use mutation pervasively without marking your type. You can see Haskell as advantageous because it means that if you have a type without one of those markers you can be certain there is no observable mutation occurring. You can also see Haskell as disadvantageous because those markers are a little annoying. The ST monad lets you transition from regions which allow mutation to pure regions and then back again.

Basically, all OCaml code runs in IO. You can still only modify things that you've marked as modifiable analogous to an IORef , but there is no constraint on where you can modify them from. In case it's unclear, I'm agreeing with tel and rephrasing.

One advantage that gives you, is that you can easily define a monad on top of that and not worry about monad transformers. But I like transformers Your Haskell program doesn't use the C stack, so using gdb may tell you something about the Haskell runtime you're using or some C library you called into, but it won't tell you much about the state of your actual program. It is also an impure functional programming language, so you can write straightforward and reasonably fast imperative code in it, if you need to.

A few mentioned in this article are true modules and polymorphic variants. Both can be partially modeled in Haskell, but it's tougher. I feel that almost nobody would disagree that these are advantages of OCaml. Most people also suggest that strict evaluation and impurity are good traits of OCaml. This is more a contested point, however, as lazy evaluation and strict evaluation are more like duals than one being definitely better than the other.

Furthermore, unrestricted side effects are a major tradeoff between convenience and safety—it's up to your use case to decide what's best. Finally, OCaml obviously has an "O"bject system in it. My understanding is that serious OCamlers shy away from it for reasons of complexity and low value.

The major stuff is provided by the module system and doesn't have anything particularly "object" about it. I would say Ocaml code is much easier to understand as a beginner than Haskell. Even with context I've never been able to just look at some production haskell and get the gist quickly.

Ocaml takes work, but I at the very least have an idea of what's going on after giving a chunk of code a once-over.