[paskozdilar]

> Not really, here's a benchmark of V compiling itself in 0.3 seconds that includes all steps (including the C -> binary part) and results in the compiler binary

From what I've seen, you've used tcc for the benchmark, right? If so, that's kinda cheating, since tcc is written to be a simple as possible (and therefore as fast as possible), so the compilation time is essentially zero. Benchmarking with gcc with optimization turned on should give you a more realistic result.

> We have thousands of tests, lots of big projects written in V (V itself is 220k loc, Vinix OS, Ved editor, Gitly, vsql etc), and they all work fine, no compiler errors.

To quote Djikstra:

    Program testing can be used to show the presence of bugs, but never to show their absence.

[dundarious]

The same argument can be levied at any project that goes for a "don't use full LLVM for debug builds where iteration time and hence compile time speed is paramount". That includes projects like cranelift for Rust. I don't think it's reasonable to say this is a wholesale illegitimate/cheating approach.

It has tradeoffs, for the project developer such as the burden of maintaining two significantly different paths for codegen, and for the project user such as the need to trust that these different codegens are largely functionally equivalent (exposing and fixing a bug in debug means it would have been but now will not be present in release). But the tcc approach is arguably one of the better ways to minimize the negatives in this tradeoff, compared to cranelift, etc., as tcc is a small but popular enough project in general usage, meaning it has some battle-testing.

And I think the point about projects that "work fine" was quite reasonable, just showing there has been a non-trivial amount of battle-testing. There is now some basis to claim that the project is not full of trivial bugs, to the point of making it useless. Nowhere was it claimed this was a proof of the absence of all bugs -- that you included the Dijkstra quotation in this context is honestly quite humorous.

My understanding is that there has been some drama in the V community in the past, especially around the feature set and release timeline and promises from its author, but I don't see the justification for all this pompous negativity when it is finally out in the wild, warts and all, but showing some nice capabilities at the same time. I don't plan to use it for any hobby projects myself right now, but if I wasn't in the middle of using a different up-and-coming language with some of the same goals, I might.

[paskozdilar]

> The same argument can be levied at any project that goes for a "don't use full LLVM for debug builds where iteration time and hence compile time speed is paramount"

It would be absurd for someone to write a frontend to LLVM then claim that their compiler is as fast as LLVM. V uses TCC - TCC is fast at compilation, not V. V is fast at transpilation, but that's not what the author has claimed.

> that you included the Dijkstra quotation in this context is honestly quite humorous

Proving compiler correctness with tests only is like proving that your regex parses html correctly with tests. It's never gonna work.

[dundarious]

Does Rust not make claims about performance, even though a large proportion of that comes from LLVM's work? Do Rust or GCC or Clang (or probably even Haskell) use tests as the primary way to ensure/approach correctness? The number of compilers for any language that actually prove correctness and that are used for some practical purpose can probably be counted on one hand (e.g., CompCert), so I'm not going to use that as an appropriate bar.

The tcc backend is just a smart choice, and in TFA it is mentioned up front:

> V compiles ≈110k (Clang backend) and ≈1 million (x64 and tcc backends) lines of code per second per CPU core. (Intel i5-7500, SM0256L SSD, no optimization)

[bheadmaster]

It's trivial to have fast compilation speed if all you do is transpile to C (naively, i.e. without any program analysis) and use TCC to compile the C (again, naively, that's why it's so fast). Such "languages" are often written as CS homework assignments.

But even with the transpilation step, the V transpiler is still unable to output correct code on trivial examples, demonstrated in other comments. The fact that you have thousands of tests (Alex's words) and the trivial examples still fail, makes me completely sure that something about the whole approach is fundamentally wrong; which lead me to the "testing whether your regex parses html properly" comment. Tests are useless if the thing you're testing does not prove anything.

The fact that the author is pushing this unfinished mess as a completed achievement (instead of work in progress), without ever mentioning any downsides (except when presented with undeniable proof, at which point he makes up another justification for the issue), only shows the author's inexperience and disconnection from the community. V compiler is a toy project wrapped up in a pretty box to look like something serious. And when faced with criticism, Alex seems to turn to his three different accounts to argue with the commenters, instead of reading the damn Dragon Book and fixing his damn compiler.

To me, personally, V language is the perfect example of an overhyped griftwork.

[dundarious]

It may be easier to have a C backend that is compiled via tcc, but if it's a smart choice (for the tradeoffs of a debug build), and hardly anybody else is doing it, then it's positive and noteworthy. The fact that it may not be particularly difficult is irrelevant.

I can't assess the quality of V in general, and it may be lacking for my needs, but I know a lot of early stage language projects with a lot of trivial bug reports (I've filed a few), that are still engineering accomplishments capable of real usage. V seems to be in that league. Maybe it's near the bottom of that league, but you can just state that and leave it at that.

Maybe V has a bit of a "dirty main branch" approach, where other languages you're used to tend to instead have long-lasting branches for the work-in-progress stuff. I can see how that would be annoying, being able to use half-finished functionality, and I might not like it myself. Maybe the author claims features are further ahead than they really are -- that would be even more frustrating. But your criticisms are hyperbolic (denigrating the work as at the level of a CS homework assignment, and comparing it to almost entirely non-existent languages that are mathematically provably correct) and often seem vindictive (unlikely to be leveled at other highly analogous early days language projects). Any legitimate criticisms you have are lost in the vitriol.

[amedvednikov]

Can you link to those trivial examples demonstrated in other comments?

[bheadmaster]

https://news.ycombinator.com/item?id=31063731

[amedvednikov]

> I don't think it's reasonable to say this is a wholesale illegitimate/cheating approach.

Thank you for a voice of reason :)

[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.