The reason V is so controversial is that it separates nearly everyone who looks at it into two diametrically opposed groups: those who have some experience or k

The reason V is so controversial is that it separates nearly everyone who looks at it into two diametrically opposed groups: those who have some experience or knowledge of programming language design and implementation and those who do not. The first group are generally the "detractors" and view every concession made to the impossible set of features as a reinforcement of their belief that the language cannot work as advertised. The second group sees every concession as a step closer to the eventual goals, sure that it's simply a matter of time and one more bug fix until the promised result is achieved. Because of this dichotomy, there cannot be completely objective discussion about the language. I would strongly urge anyone thinking of spending time on V to first examine it closely and see if it holds up to detailed scrutiny. In my opinion, V does not and the author knows this but deliberately pretends otherwise for his own personal gain. Of course, you should not solely take my word for this any more than you should take Alex's to the contrary. Consider, if it really was so easy to build a language with the speed of C, the ease of use of Python and the simplicity of Go, why haven't those languages with orders of magnitude more funding simply done so? There are fundamental tradeoffs to language design and it's clear the author does not understand this. The core problem with V is that while many language implementations tread a middle ground between the "just get an MVP out so users can give feedback; ship fast, ship often; as long as it works" engineering mindset and the "ivory tower" academic mindset, V picks the former while giving the finger to a burning pile of compiler books. The author appears willfully ignorant of the basic tecnhiques used to build compilers even going so far as to state that V won't use an abstract syntax tree because "AST is going to require lots of extra CPU power and RAM" [1]. The author later discovered that implementing an AST was actually necessary to make developing the compiler easier and made the compiler faster not slower as he originally proclaimed [2]. A few notes on the advertised feature list: - cross-compilation Cross compilation in V depends on having a C compiler toolchain present for the given target. That is to say, V's cross-compilation story is exactly the same at present as C's is. I'm sure some one will mention the "native backend" which has recently started to be able to build "hello world" without miscompilations. Until such time as it is able to build even slightly complex programs, this is a complete non-sequitur. - native GUI toolkits Native in this context means "compiled code", not that it uses the platform's native UI toolkit. V-UI draws it's own components to the screen and does not use native platform libraries at all other than to open a drawing surface. - auto-free engine that adds necessary free() commands Autofree does not work anywhere close to as well as advertised. Autofree will both leak memory in trivial programs [3] [4] [5] [6] as well as introduce use-after-free and double-free Undefined Behaviors [7] [8] [9] [10]. The autofree Ved demo required changes to Ved to work around autofree's broken state [11]. Autofree cannot work as well as advertised (90%+ of variables handled automatically, down from 100% orignally) without extensive inter-procedural analysis which doesn't exist [12] and would destroy V's compiler performance claims if it did. For anyone who still thinks there might be something to autofree, please explain how this logic for inserting a call to free could possibly be sound [13]: mut af := g.is_autofree && !g.is_builtin_mod && node.op == .assign && node.left_types.len == 1 && (node.left[0] is ast.Ident || node.left[0] is ast.SelectorExpr) - profiler The profiler works by adding instrumentation calls to every function generated in your binary [14]. This can completely change the performance of your program and invalidates the results produced. No mention of this problem exists anywhere in the documentation. In conclusion, people need to stop treating this as some kind of serious up-and-coming language and instead see it as the massive pile of poorly implemented hacks it is. [1]: https://github.com/vlang/v/issues/1255#issuecomment-513565054 https://github.com/vlang/v/issues/1255#issuecomment-51356505... [2]: https://github.com/vlang/v/issues/4128 https://github.com/vlang/v/issues/4128 [3]: https://github.com/vlang/v/issues/14033 https://github.com/vlang/v/issues/14033 [4]: https://github.com/vlang/v/issues/13821 https://github.com/vlang/v/issues/13821 [5]: https://github.com/vlang/v/issues/13539 https://github.com/vlang/v/issues/13539 [6]: https://github.com/vlang/v/issues/12201 https://github.com/vlang/v/issues/12201 [7]: https://github.com/vlang/v/issues/13554 https://github.com/vlang/v/issues/13554 [8]: https://github.com/vlang/v/issues/13398 https://github.com/vlang/v/issues/13398 [9]: https://github.com/vlang/v/issues/12455 https://github.com/vlang/v/issues/12455 [10]: https://github.com/vlang/v/issues/12453 https://github.com/vlang/v/issues/12453 [11]: https://github.com/vlang/ved/commits?author=medvednikov&before=0cc6d72b6ac12724ec424a47f8611b7ca9d7f948+35 https://github.com/vlang/ved/commits?author=medvednikov&befo... [12]: https://github.com/vlang/v/search?q=is_autofree https://github.com/vlang/v/search?q=is_autofree [13]: https://github.com/vlang/v/blob/704e3c6e7275336b5b4f8da2743871f1ee7d5b25/vlib/v/gen/c/assign.v#L30-L33 https://github.com/vlang/v/blob/704e3c6e7275336b5b4f8da27438... [14]: https://github.com/vlang/v/blob/3fa9128716cdc8a794b2ec0be4fb2be454ea25ee/vlib/v/gen/c/profile.v https://github.com/vlang/v/blob/3fa9128716cdc8a794b2ec0be4fb...