4 ms·

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 paramo

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.

amedvednikov 5y ago
> I don't think it's reasonable to say this is a wholesale illegitimate/cheating approach. Thank you for a voice of reason :)
paskozdilar 5y ago
> 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 5y ago
  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)
  - deleted 5y ago
    [deleted]
  - bheadmaster 5y ago
    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.
    - 5y ago

amedvednikov 5y ago

> I don't think it's reasonable to say this is a wholesale illegitimate/cheating approach. Thank you for a voice of reason :)

paskozdilar 5y ago

> 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 5y ago
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)
- deleted 5y ago
  [deleted]
- bheadmaster 5y ago
  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.
  - 5y ago