I never understood the motivations behind V. It's clearly not a hobby project started out by a developer who is genuinely experimenting with PLs and want to put out something unique. It feels more like a stunt or a flair to either extort money or become famous. All that would be perfectly okay if V did what it claims to do but the author fanatically makes exciting claims but implements only fluff to hide the underlying broken machinery.

I tried V when it first got popular (about 3 years ago). I am no expert on languages but the way it was ductaped (AST-less compiler for "performance", a "graphic library" when even basic things don't work etc etc) made me eventually lose interest.

3 years later V is still mostly where I left it. If the V author focused on the stabilizing the compiler instead of starting off shoot projects like vui, vdb etc. it might actually work.

Ductaped languages can be extremely useful though (cf. PHP). But extraordinary claims were what failed V and---sadly and contrary to my remaining hope---continue to do so.

Can you list here the extraordinary claims that failed please.

Read correctly; I said extraordinary claims failed V. But the other reading doesn't seem to paint a pretty picture anyway. Every point made in the original article is a reasonable expectation by outsiders, and many of them are still unsatisfactory ("failed claims" if you like).

What you should do now is to decide what to do with those points instead of arguing. If the decision is WONTFIX (okay to do, not everything can be made into the language) then the advertisement should be updated (ProTip: you should really have done this years ago). If the decision is to do something with that then the advertisement should be still updated, hopefully with a link to the tracking issue. If you are already doing something about that then you still should have a link to the tracking issue. If the point is "misleading", then you should write out clearly why it's misleading, how the author could have concluded in that way (i.e. assume no malice and debug instead), and how to verify your updated claim. With no strings attached.

Honestly though these points have been iterated and reiterated years ago. I had a hope that you have learned (hard) from that past experience; my hope seems not justified.

Can you elaborate how language features failed V? And what claims were extraordinary?

Like the language compiling itself in <1s? It's true and you can verify it yourself:

https://www.youtube.com/watch?v=pvP6wmcl_Sc

Look, you are doing what I've just said not to do. I have nothing to say because the OP did most of claims already, you should directly respond to the OP.

And you are slightly altering the very claim you've already said; the OP specificially tests the claim that "V compiles [...] ~1 million (x86 and tcc backends) lines of code per second per CPU core", which I can easily verify on my machine (1m_helloworld.v took 25.5 and 15.5 seconds to compile under the same settings). To be fair these test files are edge cases you can easily dismiss (ProTip: you can make your advertisements more accurate), but edge cases show the weakness of your design and you should not confront them.

You made a claim:

> extraordinary claims failed V.

I asked you to list such claims. You fail to do so.

There's no way it takes 15s to compile 1m_helloworld.v. You're probably using a debug build of V.

What's your hardware? CPU/SSD.

You don't have to guess because I can give you my log. I have exactly followed what the OP did, except for more recent revision because I couldn't get it compiled in my environment.

    $ git clone https://github.com/vlang/v/
    $ cd v
    $ git checkout 0e4198f23b2b9a52d72f61dd40d019412b809791

    $ VFLAGS="-prod" make
    make fresh_vc
    make[1]: Entering directory '/tmp/v'
    rm -rf ./vc
    git clone --depth 1 --quiet --single-branch https://github.com/vlang/vc ./vc
    make[1]: Leaving directory '/tmp/v'
    cd ./vc && git clean -xf && git pull --quiet
    make fresh_tcc
    make[1]: Entering directory '/tmp/v'
    rm -rf ./thirdparty/tcc
    git clone --depth 1 --quiet --single-branch --branch thirdparty-linux-amd64 https://github.com/vlang/tccbin ./thirdparty/tcc
    make[2]: Entering directory '/tmp/v'
    make[2]: Leaving directory '/tmp/v'
    make[1]: Leaving directory '/tmp/v'
    cd ./thirdparty/tcc && git clean -xf && git pull --quiet
    cc  -std=gnu99 -w -o v1.exe ./vc/v.c -lm -lpthread
    ./v1.exe -no-parallel -o v2.exe -prod cmd/v
    ./v2.exe -o ./v -prod cmd/v
    rm -rf v1.exe v2.exe
    Note: building an optimized binary takes much longer. It shouldn't be used with `v run`.
    Use `v run` without optimization, or build an optimized binary with -prod first, then run it separately.

    Note: `tcc` was not used, so unless you install it yourself, your backend
    C compiler will be `cc`, which is usually either `clang`, `gcc` or `msvc`.

    These C compilers, are several times slower at compiling C source code,
    compared to `tcc`. They do produce more optimised executables, but that
    is done at the cost of compilation speed.

    V has been successfully built
    V 0.2.4 0e4198f

    $ cat > t.sh && chmod a+x t.sh && ./t.sh > 1m_helloworld.v
    #!/bin/bash
    echo 'fn main() {'
    for i in {3..1000000}
    do
        echo '    println("hello world")'
    done
    echo '}'

    $ time ./v 1m_helloworld.v
    parsed 100000 statements so far from fn main.main ...
    parsed 200000 statements so far from fn main.main ...
    parsed 300000 statements so far from fn main.main ...
    parsed 400000 statements so far from fn main.main ...
    parsed 500000 statements so far from fn main.main ...
    parsed 600000 statements so far from fn main.main ...
    parsed 700000 statements so far from fn main.main ...
    parsed 800000 statements so far from fn main.main ...
    parsed 900000 statements so far from fn main.main ...

    real    0m14.929s
    user    0m6.516s
    sys     0m8.031s

    $ mv thirdparty/tcc/tcc.exe thirdparty/tcc/tcc.exe.orig

    $ time ./v 1m_helloworld.v
    parsed 100000 statements so far from fn main.main ...
    parsed 200000 statements so far from fn main.main ...
    parsed 300000 statements so far from fn main.main ...
    parsed 400000 statements so far from fn main.main ...
    parsed 500000 statements so far from fn main.main ...
    parsed 600000 statements so far from fn main.main ...
    parsed 700000 statements so far from fn main.main ...
    parsed 800000 statements so far from fn main.main ...
    parsed 900000 statements so far from fn main.main ...
    ==================
    cc: internal compiler error: Killed (program cc1)
    Please submit a full bug report,
    with preprocessed source if appropriate.
    See  for instructions.
    ...
    ==================
    (Use `v -cg` to print the entire error message)

    builder error:
    ==================
    C error. This should never happen.

    This is a compiler bug, please report it using `v bug file.v`.

    https://github.com/vlang/v/issues/new/choose

    You can also use #help on Discord: https://discord.gg/vlang


    real    6m50.090s
    user    6m8.375s
    sys     0m31.094s

> What's your hardware? CPU/SSD.

i7-7700 3.60 GHz, 48 GB of RAM, SSD in use, Windows 10 WSL (that's probably why kernel time is higher than average, otherwise my userland time agrees with the OP).