Re:A Tour of Standard ML
by ajb on Wednesday January 29, 2020 @03:46PM
(#22185616)
The go team had an explicit goal of very fast compilation - including low scaling with the number of files (avoiding the Nfiles^2 that C++ tends to have because of include files). It's not obvious to me that this is compatible with SML's module system and Hindley-Milner, although I'd love to be proved wrong.
[ Parent
| on HN ]
OCaml compilation is just as fast as Go.
Great. SML compilation was noticeably slow last time I used it, but maybe that's changed.
Ocaml has way more paid development time than SML. MLton guys can't focus on everything, so they've decided final performance is more important than compile time. SML was designed with few ambiguities to the syntax (simpler for students to implement), so theoretical compile times could be very low indeed. If they had Google money behind them, compile times would definitely be better
The other thing is whole-program optimization vs method-at-a-time. A lot of SML devs use New Jersey for fast compiles when developing and MLton when deploying. You can get rid of a ton of stuff in functional languages once you do a whole program compile, but that will always take more time. MLton could really use a second, faster compiler, but I'm just appreciative of all their effort to make the current compiler output fast code.