v

/twitter.com/v_language/status/1234586123424456705 [2]: https://github.com/vlang/v/blob/bc288019932c35cc09dcf7b438bc... [3]: https://github.com/vlang/v/tree/bc288019932c35cc09dcf7b438bc...

pecially with -autofree), this is baloney. Author has yet to set up PVS or Coverity although it was suggested a few days ago on Discord. Again, baloney. `-Wall -pedantic` Given V can't even compile valid V programs consistently without generating C _errors_ I find this extremely difficult to believe. > Stability. New languages using LLVM directly are going to crash often. That's inevitable, and can be seen across all new languages using LLVM. The V compiler hasn't crashed once for me, and I haven't received any crash reports from other users. V issue tracker has lots of instances of the V compiler crashing. "I haven't received any crash reports from other users" is a verifiable fabrication. ([1](https://github.com/vlang/v/issues/6310), [2](https://github.com/vlang/v/issues/6263), [3](https://github.com/vlang/v/issues/4730)) > Simplicity. LLVM is a huge C++ dependency, meaning that both developers of the language and the users are forced to install it. Calling C++ is not easy from V/C, so C wrappers have to be used, increasing the number of dependencies and complexities. But you need a C compiler. `v -o` requires either clang (and thus LLVM) or GCC both of which are massive dependencies. This logic rings hollow.

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.