Maybe something's changed, but, a slightly older review:

https://mawfig.github.io/2022/06/18/v-lang-in-2022.html

Many of the claims were false at the start. Some were fixed, some are in the "extraordinary research needed" category.

None of the claims in this article are relevant now, you can try them yourself.

This is not quite true. The claims about autofree made in the article are still extremely relevant.

For example, the following code from the article still leaks with autofree:

  [heap]
  struct MyHeapValue {
      value i64
  }
  
  fn draw_text(value MyHeapValue) {
  }
  
  fn main() {
      // ...
      arg1 := MyHeapValue { 42 }
      arg2 := MyHeapValue { 100 }
      draw_text(arg1)
      draw_text(arg2)
      // ...
  }

What's more, it leaks even if we completely remove the calls to draw_text and the function definition for draw_text.

autofree is marked as not ready on the website

Sure (although I can't find anything like that on vlang.io myself), but your post was that "[n]one of the claims in this article are relevant now."

It is still relevant that autofree does not work on heap-allocated structs. In particular, this is relevant to the day-to-day usage of the V programming language.

Whether this is well-documented by V itself does not change that it is relevant, in my opinion.

In both the review itself and in V's documentation, from which the example came, it states that autofree is still WIP. It's arguably disingenuous to pretend otherwise or present unintended usage.

The normal "day-to-day" situation would be to have the GC on or as fallback, and to do otherwise (like -gc none or -prealloc), one should know what they are doing or be prepared to deal with such issues.

Those parts of the review, considered relevant in normal usage were resolved:

https://github.com/vlang/v/issues/14803

https://github.com/vlang/v/issues/14787

https://github.com/vlang/v/issues/14786

But even beyond that, the intent of the so-called review was arguably malevolent. It was not done in good faith, to be helpful to the developers or community, but done to spur on drama (thus adding the vaporware link and spamming it) and knowingly looking for ways to bash an alpha version of the language.

But I'm not pretending that autofree isn't documented as WIP, nor am I suggesting that anybody should use anything unintended.

I am simply pointing out that a single claim from the article is still relevant to how V functions today. To be more specific, the still-relevant claim is: "So forcing the value to be allocated on the heap reveals that autofree leaks the values."

The post I am replying to did not say "almost none of the claims in this article are relevant now," it specifically said "none" without qualification.

Maybe I am just unusual in how I use the English language, but I would unquestionably consider this to be a case where you should really qualify the word none, because otherwise it's just not true.

Whether autofree is completely in alpha and intended not to be used or not, the claim from the article that it doesn't work for everything is relevant. I don't see how it couldn't be.

Surely if autofree is WIP, it's no big deal to simply agree that the fact it doesn't work on heap-allocated structs is relevant to its current state?

Now, to be clear, I am aware that arguing over a single extremely small point is, to some degree, missing the point of the comment I was originally replying to. But this is also just how I talk about things on the internet. If part of your claim is untrue, even to an extremely minor degree, I will point that out. This is why when I personally claim things, I almost always qualify what I am saying. (See? Even here I said "almost always," because I just naturally add qualifications so as not to overstate my case).

At this point I can run the ultimate test of new programming languages.

I can test the claims in the article in 5 years.

I have a 90% chance that V will no longer be active, i.e. no active development happening.

I'd love to be proven wrong though, but I'll only find out in 2028.

You can test them today, those are simple checker bugs that were fixed right away.

We're not going anywhere :)

You can check the number of commits over the last 4 years.

> We're not going anywhere :)

That's what everyone says (https://ourincrediblejourney.tumblr.com/).

Only time will tell. I'm not in a rush to use a new language, so as I said above, I can run the ultimate test.

I can check back on V in 5 years from now, if it's still around.

Good luck!

I stopped looking long ago but to my limited understanding, when V says it does X in 1s, it means they delegated the job to gcc faster than others doing the whole work.

Either that or V author is up for a few ACM turing awards.

The main claim, about V doing something in 1s, is about V compiling itself from source, on a modestly modern machine.

That is mainly because of how it is organized. tcc also compiles itself fast, because of how it works, and how it is organised.

That other compilers, like rustc, gcc or clang can not do it, because they have other priorities/tradeoffs, is their problem.

Each line is a different compiler building itself ?

Sorry, I do not understand.

Each line of what?

In the benchmark listed on their website

are they comparing how long it takes for each platform P to compile v sources or P sources ?

If you mean the table under "For comparison, space and time required to build each compiler", I think, that it is about what each compiler took in time and disk space to compile itself, on the same hardware, so it is about P compiling P sources.

V can not compile C or Go, Go can not compile C, and C compilers can not compile V or Go, so it can not be otherwise.

You'd be surprised how much can be optimized even when using the same C compiler.

No header files hell for example.

We need new languages and ideas to keep developing, obviously if someone is willing to put a lots of time and effort they found existing ones lack in something. Even if the difference is only 20%.

Talking specifically about Go, how much time did it take for Go team to acknowledge and make some workarounds to support generics? And this is not a new concept it exists for more than 30 years. I can not imaging Go actually developing and incorporating new things, it is a simple and "completed" language.

So what are the new ideas around V? It literally does the same thing as Go, and as you correctly recognize, Go was already thoroughly uninteresting when it came out from a PL perspective, the only remotely interesting part is its goroutines (though not even that is unique).

V doesn’t even have that, so there are like 10 languages just like that with slightly different syntax.

I don't know much about V, I was answering why new languages are a good thing in general, even if they seem very similar to another.

And I don't think every new language has to have some unique feature too. You can compare almost any modern "scripting" language for example to Common Lisp and ask why they exist, but they do and they enable lots of developers just fine.

They don’t need a unique feature, but they do need at least a unique combination of existing features — languages are as much determined by what features they have as what they don’t.

But V fails to make me interested on this count as well.

It improves on Go a lot: https://vlang.io/compare#go