Live data from Hacker News

Why I love OCaml (2023)

mccd.space

11–20 of 313 posts

Re: Why I love OCaml (2023)

#12
post #4
post #2

OCaml has been one of those "almost there" languages since at least 2002. Most of the worthwhile ideas in OCaml will be absorbed into more popular languages by the time existing friction is sorted out. :/

Almost there, but in the meantime supporting a casual squillion dollars of trades at JS

Unless you're building another JS, it'd be nice if there were other companies so heavily invested in it. There's a lot out there beyond compiler prototypes and high speed financial trades, but there's not enough talk of people using ocaml for those things.

Re: Why I love OCaml (2023)

#13
OCaml’s REPL is lovely, but I found myself having some friction with initial startup. The build/package system was pretty convoluted, and I ended up choosing JS’s Core stdlib for my needs (a simple compiler). With the new multicore release it’d be cool to see OCaml in some more practical projects!

Re: Why I love OCaml (2023)

#14
post #9

> It is an old language, and there are a few features that could probably be left out like the OOP-related features, and some libraries in the ecosystem over-complicate things like in Haskell. If one can stand a language that is just a little bit older, there is always Standard ML. It is like OCaml, but perfect!

I love standard ml (I'm currently writing a compiler for it), but it's far from perfect. There are weird special cases in the language definition like the ad-hoc overloading between int and real, or the annoying value restriction. Records also feel half-baked, with no support for updating fields or for partially-specified records where the full set of fields is not known

I've written a fair amount of SML (though years ago) and I can't remember the value restriction ever being an issue.

I certainly agree that SML isn't really a production language, though.

Re: Why I love OCaml (2023)

#15
post #2

OCaml has been one of those "almost there" languages since at least 2002. Most of the worthwhile ideas in OCaml will be absorbed into more popular languages by the time existing friction is sorted out. :/

Perhaps OCaml is the Velvet Underground of languages. Only a few thousand people learned OCaml but every one made a programming language[1] [1]: https://quoteinvestigator.com/2016/03/01/velvet/

That would be Elm :)

Re: Why I love OCaml (2023)

#16
There's some other stuff, but I personally believe if the tooling was closer to Rust/Go than C, it would be a lot, lot more popular.

Nobody wants to effectively learn a lisp to configure a build system.

Re: Why I love OCaml (2023)

#17
Yes, in every ML/OCaml tutorial, sooner or later the words object, class, and type inference appear and that’s when a once–minimalist language turns into an academic Frankenstein.

Re: Why I love OCaml (2023)

#18
post #2

OCaml has been one of those "almost there" languages since at least 2002. Most of the worthwhile ideas in OCaml will be absorbed into more popular languages by the time existing friction is sorted out. :/

What is this alleged friction? Because plenty of people have been shipping great projects in Ocaml since it was released so it doesn’t seem to be much of an issue to many. I doubt Ocaml will be surpassed soon. They just added an effect system to the multicore rewrite so all things being considered, they seem to be pulling even more ahead.

For me the issue is ecosystem. The foundations are great but I need more useful and well supported packages.

For example, there is no OAuth2 client library for OCaml [1]

[1] https://ocaml.org/docs/is-ocaml-web-yet

Re: Why I love OCaml (2023)

#19
post #9

> It is an old language, and there are a few features that could probably be left out like the OOP-related features, and some libraries in the ecosystem over-complicate things like in Haskell. If one can stand a language that is just a little bit older, there is always Standard ML. It is like OCaml, but perfect!

I love standard ml (I'm currently writing a compiler for it), but it's far from perfect. There are weird special cases in the language definition like the ad-hoc overloading between int and real, or the annoying value restriction. Records also feel half-baked, with no support for updating fields or for partially-specified records where the full set of fields is not known

> with no support for updating fields

While it's not yet standard nearly all Standard ML implementations support what has become known as "Successor ML" [0]. A large subset of Successor ML is common to SML/NJ, MLton, Poly/ML, MLKit and other implementations.

That includes record update syntax, binary literals, and more expressive patterns among other deficiencies in Standard ML.

For me the two big remaining issues are:

1) There's only limited Unicode support in both the core language and the standard library. This is a big issue for many real-world programs including these days the compilers for which SML is otherwise a wonderful language.

2) The module system is a "shadow language" [0] which mirrors parts of SML but which has less expressiveness where modules cannot be treated as first-class values in the program. Also if you define infix operators in a module their fixity isn't exported along with the function type. (Little annoyance that gets me every time I am inclined to write Haskell-style code with lots of operators. Though maybe that's just another hint from the universe that I shouldn't write code like that.) Of course, the fix to that would be a fundamentally different language; not a revised SML.

[0] http://mlton.org/SuccessorML

[1] https://gbracha.blogspot.com/2014/09/a-domain-of-shadows.htm...

Post reply on HN