4 ms·
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 becaus
by ajb 7y ago
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.
- sikan 7y agoOCaml compilation is just as fast as Go.
- deleted 7y ago[deleted]
- ajb 7y agoGreat. SML compilation was noticeably slow last time I used it, but maybe that's changed.
- hajile 7y agoOcaml 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.