Hacker News Reader

Comment by yen223 | Hacker News Reader

I've been using OCaml for a couple of side projects, and I have been absolutely blown away by the amount of power this language provides. It strikes a nice balance between high-level expressiveness, while not sacrificing on performance.

I feel like OCaml is one of the programming world's best kept secret - if it had better tooling and better marketing, it could have taken over the world. I'm cautiously optimistic about ReasonML for this reason.

View on HN

Version incompatibility is a big problem for OCaml. Every time I try to use it seriously, the recommended tools never seem to work together on anything but the latest version. It's like Rust, but without the "young language" excuse. My impression is that INRIA is too eager to add features and tweak the language.

Next, everything builds so slowly, and just trying to set up Core, utop, and ocp_indent is a trial in patience, watching the same dep build again and again, confusion about OPAM switches.... nope nope. OCaml/OPAMs's got a distribution problem. They've pushed the complexity off to the end user and the experience is terrible. Jane Street planting their flag on the language and encouraging massive dependencies like Core, or shit like "corebuild" is even worse. I would never depend on anything OCaml-based on it unless it could be installed by my OS' package manager (Arch/AUR doesn't count, because it builds). That rules out most popular OCaml tooling, and ruins the development experience.

I'd prefer OCaml to Haskell, I find it more practical, but I feel much better depending on Haskell-based software, which generally "just works." As much as they're a wart, Haskell syntax extensions are a real benefit. You can build new fancy Haskell software with older GHC versions.

The opam is pretty new. When I looked at OCaml a few years back my phd work, it didn't exist, so there's some churn in the tool chain

I think your overstating the pain though. Even in other languages, best practice demands you pin a library version so you wouldn't have some of those issues.

OPAM was released in 2013 and I recall it being mainstream by 2014. Maybe I am overstating the pain, but I've jumped through hoops for plenty of languages, and OCaml stands alone here. As somebody who's pretty good on the command line and at solving installation issues, the thought of a junior developer trying to get started with OCaml gives me shivers (probably another impetus for Facebook's Bucklescript).

> Facebook's Bucklescript

I think you mean FB's ReasonML. Buckle is Bloomberg's OCaml-to-JS compiler.

> It's like Rust, but without the "young language" excuse.

Howso? Stable Rust has been nothing but 100% solid for the past 1+ year I've worked with it.

Tools depend on Rust nightly. My points are more about the respective ecosystems than the core languages. For instance, getting up and running with RLS is a real hassle (in my experience, but I'm sure it's improving).

RLS is a pretty new thing and is very much a nice to have but not in any way required. I haven't used it until about a month ago. Racer worked just fine on Stable.

I dunno, maybe you had a bad experience but considering how well Cargo and the stable compiler work I don't thing it's fair to categorize Rust as never working correctly.

There's a path to RLS, and eventually Clippy, both working on stable, and to be distributed via rustup. The work isn't quite done yet. I'm guessing ~3 releases for RLS, counting the release next week.

I've been working on a side project in OCaml and I can totally relate. I'm an OCaml old timer and I find amazing the amount of development that has happened recently. There's a lot of ongoing development in the libs and the surrounding tools (more so than in the language). I've spent a lot of time just to set up my environment and I had to pin several packages to their development version to make things work (jbuilder, merlin, ppx...). Moreover, a lot of these tools lack proper documentation, and it's difficult to get answers to your questions since it's a very small community.

I'm also an OCaml old timer and I think I can relate too. I believe the recent tooling changes are going in the right direction and will eventually fix several of these problems, for example:

There's a push to remove "optional dependencies" which are the reason why opam dependencies rebuild again and again: http://rgrinberg.com/posts/optional-dependencies-considered-... For example in the Mirage project we've been working on this https://discuss.ocaml.org/t/ann-major-releases-of-cohttp-con... but it has caused some breakage here and there.

jbuilder (from Jane Street) is excellent: expressive, easy to understand, builds packages extremely quickly, is actively developed, has minimal dependencies and a lovely manual http://jbuilder.readthedocs.io/en/latest/ It takes care of generating boilerplate for other tools like merlin (which to be honest I never got around to manually configuring). There's also work to integrate it with utop https://github.com/janestreet/jbuilder/issues/114

jbuilder also supports building multiple libraries in one big source tree, so we could switch to a package lockfile model: the author uses opam to create a solution to the package constraints and checks in the specific versions known to work, the build clones the dependency sources and jbuilder builds it all simultaneously. I'm keen to try this on one of my larger projects so that "git clone; make" just works, irrespective of where the host OCaml comes from.

PPX syntax extensions depend on specific compiler versions, so when (for example) homebrew updates to OCaml 4.05 you might find that extensions you need have not been ported yet. ocaml-migrate-parsetree aims to fix this problem http://ocamllabs.io/projects/2017/02/15/ocaml-migrate-parset...

There's obviously still plenty of work to do, but I think things are improving!

Yes, I agree that things are going in the right direction.

But a lot of things I'm trying to use aren't quite there yet. You mention jbuilder and the generated .merlin... it just doesn't work with current opam packages (at least not with ppx - I'm not doing anything fancy, just basic project with core). To fix this, I had to learn about opam pinning features, and then I had to carefully choose the jbuilder commit that works (the one after the bug has been fix, but before it breaks the compilation of bin_prot that I also use) and so on... As for Merlin, it's great, but the documentation is minimal. When it doesn't work as expected, it's hard to find where to look.

Core and Async are great, but besides 'Real World OCaml' that is a bit outdated and insufficient, there is little documentation and not much help on Stack Overflow.

That being said, I'm not complaining and I'm grateful to the guys developing these tools. But I think newcomers should expect some difficulties if they want to do anything serious using these most recent tools.

> the recommended tools never seem to work together on anything but the latest version

Whenever a package is added to the repository, the CI tests (the latest compatible version of) every package that depends on it to check everything still works. However, non-current packages may break if they're missing upper bounds (it doesn't check all previous releases).

However, since opam-repository is just a Git repo, you can clone a known snapshot of it at some point in time and keep using that. That allows you to continue using old versions of packages without the risk of new software causing unwanted upgrades.

> My impression is that INRIA is too eager to add features and tweak the language.

That's strange. I've always had the opposite impression - that they maintain compatibility at all costs, including leaving sub-optimal APIs in the standard library.

> Next, everything builds so slowly, and just trying to set up Core, utop, and ocp_indent is a trial in patience, watching the same dep build again and again

The Core alternative standard library is pretty huge, indeed (I don't use it). I just tried installing all the tools you mention in a fresh container:

$ time docker run ocaml/opam:debian-9_ocaml-4.05.0 opam install core utop ocp-indent

6:03.75elapsed

So, 6 min to set up a dev environment with those tools. That installed 67 packages, so compilation took about 5 seconds/package on average. I'm not sure why it would build the same dep twice - I haven't seen it do that.

"> My impression is that INRIA is too eager to add features and tweak the language.

"That's strange. I've always had the opposite impression - that they maintain compatibility at all costs, including leaving sub-optimal APIs in the standard library."

When I started using OCaml, many standard library functions weren't tail recursive---you couldn't get the length of a list with more than ~10,000 elements, for example. The library definitely seems like an afterthought compared with the language. (And that would be why there are so many of them.)

Why would you hold 10,000 elements in a linked list?

I couldn't hold them in my cupped palms.

That's just - for example - every point in 100×100 R^2 cartesian grid. 10k elements is not by any measure a 'large number of elements'.

Just pick your algorithmic use case for a good excuse to use list and not an array from here:

http://bigocheatsheet.com

When you first write design your program, you might indeed use a different data structure than a linked list when you anticipate 10k+ elements.

But often programs are used long after they are designed, and it is great if they can degrade gracefully as you move outside their original design parameters.

> However, non-current packages may break if they're missing upper bounds....

Out of curiosity, how feasible is it for opam packages to use lockfiles like npm is nowadays? Then packages which depend on some other package will continue to build against the exact same version they always did, until and unless they are explicitly upgraded to the latest version of that dependency.

> I'm not sure why it would build the same dep twice - I haven't seen it do that.

Maybe https://discuss.ocaml.org/t/why-does-opam-recompile-so-much/... provides a clue to that.

I largely agree with you on OCaml, which was one of my favorite languages for quite a while and still is somewhere near the top. Last I checked, there were 3 (?) standard libraries, counting Core and the OCaml release.

But,

"I'd prefer OCaml to Haskell, I find it more practical, but I feel much better depending on Haskell-based software, which generally "just works.""

I take it you haven't been bitten by cabal? It's a nightmare every time I touch it.

On the other hand, I've been using stack (https://docs.haskellstack.org/en/stable/README/) with hakyll, which seems to improve the situation dramatically. It's just that first build for a new project that's very slow.

I think a first build with cabal is also very slow.

Haskell could solve that with binary distributions - but that requires more resources than are devoted to it, it seems.

`cabal new-build` basically fixes the problems you have had with Cabal, and the development experience with Haskell under Nix(OS) is pretty great too.

OCaml is great in itself, but in practical terms, it is only great for limited dependency projects (this however doesn't mean limited complexity--a Perl 6 implementation called Pugs was once written in OCaml. FFTW's code generator is also written in OCaml).

In many projects where one has to "stand on the shoulders of giants", OCaml has a limited ecosystem to draw from.

A practical compromise is F#, which is an ML language for the .NET platform. And even with Microsoft's heft behind it and a rich .NET ecosystem, F# is still a niche language used in finance and a few other specific domains.

A functional language "taking over the world" is a tough proposition. That usually requires a strong use-case (like scientific computing--and now data science--for Python) and fungibility of expertise, which in turn calls for a language with a very low barrier to entry.

Minor correction: `pugs` was written in Haskell, not OCaml.

https://hackage.haskell.org/package/Pugs

You are right. Thanks for the correction.

You are right about the difficulty of a functional _language_ taking over the world anytime soon. But as a consolation prize we are seeing functional features making it into more and more mainstream languages.

Even people using eg C++ no longer look at you too funny if you explain that you prefer all your variables to be 'const'.

F# is even less used than OCaml and Microsoft lost interest in it.

If you are into functional programming, you should rather choose Scala. Huge ecosystem, largely used in production. Compatibility with java mean you can have all the library you want. A lot of people love to trash sbt it's build system, but for me it always work as expected. And other tooling are just awesome (you even have IDE).

> Microsoft lost interest in it.

Do you have any sources for this?

F# clearly lags behind C# in editor attention and integration into the latest and greatest GUI techs from Microsoft...

For many on the MS treadmill this is seen as a negative, as you can't always get visual studio RCs and be months ahead of the competition on the next version of blend/WPF/silverlight/whatever.

For others, the community driven aspect and lack of obsessions with technical fashion in the MS product line (with the track record they have...), is seen as a _major_ feature.

F# has a much more active open source community and presence than C#, most of the devs are actively cross-platform in a way C# still struggles with, and it has a better .net stack than C# aimed at command line efficiency and relatively stable approaches to common problems.

F# is still a first class language from MS, and would be quite OK on its own these days. Regardless, there is no chance MS will "lose interest" in F# given the impact on data science, machine learning, cloud computing, parallel computing, and stream-processing F# has. MS invested heavily in filling out their language portfolio to avoid being excluded from the big servers and big clusters. Time has shown those concerns to be growing, not shrinking :)

According to members of the .net team, one should embrace f#: https://blogs.msdn.microsoft.com/dotnet/2017/05/31/why-you-s...

Have you seen https://github.com/BuckleScript/bucklescript ?

It's outputted js is fantastic.

OCaml even does relatively well compared to Haskell: OCaml is a much simpler language with more predictable resource usage (space and time), but still gives a sizable fraction of Haskell's power.

If you like Reason, you might also be interested in BuckleScript.

This is exactly my experience. In fact, I moved from O'Caml to Haskell, but I still miss some things from O'Caml. (The most important of which is a good module language... but I think the Haskell world is getting that, eventually, via Backpack.)

On a micro-level, or-Patterns are also pretty nifty. There's nothing technically keeping Haskell from getting them, it's just a problem of how to fit them into Haskell's already crowded syntax.

> if it had better tooling and better marketing

It would known as F# :)

Project tooling and standard library are the two things keeping me from using it. If they built Cargo for OCaml and improved the standard library, I think people would flock to it. Although I never seem to quite get used to the syntax...

Maybe you'll have better luck with ReasonML syntax?

Not the parent, but ReasonML's syntax is actually not great. They fixed a bunch of pain points with OCaml but then added their own idiosyncrasies to make it look more like JS

They actually thought the JavaScript-like syntax through very carefully, trying to balance several factors (like JS appeal, future-proofing, simplifying, etc.). See https://www.reddit.com/r/reasonml/comments/6v2olv/new_syntax... for a quite informative summary of the changes.

Yeah, I came to OCaml by way of reason, and I preferred reason's syntax, but the tooling and documentation were still very unpolished. The syntax niceness didn't do enough to justify sticking with it. I really like Rust's syntax and tooling (best of any functional/ML IMHO), I just don't want to spend all my time thinking through moves and borrows and lifetimes.

Tooling is getting better! Reason/BuckleScript recently shipped Elm/Rust-like errors: https://reasonml.github.io/community/blog/#way-way-waaaay-ni...

Docs are more of a WIP right now, but I'm confident they'll get a handle on them: https://reasonml.github.io/api/index.html

I'm happy to hear it. My grievances were with project tooling (and documentation therefore). It was hard to figure out how to compile a multifile project, add a dependency, etc. Some of the problem was that there was a lack of documentation about how to use the OCaml tools to build reason projects, and the other part of the problem is that OCaml project management leaves a lot to be desired.

I'm very happy to see the standard library documentation is available for Reason, that alone tells me the Reason community cares about improving the experience for new developers (which is not the impression I get from the OCaml community).

  I feel like OCaml is one of the programming world's best kept secret

A little bit exagerated... In France we learn this language in a lot of post secondary universities / engineering schools

Do many French businesses use it?

Not sure :/ : startups seem to follow the SV technology hypes just like everyone else and well established business like Airbus, Thales etc. use languages like Ada or Java

Threading is the one thing that's missing for me, in OCaml; they may have added it, but it wasn't there last I checked.

You have light threads (Lwt or Async) that are sufficient for most purpose.

SML/CML might interest you.

http://cml.cs.uchicago.edu/ -- the CML idea

Three SML implementations with CML support

http://www.polyml.org/

http://www.mlton.org/

http://www.smlnj.org/

Poly/ML is the only "mainstream" implementation (and the only one on your list) with OS thread support. The rest are green threads. Various research offshoots from MLton have existed with full support for OS thread but none are still around and they haven't made it upstream. For the most part, the Standard ML native thread situation is not much better than OCaml's.

You're forgetting SML# which uses MassiveThreads library and despite the name isn't for .Net.

http://www.pllab.riec.tohoku.ac.jp/smlsharp/

https://github.com/smlsharp/smlsharp

https://github.com/massivethreads/massivethreads

It was conceived at Tohoku University for use in Japan's high performance computing projects. SML# uses LLVM as a backend, has a nice FFI and EDSLs for SQL and JSON and a non-moving GC. All stemming from the use case it's designed for.

Agreed. I'm always looking for excuses to use it or F# at work but rarely come up.

Reply on news.ycombinator.com