- OCaml success stories which explore how major OCaml industrial users solved real-world challenges using OCaml. (https://ocaml.org/industrial-users)
- An interactive OCaml playground to try OCaml code directly in the browser. (https://ocaml.org/play)
- A syndicated blog, which links to blog articles from the community and offers original blog posts. (https://ocaml.org/blog)
I'm thrilled that the website is live after more than a year of development! We hope that this will help new comers to have a smoother experience when trying OCaml (in particular with OCaml 5 coming soon), so don't hesitate to share feedback on how we can improve it further!
OCaml has a particularly easy to associate mascot that's been prominently featured in the past - is there a reason the website is moving away from the more familiar camel iconography?
The graph on the front page is unclear. Is it the fast compiler or the slow computer? The columns are labelled with mysterious words like "menhir" and "opam." I don't know what a reader new to OCaml is supposed to learn from it.
what website / community is the most warm on ocaml these days ? reddit ? irc ? I don't know, I'm curious where to find people thinking and working with *caml.
It's a nice website and certainly an improvement from the older one. I just hope that this isn't the only area where OCaml improves. I'd love a consistent documentation source a la docs.rs, better support for language servers, and maybe an explicit effort to build out a good package ecosystem.
I really want to like OCaml but the usability story is so far behind Rust. The language is stunning but the ecosystem needs a lot of work.
I've been using ocaml-lsp-server with nvim-lspconfig and it's been great, I'm wondering what issues you've had? From my perspective the ecosystem is evolving pretty quickly!
I can second your experience of using ocaml-lsp-server - I use it with VSCode and it's been incredibly pleasant with lots of active and ongoing work to make it even better. Gone are the days when writing OCaml basically meant using emacs (thought that's still a good option if you want it!)
OCaml has a pretty decent language server [1]. You can pair it with the excellent OCaml vscode plugin [2], or any other LSP plugin for the editor of your choice.
The VSCode plugin and language server are really good. They're not quite on par with rust-analyzer, but I very rarely have issues with them, especially when using esy as the package manager (because you can easily set the version of the language server and be sure that everyone on the team is on the same version).
I don't think the ocaml tooling is great but I don't find it too much of an outlier compared to other languages I work with. I haven't used rust but I do believe it's better there. Ocaml has been improving steadily over the last few years though, and none of those things has been a major barrier to anything I needed to do recently.
For the language check out Reason. It looks even better! It’s almost like Ocaml but for made JS, React and stuff. You can use Ocaml modules with it by the way. Since it’s all based on Ocaml
I used Reason for a few projects. It was a nice skin over OCaml, although the syntax errors were absolutely horrendous, and the async story was quite mediocre. I don't love it when the solution is "just use callbacks"
When you say "something similar", what are you thinking about? Simply this rather professional presentation, or something social, or something technical? Or the fact of a renaissance? Is this sort of revamp a cause or a symptom of a renaissance?
For Common Lisp it's always seemed to me that SBCL (disclaimer: never used it, only read about it) is the "modern" option in the sense that it's well maintained, portable and fast, but it has the most amazingly old-school web presence.
Another great example is Poly/ML (https://polyml.org/) - one of the best implementations of Ocaml's close relative SML, but it's very much lacking a Bootstrap theme and "trusted by" testimonials and it has a splendid naive-art parrot. I like all that about it, but you wouldn't look at the page and think "I'll choose that for my new green-field project with venture capital money".
I would love to see a renaissance of Prolog as well.
common lisp suffers for a lack of new blood coming in and making well maintained websites with docs and getting started guides.
case in point, go to cliki for osx and they advise downloading emacs, setting up slime and downloading sbcl. but there's a lot of information missing. Also no mention of arguably the easiest (in practice) way of setting up common lisp ie: spacemacs.
just runnign and maintaining common lisp codebases is a hodgepodge of arcane knowledge collected accross disseperate smaller websites that look like they were designed in th e90's. no wonder all the noobs think javascript is the end all be all of languages.
My daily driver is elixir. I have mix and with one command I can start a whole project with a complete build system. I was able to setup a full elixir environment and get a hello world in about 5 minutes just reading the main elixir website. If I needed a package, I could just go to hex.pm, search for a library and add a line to my mix file to automatically pull the dependency and build it. ie: I gae bills to pay and the ecosystem is setup so I can get work done.
common lisp suffers from extreme fragmentation that presents significant friction for doing any kind of work. Its only saving grace is that the language itself is so powerful, it makes the impossible possible. where other languages fail in a fractcal of complexity, common lisp can be used to produce a working solution.
have you used it for anything? i followed it hopefully when it first came out but it never seemed to make the leap beyond "research/teaching language" and was finally abandoned :(
same. I think something along those lines might be happening with projects like Janet, Fennel and Clojure. But I’d love to be able to experience that so talked about CL teaching a system how to behave in CL/Small Talk
It's surprisingly general purpose. I mostly use it for toy side projects. I've used it for basic CRUD apps, like a reddit aggregator. I've written a couple opengl graphics libraries with it. Used it instead of JS for a web implementation of a board game. a toy Datomic clone, and I'm currently working on an alternative unix shell.
It's pretty comfortable for organizing and refactoring because of the nice module and type system. And once you grok Dune (the build system) you can get going pretty quick. Builds are very fast compared to most of the languages I use at work. And if you're not doing anything egregious the optimizing compiler (Flambda) can usually be within ~2x of C for most things. When it's not dropping down to C is very easy because the FFI system is very straight forward, and has built in support in Dune.
It is lacking a bit in libraries and when you need to drop down to imperative features you may find it a bit rough. For example not having a return keyword can make it annoying to port over libraries.
Overall I like it because I think the pros outweigh the cons, but I've also been using it for a decade so I'm probably getting set in my ways now. I'd say it's worth trying at least to understand Sum types (and maybe GADTs), and use a language with first class modules, it can change your approach to problems once you see some extra tools.
This is totally a biased cop out, but I'd say "most things".
Like, what's java's niche? I'd say it doesn't really have one anymore, it's just a generalist language. Ocaml is also a generalist language, but it has much better language paradigms, is safer, more concise, has more features with less baggage, etc. It's just good all around.
As a functional programming advocate, I'd point to safety, readability, and development velocity as features, but those are all around good and desirable, not really a niche.
I wish more companies were using languages like ocaml/f#/clojure vs c++/python/java when there is no specific reason to use the former.
Maybe it's more usefull to talk about a 'slant'? Like, you can totaly do desktop apps with custom GUI components in Java but those tends to be written in C++ for some reason.
Like java, python, c# 'slants' towards web services and maaybe CRUD apps, C++ 'slants' towards games and graphicly complex apps.
I've used OCaml at day-jobs for the past couple of years. It has an excellent concurrency story, and I've used OCaml for lots of "boring" work (web services, database drivers, data processing, etc).
I really think it's such a good fit for most of the daily non-web work I've had to do. It lets you keep the core logic clean & fun and then you can just shrug and let rip with the mutations or whatever when that makes the most sense.
I'm well out of my FP fanboy phase now but ocaml feels great for my favorite parts of that without being judgmental when I'm not in the mood.
> It lets you keep the core logic clean & fun and then you can just shrug and let rip with the mutations or whatever when that makes the most sense.
Very true! I've used mutations and imperative OCaml quite a few times. Sometimes it was for performance reasons (I've been working on a web server library), and other times when loops either made the implementation a little easier to read, and/or helped avoid some allocations. I am glad that the language is pragmatic enough that I can still use mutation or imperative code where it makes sense, while still being able to present a nice clean api on top.
The first time was hearing about a startup that used OCaml on one of the monthly hackernews Who is hiring thread. The current day job was also somewhat similar in that I had read about a startup's job listing on the OCaml forum [1], checked with them again a while later (the startup was acquired by another company), and found an open role on the team that continued to use OCaml after the acquisition.
> it but it seems like there are very very few jobs that use it primarily.
I completely agree. I never tried looking for an OCaml job mostly because there weren't enough options at-least in the US (I'm based in USA), and I am picky about who I work for and wasn't interested in exploring job opportunities at companies working on cryptocurrencies. I just got lucky that I stumbled upon two different companies that used OCaml. The first time around I applied for the job because of OCaml, the second time around it was because I liked the company and OCaml was an added bonus on top.
Ugh yeah that pretty much confirms what I suspected. It's a few huge players using it for small internal projects, jane street, and a bunch of crypto shit I'm not willing to touch.
The language I work in is not even one of my top priorities when looking for work, but still it would be cool. I'm lucky enough to have enough freedom to work in it from time to time, which is good enough for me.
> The language I work in is not even one of my top priorities when looking for work, but still it would be cool.
Same! I've made the mistake of overlooking certain things just because I wanted to get some real world OCaml experience in the past, and I will not make the same mistake again.
At my current job I mostly use OCaml and Python, with some Typescript for whenever I need to touch a frontend application. As much as I like using OCaml, I'm more thrilled about working on a team where I enjoy working with everyone, and having a work environment that provides flexibility about picking the best tool for a job. Most of my OCaml hacking still takes place on my free time, and on my personal open-source explorations :-)
> Thanks for the response!
You are welcome! Sorry if my responses weren't too useful with respect to using OCaml at work.
Yeah I think that's a good example of what I mean though. That'll be a couple tiny teams within a huge org, with a lot of people willing/desiring to transfer internally onto it. Those rarely if ever get filled from outside the org, and when they do they're looking for experts not competent part-time users.
Yeah especially considering the safety guarantees that ocaml offers over say solidity. If tezos ever went above 10$ maybe I'd be able to convince people who are going all in on ethereum to start projects with it.
I've seen it in things where performance isn't super important (OCaml is slow as per my experience). Many, many provers/theorum solvers use OCaml because it reduces the bugs in the provers themselves.
It was written in tandem with a prover and is generally very nice to use to develop compilers and analysers. The biggest company using it does algorithmic trading with it.
Kind of an annoying point but I'm tired of seeing factorial-like functions as the first demos of PL sites. It does nothing to explain how the language works, what it looks like, what any defining/unique features are, what the standard library - if any - might have included, etc.
Actually, it does here. Definitions with let in OCaml are not recursive. let rec permits you to have recursive definitions. A simple numeric function is probably the fastest way to show something that a user can type in that illustrates how you'd write a simple recursive function.
This landing page includes a pet peeve: zero-context social proof.
It's great to know that Microsoft, Docker, and Facebook use OCaml. Buy do they use it seriously? The industrial users (https://ocaml.org/industrial-users) page links directly the company websites. Only two logos from the home page have case studies. Don't just tell me that Microsoft uses OCaml, tell me how!
I know that Facebook's Typescript competitor, Flow, was both written in OCaml and tried to introduce the HM type system into the JS world. It was quite popular back in the day, but eventually lost the war to TS.
Perhaps more notably, they are still actively working on Rescript (formerly ReasonML), which is an Ocaml dialect with JS as the primary compilation target (think Clojurescript but Ocaml). They also maintain a flavor of React specific for Rescript. I don't know how much they dogfood it, but it seems like they're at least somewhat betting on an ML future.
Same way Microsoft uses Java, mainly. They copied it, paid a bunch of geniuses massive amounts of money to make it better and run on their platform, then spent millions and millions of dollars recruiting Ocaml (Java) developers into their proprietary F# (C#) universe.
What's the current state of OCaml regarding parallelism & concurrency? Is it like Node.js where I have single threaded async/await model or do I have access to parallelism?
OCaml is more like Python in that it has true OS threads, but it has a GIL (it also has an async ecosystem via `lwt` and `Async`).
This will change when OCaml 5 is released, though it is likely that will require test driving and fixes in both ocaml itself and the ecosystem.
Multicore OCaml was merged in PR #10831, and 5.0 was originally targeted to be cut in March or April 2022, but it seems there are still blockers: https://github.com/ocaml/ocaml/milestone/40
A nit about the code sample syntax highlighting, shouldn't "rec" be highlighted as a keyword and "fac" be the yellowish color that "square" was in the first line?
Why do functional programming examples always use such short names? I feel like it adds extra cognitive overhead to trying to learn something that's got plenty of foreign concepts to grok.
I suspect the ideal behind that is the "variables with small scope should have shorter names" concept. So in a one-liner it's ok to abbreviate.
I don't necessarily agree with this especially for examples. But in practice I haven't found the fp communities I'm familiar with (clojure and ocaml) to be too bad about using confusingly terse names. Php and go are by far the worst there, again at least from my experience.
a lot of the time there are patterns and idioms that occur very frequently in the language, and have evolved a set of standard short names, e.g. "xs" for a list and then "x" for the element in an iteration, or "acc" for an accumulator parameter in a recursive function.
Often the expressiveness of the type system captures info you'd have to stuff in the name in something like Java or python or at least they just want to emphasize the types over the names. Not always the case though.
The “Carbon Footprint” page[0] is a nice touch. Not much in terms of concrete action there, but the fact it has been written (and linked to in the footer) is a good start.
I know these languages are both members of the ML language, but why would one pick OCaml over F#?
I've toyed a bit with both and F# seems a bit more ergonomic: pipes, computation expressions, a more concise syntax, etc. I do like how fast the OCaml compiler is though.
The most straightforward reason to pick OCaml over F# is that OCaml's not tethered to the .NET world. Though this is also an excellent reason to pick F# over OCaml!
OCaml's type and module system is generally more sophisticated than F#'s - F# doesn't have GADTs, all the functor-y goodness of OCaml's module system, or even OCaml's weird-but-brilliant structurally typed object system. The new algebraic effects that OCaml's getting imminently are pretty killer, too. F#, of course, has several awesome features that OCaml lacks.
OCaml has had pipes for a long time and it has also added let-operators, which are very similar to computation expressions. In the upcoming version 5 they are also going to push towards direct-style coding of parallelism and concurrency thanks to the new effects systems, making 'futures', 'promises' etc. and their use with computation expressions obsolete.
For me it would be because OCaml is supported by Ubuntu as a package. In contrast, for installing F# you need to add an external repository and mess with GPG keys etc. which seems odd. Perhaps I'm wrong but what it tells me is that F# is not yet fully embraced by the open source/Linux community.
It also has modules that take other modules as arguments and produce new modules - these are called functors. They're a really useful way of organising code, with F# you'd use .NET objects for similar issues. Nothing against objects - I'm not one of those - but the ocaml design just feels a lot cleaner.
I wish people will use Reason[1] more often and create a vibrant ecosystem with it. It’s the perfect language. Functional, ML but not so hard as Haskel. Very fast to learn and easy to use. And some powerful features like the switch couple with other types and structures. Also no null and undefined and stuff only one thing « None » which avoid many bugs.
Ya it has some kirks. But I mean look at the language. It’s so readable. I’m so sad I was talking about this the other day how where it looks like the perfect language but there is not ecosystem…
I have no familiarity with OCaml at all, so I really don't know what the unit should be here. If it's milliseconds, that's really, really, impressive. If it's seconds though, that seems on par with other languages/compilers I've used.
It's probably the best open source OCaml project in terms of documentation and in my opinion it really sets the bar for all oss project a little higher. Aantron really did some amazing work here.
Is MirageOS (Ocaml unikernel) still making forward progress? Ten years ago I thought security sensitive apps would all move to unikernals, but it never happened.
Just wanted to also link the announcement post here: https://discuss.ocaml.org/t/v3-ocaml-org-we-are-live/9747.
This new website comes with lots of improvements over the previous version, and in particular, the team has been working hard on the following:
- Central OCaml package documentation, which contains the documentation of every version of every OCaml packages. (https://ocaml.org/packages)
- OCaml job board, which lists job opportunities from the community. (https://ocaml.org/opportunities)
- OCaml success stories which explore how major OCaml industrial users solved real-world challenges using OCaml. (https://ocaml.org/industrial-users)
- An interactive OCaml playground to try OCaml code directly in the browser. (https://ocaml.org/play)
- A syndicated blog, which links to blog articles from the community and offers original blog posts. (https://ocaml.org/blog)
I'm thrilled that the website is live after more than a year of development! We hope that this will help new comers to have a smoother experience when trying OCaml (in particular with OCaml 5 coming soon), so don't hesitate to share feedback on how we can improve it further!