I've always felt that ML hit the sweet spot between functional and imperative programming. It affords conveniences such as algebraic data types and first-class functions, but unlike Haskell, it doesn't require monadic programming to use IO or mutable references.
ML also has an interesting module system, which achieves similar goals as object-oriented programming, but in a very different way. While mainstream "class-based" OOP identifies the data type with the unit of encapsulation, ML has "modules," which are separate entities from types, and which may both define types and values as members. However, a downside of this approach is that you sacrifice late binding, as the module language and "core" language are stratified into different layers. Instead, dependency injection is achieved through module-level functions, called functors,
A lesser-known fact is that ML originated as the scripting language for the LCF proof assistant (which is where the name "ML," or meta language, comes from). In the LCF tradition, the inferences rules of the logic are implemented in a trusted kernel, then clients use those inference rules to write tactic scripts that construct theorem objects. This design was supported by ML's module system: theorems were defined as an abstract type in a "kernel" module, and the inference rules were defined as functions inside the module. Here is a tutorial that explains the LCF design better than I can: https://www.cs.cmu.edu/~fp/courses/15317-f17/recitations/rec...
If only Microsoft had more love for F# instead of slowly copying its features into C#.
At least it is still officially developed getting new features, unlike C++/CLI and VB that only get bug fixes and updates to keep running on top of recent .NET versions.
This rests entirely on the same same sort of conservative attitude towards new experiences that holds the other half of the development world back. The Java world. People generally do not want to learn new things, they want "faster horses", which incidentally is what C# and Java is these days.
This is why we can't have nice things.
Java with Streams and "functions" is a lot better than what I left behind 15 years ago. But it is still extremely primitive compared to what F#, Rust and Scala offers. And I know this because I have spent 10+ years EACH using all of these in anger. So 20+ years.
Agreed it is the "We were not out to win over the Lisp programmers; we were after the C++ programmers. We managed to drag a lot of them about halfway to Lisp." approach.
Thing is, for 99% of corporate software, it hardly makes a difference, even more so with AI generated stuff going forward.
So yeah, we can't have nice things, especially when money and profit are part of it.
This is just not true, the last bit you say. That is the same old trope about F#, Rust or Scala being niche, things people that don't have to earn money or feed children can do. I worked 100% in those languages from 2012 through 2023.
But sure, with AI, maybe this will matter less because people don't care about the code anymore.
I would not place Rust in the same bucket as Scala or F# in terms of industry adoption.
F# is as it is.
Scala in 2026, especially after Scala 3, isn't doing great either.
Most Scala companies, nowadays also do Java and Kotlin, and in countries like Netherlands, according to discussions on Reddit, most consulting offers seems to have vanished.
Rust hit jackpot with the adoption across all major OS vendors and hyperscalers, being slowly certified for deployment into high integrity computing, and landing on the Linux kernel.
However even with all that, just look at Android, where Google proudly talks about their Rust adoption, yet Rust is not officially supported for app development, Java and Kotlin are, with NDK still only allowing C and C++, and that is mostly for game developers anyway.
I am not. I am saying that had I been a good little Java/ C# developer, then I would never have learned Rust and all of the things that come with that.
Scala is not doing great, probably because they took too long to get 3 finished and good.
Yes. Companies are going back to Java because this is what all the convervative guys and girls want to use. That fact is what I am criticizing. You want fast horses, you don't want nice things.
So now you have Maven, semi-typed code intermingled with container logic because you cannot abstract over anything, you have millions of lines of impenetrable tests. Just like we all did in 2006. You all love this because learning things is not your forte :) That other stuff is for academics and niche.
Unfortunately there is this alternative universe where languages like Lisp, and Smalltalk would have taken over mainstream, and by association languages like Standard ML.
I still fondly remember my introduction to ML ecosystem via Caml Light, OCaml was still Objective Caml, and Haskell was still getting beyond Miranda.
Instead as you well put it we keep we talking about faster horses, with the leading horse being C, and how to replace it by another one.
Or at least that was the path, until vibe coding became a thing, hopefully the bubble will burst.
Right and C has a special place in my heart. I have never coded C in anger, but the weird thing about coding in Java is how low level all the implementations are. I've had this debate/ conversation with people over the years and I realize that if I am the only one at a certain position, then I am wrong and not everyone else.
But I claim that Rust is actually a high level language. Higher level than Java. My argument is that in Rust (, F# and Scala) you can encode in structure, what has to be operational code in Java.
So in the stronger languages you can reason about larger swaths about domain concepts easily, whereas in Java you have to trust the test panel on faith and wade through deep sections of "magic code" (compare with magic numbers. Why is there a 427/ these 7 lines of logic here? What does it do?)
Isabelle is still a very active LCF proof assistant, and it's still written in Poly/ML. It's pretty aggressively concurrent under the bonnet, and leverages Poly/ML well for that. There's still HOL4, which predates Isabelle and is still going, and it also recommends using Poly/ML.
I mostly worked with HOL Light which started as a CAML project and now runs on OCaml.
and you get concurrentML. People get all wet in the pants by the actor model and CSP, but my god CML is much nicer in every way.
I had a weird introduction to programming. I spent my first half year doing php, and them went all in on scheme and sml. Which is nice in many ways, but I do have a hard time accepting many of the completely braindead (subjective opinion, of course) choices of most of the popular languages.
I do think clojure is a pretty nice compromise. Rich has good taste, obviously. Clojure's core.async could be less async and more CML in my taste. Wrapping a simpler async api in cml is easy. Implementing CML on top on core.async is either very hard or full of compromises.
it is like CSP but with first class events. In CSP you have to manage complex protocols yourself, whereas in cml you can compose larger even trees and then do one sync.
a classic example of something that is trivial in cml but requires a mediator in CSP or go is two fibers swapping values atomically where a fiber can pull out at any time. in cml it is about 20 lines of code that can be in a library. it composes with other events.
in csp it is a "server" that manages the swap which means you lose the sectability.
Evert time you want to have any kind of protocol, cml wins.
For those interested in the Standard ML compilers, Mlton is another one worth checking out. Standard ML of New Jersey (smlnj) is another interesting one although it tends to be more of a research vehicle than polyml or mlton. If you are inclined toward verification, the cakeml project is quite cool as well. For those unfamiliar with standard ML, if you’ve heard of ocaml or F#, they’re relatives in the ML language family.
> Standard ML of New Jersey (smlnj) is another interesting one although it tends to be more of a research vehicle than polyml or mlton.
This is interesting! My impression was that SML/NJ was the de facto "standard" Standard ML implementation (maybe analogous to SBCL in the Lisp world), and (FWIW) Gemini agrees, describing it as "the oldest and most widely used". So I'm surprised to see someone stick it in the rear behind Poly/ML and MLton.
I don't really know what to make of that, except that I guess there's a surprisingly vibrant SML ecosystem and don't listen to any one person (myself included) about it: try them all and see which SML implementation is right for you :)
I think mlton is the one to reach for if you want strict conformance to the SML'97 definition [1]. There's a page on the MLton site that describes where SMLNJ deviates from SML'97 [2].
I'm surprised Gemini says SML/NJ its the most widely used. I've been an active Standard ML user for close to 30 years, and while that was certainly true for the first half of that time, I found most projects around me drifted to defaulting to want to compile with mlton or polyml. SML/NJ's heap2exec was a bit clunky compared to the others. It's great that they're slowly moving it over to LLVM.
I understood that MLton was mostly about performance. It does whole program optimisation and is prepared (or does?) monomorphise just about everything, and applies all of your functors at compile time, so that you've got something more like C++ templates but well-typed.
> SML/NJ's heap2exec was a bit clunky compared to the others.
Unlike the others, SML/NJ implements call/cc, so it's going to need to do something funkier.
SMLofNJ.Cont.callcc
> val it = fn : ('a ?.Cont.cont -> 'a) -> 'a
"Standard ML is a functional programming language, in the sense that the
full power of mathematical functions is present." From a Pdf linked on the repo (I didn't know what Standard ML was, I was hoping for a mark up language)
StandardML is a rather nice modular high level functional programming language with algebraic datatypes, pattern matching, compile-time type checking and type inference etc. Poly/ML extends this with strong proven multi-core and cross platform support including Posix threads, parallel garbage collection, FFI etc. Poly/ML has been around a while, but it is still actively maintained by Dave Mathews et al (most recent release June 2026) has good windows and X11 support. Poly/ML is a great way to explore the world of StandardML and is used to build Isabelle and HOL theorem provers. Definitely worth a look!
I've always felt that ML hit the sweet spot between functional and imperative programming. It affords conveniences such as algebraic data types and first-class functions, but unlike Haskell, it doesn't require monadic programming to use IO or mutable references.
ML also has an interesting module system, which achieves similar goals as object-oriented programming, but in a very different way. While mainstream "class-based" OOP identifies the data type with the unit of encapsulation, ML has "modules," which are separate entities from types, and which may both define types and values as members. However, a downside of this approach is that you sacrifice late binding, as the module language and "core" language are stratified into different layers. Instead, dependency injection is achieved through module-level functions, called functors,
A lesser-known fact is that ML originated as the scripting language for the LCF proof assistant (which is where the name "ML," or meta language, comes from). In the LCF tradition, the inferences rules of the logic are implemented in a trusted kernel, then clients use those inference rules to write tactic scripts that construct theorem objects. This design was supported by ML's module system: theorems were defined as an abstract type in a "kernel" module, and the inference rules were defined as functions inside the module. Here is a tutorial that explains the LCF design better than I can: https://www.cs.cmu.edu/~fp/courses/15317-f17/recitations/rec...
If only Microsoft had more love for F# instead of slowly copying its features into C#.
At least it is still officially developed getting new features, unlike C++/CLI and VB that only get bug fixes and updates to keep running on top of recent .NET versions.
This rests entirely on the same same sort of conservative attitude towards new experiences that holds the other half of the development world back. The Java world. People generally do not want to learn new things, they want "faster horses", which incidentally is what C# and Java is these days.
This is why we can't have nice things.
Java with Streams and "functions" is a lot better than what I left behind 15 years ago. But it is still extremely primitive compared to what F#, Rust and Scala offers. And I know this because I have spent 10+ years EACH using all of these in anger. So 20+ years.
Agreed it is the "We were not out to win over the Lisp programmers; we were after the C++ programmers. We managed to drag a lot of them about halfway to Lisp." approach.
Thing is, for 99% of corporate software, it hardly makes a difference, even more so with AI generated stuff going forward.
So yeah, we can't have nice things, especially when money and profit are part of it.
This is just not true, the last bit you say. That is the same old trope about F#, Rust or Scala being niche, things people that don't have to earn money or feed children can do. I worked 100% in those languages from 2012 through 2023.
But sure, with AI, maybe this will matter less because people don't care about the code anymore.
I would not place Rust in the same bucket as Scala or F# in terms of industry adoption.
F# is as it is.
Scala in 2026, especially after Scala 3, isn't doing great either.
Most Scala companies, nowadays also do Java and Kotlin, and in countries like Netherlands, according to discussions on Reddit, most consulting offers seems to have vanished.
Rust hit jackpot with the adoption across all major OS vendors and hyperscalers, being slowly certified for deployment into high integrity computing, and landing on the Linux kernel.
However even with all that, just look at Android, where Google proudly talks about their Rust adoption, yet Rust is not officially supported for app development, Java and Kotlin are, with NDK still only allowing C and C++, and that is mostly for game developers anyway.
I am not. I am saying that had I been a good little Java/ C# developer, then I would never have learned Rust and all of the things that come with that.
Scala is not doing great, probably because they took too long to get 3 finished and good.
Yes. Companies are going back to Java because this is what all the convervative guys and girls want to use. That fact is what I am criticizing. You want fast horses, you don't want nice things.
So now you have Maven, semi-typed code intermingled with container logic because you cannot abstract over anything, you have millions of lines of impenetrable tests. Just like we all did in 2006. You all love this because learning things is not your forte :) That other stuff is for academics and niche.
Unfortunately there is this alternative universe where languages like Lisp, and Smalltalk would have taken over mainstream, and by association languages like Standard ML.
I still fondly remember my introduction to ML ecosystem via Caml Light, OCaml was still Objective Caml, and Haskell was still getting beyond Miranda.
Instead as you well put it we keep we talking about faster horses, with the leading horse being C, and how to replace it by another one.
Or at least that was the path, until vibe coding became a thing, hopefully the bubble will burst.
Right and C has a special place in my heart. I have never coded C in anger, but the weird thing about coding in Java is how low level all the implementations are. I've had this debate/ conversation with people over the years and I realize that if I am the only one at a certain position, then I am wrong and not everyone else.
But I claim that Rust is actually a high level language. Higher level than Java. My argument is that in Rust (, F# and Scala) you can encode in structure, what has to be operational code in Java.
So in the stronger languages you can reason about larger swaths about domain concepts easily, whereas in Java you have to trust the test panel on faith and wade through deep sections of "magic code" (compare with magic numbers. Why is there a 427/ these 7 lines of logic here? What does it do?)
> a downside of this approach is that you sacrifice late binding, as the module language and "core" language are stratified into different layers
https://people.mpi-sws.org/~rossberg/1ml/1ml-extended.pdf
https://github.com/rossberg/1ml
Isabelle is still a very active LCF proof assistant, and it's still written in Poly/ML. It's pretty aggressively concurrent under the bonnet, and leverages Poly/ML well for that. There's still HOL4, which predates Isabelle and is still going, and it also recommends using Poly/ML.
I mostly worked with HOL Light which started as a CAML project and now runs on OCaml.
and you get concurrentML. People get all wet in the pants by the actor model and CSP, but my god CML is much nicer in every way.
I had a weird introduction to programming. I spent my first half year doing php, and them went all in on scheme and sml. Which is nice in many ways, but I do have a hard time accepting many of the completely braindead (subjective opinion, of course) choices of most of the popular languages.
I do think clojure is a pretty nice compromise. Rich has good taste, obviously. Clojure's core.async could be less async and more CML in my taste. Wrapping a simpler async api in cml is easy. Implementing CML on top on core.async is either very hard or full of compromises.
Could you share more about what makes CML so awesome?
it is like CSP but with first class events. In CSP you have to manage complex protocols yourself, whereas in cml you can compose larger even trees and then do one sync.
a classic example of something that is trivial in cml but requires a mediator in CSP or go is two fibers swapping values atomically where a fiber can pull out at any time. in cml it is about 20 lines of code that can be in a library. it composes with other events.
in csp it is a "server" that manages the swap which means you lose the sectability.
Evert time you want to have any kind of protocol, cml wins.
[flagged]
For those interested in the Standard ML compilers, Mlton is another one worth checking out. Standard ML of New Jersey (smlnj) is another interesting one although it tends to be more of a research vehicle than polyml or mlton. If you are inclined toward verification, the cakeml project is quite cool as well. For those unfamiliar with standard ML, if you’ve heard of ocaml or F#, they’re relatives in the ML language family.
> Standard ML of New Jersey (smlnj) is another interesting one although it tends to be more of a research vehicle than polyml or mlton.
This is interesting! My impression was that SML/NJ was the de facto "standard" Standard ML implementation (maybe analogous to SBCL in the Lisp world), and (FWIW) Gemini agrees, describing it as "the oldest and most widely used". So I'm surprised to see someone stick it in the rear behind Poly/ML and MLton.
I don't really know what to make of that, except that I guess there's a surprisingly vibrant SML ecosystem and don't listen to any one person (myself included) about it: try them all and see which SML implementation is right for you :)
I think mlton is the one to reach for if you want strict conformance to the SML'97 definition [1]. There's a page on the MLton site that describes where SMLNJ deviates from SML'97 [2].
I'm surprised Gemini says SML/NJ its the most widely used. I've been an active Standard ML user for close to 30 years, and while that was certainly true for the first half of that time, I found most projects around me drifted to defaulting to want to compile with mlton or polyml. SML/NJ's heap2exec was a bit clunky compared to the others. It's great that they're slowly moving it over to LLVM.
[1] http://www.mlton.org/Features
[2] http://mlton.org/guide/20051202/SMLNJDeviations
I understood that MLton was mostly about performance. It does whole program optimisation and is prepared (or does?) monomorphise just about everything, and applies all of your functors at compile time, so that you've got something more like C++ templates but well-typed.
> SML/NJ's heap2exec was a bit clunky compared to the others.
Unlike the others, SML/NJ implements call/cc, so it's going to need to do something funkier.
>(FWIW) Gemini agrees
LLM hallucination: Poly/ML has been in use since at least 1986 (see e.g. Paulsons preliminary user's manual for Isabelle).
There is also MLKit which is pretty interesting in how it handles memory, it is region based with some fallback to garbage collection.
https://elsman.com/mlkit/
OCaml seems nice for doing real world app development (e.g) web backend, and not limited only for prog lang research.
Hmmm....
"Standard ML is a functional programming language, in the sense that the full power of mathematical functions is present." From a Pdf linked on the repo (I didn't know what Standard ML was, I was hoping for a mark up language)
StandardML is a rather nice modular high level functional programming language with algebraic datatypes, pattern matching, compile-time type checking and type inference etc. Poly/ML extends this with strong proven multi-core and cross platform support including Posix threads, parallel garbage collection, FFI etc. Poly/ML has been around a while, but it is still actively maintained by Dave Mathews et al (most recent release June 2026) has good windows and X11 support. Poly/ML is a great way to explore the world of StandardML and is used to build Isabelle and HOL theorem provers. Definitely worth a look!
I had just never heard of it before, I didn't realize it was well know. I was quoting from it's specification.
See SGML for a markup language.