[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

[dundarious]

All of those issues are related to autofree. From vlang.io:

> Note: right now autofree is hidden behind the -autofree flag. It will be enabled by default in V 0.3.

I'm assuming because it's not considered good enough quality yet. It would be better to be explicit about that, but it's not unreasonable as-is.

I think it's only reasonable to mostly ignore autofree issues when assessing whether the language has trivial issues. Count all those issues as a single "autofree is alpha quality" conceptual issue. Counting each individual autofree issue in order to convey the sense that there is a critical mass of issues in the project in general is quite harsh, I think.

[amedvednikov]

There are no trivial examples unable to output correct code in that comment.

Your attempts to discredit the language are just sad.

[paskozdilar]

Alright, you cheeky bastard. It's on.

You can expect a deep (and public) analysis of everything you've done with V in a couple of months. We'll see who's right.