It's not about the author being a CS major or how the parser is implemented. It's about the author being completely wrong and unwilling to admit it ("parsers are why compilers are slow" -> v 0.2 gets a parser) and being completely ignorant of the basics of writing a compiler.
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)
and a use 5 lines later with no "unsafe" or other escape hatches in sight. Looks to me like you have null, you just don't have a keyword for it.
> No undefined behavior
What's the behavior of
error_msg := charptr(0)
*error_msg
How are they guaranteeing no UB? The compiler works by generating C via string concatenation. Where does the compiler validate the C generated is free of UB? If it's true via construction, then how do basic issues like [this](
https://github.com/vlang/v/issues/6290) [keep](
https://github.com/vlang/v/issues/5912) [happening](
https://github.com/vlang/v/issues/6206)?
> 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
You're telling me I can read a file off disk in a "pure" function? Wat?
> 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.