> What's the behavior of error_msg := charptr(0) error_msg
1[23:04:49] /v/nv LINUX $ cat > hate_will_raise_your_cortisol_levels.v
error_msg := charptr(0)
*error_msg
0[23:05:12] /v/nv LINUX $ ./v run hate_will_raise_your_cortisol_levels.v
hate_will_raise_your_cortisol_levels.v:2:2: error: undefined variable: `error_msg`
1 | error_msg := charptr(0)
2 | *error_msg
| ~~~~~~~~~
1[23:05:14] /v/nv LINUX $ cat > hate_will_raise_your_cortisol_levels.v
error_msg := charptr(0)
*error_msg = 1
0[23:05:32] /v/nv LINUX $ ./v run hate_will_raise_your_cortisol_levels.v
hate_will_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?