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.

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

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.

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

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

That would be Elm :)

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

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

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.

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

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.

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

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

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

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.

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

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.

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.

gleam is compiled... to erlang bytecode

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.

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.

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

The answer is 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 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 (for F# on front end) and people always commented how our demos had literally 0 bugs, maybe it was too productive for our own good.

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

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.