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.
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.
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)
// ...
}
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.
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.
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).
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.
We're not going anywhere :)
You can check the number of commits over the last 4 years.
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!