[vlang1dot0]

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

[super_flanker]

Thanks for taking time and explaining things around v's state of affairs.

Also I'd like to add that V's first feature, "no null" is a myth. V supports initializing a reference with 0, which is null/nil or whatever you call it.

I'm pretty sure v's author will not bother responding to a well laid out facts.

[Tozen]

Actually, V's author was gracious enough to come to HN to address and answer a number of users (including on this thread). This includes that he has previously answered questions by vlang1dot0 (on other threads), despite repeated attempts at spreading misinformation or the obvious and continual trolling (with just the username alone).

If you notice, HN doesn't have zig1dot0, nim1dot0, or odin1dot0 accounts trolling any threads they can find pertaining to the language or alluding to why they aren't at 1.0 yet. Despite the fact that both Zig and Odin started around 2016 (3 or more years before Vlang) and have yet to achieve 1.0. Zig only managed self-hosting this year (2022), after more than 6 years of existence. Nim took 11 years to reach 1.0 (created 2008 to achieved 1.0 in 2019).

Add to this, the incessant and demonstrably false claims that V is vaporware or fake despite it having over 90 releases, applications written in it, and thorough documentation about the language.

https://github.com/vlang/v/releases (releases) https://github.com/vlang/v/blob/master/doc/docs.md (documentation) https://modules.vlang.io/ (modules)

By the way, types in V are zeroed by default. Zeroed means that they are assigned default values. Empty string for string types, 0 for integers, and false for Boolean types. When not sure what to initialize variables with, it is recommended to make them mutable, so to be updated as needed. In V, you don't assign null or nil. There isn't any *ptr = NULL or Var := nil. That is the context in which they are referring to.

[Tozen]

First, nobody should take what you have posted as an honest assessment, because your username is for the explicit purpose of trolling. Running around with the name "vlang1dot0", demonstrates a commitment to being a hardcore troll and spreading misinformation.

As with any attempt at propaganda and misinformation, you are taking elements of truth and then greatly distorting it to fit your agenda. Which is possibly to hurt your competition, because of developing or being heavily invested in a competing language. It would be much more honest to come out and say what your preferred language is and what your involvement with it is, than to put on a troll costume and do hit posts.

> ...Because of this dichotomy, there cannot be completely objective discussion about the language.

No, you have created a false dichotomy. You can not be objective, because of your bias and possible investment in other languages.

> 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?

This is a straw man argument. It would be like someone saying, "If the car was really such a good idea, why wasn't it invented by the Egyptians back in 1000 BC? They had plenty of gold and engineers."

Programming languages are built upon and borrow from each other. It is the prior existence of C, Python, and Go that something new which is blended from various elements of each, with various new concepts added, can be created. Thus we can have Vlang and various other newer languages.

-Cross compilation

You didn't refute that Vlang can do it, but rather it doesn't meet your preferences. So damn what it makes use of C compilers, for now or as an option in the future? So have other languages. Not to mention, Vlang has very strong interop with C, to begin with.

And they are working on the native backend, which is producing results, and will only get better. It must also be kept in mind how young Vlang is as a language, which started from 2019. So its level of progress and popularity is arguably amazing, and has surpassed a number of its rivals. It is asinine to compare a language of such young age to those from say 2008 or the 1990s, who at the same comparative stages were less advanced.

- native GUI toolkits

Again, you are spouting out your preferences. Furthermore, Vlang has a number of GUI wrapper libraries. Such as: vsdl/vsdl2, vig (ImGui), vnk (nuklear), viup (IUP), etc... If a person doesn't want to use the VUI (written in V), they can hop over to a bunch of others.

- Autofree

The developers have repeatedly said that it wouldn't be ready until 0.3 of the language. It exists and functions, but they are working on improving it, which is not anything unusual at this stage. People can disable it with -noautofree, and do manual memory management. There is -prealloc too. There is also GC (-gc boehm).

The developers have stated there would be a few memory management options, of which there will be at least -autofree and -gc boehm. Not sure why certain people are getting their panties all twisted, when a number of other programming languages also have multiple memory management options, to include those languages having had all kinds of development problems and they still have issues.

- GitHub Issues

This is probably the more ludicrous part of your post. All popular programming languages on GitHub will have a long list of issues. The more popular, the more you will see. For example, Rust has nearly 8,000 OPEN issues. If someone listed them all on HN, would they win any points?

The true point is that issues submitted, are those that contributors and developers work on to resolve. Using an open issue as a reference to attempt to prove a language is somehow deficient is very, very deceptive. That's a problem they are fixing and will usually fix (sooner or later), or discover it's not really an issue as user error. More importantly, is how useful those users, supporters, and contributors feel the language is. That's why Vlang is constantly gaining in popularity, despite angry detractors and competitors.

Troll hit jobs will simply not stop Vlang, and just reflects an odd desperation in wishing it would. Whatever programming language that you prefer or are developing, it should be able to stand on its own merits, without the need for trolling others.