I think the critical thing of V, which article only mentions in passing, is it's "Fake it till you make it" philosophy. For me, this completely kills any interest I might have in the language.
In particular, many people close to the language make great-sounding claims, which are simply not true.
An example: if you go to https://vlang.io/, right there in "Safety" section, it mentions "No null (allowed in unsafe code)"
So you might think: great! This sounds like Rust but without all the tedious errors, I hate null pointer exceptions! But turns out this is pretty much a lie, there may be no "null" keyword, but it's not that hard to get it. Go to https://play.vlang.io/, enter the program and press "run":
&nil
/box/code.v:4: at main__main: RUNTIME ERROR: invalid memory access
/tmp/v_60000/code.01JVGJG6KBEYKWAMZZR4YPHR0S.tmp.c:10807: by main
Exited with error status 255
that sure looks like a null to me (except spelled "nil").. and behaves as it was a null too. And no "unsafe" in sight!
Would you trust the language which outright lies about the basic features on its own front page? I certainly would not recommend so.
(Alternative interpretation is that this was not an intentional lie, but rather that language designers never thought how "no null" and "can create array of pointers without unsafe" rules would interact together.. That's even worse IMHO)
baranul · 49d ago
"Null" is not used in "proper" V. It's not a keyword assigned to any variables, outside of unsafe, and even that is strongly discouraged. Additionally, all variables in V have to be initialized with some value and the required memory (which leads to the error from cap being set to 0).
V can compile to C, including native (still in development) and other languages (WASM, JavaScript...), so depending on what someone is doing they can see related error messages. Additionally, there is the circumstance of keeping compatibility with other languages. This is why V has "nil", which is explained in the documentation, but its their objective to eliminate or contain its usage to only unsafe.
From their documentation- "Zero-value references, or nil pointers, will NOT be supported in the future...". Users of V would be familiar with the circumstances and context, to include seeing examples of proper usage.
theamk · 49d ago
I have no objection to Vlang having "null", after all many languages have it. My problem is the outright lies on the front page. Someone who is looking into Vlang might actually believe what's written on the front page, spend some time learning language, and come up disappointed. So I am saving them some time by warning them in advance.
And no, if you that using null is V is "improper", this still means V has nulls. If the it will not have nulls "in the future", it means it still has nulls today. The front page does not mention any "future" part. And mentioning that you cannot assign it to any variables outside of "unsafe" is outright wrong.. It works just fine, it's just spelled differently (as "voidptr(0)"). Try it yourself in playground:
ptr := &int(voidptr(0)); println(*ptr);
The thing is, there are plenty of languages without "null" - Rust of course, but also much more "conventional" languages like Kotlin and Swift. So we know what language-without-nulls looks like - there are nullable and non-nullable pointer-things (they may be called using different terms), they are distinct types, and you need a special ceremony to access nullable pointer-things where you specify what to do if the value is null/missing. Vlang does not have anything like that, and it's trivially easy to get the null pointer (either intentionally or from trivial programming error) in safe code.
baranul · 49d ago
This comes across as a poorly written article that has the intent to capitalize on controversy generated by V's adversaries. Sadly, the author appears to have spent little time doing any studying of the language or community, outside of seeing how such controversies can be used for click-bait purposes.
Raylib is not the main UI library of V nor is it promoted as such. Instead, VUI[1] (which is on the main site) would usually be used or related UI toolkits such as IUI[2], MUI[3], or GUI[4]. Instead of appreciation for how V contributors used C2V[5] to create an up to date binding to a popular library (Raylib) for their community, they are figuratively "kicked in the teeth" for their efforts. That's after taking an unneeded swipe at even the name of VPM (which is descriptive to its purpose).
Globals are not used a lot in V nor are they encouraged. Instead of globals, users of V would use struct fields that hold data between function calls. Globals are to be only used under certain circumstances or for specific compatibility reasons with other languages, and is activated only through a flag.
It is conveniently forgotten that V is many years younger than the other languages referred to. Despite this, it's forced to carry the unrealistic expectations of critics, from before it was even released to the public and while still in alpha and beta.
Amazingly, its older competitors are allowed to not deliver on their "promises" (twist the definitions of project goals), be hobbled by thousands of issues (per their GitHubs), and continue to fail at achieving 1.0 (and likely no time in the next few years).
Then the final "kick below the belt", is to give the impression that V doesn't challenge its older rivals. But if we look on TIOBE, we find that V is ranked 43 (May 2025). Zig, Odin, C3, etc... are not even in the TIOBE top 50. Jai at least has an excuse, as is not public, but is still several years older. Not only does V challenge the other so-called players, but appears subject to forces trying to derail or harm the project.
All of this is true. I think a lot of us in this community are getting sick and tired of the queer anti-V religion.
valunord · 49d ago
This piece cherry-picks misfires, ignores the last couple years of solid momentum, and pads its case with biased jabs while skipping repos that actually ship code in V. It lands as a “see, I told you so” hit, not a balanced review... Its takes on memory, stdlib, and maturity are half-true at best.
Not a trustworthy article.
benstigsen · 49d ago
I disagree. Having been a previous V developer contributing to the language (though arguably very little), the issues of missed deadlines, fake it till you make it and more seems completely valid.
If you join the Discord and search for "this week", "this month", "next week" and "next month" with Alex Medvednikov as the author, you'll see 80+ (yes, that many) missed deadlines, some that go all the way back to 2019.
Version 0.3 promised autofree and a syntax freeze, it got none of those. I remember discussing this with Alex, saying that it would be ideal, to publicly mention that autofree wouldn't be included in the release, and it is as if he just couldn't see why that type of communication was important.
There were also instances of moderators publicly being mean to other chatters, _especially_ when asking about valid concerns in the language, like the criticism mentioned in other blog posts (specifically the "V is for Vaporware" posts). When talking to one of the other moderators, this was defended as "cultural differences".
I left the team (and was blocked by Alex) the same day that another developer left.
The V syntax has also changed quite a bit, and is significantly more complex than it was in 0.3.
One thing I wish would have happened with V, would be having a narrow focus, instead of working on Gitly, vbrowser, ved, vinix, Volt, native backend, autofree, c-to-v converter, go-to-v converter and all the other things. Alex is very ambitious to the point that very little seems finished.
baranul · 49d ago
In agreement. The unnecessary jabs taken are very obvious. For example, weirdness like attacking the name VPM, which is based on the purpose it serves.
Anybody can cherry-pick any language, then generate fake controversy for clicks. Rather see something informative or is teaching something worthwhile, rather than drama.
In particular, many people close to the language make great-sounding claims, which are simply not true.
An example: if you go to https://vlang.io/, right there in "Safety" section, it mentions "No null (allowed in unsafe code)"
So you might think: great! This sounds like Rust but without all the tedious errors, I hate null pointer exceptions! But turns out this is pretty much a lie, there may be no "null" keyword, but it's not that hard to get it. Go to https://play.vlang.io/, enter the program and press "run":
I just this run this and got the response: that sure looks like a null to me (except spelled "nil").. and behaves as it was a null too. And no "unsafe" in sight!Would you trust the language which outright lies about the basic features on its own front page? I certainly would not recommend so.
(Alternative interpretation is that this was not an intentional lie, but rather that language designers never thought how "no null" and "can create array of pointers without unsafe" rules would interact together.. That's even worse IMHO)
V can compile to C, including native (still in development) and other languages (WASM, JavaScript...), so depending on what someone is doing they can see related error messages. Additionally, there is the circumstance of keeping compatibility with other languages. This is why V has "nil", which is explained in the documentation, but its their objective to eliminate or contain its usage to only unsafe.
From their documentation- "Zero-value references, or nil pointers, will NOT be supported in the future...". Users of V would be familiar with the circumstances and context, to include seeing examples of proper usage.
And no, if you that using null is V is "improper", this still means V has nulls. If the it will not have nulls "in the future", it means it still has nulls today. The front page does not mention any "future" part. And mentioning that you cannot assign it to any variables outside of "unsafe" is outright wrong.. It works just fine, it's just spelled differently (as "voidptr(0)"). Try it yourself in playground:
The thing is, there are plenty of languages without "null" - Rust of course, but also much more "conventional" languages like Kotlin and Swift. So we know what language-without-nulls looks like - there are nullable and non-nullable pointer-things (they may be called using different terms), they are distinct types, and you need a special ceremony to access nullable pointer-things where you specify what to do if the value is null/missing. Vlang does not have anything like that, and it's trivially easy to get the null pointer (either intentionally or from trivial programming error) in safe code.Raylib is not the main UI library of V nor is it promoted as such. Instead, VUI[1] (which is on the main site) would usually be used or related UI toolkits such as IUI[2], MUI[3], or GUI[4]. Instead of appreciation for how V contributors used C2V[5] to create an up to date binding to a popular library (Raylib) for their community, they are figuratively "kicked in the teeth" for their efforts. That's after taking an unneeded swipe at even the name of VPM (which is descriptive to its purpose).
Globals are not used a lot in V nor are they encouraged. Instead of globals, users of V would use struct fields that hold data between function calls. Globals are to be only used under certain circumstances or for specific compatibility reasons with other languages, and is activated only through a flag.
It is conveniently forgotten that V is many years younger than the other languages referred to. Despite this, it's forced to carry the unrealistic expectations of critics, from before it was even released to the public and while still in alpha and beta.
Amazingly, its older competitors are allowed to not deliver on their "promises" (twist the definitions of project goals), be hobbled by thousands of issues (per their GitHubs), and continue to fail at achieving 1.0 (and likely no time in the next few years).
Then the final "kick below the belt", is to give the impression that V doesn't challenge its older rivals. But if we look on TIOBE, we find that V is ranked 43 (May 2025). Zig, Odin, C3, etc... are not even in the TIOBE top 50. Jai at least has an excuse, as is not public, but is still several years older. Not only does V challenge the other so-called players, but appears subject to forces trying to derail or harm the project.
[1] https://github.com/vlang/ui (promoted on main page and documents)
[2] https://github.com/isaiahpatton/ui
[3] https://github.com/malisipi/mui
[4] https://github.com/mike-ward/gui (new)
[5] https://github.com/vlang/c2v
[6] https://web.archive.org/web/20250515181418/https://www.tiobe... (TIOBE May 2025)
Not a trustworthy article.
If you join the Discord and search for "this week", "this month", "next week" and "next month" with Alex Medvednikov as the author, you'll see 80+ (yes, that many) missed deadlines, some that go all the way back to 2019.
Version 0.3 promised autofree and a syntax freeze, it got none of those. I remember discussing this with Alex, saying that it would be ideal, to publicly mention that autofree wouldn't be included in the release, and it is as if he just couldn't see why that type of communication was important.
There were also instances of moderators publicly being mean to other chatters, _especially_ when asking about valid concerns in the language, like the criticism mentioned in other blog posts (specifically the "V is for Vaporware" posts). When talking to one of the other moderators, this was defended as "cultural differences".
I left the team (and was blocked by Alex) the same day that another developer left.
The V syntax has also changed quite a bit, and is significantly more complex than it was in 0.3.
One thing I wish would have happened with V, would be having a narrow focus, instead of working on Gitly, vbrowser, ved, vinix, Volt, native backend, autofree, c-to-v converter, go-to-v converter and all the other things. Alex is very ambitious to the point that very little seems finished.
Anybody can cherry-pick any language, then generate fake controversy for clicks. Rather see something informative or is teaching something worthwhile, rather than drama.