vc

b.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 <file:///usr/share/doc/gcc-7/README.Bugs> 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).

ill_raise_your_cortisol_levels.v:2:2: error: `error_msg` is immutable, declare it with `mut` to make it mutable 1 | error_msg := charptr(0) 2 | *error_msg = 1 | ~~~~~~~~~ 1[23:05:35] /v/nv LINUX $ 0[23:05:36] /v/nv LINUX $ cat > hate_will_raise_your_cortisol_levels.v mut error_msg := charptr(0) *error_msg = 1 0[23:06:13] /v/nv LINUX $ ./v run hate_will_raise_your_cortisol_levels.v hate_will_raise_your_cortisol_levels.v:2:12: error: modifying variables via dereferencing can only be done in `unsafe` blocks 1 | mut error_msg := charptr(0) 2 | *error_msg = 1 | ^ 1[23:06:13] /v/nv LINUX $ Note that charptr is intended to be used only for easier C interoperability, not in pure V code. Also note, that the V language implementation has not yet reached version 0.2 , and new checks about undefined and dangerous behavior are added on a regular basis. >> V is written in V and compiles itself in under a second. > That's not what fast.vlang.io says: 2080ms. Both are true. What you seem to lack in understanding, is that performance comparisons with absolute time need also another dimension - the hardware on which they are run, and also what backend C compiler is used. On my i3-3225 for example, I can recompile v with tcc in ~0.6s on average (and under 0.5s when v was compiled with clang before that): 0[23:16:04] /v/nv LINUX $ time ./v -cc gcc -show-timings self V self compiling (-cc gcc -show-timings)... PARSE: 175 ms CHECK: 64 ms C GEN: 116 ms C gcc: 4422 ms real 0m4.792s user 0m4.604s sys 0m0.159s 0[23:16:22] /v/nv LINUX $ time ./v -cc clang -show-timings self V self compiling (-cc clang -show-timings)... PARSE: 167 ms CHECK: 62 ms C GEN: 118 ms C clang: 2265 ms real 0m2.629s user 0m2.499s sys 0m0.108s 0[23:16:31] /v/nv LINUX $ time ./v -cc tcc -show-timings self V self compiling (-cc tcc -show-timings)... PARSE: 186 ms CHECK: 66 ms C GEN: 117 ms C tcc: 104 ms real 0m0.489s user 0m0.437s sys 0m0.050s 0[23:16:36] /v/nv LINUX $ > They could just say that it compiles very fast and link to their benchmark site. Yes, but for most people with average hardware produced in the last 10 years, the times will be < 1s much more likely than not, while recompiling from scratch say gcc, or clang, or go for that matter, will definitely not happen for < 1s even with very powerful hardware ... > I'm not even going to touch the "no dependencies" claim when you need a C compiler (and often two if you want optimizations). The V compiler itself do not have dependencies - it is a single C file (see https://github.com/vlang/vc/blob/master/v.c), that can be generated from its V source code (with `./v -o v.c cmd/v`). That v.c file, can then be used to bootstrap v, by needing just a working C99 compiler. In fact that is exactly what the make.bat and Makefile do. You can use just one working C99 compiler, for example gcc to bootstrap v. If you mean that you need 2 compilers, because tcc is so much faster but it does not optimize, well yeah, I do like to use tcc while developing, and then use gcc only when releasing. In my opinion, having the choice to do that is a big feature, not a disadvantage. > Hopefully you consider C files over 100,000 lines to be readable. You can use `-printfn module__func_name` to read single generated C functions that are of interest to you directly in your shell, there is no need to look at the whole generated .c file. Plus even with the full file, most editors have the amazing ability to search for text, so you do not have to read the whole file from start to finish. > Maybe focus should be spent instead on completing the memory management story which is still a TODO item? May be your focus should be on helping the projects that you like, instead of complaining about the ones you do not?