I did Advent of Code in SML a couple years ago. It was an interesting experience. I don't think I've ever previously experienced such a vast disconnect between the quality of the core language, and the lack of functionality in the standard library.
I think that it could have easily been my favorite dialect of ML if its standard library hadn't been so anemic even by 1990s standards. As it is, though, my AoC solutions tended to take a large effort, not because the problems were difficult to solve in the language, but because I ended up having to build up so many of my own algorithms and data structures. Fortunately, doing that in in SML is a genuine joy. But it still, sadly, renders the language irrelevant for just about any practical purpose nowadays.
SML/NJ has a standard library [0] beyond Basis with a lot of useful functionality, e.g. sets, queues, hash maps, red-black trees, sorting functions, regex.
> This website looks hilariously mangled on mobile.
Not much better on the browser though they seemed to have cleaned it up a bit since my last visit. Many years ago when I visited the website to download smlnj for class, I had to double and triple check the url and google/bing/etc the website to make sure it was not a spam site because of how barebones and amateurish the site looked.
> Which at first I kind of expected, until it said at the bottom it was updated in 2022.
I think the last update year is actually 2020. 2022 is the release year of the latest SMLNJ version. I think they could have layed it out better but smlnj is mostly for academic use so I'll let it slide.
i concur with this assessment. I did the wonderful course, "Programming Languages, Part A" by The University of Washington. Part "A" of the course teaches Functional Programming and uses Standard ML as a vehicle to teach it's semantics.
I completely fell in love with the language, but I concur that the tooling is almost non-existent and the error messages that bubble up, leaves much to be desired.
I had the exact same experience - I did some of AoC in SML, fell in love with the core language, and even hacked on a toy SML compiler (didn't get too far).
It really is a wonderful language held back by a lack of good tooling and ecosystem, and well, users.
While it is true that things don't move fast, there have been proposals to it which have seen some adoption (thinking MONO_BUFFER was implemented by smlnj has compat in mlton). And I recall a proposal from polyml subsequently was implemented in smlnj. I don't know if there actually is a process in place to actually decide to accept proposals into the basis.
One of the things I like about the basis library is it's principled stance that if it doesn't require compiler support, host operating system support, is more efficiently implementable by the compiler than would be with an external library, or has clear proven utility it belongs in a separate library.
This barrier for inclusion is to me at least undoubtedly good.
Personally I would split things apart further (kicking host OS support to a separate library from the basis, as I am inclined towards non-posix hosts where most of the API requiring host support isn't implementable). And kicking out any optional types/modules to separate libraries (where said library is then optional).
So while it is about as minimal a standard library as exists, (for my purposes at least) it sometimes feels like it contains too much. Given there is no language level support for things like conditional compilation of anything optional within the basis. These tend to be my gripes with the basis... not "it needs more things".
Though, also, maybe don't go too far with kicking things out into individual separate libraries. Last year I did AoC in Scheme, and there the annoyance was figuring out exactly which of the approximately nine kajillion SRFI packages I needed to import to get different bits of functionality. A smaller number of more tightly integrated libraries that are allowed to evolve over time would have been more pragmatic.
Yeah, excessive modularity can be just as bad as any monolith. I'd tend towards sticking to a few libraries with well defined boundaries like target OS, or perhaps one for native cpu architecture word sizes and the like. But that still leaves some optional oddities like IntInf without an obvious destination.
I think that it could have easily been my favorite dialect of ML if its standard library hadn't been so anemic even by 1990s standards. As it is, though, my AoC solutions tended to take a large effort, not because the problems were difficult to solve in the language, but because I ended up having to build up so many of my own algorithms and data structures. Fortunately, doing that in in SML is a genuine joy. But it still, sadly, renders the language irrelevant for just about any practical purpose nowadays.