> Spreading FUD about the language they compare against Yeah, that's a big part of why I'm not a fan. They never reflect the actual experience of using a language.
> FWIW we actually do pretty well on the compilation speed: > [https://vlang.io/compilation_speed](https://vlang.io/compilation_speed). I > find it incredibly unlikely that this benchmark hasn't been gamed in V's > favour though, 0.6s? It's not gamed, but the small print has been omitted. Basically, V has two compilation modes. One is a dumb tcc-style compiler that doesn't really optimize anything, the other is to compile to C (like Nim). You get the fast compilation speed by basically having a very fast backend and a language with simple semantics. Problems: * It's really not that much of a benefit, as long as you have incremental compilation. The test compiles massive standalone files that you will rarely see in practice and which may actually trigger non-linear behavior that compiler writers don't care about, because nobody will write such code. * If you need optimization during development, you lose the fast compilation speed. Many programs require at least some optimization to run at acceptable speeds even while debugging them. * The fairly large tradeoffs between compilation speed and code performance may encourage bad programming practices, such as manual inlining to keep the compilation speed of the dumb compiler and being able to live without optimization.
