What does HackerNews think of v?

It is very easy to verify. Just have a working C compiler + git + make:

    git clone https://github.com/vlang/v
    cd v
    make
    ./v your_program.v

On a modern machine with good network, it will take you under a minute, to have your own copy of latest V, and less than 200MB, including the .git/ folders.

You can also download .zip releases from https://github.com/vlang/v/releases , without needing git. The .zips there are <15MB, and contain a prebuilt V executable, so you do not even need make to use it.

I mean what it would be nice to have no forced leaks also when using the -manualfree command line option.

However, I just checked, and the 0.3 release does leak even without -manualfree!

    lxc launch images:debian/bullseye test-v
    lxc exec test-v bash

    # Inside the container:
    apt install build-essential git valgrind
    git clone https://github.com/vlang/v
    cd v
    git rev-parse HEAD
    # 74bb5ae17a4a0af8dda913ddb1ca9d8d4a590136
    make
    # ...
    # Your `tcc` is working. Good - it is much faster at compiling C source code.
    # V has been successfully built
    # V 0.3.0 74bb5ae

    ./v examples/hello_world.v

    valgrind --leak-check=yes examples/hello_world
    # ... report about invalid read of size 1.
    # ... reports about uninitialized values.
    # ==5750== LEAK SUMMARY:
    # ==5750==    definitely lost: 0 bytes in 0 blocks
    # ==5750==    indirectly lost: 0 bytes in 0 blocks
    # ==5750==      possibly lost: 1,360 bytes in 5 blocks
    # ==5750==    still reachable: 0 bytes in 0 blocks
    # ==5750==         suppressed: 0 bytes in 0 blocks
    # ...
    # ==5750== ERROR SUMMARY: 144 errors from 17 contexts (suppressed: 0 from 0)

I checked also with the 0.3 release: https://github.com/vlang/v/releases/tag/0.3

    apt install wget unzip

    rm v -r
    wget https://github.com/vlang/v/releases/download/0.3/v_linux.zip
    sha1sum v_linux.zip
    # bb6f81630fe2ae4e7e283360f507be99f88f32bd  v_linux.zip
    unzip v_linux.zip

    cd v
    ./v examples/hello_world.v 
    valgrind --leak-check=yes examples/hello_world
    # Exact same result as above, just a different PID of course.

Am I missing something?

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

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

I have also verified that TCC was indeed in use:

    $ 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

(I gave up when the gcc memory usage ballooned up to 20 GB.)

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