[amedvednikov]

V is also written to be as simple as possible :)

Compilation time is very important during development for the quick dev cycle (change, build, test).

You don't need to do -O2 builds dozens of times per day.

-prod (-O2) builds are definitely an order of magnitude slower, that's a fact.

[vlovich123]

What is the performance delta between debug and prod? What is the performance delta between tcc and GCC -O0 if you’ve had a chance to compare?

I also disagree with others that using a different compiler is somehow cheating. Engineering is about winning and choosing the right tradeoffs. Being able to choose a faster backend for debug is one that all compilers offer. Most people spend most of the time living with -O0 builds because they need to debug the code. Heck, 90% of complaints about Rust compile times are about its performance making a debug build and it’s where that dev team spends its efforts. This criticism seems misplaced although it’s not clear to me why there’s this much pushback that most other languages don’t see.

[amedvednikov]

No difference between tcc and gcc -O0, despite tcc compiling it 10 times faster.

20%-100% difference between gcc -O0 and -O2.

[paskozdilar]

It's a dishonest benchmark. You're basically saying that "V compiles fast if you use a fast C compiler after the transpilation step", and wrapping it up as "V compiles fast". Those two are not exactly the same.

[amedvednikov]

It's absolutely not a dishonest benchmark. This backend comes bundled with V, it's what it uses by default. That's how you get the end result binaries when you use V.

To the end user it doesn't matter how the binary was generated. Via LLVM or via a bundled C compiler.

The only thing that matters: getting that binary after compilation and getting it fast.

[paskozdilar]

At this point, I'm sure you can find a justification for any kind of criticism anyone brings up, so I will stop bringing it up. Sorry for being a bother, and good luck with your Go clone.

[amedvednikov]

It's not a justification. It's how it works. People download the language, they use it to compile a binary, it's produced quickly.

I'm not sure how you can argue about that.

[kgeist]

Did you consider writing an interpreter for the quick dev cycle mode instead? Compilation times are down to 0 seconds (if we ignore the parsing time). As LuaJIT's Mike Pall has shown, a well-thought out interpreter can be as fast as a naive compiler. It's also more portable, and experiments are easier to introduce. The main page at vlang.io focuses on compilation speed, not runtime speed. You also admit that the fast compilation mode uses simpler backends without optimizations. So why not just interpret it, if compilation speed and quick dev cycles is number one priority? That's what interpreted languages already excel at.

[amedvednikov]

Runtime speed is as fast as it gets, because it's C.

Writing an interpreter is a huge task. It works well without it. Actually I'd say it's quicker, because interpreters have startup costs.

[vlang1dot0]

No, "it's fast because it's C" doesn't hold. You can write slow code in any language.