To me compilation speed is right up there with runtime speed in terms of importance. I do not like this trend where we sacrifice compilation speed to have "correct" code and give up because computers are so slow when in fact computers are incredibly fast and its this attitude of not caring about compilation speed that makes them seem so slow.
All these typed languages have to balance how much static analysis they do anyways, I just think they should dial it back and settle for the middle ground between analysis and compilation speed as the default. You can have options to increase it just as you have options for optimization levels.
The default should never be having to wait half and hour to fix a typo. That seems crazy to me but that is exactly what we have with some of these languages.
I have a strong preference for fast compilation, but the trade-off with analysis is not so straightforward.
Just finishing compilation is not sufficient to find problems, testing is needed too; if compilation and analysis can be done faster than compilation and testing, then you can still come out ahead.
I think SBCL shows that there's a decent amount of low hanging fruit for analysis; it catches a surprising number of errors with reasonably fast compilation (incremental compilation of dozens of functions feels instant), and notes places where the code could be restructured to allow for better analysis.
All these typed languages have to balance how much static analysis they do anyways, I just think they should dial it back and settle for the middle ground between analysis and compilation speed as the default. You can have options to increase it just as you have options for optimization levels.
The default should never be having to wait half and hour to fix a typo. That seems crazy to me but that is exactly what we have with some of these languages.