It's one thing to like V but it's another to constantly repeat misleading information in an attempt to give it more credence than it has.

Even V's own changelog only contains 28 releases (mostly from the 0.1 era in 2019 - early 2020) not "hundreds" like you've claimed.

https://github.com/vlang/v/blob/master/CHANGELOG.md

https://github.com/vlang/v/pull/14805

Over promising (hardly a one line patch) and under delivering (well beyond your "it will be fixed today" statement) as usual.

https://github.com/vlang/ved/blob/9b85e6291c9fe9135db1e300de...

You have to have type safety to have memory safety and that was the whole point of Rust.

If your threat model legitimately considers the US gov to be a hostile actor, you need far more than a piece of paper that claims what the behavior of your compiler is.

[0]: https://xkcd.com/538/

Sounds to me like you already decided what your conclusion was and are just looking for data to back it up without actually analyzing it.

> YJIT is a relatively simple JIT compiler that totals about 11,000 lines of C code.

If you want to look at GitHub, sure let's do that. I see perhaps 5 regularly active contributors, many more who seem to have left the community, and a downward slope of commit activity starting in April 2020. Hardly some vast hub of activity like your comment would suggest.

Given autofree has been practically untouched in 6 months with no major bug fixes to speak of, reality would seem to be that V is on the slow road to nowhere. At the current rate of progress, I doubt we'll see 0.3 before mid 2023 and 1.0 perhaps sometime in the 2030s. It's been 6 months since anything was completed on the 0.3 checklist: https://github.com/vlang/v/commits/master/ROADMAP.md

- No null

Then what is `voidptr(0)`?

- No global variables

https://github.com/vlang/v/blob/master/doc/docs.md#global-va...

At least add "by default" to the web site.

- No undefined values

Which is done by initializing all values to 0. Probably not a good idea to do that for references though. (See also "no null values")

- No undefined behavior

`*voidptr(0)` is accepted by the compiler. Unsigned integer overflow is accepted by the compiler and UB in the generated C. How can V generate C code free of UB when it can't even generate C code that compiles all the time?

- Pure functions by default

Excluding I/O, one of the biggest sources of impurity, from your definition of pure is useless.

- Generics

You don't actually have generics, you have templates. Kind of ironic since Go has actually added generics before V has managed to get a 0.3 release out. The distinction is this: with generics the compiler is able to validate that the generic code type checks prior to substitution/monomorphization. With templated code, it's not possible to perform type checking until the concrete types have been instantiated. V implements templates with all the drawbacks including code bloat and inflated compile times that comes with it.

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)

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-51356505...

[2]: https://github.com/vlang/v/issues/4128

[3]: https://github.com/vlang/v/issues/14033

[4]: https://github.com/vlang/v/issues/13821

[5]: https://github.com/vlang/v/issues/13539

[6]: https://github.com/vlang/v/issues/12201

[7]: https://github.com/vlang/v/issues/13554

[8]: https://github.com/vlang/v/issues/13398

[9]: https://github.com/vlang/v/issues/12455

[10]: https://github.com/vlang/v/issues/12453

[11]: https://github.com/vlang/ved/commits?author=medvednikov&befo...

[12]: https://github.com/vlang/v/search?q=is_autofree

[13]: https://github.com/vlang/v/blob/704e3c6e7275336b5b4f8da27438...

[14]: https://github.com/vlang/v/blob/3fa9128716cdc8a794b2ec0be4fb...