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 ar

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-functions-from-v 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 https://github.com/vlang/v/issues/6290) [keep](https://github.com/vlang/v/issues/5912 https://github.com/vlang/v/issues/5912) [happening](https://github.com/vlang/v/issues/6206 https://github.com/vlang/v/issues/6206)? > Pure functions by default https://github.com/vlang/v/blob/master/doc/docs.md#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 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-513467311 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-680182564 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-changes 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/bffa100aa6fbf4842aa6b4f442bd2c273ac35c7f https://github.com/vlang/v/commit/bffa100aa6fbf4842aa6b4f442... - https://github.com/vlang/v/commit/db51ee08ea269b17bec97fb102f3720914bb2994 https://github.com/vlang/v/commit/db51ee08ea269b17bec97fb102... - https://github.com/vlang/v/commit/b74c1805d72df8fd6e30cc236a8ada0f7717ab9a https://github.com/vlang/v/commit/b74c1805d72df8fd6e30cc236a... - https://github.com/vlang/v/commit/e0d20eadff113b3f36fb96226b228793c42febf1 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.