Why I love OCaml (2023)

https://mccd.space/posts/ocaml-the-worlds-best/

by art-w • 9 months ago

391 293 9 months ago

dmpk2k5• 9 months ago

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. :/

StopDisinfo9108• 9 months ago

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.

dmpk2k5• 9 months ago

Alleged? Come now.

Beginners face the following problems: there's multiple standard libraries, many documents are barely more than type signatures, and data structures aren't printable by default. Experts also face the problem of a very tiny library ecosystem, and tooling that's often a decade behind more mainstream languages (proper gdb support when?). OCaml added multicore support recently, but now there is the whole Eio/Lwt/Async thing.

I used to be a language nerd long ago. Many a fine hour spent on LtU. But ultimately, the ecosystem's size dwarfs the importance of the language itself. I'm sympathetic, since I'm a Common Lisp man, but I don't kid myself either: Common Lisp isn't (e.g.) Rust. I like hacking with a relic of the past, and that's okay too.

greener_grass5• 9 months ago

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

creata5• 9 months ago

Because plenty of people have been shipping great projects in Ocaml

What applications are written in OCaml? All I can think of (which says more about me than it does about OCaml) is the original Rust compiler.

Even Haskell has Pandoc and Xmonad.

jddj• 9 months ago

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

zdragnar2• 9 months ago

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.

ng122• 9 months ago

Yes and they had to basically build their own version of the compiler to keep everything from falling over (https://oxcaml.org/).

procaryote• 9 months ago

Yeah, but when these things happen I ask myself, is Jane Street successful because of ocaml, or did they just happen to pick ocaml and then make it work?

There might be some power in attracting all the people who happen to love ocaml, if there are enough of competent people to staff your company, but that's more a case of cornering a small niche than picking on technical merits

hardwaregeek• 9 months ago

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/

greener_grass5• 9 months ago

That would be Elm :)

specialgoodness• 9 months ago

Xavier Leroy as Lou Reed... :-) Don't forget the amazing theorem provers too, like Imandra ( https://www.imandra.ai/core ), HOL-Light ( https://hol-light.github.io/ ) and Rocq ( https://rocq-prover.org/ ), ... !

pohl• 9 months ago

To this day, whenever I see Machine Learning abbreviated, my heart skips a beat, then I become crestfallen as I realize I'm not about to read something about Meta Language.

PaulHoule• 9 months ago

ML blew my mind back in the late 1980s when I got to use it on a 80286 machine for the first time!

kjmh• 9 months ago

ML refers to Meta Language and LLM refers to Languages and Logic Montreal [0], a PL theory group. [0] https://llm.uqam.ca

embedding-shape2• 9 months ago

PL theory group

I know there are great many Polish people in the world, but why it matters so much in this case? They could have been any nationality, even French!

seanw444• 9 months ago

I'd rather have that issue than seeing "AI" plastered all over the place. I'm of the opinion AI should be reserved for artificial general intelligence. These things aren't intelligent yet. They're just em-bloat-ified traditional machine learning techniques. Not that they're useless. I just hate the terminology.

If people start using the term AI, we better be living in I, Robot. Not whatever the hell this is.

Tangential rant. Sorry.

crdrost3• 9 months ago

We lost this fight at least by 1994 when Sun acquired “Thinking Machines,” which to its credit was bankrupting itself by making highly parallel supercomputers, at least. Now of course there is a new AI company of the same name. If the wrestling world echoes the computing world, one can only wonder what in 5-10 years will be the equivalent of Undertaker throwing Mankind off of Hell In A Cell to plummet 16 feet down through an announcer’s table...

timeon2• 9 months ago

I also think AK would fit better.

afiori• 9 months ago

I believe that current publicly available Ais are more intelligent than a non trivial fraction of adults.

jrh3• 9 months ago

Thanks for posting about ML! I made a post similar to yours a couple of years ago and got downvoted, lol.

wslh• 9 months ago

Offtopic HTML issue to the author: there is a trailing </head> tag at the end of your generated HTML after the </body> (instead of </html>).

yawaramin• 9 months ago

I don't see it...the end of the document is:

        </div>
      </body>
    </html>

mccd2• 9 months ago

I updated it just now :).

mccd2• 9 months ago

Fixed it, thanks for pointing it out :)

fmbb• 9 months ago

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!

assbuttbuttass• 9 months ago

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

mkehrt• 9 months ago

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.

retrac• 9 months ago

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...

cmrdporcupine2• 9 months ago

I far preferred Standard ML when I learned both back in the day, but it was OCaml that won the headspace it seemed.

Ironically probably because it had the "O"bjects in it, "which was the style of the time"... something that has since dropped off the trendiness charts.

abathologist5• 9 months ago

I love SML, and came to OCaml a bit begrudgingly initially just for a larger ecosystem. But, I think the object system gets a unjustly bad wrap. The OCaml object system is dope. It is rarely needed and not the best feature for most use cases, but when you want structurally-typed records, or need open recursion (or need to represent JS objects for the amazing `Js_of_ocaml`), they are a perfect fit.

DeathArrow4• 9 months ago

For something a bit more modern but still related to OCaml, one can try F#.

greener_grass5• 9 months ago

F# is a practical choice but the language features are quite far behind OCaml now.

{Ecosystem, Functors} - choose 1

runevault2• 9 months ago

From an outsider's perspective, it feels like Ocaml has more active development of features, between the new effects system they added in 5 and all the work Janestreet is doing to let Ocaml developers have more control over performance.

F# is not stagnant thankfully, it gets updates with each new version of dotnet (though I haven't checked what is coming with dotnet 10), but I don't recall anything on the level of the above Ocaml changes in years.

phplovesong7• 9 months ago

F# also has a real slow compiler. Last time hello world took a few secs on brand new mac.

Bootvis• 9 months ago

What about a strict subset of C#. The use case for F# seems to be shrinking because MS is putting all its energy in language.

sanufar• 9 months ago

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!

paulsmith• 9 months ago

As an OCaml-curious, is this the community recommendation, to choose the Jane Street stdlib if you’re just getting started?

tlavoie• 9 months ago

It's probably the path of least resistance if following the Real World OCaml book (https://dev.realworldocaml.org/), which is quite excellent.

debugnik9• 9 months ago

Many learning materials will push you that way, but the vast majority of FOSS packages don't use it.

There's nothing inherently wrong with using Jane Street's stdlibs if you miss the goodies they provide, but be aware the API suffers breaking changes from time to time and they support less targets than regular OCaml. I personally stopped using them, and use a few libraries from dbunzli and c-cube instead to fill the gaps.

pkilgore• 9 months ago

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.

phplovesong7• 9 months ago

Dune is quite good these days. The lisp part is really just sexps (not a full languge). But i kind of get your point.

_gmkt• 9 months ago

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.

rwmj• 9 months ago

I don't think objects and classes are used much by OCaml programmers (not by me anyway). Type inference is a rather fundamental feature, and fairly easy to understand.

giovannibonetti2• 9 months ago

Why does type inference contribute to that issue?

Barrin92• 9 months ago

It's not a minimalist language, you know what the "O" in Ocaml stands for right? It's a multi-paradigm language that explicitly accommodates more styles of programming than Caml, it's why it exists.

pulkas• 9 months ago

darklang team loved ocaml too. in the end they ended up using f#.

karmakaze2• 9 months ago

I've dabbled in F# (and aside from the rough setup with little coherent information at the time) had a pretty good time. Actor-based concurrency was easy to grok. The one gotcha was whenever those mutable Arrays entered the picture.

I'd like to hear some practical reasons for preferring OCaml over F#. [Hoping I don't get a lot about MS & .NET which are valid concerns but not what I'm curious about.] I want to know more about day to day usage pros/cons.

ernst_klim2• 9 months ago

I'd like to hear some practical reasons for preferring OCaml over F#

Bigger native ecosystem. C#/.net integration is a double edged sword: a lot of libraries, but the libraries are not written in canonical F#.

A lot of language features F# misses, like effect handlers, modules, GADTs etc.

karmakaze2• 9 months ago

I did get some sense of that where F# sort of (actually is) 2nd class to C# which is slowly gaining some F# features, but F# itself isn't well promoted/supported.

As for missing language features, they can also be a double-edged sword. I slid down that slippery slope in an earlier venture with Scala. (IIRC mostly implicits and compile times).

Nelkins• 9 months ago

There are libraries that simulate a lot of these things (e.g. https://github.com/G-Research/TypeEquality for GADTs). You're absolutely right that it's not as first class as in OCaml, but the tools are there if you want them.

debugnik9• 9 months ago

It's a matter of trends: F# is losing compatibility with the overall CLR ecosystem due to the churn in C# features with poor F# interop, but F# has already mingled its design with the CLR's, too much to live on its own as a native language. Plus its compiler is slow and the tooling is getting increasingly unstable.

Meanwhile, OCaml got rid of its global lock, got a really fast-compiling native toolchain with stable and improving editor tooling, and has a cleaner language design with some really powerful features unavailable to F#, like modules/functors, GADTs, effects or preprocessors. It somehow got immutable arrays before F#!

F# still has an edge on some domains due to having unboxed types, SIMD, better Windows support and the CLR's overall performance. But the first two are already in the OxCaml fork and will hopefully get upstreamed in the following years, and the third is improving already, now that the opam package manager supports Windows.

neonsunset2• 9 months ago

has an edge on some domains due to having unboxed types

If a language makes "unboxed types" a feature, a specific distinction, and has to sell "removing global lock" as something that is a massive breakthrough and not table stakes from 1.0, it can't possibly be compared to F# in favourable light.

debois• 9 months ago

We’ve used f# professionally for the computations-intensive parts of our product for a couple of years. Here’s what comes to mind:

1. Interop with C# is great, but interop for C# clients using an F# library is terrible. C# wants more explicit types, which can be quite hard for the F# authors to write, and downright impossible for C# programmers to figure out. You end up maintaining a C#-shell for your F# program, and sooner or later you find yourself doing “just a tiny feature” in the C# shell to avoid the hassle. Now you have a weird hybrid code base.

2. Dotnet ecosystem is comprehensive, you’ve got state-of-the web app frameworks, ORMs, what have you. But is all OOP, state abounds, referential equality is the norm. If you want to write Ocaml/F#, you don’t want to think like that. (And once you’ve used discriminated unions, C# error-handling seems like it belongs in the 1980’ies.)

3. The Microsoft toolchain is cool and smooth when it works, very hard to wrangle when it doesn’t. Seemingly simple things, like copying static files to output folders, require semi-archaic invocations in XML file. It’s about mindset: if development is clicking things in a GUI for you, Visual Studio is great (until it stubbornly refuses to do something) ; if you want more Unix/CLI approach, it can be done, and vscode, will sort of help you, but it’s awkward.

4. Compile-times used to be great, but are deteriorating for us. (This is both F# and C#.)

5. Perf was never a problem.

6. Light syntax (indentation defines block structure) is very nice until it isn’t; then you spend 45 minutes how to indent record updates. (Incidentally, “nice-until-it-isn’t” is a good headline for the whole dotnet ecosystem.

7. Testing is quite doable with dotnet frameworks, but awkward. Moreover. you’ll want something like quickcheck and maybe fuzzing; they exist, but again, awkward.

We’ve been looking at ocaml recently, and I don’t buy the framework/ecosystem argument. On the contrary, all the important stuff is there, and seems sometimes easier to use. Having written some experimental code in Ocaml, I think language ergonomics are better. It sort of makes sense: the Ocaml guys have had 35 years or so to make the language /nice/. I think they succeeded, at least writing feels, somehow, much more natural and much less inhibited than writing F#.

int_19h9• 9 months ago

OCaml is a much more powerful language. Take a look at functors, for example, or modules as first-class values, or GADTs, or its object system that can do type inference from use:

  # let foo x = x#frob;;
  val foo : < frob : 'a; .. > -> 'a = <fun>

F# is often called "OCaml for .NET", but it is a misrepresentation. It is an ML-family language for .NET, but aside from that ML core they don't have much in common.

Whether those features are more valuable to you than the ability to tap into .NET libraries depends largely on what you're doing.

p0nce• 9 months ago

Well I need both float and double, so cannot even start using it.

ModernMech2• 9 months ago

why isn’t OCaml more popular?

OCaml did become popular, but via Rust, which took the best parts of OCaml and made the language more imperative feeling. That's what OCaml was missing!

StopDisinfo9108• 9 months ago

Rust is very different from Ocaml. Rust is a low level language with a borrow checkers, traits, no first class module system, no GADT, no effects.

The similarities are fairly superficial actually. It’s just that Rust is less behind the PL forefront that people are used to and has old features which look impressive when you discover them like variants.

There is little overlap between what you would sanely use Rust for and what you would use Ocaml for. It’s just that weirdly people use Rust for things it’s not really suited for.

reddit_clone• 9 months ago

Ocaml can be as imperative as you need it to be. Or as functional.

It has no dogmatic inclination towards functional. It has a very pragmatic approach to mutation.

talideon2• 9 months ago

True, but writing imperative code in OCaml feels quite right. Maybe it's just me, but it always feels significantly clunkier than the functional equivalent. I've had things I've been implementing and though "this works be easier to express imperatively", and almost invariably I've gone and rewritten the code to be functional because of how ungainly the imperative implementation ended up being. It feels a bit too much like somebody embedded a subset of Rexx or Pascal awkwardly into an otherwise perfectly reasonable functional language

abathologist5• 9 months ago

As someone who has worked professionally in both, programming in rust does not feel much like programming in OCaml. Working with traits in an imperative manual memory managed language is really different than working with proper modules in a mixed paradigm language with an awesome GC.

int_19h9• 9 months ago

Aside from ADTs, what else did Rust take from OCaml?

ModernMech2• 9 months ago

Expression-based, immutable by default, pattern matching, static typing, and result / option types are the mix of features that make Rust what it is at its core, and each of those you'll find in OCaml. There's a couple others but that's the heart of it.

I'm not saying that Rust feels like Ocaml as some are interpreting, I said Rust is more imperative feeling, they're not the same. The reason Rust has had success bringing these features to the mainstream where Ocaml has not, I believe, is because Rust does not describe itself as a functional language, where as Ocaml does, right up front. Therefore, despite Rust having a reputation for being difficult, new learners are less intimidated by it than something calling itself "functional". I see it all the time. By the time they learn Rust, they are ready to take on a language like Ocaml, because they've already learned some of the best parts of that language via Rust.

Note my comment about their similarities is not at the level of borrow checkers and garbage collectors.

pasxizeis• 9 months ago

As a Rust newbie and seasoned Go dev, I'm pretty interested to knownwhere would people experienced in both OCaml and Haskell, would put it in the spectrum.

hollerith2• 9 months ago

What does "it" refer to? Ocaml?

7thaccount5• 9 months ago

What spectrum? Language practicality? Popularity?

OCaml has some high profile use at Jane Street which is a major fintech firm. Haskell is more research oriented. Both are cool, but wouldn't be my choice for most uses.

bojo• 9 months ago

My team still has 8 year old Haskell systems in production. We pivoted away from the language a few years ago, which I discuss here a bit: https://news.ycombinator.com/item?id=37746386

I personally love ML languages and would be happy to keep developing in them, but the ecosystem support can be a bit of a hassle if you aren't willing to invest in writing and maintaining libraries yourself.

jlouis5• 9 months ago

I don't think it's a spectrum.

Languages have features/constructs. It's better to look at what those are. And far more importantly: how they interact.

Take something like subtyping for instance. What makes this hard to implement is that it interacts with everything else in your language: polymorphism, GADTs, ...

Or take something like Garbage Collection. It's presence/absence has a large say in everything done in said language. Rust is uniquely not GC'ed, but Go, OCaml and Haskell all are. That by itself creates some interesting behavior. If we hand something to a process and get something back, we don't care if the thing we handed got changed or not if we have a GC. But in Rust, we do. We can avoid allocations and keep references if the process didn't change the thing after all. This permeates all of the language.

efficax• 9 months ago

OCaml is fantastic, but I avoided it and went with Rust for many projects because it had no multicore story and no green threads for a very long time. But it has that now, and I wish I could go back and start everything over in OCaml.

darksaints• 9 months ago

I've also felt very similar, and adopted Rust for those reasons. Even though I'd still love to have a garbage collected, AOT compiled ML-variant, using OCaml still feels like a step backwards now. OCaml's module system and generics feel clumsy and unintuitive now that I've used Rust's Trait system.

fer• 9 months ago

One of the best P2P clients ever created is written in OCaml: https://github.com/ygrek/mldonkey

I'm still surprised it can do so many things so well, so fast.

japhib• 9 months ago

Elixir is the closest thing to OCaml that has a chance at semi-mainstream usage IMO.

It has basically all of the stuff about functional programming that makes it easier to reason about your code & get work done - immutability, pattern matching, actors, etc. But without monads or a complicated type system that would give it a higher barrier to entry. And of course it's built on top of the Erlang BEAM runtime, which has a great track record as a foundation for backend systems. It doesn't have static typing, although the type system is a lot stronger than most other dynamic languages like JS or Python, and the language devs are currently adding gradual type checking into the compiler.

DrewADesign4• 9 months ago

I think it’s odd that elixir doesn’t get more love. It ticks a lot of boxes that folks here get excited about, has a great ecosystem and tooling, BEAM is great, and it’s much more syntactically familiar than erlang to my eye. I know of a couple companies aside from the perennial goto examples that built sizable saas products backed by it.

skybrian• 9 months ago

What does deployment look like? Can you get a static binary easily like with Go?

pluralmonad2• 9 months ago

Elixir is good at managing complexity. I love flattening hierarchy and dealing with edge cases right in function definitions using pattern matching. Every other language without it just feels crippled after getting used to the feature.

cardanome• 9 months ago

The backend work I do is just super boring.

I always wanted to learn Elixir but never had a project where it could show it strengths. Good old PHP works perfectly fine.

Also corporations like their devs to be easily replaceable which is easier with more mainstream languages, so it is always hard for "newer" languages to gain traction. That said I am totally rooting for Elixir.

lenkite2• 9 months ago

The BEAM VM executing bytecode is slower than a compiled binary. Sure, it is great when compared to Python and other interpreted languages. Not so much when you need fast processing and raw CPU performance. It also loses out to the JVM in performance, but wins in memory consumption.

phplovesong7• 9 months ago

Gleam also. But i cant justify a non compiled language in many things i do.

cultofmetatron• 9 months ago

gleam is compiled... to erlang bytecode

vvpan2• 9 months ago

If it's functional (recursion vs imperative loops) most people/organizations will not use it. At this point that is just the reality.

zaphar• 9 months ago

Having loops is not the defining feature that separates functional from imperative. Where did this idea come from? I'm suddenly seeing it in a lot of places.

bsder2• 9 months ago

I really wish people would quit pushing "functional". People equate that with "My programming is now always a recursive logic puzzle."

Talk about "immutable by default". Talk about "strong typing". Talk about "encapsulating side effects". Talk about "race free programming".

Those are the things that programmers currently care about. A lot of current Rust programmers are people who came there almost exclusively for "strong typing".

cyberpunk• 9 months ago

immutability?

    Interactive Elixir (1.19.0) - press Ctrl+C to exit (type h() ENTER for help)
    iex(1)> x = 1
    1
    iex(2)> x = 2
    2
    iex(3)>

What's immutable about elixir? It's one of the things which I MISS from Erlang -- immutability.

nitros• 9 months ago

This is like saying Haskell doesn't have immutability because it has the state monad, or that rust doesn't because you can shadow with let.

Data is immutable and thats much more important than whether local variables can be modified imo.

debugnik9• 9 months ago

Shadowing is not mutability. The former isn't affected by control flow nor does it affect closures.

int_19h9• 9 months ago

What you wrote is roughly equivalent to this in C:

  {
    const int x = 1;
    {
      const int x = 2;
    }
  }

which is to say, there are two different `x` in there, both immutable, one shadowing the other. You can observe this if you capture the one that is shadowed in a closure:

  iex(1)> x = 1
  1
  iex(2)> f = fn () -> x end
  #Function<43.113135111/0 in :erl_eval.expr/6>
  iex(3)> x = 2
  2
  iex(4)> f.()
  1

BenGosub2• 9 months ago

Writing OCaml and writing Elixir code is much different for me. OCaml requires more braincells, while Elixir is more flexible.

BenGosub2• 9 months ago

I think that a better question is why F# isn't a more popular language, since it's much closer to OCaml, than Elixir and you can use the whole Dotnet ecosystem in F#, which is one of the weakest points of OCaml (no libraries).

schonfinkel• 9 months ago

The answer is (most likely) Microsoft, I kid you not. I've worked with F# professionally for many years is its incredible how they are literally sitting atop a gold mine that is the output of Microsoft research and do basically nothing with it. Even though it's sold as an ecosystem, .NET revolves around C# and its related tooling.

"Type Providers" are an example of such negligence btw, it's something from the early 2010's that never got popular even though some of its ideas (Typed SQL that can generate compile-time errors) are getting traction now in other ecosystems (like Rust's SQLx).

My team used SQL Providers in a actual production system, combined with Fable (to leverage F# on the front end) and people always commented how our demos had literally 0 bugs, maybe it was too productive for our own good.

belter• 9 months ago

BEAM performance model trades throughput for isolation, which hurts CPU-bound tasks, and ironically, whenever you need speed, you end up using NIFs that break BEAM safety guarantees, and reintroduce the exact fragility Elixir was supposed to avoid.

In 2025, Elixir is a beautiful system for a niche that infrastructure has already abstracted away.

jimbokun2• 9 months ago

In 2025, Elixir is a beautiful system for a niche that infrastructure has already abstracted away.

Do you mean Kubernetes?

My mental model of Erlang and Elixir is programming languages where the qualities of k8s are pushed into the language itself. On the one hand this restricts you to those two languages (or other ports to BEAM), on the other hand it allows you to get the kinds of fall over, scaling, and robustness of k8s at a much more responsive and granular level.

creata5• 9 months ago

whenever you need speed, you end up using NIFs that break BEAM safety guarantees, and reintroduce the exact fragility Elixir was supposed to avoid.

That's like complaining that unsafe{} breaks Rust's safety guarantees. It's true in some sense, but the breakage is in a smaller and more easily tested place.

jlouis5• 9 months ago

It's not isolation which hampers throughput. That's a red herring. In fact, isolation increases throughput, because it reduces synchronization. A group of isolated tasks are embarrassingly parallel by definition.

The throughput loss stems from a design which require excessive communication. But such a design will always be slow, no matter your execution model. Modern CPUs simply don't cope well if cores need to send data between them. Neither does a GPU.

timeon2• 9 months ago

I do not think that monads/type system are issue, but yes BEAM runtime is killer feature.

a-dub• 9 months ago

fun fact: the secret sauce that makes fftw fast is a code generator written in ocaml: https://github.com/FFTW/fftw3/tree/master/genfft

yujzgzc4• 9 months ago

I loved Ocaml but now I love TypeScript more. It's got about the same amount of type safety, the ergonomics are better to me, and the packaging and ecosystem tooling are leaps and bounds above anything else.

phplovesong7• 9 months ago

You would not really build the same software tho.

abathologist5• 9 months ago

It's got about the same amount of type safety

What?

yujzgzc4• 9 months ago

Both languages have robust and expressive type systems. My experience is that TypeScript's is also more flexible. In Ocaml everything is cool as long as you stick with the functional programming style. But every "interesting" program also has imperative, non-functional-programming parts, and TypeScript has really good automatic "type narrowing" features that make that part much safer in my experience. In Ocaml however, type narrowing isn't automatic at all.

phplovesong7• 9 months ago

I kind of wish (like the OP mentioned) there was a ML (ocaml) like language that compiled to Go source. You would get the best of both worlds and access to a huge ecosystem.

nathcd• 9 months ago

There's Borgo: https://github.com/borgo-lang/borgo

I've never used it so can't speak from any experience, and unfortunately it doesn't seem particularly active (and doesn't mention a current status anywhere), and doesn't have a license, so shrug. When it's been posted here (https://news.ycombinator.com/item?id=40211891), people seemed pretty excited about it.

phplovesong7• 9 months ago

Borgo looks like some guys phd thesis. It looks like it was a fun experiment.

I feel a new simple ocaml like language that just compiled to Go would be really popular, really fast. And it would not even need to build a ecosystem, as Go already have all the things you need.

Something like what Gleam is for Erlang.

fermigier• 9 months ago

Little known fact: OCaml was at one point called "Zinc" ("Zinc is not Caml").

Qem• 9 months ago

Perhaps the language would be more lucky with the original name. Zinc is used to galvanize steel and prevent Rust formation[1].

[1] https://en.wikipedia.org/wiki/Galvanization

ilaksh• 9 months ago

Why isn't it more popular if it's so good? Because popularity and merit are not the same thing. People confuse them all the time though.

Check out the most popular music today. Like the top ten songs currently. Do you think those are really the best songs out there?

Popularity is mostly driven by either trends or momentum.

MeetingsBrowser• 9 months ago

I think popularity and regarded favorably are probably inversely correlated.

Many of the most popular languages are also the most hated. Many of the more niche languages are viewed the most favorably.

It is easy to dislike something yo are familiar with, and easy to be overoptimistic about something you don't know as well.

"the grass is always greener ... "

levzettelin• 9 months ago

Music being "good" is subjective. A programming language, however, can objectively be better if it allows a subset of programmers to better solve certain problems.

The reason for why OCaml is not more popular, thus, is that this subset is small. The reason for this may be either (a) habit or (b) it's not that much better than other languages. I'm gravitating to (b). OCaml guys seem to be quite dogmatic for the wrong reasons.

StopDisinfo9108• 9 months ago

I posit (c) it’s from France and written mostly by French people and American naturally gravitates towards languages which generate hype in English and preferably from the USA.

Also it didn’t employ a marketing team to work on outreached and write fancy comments here and some people who have used it for 10 minutes are apparently offended by the Pascal-like syntax and can’t stop discussing it on every Ocaml discussion making every actual users tired.

999900000999• 9 months ago

The popularity of a language usually translates into better support, tooling and learning materials.

tharne• 9 months ago

Why isn't it more popular if it's so good? Because popularity and merit are not the same thing.

Yes! To add to that, the question itself is wrong. We should be asking, how is OCaml able to be so good without being popular? People get the whole thing backward.

The popular languages are typically popular first, then get good later as a result of that popularity. They have to work, they have to be good, they're too big to fail.

This is what happened with Java. It was marketed like crazy at first and only later got refined in terms of tooling and the JVM itself. The R programming language was a mess for data wrangling, but once it was popular, people built things like the tidyverse or the data.table library. The Python ecosystem was disaster with all different testing packages, build tools, and ways to create and manage virtual environments, until the relatively recent arrival of uv, more than three decades after the creation of Python itself. And then there's javascript that's had more money, blood, sweat, and tears poured into it to be improved in one way or another because that's what practically anything running in a browser is using.

ArnavAgrawal03• 9 months ago

Came here to say I love Ocaml too

timhh3• 9 months ago

why isn’t OCaml more popular

I've used OCaml a bit and found various issues with it:

* Terrible Windows support. With OCaml 5 it's upgraded to "pretty bad".

* The syntax is hard to parse for humans. Often it turns into a word soup, without any helpful punctuation to tell you what things are. It's like reading a book with no paragraphs, capitalisation or punctuation.

* The syntax isn't recoverable. Sometimes you can add a single character and the error message is essentially "syntax error in these 1000 lines".

* Ocamlfmt is pretty bad. It thinks it is writing prose. It will even put complex `match`es on one line if they fit. Really hurts readability.

* The documentation is super terse. Very few examples.

* OPAM. In theory... I feel like it should be great. But in practice I find it to be incomprehensible, full of surprising behaviours, and also surprisingly buggy. I still can't believe the bug where it can't find `curl` if you're in more than 32 Unix groups.

* Optional type annotation for function signatures throws away a significant benefit of static typing - documentation/understanding and nice error messages.

* Tiny ecosystem. Rust gets flak for its small standard library, but OCaml doesn't even have a built in function to copy files.

* Like all FP languages it has a weird obsession with singly linked lists, which are actually a pretty awful data structure.

It's not all bad though, and I'd definitely take it over C and Python. Definitely wouldn't pick it over Rust though, unless I was really worried about compile times.

systems2• 9 months ago

+10 for bad windows support, i think this is a key and weirdly underestimated reason

just to give an idea how bad, until recently, you could not just go to ocaml.org and download ocaml for windows, you had to either download one for mingw or wsl

so for many it was just not installable, i.e. for many we didnt have ocaml for windows, until very very recently

thaumasiotes• 9 months ago

just to give an idea how bad, until recently, you could not just go to ocaml.org and download ocaml for windows

On the other hand, you could get ocaml for Windows from Microsoft ever since 2005.

mbac327686• 9 months ago

The Windows support is bad because OCaml is a PL designed by people who are deep in Linux life. Windows is not something that keeps them up at night. (Which isn't to say they didn't try, just, you know, not as much as it takes)

One of the things people often neglect to mention in their love letters to the language (except for Anil Madhavapeddy) is that it actually feels UNIXy. It feels like home.

fithisux4• 9 months ago

Opam on Windows is a masterpiece of engineering

delta_p_delta_x4• 9 months ago

I would suggest that people interested in using OCaml on Windows (or indeed, OCaml at all) try F# instead. It is still an ML-family language. Incidentally, by targeting the CLR, F# is considerably more deployable (both to users and to developers) than OCaml is. Plus, any old NuGet library written in C# or VB.NET can be used almost trivially in F#. This also solves the problem OP listed about a tiny ecosystem, because the C#/.NET ecosystem is massive.

I couldn't agree more with the parent commenter about OCaml documentation. Functional programmers appear to love terseness to an almost extreme degree. Things like `first` are abbreviated to `fst`, which is just odd. Especially now that good IntelliSense means there is no real functional (heh) difference between typing `.fi` and pressing Tab, and typing `.fs` and pressing Tab.

The F# documentation is comparatively very spiffy and detailed, with plenty of examples[1][2][3].

[1] https://learn.microsoft.com/en-gb/dotnet/fsharp/language-ref...

[2] https://fsharp.github.io/fsharp-core-docs/

[3] https://fsprojects.github.io/fsharp-cheatsheet/fsharp-cheats...

mbac327686• 9 months ago

I find F# nowhere near as good as OCaml and think this comparison is ugly, but if I was forced to use a .NET platform I would almost certainly use F#

int_19h9• 9 months ago

F# is indeed an ML-family language, but at this point it doesn't have all that much in common with OCaml specifically: it doesn't have the latter's structurally typed object model with inferred row-polymorphic types, nor its extremely powerful module system, not even many convenience features like open variants.

Syzygies• 9 months ago

To decide on a language for a math research project, I implemented a toy problem in many languages: What is the distribution of cycle counts for signed permutations on n letters? Use all cores in parallel.

  C++  100  19.57s                 
  Rust  96  20.40s                 
  F#  95  20.52s                  
  Nim  75  26.04s                  
  Julia  64  30.40s                 
  Ocaml  48  41.07s                 
  Haskell  41  47.64s                
  Chez  39  49.53s                 
  Swift  33  58.46s                 
  Lean  7  278.88s                 

  Tarjan, n = 10
  Nyx - Apple M4 Max - 12 performance and 4 efficiency cores
  n! * 2^n = 3,715,891,200 signed permutations
  score = gops normalized so best language averages 100
  time = running time in seconds

This had me briefly smitten with F#, till I realized the extent that rusty .NET bed springs were poking through. Same as the JVM and Clojure, or Erlang and Elixir. The F# JIT compiler is nevertheless pretty amazing.

I nearly settled on OCaml. After AI warning me that proper work-stealing parallelism is a massive, sophisticated project to code properly, the 40 lines of OCaml code I wrote that beat available libraries is my favorite code file in years.

Nevertheless, once one understands lazy evaluation in Haskell, it's hard to use any other language. The log slowdown for conventional use of a functional data structure becomes a linear speedup once one exploits persistence.

7thaccount5• 9 months ago

F# pretty much assumes you already know C#. I found that it made it hard to get up to speed on it. I really do enjoy the the syntax though.

mbac327686• 9 months ago

A lot of these are learning curve issues, but once you scale them you still permanently suffer with a very deficient, fragmented ecosystem. Until you have built up your own curated set of dependencies for your business stack, anyway.

* Ocamlfmt is pretty bad. It thinks it is writing prose. It will even put complex `match`es on one line if they fit. Really hurts readability.

I suggest configuring ocamlformat to use the janestreet profile for better defaults.

* Optional type annotation for function signatures throws away a significant benefit of static typing - documentation/understanding and nice error messages.

People should be providing .mli files, but don't. That said, an IDE with type hints helps this enormously. The VS Code plugin for OCaml is the best experience for noobs, hands down.

OPAM

yes

boppo12• 9 months ago

With all the issues, how does janestreet love it so?

LAC-Tech• 9 months ago

I wish I could make a list like this about rust in this place and not be flagged.

timhh3• 9 months ago

I don't think you would be flagged. Rust definitely has flaws:

* Compile time is only ok. On par with C++.

* Async has a surprisingly number of footguns and ergonomic issues.

* There's no good solution to self-borrowing or partial borrows.

* While using macros is fine, writing them is pretty awful. Fortunately you rarely need to do that. Relatedly it is missing introspection support.

* Sometimes the types and lifetimes get very complex.

But overall I still much prefer it to OCaml. The syntax is much nicer, it's easier to read, the ecosystem and tooling are much better, the documentation is much better, and it actively hates linked lists!

kristianp• 9 months ago

* Like all FP languages it has a weird obsession with singly linked lists, which are actually a pretty awful data structure

This made me chuckle. I've had that thought before, shouldn't the default be a vector on modern devices? Of course other collection types are available.

olivia-banks7• 9 months ago

I'd say that functional programming is probably one of the only domains where linked lists actually make sense. Vectors certainty have their use in more places though.

int_19h9• 9 months ago

The reason why functional languages like linked lists so much is because they are very easy to make immutable without a lot of pain all around. If you implement an immutable vector in a straightforward way, though, you basically need to do a lot of copying for any operation that needs to construct one (the rigmarole with immutable strings, and existence of hacks such as StringBuilder, is a good illustration of the problem).

But you can have a data structure that is more like vector under the hood while still supporting efficient copy-with-modifications. Clojure vectors, for example.

le-mark• 9 months ago

The syntax is hard to parse for humans

This was my problem as well, the object oriented related syntax is just too much. ML of which caml is a version of, has really tight syntax. The “o” in ocaml ruins it imo.

StopDisinfo9108• 9 months ago

No offense but the only time I have encountered objects in Ocaml was while using LablGTK a long time ago and the object syntax was pretty clean and not far from the module one. They are also structurally typed which is very handy.

Considering it only impacts a fairly small subset of the language, could you explain how it supposedly ruins everything?

Kwpolska• 9 months ago

* OPAM. In theory... I feel like it should be great. But in practice I find it to be incomprehensible, full of surprising behaviours, and also surprisingly buggy. I still can't believe the bug where it can't find `curl` if you're in more than 32 Unix groups.

I couldn’t believe this was an actual bug in opam, and I found it: https://github.com/ocaml/opam/issues/5373

I don’t think that’s an opam bug, it’s an issue with musl, and they just happened to build their binaries with it.

chris_armstrong• 9 months ago

It's interesting reading many of the associated comments, because there is a genuinely active effort to address many of the pain points of the language:

* Windows support has improved to the point where you can just download opam, and it will configure and set up a working compiler and language tools for you[^1]. The compiler team treat Windows as an first tier target. opam repository maintainers ensure new libraries and library versions added to the opam repository are compiled and tested for Windows compatibility, and authors are encouraged to fix it before making a release if its reasonably straightforward

* debugger support with gdb (and lldb) is slowly being improved thanks to efforts at Tarides

* opam is relatively stable (I've never found it "buggy and surprising"), but there are aspects (like switches that behave more like python venvs) which don't provide the most modern behaviour. dune package management (which is still in the works) will simplify this considerably, but opam continues to see active development and improvement from release to release.

* the platform team (again) are working on improving documentation with worked recipes and examples for popular uses cases (outside of the usual compiler and code generation cases) with the OCaml Cookbook: https://ocaml.org/cookbook

There are other things I find frustrating or that I work around, or are more misperceptions:

* there isn't a builtin way to copy files because the standard library is deliberately very small (like Rust), but there is a significant ecosystem of packages (this is different to other languages which cram a lot into their standard library). The result is a lot of friction for newcomers who have to install something to get what they need done, but that's valued by more experienced developers who don't want the whole kitchen sink in their binary and all its supply chain issues.[^2]

* the type inference can be a bit of a love/hate thing. Many people find it frustrating because of the way it works, and start annotating everything to short-circuit it. I've personally found it requires a bit of work to understand what it is doing, and when to rely on it, and when not to (essentially not trying to make it do things it simply will never be able to do).[^3]

* most people use singly-linked lists because they work reasonably well for their use cases and don't get in their way. There are other data structures, they work well and have better performance (for where it is needed). The language is pragmatic enough to offer mutable and immutable versions.

* ocamlformat is designed to work without defaults (but some of them I find annoying and reconfigure)

Please don't take this as an apology for its shortcomings - any language used in the wild has its frustrations, and more "niche" languages like OCaml have more than a few. But for me it's amazing how much the language has been modernised (effects-based runtime, multicore, etc) without breaking compatibility or adding reams of complexity to the language. Many of these things have taken a long time, but the result is usually much cleaner and better thought out than if they were rushed.

[^1] This in itself is not enough, and still "too slow". It will improve with efforts like relocatable OCaml (enabling binary distribution instead of compiling from source everywhere) and disentangling the build system from Unixisms that require Cygwin.

[^2] I particularly appreciate that the opam repository is actively tested (all new package releases are tested in a CI for dependency compatibility and working tests), curated (if its too small to be library, it will probably be rejected) and pruned (unmaintained packages are now being archived)

[^3] OCaml sets expectations around its type inference ("no annotations!") very high, but the reality is that it relies on a very tightly designed and internally coherent set of language constructs in order to achieve a high level of type inference / low level of annotation, but these are very different to how type inference works in other languages. For example, I try and avoid using the same field name in a module because of the "flat namespace" of field names used to infer record types, but this isn't always possible (e.g. generated code), so I find myself compensating by moving things into separate modules (which are relatively cheap and don't pollute the scope as much).

tempodox2• 9 months ago

The syntax is hard to parse for humans.

Funny how tastes differ. I'm glad it has a syntax that eschews all the noise that the blub languages add.

codesnik2• 9 months ago

I kinda feel that singly linked lists isn't a data structure in FP as much as a (dynamic) control flow structure. It's okay in that application.

thw_9a83c4• 9 months ago

The documentation is super terse. Very few examples.

I agree. OCaml is a complex language with very beginner-unfriendly documentation. In fact, I would even say it's unfriendly to engineers (as developers). The OCaml community prefers to see this language as an academic affair and doesn't see the need to attract the masses. E.g. Rust is an example of the opposite. It's a complex language, but it's pushing hard to become mainstream.

yodsanklai• 9 months ago

I just don't get these comments about syntax...

Just taking the first example I can find of some auto-formatted OCaml code

https://github.com/janestreet/core/blob/master/command/src/c...

It doesn't look more a soup of words than any other language. Not sure what's hard to parse for humans.

zipy124• 9 months ago

That third issue is very annoying. C++ in visual studio often has that and I'll help someone who has like 2,000 weird errors and my response is usually "looks like a missing semicolon to me" and they're like "????" Why wouldn't it be able to just say that.

agentultra2• 9 months ago

Why isn't it more popular?

I think Richard Feldman [0] proposed some of the most reasonable theories as to why functional programming isn't the norm. Your language needs to be the platform-exclusive language for a widely used platform, have a killer application for a highly desired application domain, or be backed by a monster war-chest of marketing money to sway opinions.

Since Feldman's talk, Python has grown much faster in popularity in the sense of wide use in the market place... but mostly because it's the scripting language of choice for PyTorch and AI-adjacent libraries/tooling/frameworks which is... a killer application.

I like OCaml. I started evaluating functional programming in it by taking the INRIA course online. I spent the last four and half years working in Haskell. I've built some side projects in Zig. I was a CL stan for many years. I asked this question a lot. We often say, "use the best tool for the job." Often that means, "use the tool that's available."

I think languages like OCaml, Rust, Haskell etc can be "popular," but in the sense that people like to talk about them and want to learn them and be able to use them (at least, as trends come and go). It's different from "popular" as in, "widely adopted."

[0] https://www.youtube.com/watch?v=QyJZzq0v7Z4

m3at• 9 months ago

mostly because it's the scripting language of choice for PyTorch and AI-adjacent libraries/tooling/frameworks

I would politely disagree. Torch started in Lua, and switched to Python because of its already soaring popularity. Whatever drove Python's growth predates modern AI frameworks

int_19h9• 9 months ago

Python was already big for scientists back in 2010. I remember working on Python tooling at the time, and DS/ML was one of our single largest user groups. It was already popular enough to have an IDE specifically for scientific Python use: https://en.wikipedia.org/wiki/Spyder_(software).

As far as I could tell, it had to do with two things. First, Python is notoriously dynamic and extensible, making it possible to implement "sloppy" syntax like advanced slicing or dataframes. But also, those guys had lots of pre-existing C and Fortran code, and Python had one of the easiest extensibility APIs to wrap it as high-level packages. And with IPython, you had a nice REPL with graphing to use all that from, and then of course notebooks happened.

agentultra2• 9 months ago

Yeah, I can see that. At the time of the talk Feldman claims Python is a slow-and-steady language. It definitely did get a lot of support from the scientific/engineering community for a long time. I spent a good part of my career with Python from about 2006-2016.

It had boosts from Django... but it never had Rails' level of popularity. You kinda have to be first-to-market and that good to get the "killer app" effect.

It's also been integrated as the scripting language for several popular software pacakges (Blender comes to mind).

Machine learning and now... "AI"; seems to be a market cornered by Python quite a bit.

aeonik2• 9 months ago

A MAJOR portion of popularity was because of this xkcd comic.

https://xkcd.com/353/

It hit the front page of Slashdot, Digg, Reddit, made the rounds on Hacker news, etc... (https://news.ycombinator.com/item?id=86246)

Django was also very popular at the time.

I had already learned Basic, C++, Java, and C#. I wanted to add a dynamic scripting language that was cross-platform under my belt.

A lot of my peers were in the same boat.

Python seemed at the time, to be the only general purpose scripting language that was easy to use on multiple platforms.

I had heard bad things about Perl being write only, and Ruby being tough to deploy, I also found it hard to read. (Which is a shame they are wonderful languages, though Ruby is dog slow, Python is slow too, but Ruby is worse somehow).

IIRC Google and some other large companies were pushing it as one of their official languages.

Right as Python was rocketing in popularity, Go came out, and I also heard a lot of good things about Clojure (they seemed neck and neck in popularity from my incorrect perspective at the time, lol).

spooky_deep2• 9 months ago

Google blessed Python at a time when Java didn’t even have lambdas.

atombender2• 9 months ago

I look at how people write TypeScript these days, and think about how the world might have been different if, 10-15 years ago, these functional languages had been a bit closer to the imperative world. OCaml allows mutation and side effects and could even feel a bit imperative if it weren't for the "let ... in" syntax.

Let's face it, syntax matters. We saw that with Elixir becoming much more popular than Erlang ever did. We saw it with TypeScript being able to introduce a fairly complex type system into JavaScript, and becoming successful among web devs by adapting to established ecosystem and offering a gradual approach, rather than forcing an entirely new, incompatible paradigm on it. The TypeScript story seems a little improbable in hindsight, but it was able to get there by offering an incremental path and making a lot of compromises (such as config options to allow less strict enforcement) along the way.

Personally, I think a new syntax for OCaml might actually be successful if done right. Sure, there have been multiple attempts (the "revised" syntax, Reason, etc.), but none of them are really willing to modernize in ways that would attract your average programmer. The toolchain also needs work to appeal to non-OCaml programmers.

debugnik9• 9 months ago

Could you explain how Reason syntax isn't "really willing to modernize in ways that would attract your average programmer"? I'm trying to understand what do you even mean.

rootnod3• 9 months ago

I absolutely love the idea and methods behind OCaml, but the syntax..... I also love Haskell and already feel that its syntax is not easy to grok on larger projects, but OCaml basically went "hold my beer" and went to town on that.

mikaeluman2• 9 months ago

I like the ML languages, and as many others I spent a lot of time with F#.

I would love to spend more time but even though Microsoft gives it plenty of support (nowhere near as much as C#), the community is just too small (and seems to have gotten smaller).

Looking at https://www.tiobe.com/tiobe-index/ numbers fall off pretty quickly from the top 5-7.

Guessing this is the same for OCaml, even if the language as such is nice.

throwa5675432• 9 months ago

Anecdotally we are using F# more than ever before, and it works for us for a large sized organisation. Fast code, it is keeping up with the .NET features that matter for that (e.g. spans), and tbh has still been getting better over the years. In fact I find some of the new features like Span, SIMD/intrinsics somewhat synergise with existing F# features (e.g. inline). C# IMO still hasn't quite caught up but is getting there. Comparing to Go/Java/etc I can usually get faster code out of the .NET runtime as well especially in our domain which requires large scale computation. If I was to move to something else for our domain it would be C++ or Rust. F# piggy backing of the .NET platform in general, has a decent ecosystem and easy onboarding cross platform and gets a lot "for free" (e.g. CLI, GC improvements).

Community is an interesting thing, and for some people I guess it is important. For me language is just a tool having coded for quite some time and seen communities come and go; don't care about being known or showing an example per se. If the tool on the balance allows me to write faster code, with less errors quicker and can be given to generic teams (e.g. ex Python, JS devs) with some in house training its a win. For me personally I just keep building large scale interesting systems with F#; its a tool and once you get a hang of its quirks (it does have some small ones) quite a good one that hits that sweet spot IMO.

My feeling however is with AI/LLM's communities and syntax in general is in decline and less important especially for niche languages. Language matters less than the platform, ecosystem, etc. Its easier to learn a language then ever before for example, and get help from it. Any zero cost abstraction can be emulated with more code generation as well as much as I would hate reviewing it. More important is can you read the review the code easily, and does the platform offer you the things you need to deliver software to your requirements or not and can people pick it up.

mikaeluman2• 9 months ago

Interesting take. I agree with you mostly but regarding "community" I am more thinking of the side effects there in terms of _other_ people developing interesting libraries etc.

I don't know if AI can change that but when using python, there is a feeling that there is an awesome quality library for just about anything.

tasuki2• 9 months ago

Fast compile times
Fewer abstractions, and an easy to understand runtime
Strong static guarantees
Functional programming constructs. Especially pattern matching and sum types.
Good performance
Good documentation

I feel this is also Elm!

creata5• 9 months ago

Elm is pure-functional, unlike OCaml, which has easy escape hatches (refs) when you need mutability.

tasuki2• 9 months ago

I feel as a frontend language Elm has somewhat less need for mutability. At least I haven't missed it.

pshirshov• 9 months ago

why isn’t OCaml more popular?

Hashtbl.add table key value

Precedence, nominal inheritance, HKTs, incoherent typeclasses make Scala much less aesthetically pleasant but much more productive.

rixed• 9 months ago

  Hashtbl.add table key value

What's your point with that?

seabrookmx• 9 months ago

Lots of complaints about the OCaml syntax here.. is ReasonML dead?

davesnx• 9 months ago

is very alive, released with OCaml 5.4 support and improving bit by bit

olivia-banks7• 9 months ago

It just genuinely felt like the Go language designers didn’t want to engage with any of the ideas coming from functional programming.

You'd be right.

"The key point here is our programmers are Googlers, they’re not researchers. They’re typically, fairly young, fresh out of school, probably learned Java, maybe learned C or C++, probably learned Python. They’re not capable of understanding a brilliant language but we want to use them to build good software. So, the language that we give them has to be easy for them to understand and easy to adopt. – Rob Pike 1"

"It must be familiar, roughly C-like. Programmers working at Google are early in their careers and are most familiar with procedural languages, particularly from the C family. The need to get programmers productive quickly in a new language means that the language cannot be too radical. – Rob Pike 2"

Talking as someone who wrote OCaml at work for a while, the benefits of functional programming and the type guarantees that it's ilk provides cannot be understated; you only start to reach them, however, once most developers have shifted their way of thinking rather extremely, which is a time cost that that designers of Go did not want new Googlers to pay.

VirusNewbie• 9 months ago

You would be surprised how many Googlers think the Go team is making bad decision after bad decision.

olivia-banks7• 9 months ago

How so? I’m not that familiar with Go anymore.

keyle• 9 months ago

Not just Googlers. There is a certain pragmatism and then there is being stubborn.

boppo12• 9 months ago

I am exactly the type of novice programmer described in the quotes.

have shifted their way of thinking rather extremely

What could I read to shift my way of thinking?

The signals & threads episode about OCaml strongly piqued my interest, and not because I have any JS delusions (they would never, lol).

olivia-banks7• 9 months ago

Functional programming is a different way of thinking about solving problems. People say it's about thinking about "what you're trying to compute" versus "how you're computing it," but quite frankly that never made sense to me. I prefer to think about it in terms of thinking about relationships (FP) versus thinking about steps over time (procedural).

This, at least for me, brings the act of writing a specific piece of code more inline with how I think about the system as a whole. I spend less energy worrying about the current state of the world and more about composing small, predictable operations on relationships.

As for what you can read, I find it's just best to get going with something like OCaml or F# and write something that can take advantage of that paradigm in a relatively straightforward way, like a compiler or something else with a lot of graph operations. You'll learn pretty quickly what the language wants you to do.

olivia-banks7• 9 months ago

OCaml is weird in that it’s a garbage collected language for systems, similar to Go.

I don't understand why this isn't more popular. For most areas, I'd gladly take a garbage collector over manual memory management or explicit borrow checking. I think the GC in D was one of it's best features, but it's downfall nonetheless as everyone got spooked by those two letters.

DeathArrow4• 9 months ago

The problem I see for the adoption is that the landscape is very fragmented.

ML is a family of languages and we have StandardML with different implementations, OCaml with official path and JS path, F# and whatnot.

This is the problem for Lisp, too as there are many Lisps.

StopDisinfo9108• 9 months ago

I find it interesting that 80% of the Ocaml discussions here are similar to what I encounter during the change management phase on every complex project I work on: "But it’s different from what I’m used and must therefore be bad. Look, the syntax, it doesn’t look like usual. Scary."

15% are people trying to sell their own language of choice sometimes with the argument that "it’s less scary, look".

I would be shocked if a mere 5% is actual engagement with the topic at hand sometimes while pointing flaws which are very real.

From there, I gather two things, the main one being: maybe Meta was right actually. People are that limited and the syntax should have been changed just to be done with the topic.

fithisux4• 9 months ago

"but the more I use it the more I feel like this old language had it all figured out,"

sounds superficially similar to Common Lisp

Why I love OCaml (2023)

Related Stories