Hacker News Reader

Comment by lamchob | Hacker News Reader

While it looks nice, it brags about it's compilation speed while simultaneously not offering any optimizations. If you want to have optimizations, C/C++ source-to-source compilation is required, which is slower by factor of 10. After that, a traditional C/C++ compiler runs the compilation/optimization, which again, costs time. What use is fast a compilation, if the resulting program can be slower by orders of magnitude?

Other than that, the design of the language looks nice and I will give it a spin at some point. Maybe I'll convert some HPC benchmarks to V and see how they perform.

View on HN

This is the same approach that the language Jai (which Jonathan Blow is developing) is using: Fast-to-compile debug builds via hand-written x64 compiler, heavily optimized release builds via LLVM. This is why he was able to have ridiculously high-speed debug builds, and I think V is probably the same right now.

I think J. Blow commented in one of his videos that he might be able to put some optimization on the x64 compiler (such as dataflow optimization) when the language is mostly complete. Although builds will be slower because of this, I still trust Blow that he will make a faster compiler than GCC/Clang, because the compiler will be specialized to its language rather than being all-purpose. (Also, C++ takes ridiculously lot to just parse everything, while Jai is must simpler to parse). Maybe V's developer will also work on some optimizations after the basic compiler's finished.

You can build and test faster using the direct to machine code compiler, then use the C compiler for a final production test and distribution.

You are right in a scenario where testing is lightweight and quick. I'm sure this can cover a lot of use cases. However, If the testing/development itself involves heavy computation (large integration tests for example), there are diminishing return from quick but unoptimized compilation.

I generally agree with what you’re saying in terms of perf comparisons, but high performance debug builds are incredibly important.

On the other hand, the reason they tend to be slow in large c/c++ programs is the module model basically meaning “behold as every file in your project parses and interprets large portions of the host platform’s standard library”. All modern languages know to avoid that - honestly if you want masochism I’d be curious to compare the time-to-execute for modern js engines, simply because they have incredibly large amounts of pressure to get to running code as fast as possible.

Reply on news.ycombinator.com