4 ms·

Why is it odd? The compiler does all sorts of other checks based on things like static assert or type information.

• kstenerud 2y ago
  It's odd because you lose control over that aspect of compilation. It slows down the development loop because every time you do a build you have to wait for a bunch of unit tests that you don't care about yet. Every time you do exploratory work you now have to comment out all the tests that this work breaks because otherwise it won't compile anymore. That would be even more annoying than Go's stupidly pedantic compiler.
  • Alifatisk 2y ago
    > It slows down the development loop because every time you do a build you have to wait for a bunch of unit tests that you don't care about yet. Can't that be an optional thing decided by some compiler flag? I think I remember doing something like that in D.
    • kstenerud 2y ago
      That's how one would normally do it, and that's what I would expect to see: Build for development, and the compiler only errors out if things are so bad that it's unable emit a binary (for everything else, it emits warnings). Build for release, and it errors out unless EVERYTHING is done right. Unfortunately, ever since golang decided on an autocratic and backwards "there are no warnings, only errors" policy, others have started to sip from the same kool aid jar.