Actually, if the author really is a teenager, you do owe him better. Teenagers should be encouraged and educated, not beaten with internet clubs. And whether he really is a teenager or not, using that word as an insult is not in the spirit of HN.
I understand how annoying it can be when someone makes inflated or false claims about their project, but if you're going to react to that, please don't do it in a way that damages the commons.
We detached this subthread from https://news.ycombinator.com/item?id=24483203.
Now I don't know if you're right or wrong, but that whole attitude is a turn-off unless you're obviously right every single time, and from a cursory glance, V looks like it has some things that I like the look of.
I really don't care about the technical awesomeness or lack thereof of the parser, if it works. I really couldn't care less if the author is a CS major, if he's produced something good. I'm not making the judgement about whether it's good or not because V is new to me, but I'm prepared to give him the benefit of the doubt until I've tried it, and someone barfing all over every aspect of the project doesn't come across well.
I'm not downvoting you (I can't even if I wanted to :) but there's not much in this world that is utterly without any redeeming factor, and you seem to be trying to persuade everyone that V is one of those things. Maybe it is. I guess we'll see.
My generous side says this might just be a language or communication issue but my cynical side says $900 a month on Patreon has a lot to do with it.
However, my pet peeves with the project basically just boil down to the half-truths or outright lies on the home page:
> No null
From their own docs: https://github.com/vlang/v/blob/master/doc/docs.md#calling-c...
we see
error_msg := charptr(0)
> No undefined behavior
What's the behavior of
error_msg := charptr(0)
*error_msg
> Pure functions by default
https://github.com/vlang/v/blob/master/doc/docs.md#pure-func...
https://github.com/vlang/v/blob/master/doc/docs.md#pure-functions-by-default
> Generics
Generics only work if there's 0 or 1 type parameters. Support for generics in general is "alpha" quality at best. [Lots of correct code just segfaults the compiler](https://github.com/vlang/v/issues/6263). (If the language has no UB and has bounds checking, why does the compiler seg fault?)
Array.map and Array.filter are not regular library functions with a generic type, they're special cased in the compiler with special syntax.
> V is written in V and compiles itself in under a second.
That's not what fast.vlang.io says: 2080ms.
They could just say that it compiles very fast and link to their benchmark site.
I'm not even going to touch the "no dependencies" claim when you need a C compiler (and often two if you want optimizations).
> C translation (wip)
WIP is overly generous. A very broken version of c2v was released for v0.1 and never updated for v0.2.
> V can emit (human readable) C, so you get the great platform support and optimization of GCC and Clang.
Hopefully you consider C files over 100,000 lines to be readable.
> Powerful built-in web framework > Built-in ORM
Maybe focus should be spent instead on completing the memory management story which is still a TODO item?
[The author doesn't seem to even understand what he's trying to do.](https://github.com/vlang/v/issues/1247#issuecomment-51346731...)
When asked what the plan is there, all the community says is that it will be similar to Lobster's (searching "Lobster" on their Discord will show numerous results). However when the reasons why that can't work with V as is currently exists are pointed out, [there is silence](https://github.com/vlang/v/issues/1247#issuecomment-68018256...). Meanwhile, V has already [promised no breaking changes for at least 5 or 10 years](https://github.com/vlang/v#stability-guarantee-and-future-ch...). Perhaps that should have been done after deciding how memory management would work?
You'd think this would be pretty much the top priority at the moment but the handful of buggy commits say otherwise:
- https://github.com/vlang/v/commit/bffa100aa6fbf4842aa6b4f442...
- https://github.com/vlang/v/commit/db51ee08ea269b17bec97fb102...
- https://github.com/vlang/v/commit/b74c1805d72df8fd6e30cc236a...
- https://github.com/vlang/v/commit/e0d20eadff113b3f36fb96226b...
If look closely, you'll see lots of code under the "autofree" path is commented out. I guess you can't have use after free if you never free?
You'll also notice the author has a consistent pattern of committing commented out code, uncommenting it in a later commit and then recommenting it again because it never worked in the first place. This is probably why the author refuses to go use the PR process for themselves and instead pushes directly to master often breaking CI and the project for everyone else.
The problem with V in my opinion is not that it has high aspirations, it's that doesn't distinguish between aspirations and the mostly unimplemented barely functioning reality of the present. Only the happiest of happy paths currently work which is probably only 10% of the effort required to make a serious programming language. You'd think from their website and their fanatics that they're nearly there when they have yet to even realize how much work hasn't even been started yet.
> 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 $
>> 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 $
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?
foo := charptr(0)
x := *foo
foo := charptr(0)
x := **********foo
Unless you're a chef you're not allowed to say some food tastes bad?
Unless you're a programmer you cannot write bug reports?
No one can write a product review unless they're able to create an instance of the product by themselves?
That's not how it works and [edit]not[/edit] a good reply to someone critiquing something.
Had you written exactly that, you would've gotten the reply you expected from them. Apologies for the misunderstanding.
Also, engineers don't do dishonest marketing doesn't mean they can't be good at it.
In the case of V it's clearly worked hasn't it? Seems like there is a community growing in V and people are contributing to the language.