They said vaporware, which isn't necessarily the same thing as abandonware. It still could be vaporware if it never lives up to delivering what it promised. I'm not sure on the current state of those promises though, so I don't know if the outlook of it being vaporware is true anymore. At one point it looked like it, but I haven't kept up with it enough.
This is a good POV. For a while there they did think they had a chance at finally figuring out how to solve the halting problem. They of course haven't, and had no chance to do so, but they wanted to discover that for sure, for themselves. So I admire them for trying. These days autofree handles about 95% of allocations, but what's left dangling is pruned by their very low cost tight cleanup looped GC. If you really need to you can do manual memory management, from my fairly substantial usage of the language so far I've been a satisfied customer for sure. I've found compiler bugs, strange behaviour, edge cases etc., yes the team are blunt and to the point, but they're the most professional language team I've ever interacted with, often responding within hours, one time a compiler fix was released the next day.
I have seen this thrown around a lot, but I do not think it is true anymore.
V lang had a rough launch from what I can tell, with the author overselling and mistakenly underestimating the amount of work needed to fulfill their vision.
V still has a ways to go, but it is in constant heavy development with lots of contributors. It also has a wide gambit of interesting hobby projects using it.
V has good ideas on paper, but most of its claimed features are aspirational. Actually using it for any real world project is an exercise in frustration and confusion, since you're never sure if the weird behavior is intentional or a bug. The documentation is outdated, missing or wrong. The implementation is a mess, even in its pre-1.0 state. Most projects written in it[1] are either demos or abandonware.
Much has been discussed about it, and every few years someone writes a "V Language Review" with the same findings. I gave it a try a few months ago and ran into many of the same issues. I'd stay away, and stick with Go, or Zig, Odin or Nim if you're interested in similar alternatives.
I have no desire to get into a discussion. You can find plenty of details in feedback from people who have given your language a try over the years. Here's a blog post from September 2024[1]. A quick glance at the open issues yields [2], and many others if you search for "immutable".
To be fair, open issues are a sign of interest and people wanting to move the project forward, which is good. I think what you're trying to achieve is commendable, and I truly wish a language as you envisioned it existed. But it's really hard to take the project seriously when one of its core features is not well defined and causes confusion after 5 years of existence.
I remember running into similar issues when I tried it last year, but just didn't bother to document or report any of it. You can assume that for every person who creates an issue, there are 10x that amount who don't bother and move on.
Such discussions are always the same. You say there are lots of issues, but can never list one. And you point to articles that complain about V using libc or that C2V was released in 2022 and not earlier. It's 2025!
Our documentation is very vast and up-to-date and we try to keep it up-to-date. So if you say it's wrong/missing/outdated, you could post a couple of examples, so that we can fix it. That shouldn't be hard for you.
As for an issue you referenced, yes a pre-1.0 language has bugs. Thousands. Like all other pre-1.0 languages being developed. We fix them quickly (~9k fixed, ~800 open)
Like I said, I didn't want to get into a discussion. This is not the appropriate forum to discuss bug reports. I was simply sharing my experience with the project, which admittedly could be outdated by now, but those were my impressions from a few months ago.
What I don't appreciate is the implication that I'm fabricating this, or that I'm biased, as OP accused me of upthread. I think that the defensive stance that you and some of the people in the V community[1] have historically taken when faced with any sort of criticism continues to be detrimental to your project. Whether the criticism is a misconception or a flaw in the project, if a user is confused it's still on you to address that with documentation, a bugfix, or a friendly response, if nothing else. Most people are not actively making up issues for some Machiavellian reason. This "us vs them" mentality is barbaric.
As for users telling you what is wrong, it's delusional to think that it's somehow their responsibility and that it shouldn't be hard. Creating a bug report that clearly explains the issue requires time and effort. And what is to be gained from that if it's only going to be met with defensive arguments and hostility? Like I said, most people will not bother with this, and you should expect that most issues will not be reported. Most users will simply move on, but they will remember they had a bad experience.
Yes, projects in early stages have many bugs. All projects do. But maybe it would be wise to focus on stabilizing the core features the project claims to have, before moving on to building editors and operating systems with it? After 5 years there shouldn't be any confusion and unexpected behavior of core functionality.
The work done on V is truly impressive, and I do wish the language was successful. But I think that realigning some priorities, being honest about what works now and how well it works, and a major shift in tone from maintainers to users, would go a long way towards earning back the trust the project lacks. Good luck!
I didn't mean to accuse you of being biased, I was just calling you not to be in case you were. I am sorry it came across otherwise. Your point of view is just as valid as anyone else. Also the editor project is completely separate to the main V team, I suppose I help with V itself in my own small way by finding occasional issues and raising them with the core team, but I am not equipped nor frankly interested in putting my own efforts into the language dev itself, it seems pretty well staffed over there atm.
I've not found any issues with using v for this project, please try and be unbiased and objective and I urge you to try and write a non trivial program and let the results speak for themselves. Up to you!
Why do you think I'm biased? I'm speaking from my own experience with the language last year. Judging by recent reports from others, there still seems to be a lot of confusion about fundamental features.
Though you've clearly invested much more time and effort into the language than me, so either it's gotten better, we haven't run into the same issues, or we have different thresholds for what constitutes an issue. I'm certainly keeping an eye on V, and I might try it out again in a few years.
Many would argue those aren't real reviewers. It has been mentioned that these persons behind the "V Language Review" series don't review other programming languages and are very specifically targeting V.
It is easy to check and see that Zig, Go, etc... Have thousands of open issues. That, or are lesser known languages like Odin, with less contributors, stars, and vetting. Anybody can take several open issues from any language and create a blog post that pretends the sky is falling.
Real reviewers, would have reviewed multiple other languages and preferably are recognized for doing so. Below are examples of fair and real reviewers of the V language, along with others:
[1] Is V Lang Better Than Go And Rust? Let's Find Out
V overpromised and underdelivered, and the creator is pretty abrasive and went to war with anyone who criticized it, so most people stopped paying attention to it until it fulfills what was promised.
It would be fair to say that many would disagree or have different opinions about the language and the creator. V's creator has an open discussion for criticism[1], which many other languages don't have.
After reading various related threads, the strange abrasiveness and negativity often seems to be from others, not the other way around.
Clearly, many people are paying attention to V. It is quite popular at GitHub with over 36.2k stars, 2.2k forks, and 775 contributors.
They said years ago, when they last took a look. Just a thought, maybe just let all this go, people are complicated, you'll never please everyone. It's not worth the time trying. If anything you're giving them more ammo to prove them right about your attitude to negative takes. I'm not taking sides, just my opinion! :)
I think it is still useful to correct them. The language is not the same as it was a few years ago, it applies to every programming languages (depending on how far we go in time).
Agree. If there is no correction or counter, then this allows a negative narrative or falsehoods to be continually pushed. By people seeing that there is at least another side to the argument, it can promote fact checking, fairness, or open-mindedness.
chaotic-neutral dictator/chief dev categorizes any criticism (regardless of merit) as trolling and bans; language design far exceeds technical merit of implementation details; basically, things only look good on paper, but fall apart once you get past the shallow end of the pool.
I've been finding it perfectly suitable for this and other projects. Have you updated your point of view after recently attempting to write and profile a non trivial program?
This AI answer is mostly referencing sources between 2020-2023. The only exception is an article written from last year, which itself admits "Anyone evaluating V for use today should obviously make judgement based on the language's current state.", but doesn't actually do that, it itself regurgitates points from other sources made multiple years ago. I think the recommendation I give is my staple "ABCs". Assume nothing, believe no-one, check everything.
I have had some positive interactions with the author in the past and did a little Lilly / NixOS / V crossover video a while ago.[1] It's nice to see this project posted here and that it's still making steady progress!
Yes pretty much. Admittedly that's all the README needs to say. When I first wrote the project README LLMs were still relatively new for public use, it was much harder to detect back then. Thanks for the feedback.
Thank you everyone for commenting and sharing your thoughts regarding my project! I'm aware of the history of V and it's less than stellar reputation in the beginning. I really hope this comment section doesn't devolve into yet another stream of people regurgitating blog posts from over 5 years ago. I evaluate languages and their suitability for projects by just my personal experience using them. Does it do what I need, and does it do it now? That's it.
Great project. Something else, that needs to be said, is that you should not allow others to make you feel ashamed for using programming languages that you like. No reason to succumb to others who are trying to force switching to what they are pushing. It's your project and your time, not theirs.
I certainly did feel some of that in the past, but not anymore. I started using V for this project fully expecting it to go wrong, experience no end of issues, bugs, memory weirdness, edge cases etc., based on the many articles targeting V. But like with everything, I also tried to stay as objective and unbiased as possible, and that just... Never happened. If anything as my experience and exposure with the language increased, so did my enjoyment, and confidence that V was just the right choice for the project, and for me.
I'm in a weird position, where I have no personal bias or stake towards V, I just like using it, but I frequently get attacked or questioned for making a choice that people find offensive or incomprehensible. It's almost like they see my not choosing something they like, like Rust, or Zig, etc., is my way of attacking them for choosing it for their own projects. No, not at all. In my opinion, the more languages that exist the better, the better the range of choice. This isn't a war guys, holy or otherwise. Let's just try and stay in our lane. There is work to do, we just need to get it done.
> If anything as my experience and exposure with the language increased, so did my enjoyment, and confidence that V was just the right choice for the project, and for me.
Your right and freedom to choose V (Vlang) or any other should be respected. Many, including myself, find using it enjoyable too.
> It's almost like they see my not choosing something they like, like Rust, or Zig, etc., is my way of attacking them for choosing it for their own projects.
It has gotten almost out of control, where evangelists or rivals think they can force or shame others into not using a language or choosing their language. Some of us need to accept that others can want to use different things, for different reasons, and that's good too.
Where it's going is a valid question though. If I'm building something on top of it, am I building on top of sand or stone? At which point, looking at its past isn't totally unreasonable.
If anyone's interested in learning vim fundamentals, right now I am building vimgolf.ai which is a site where you can linearly learn new vim motions by trying to beat a bot's score.
Haven't tried it, but it looks nice. Well done to the authors.
Reminds me of Flow Control (https://flow-control.dev/), which is really nice and comfortable to use! It looks and feels more mature than a 0.x release.
Haven't heard of this, thanks! I'll definitely be taking a peak at their buffer implementation. Zig was a no go for this project for me due to the lack of concurrency.
62 comments
[ 3.1 ms ] story [ 142 ms ] thread[1] https://www.google.com/search?client=firefox-b-d&channel=ent...
V lang had a rough launch from what I can tell, with the author overselling and mistakenly underestimating the amount of work needed to fulfill their vision.
V still has a ways to go, but it is in constant heavy development with lots of contributors. It also has a wide gambit of interesting hobby projects using it.
I'd recommend taking a look at the the examples here:https://github.com/vlang/v/tree/master/examples
I think the language has a lot of potential.
Much has been discussed about it, and every few years someone writes a "V Language Review" with the same findings. I gave it a try a few months ago and ran into many of the same issues. I'd stay away, and stick with Go, or Zig, Odin or Nim if you're interested in similar alternatives.
[1]: https://github.com/vlang/awesome-v
And examples of the documentation being outdated/wrong?
I have no desire to get into a discussion. You can find plenty of details in feedback from people who have given your language a try over the years. Here's a blog post from September 2024[1]. A quick glance at the open issues yields [2], and many others if you search for "immutable".
To be fair, open issues are a sign of interest and people wanting to move the project forward, which is good. I think what you're trying to achieve is commendable, and I truly wish a language as you envisioned it existed. But it's really hard to take the project seriously when one of its core features is not well defined and causes confusion after 5 years of existence.
I remember running into similar issues when I tried it last year, but just didn't bother to document or report any of it. You can assume that for every person who creates an issue, there are 10x that amount who don't bother and move on.
[1]: https://justinas.org/the-bizarre-world-of-v
[2]: https://github.com/vlang/v/issues/23509
Our documentation is very vast and up-to-date and we try to keep it up-to-date. So if you say it's wrong/missing/outdated, you could post a couple of examples, so that we can fix it. That shouldn't be hard for you.
As for an issue you referenced, yes a pre-1.0 language has bugs. Thousands. Like all other pre-1.0 languages being developed. We fix them quickly (~9k fixed, ~800 open)
What I don't appreciate is the implication that I'm fabricating this, or that I'm biased, as OP accused me of upthread. I think that the defensive stance that you and some of the people in the V community[1] have historically taken when faced with any sort of criticism continues to be detrimental to your project. Whether the criticism is a misconception or a flaw in the project, if a user is confused it's still on you to address that with documentation, a bugfix, or a friendly response, if nothing else. Most people are not actively making up issues for some Machiavellian reason. This "us vs them" mentality is barbaric.
As for users telling you what is wrong, it's delusional to think that it's somehow their responsibility and that it shouldn't be hard. Creating a bug report that clearly explains the issue requires time and effort. And what is to be gained from that if it's only going to be met with defensive arguments and hostility? Like I said, most people will not bother with this, and you should expect that most issues will not be reported. Most users will simply move on, but they will remember they had a bad experience.
Yes, projects in early stages have many bugs. All projects do. But maybe it would be wise to focus on stabilizing the core features the project claims to have, before moving on to building editors and operating systems with it? After 5 years there shouldn't be any confusion and unexpected behavior of core functionality.
The work done on V is truly impressive, and I do wish the language was successful. But I think that realigning some priorities, being honest about what works now and how well it works, and a major shift in tone from maintainers to users, would go a long way towards earning back the trust the project lacks. Good luck!
[1]: https://github.com/vlang/v/discussions/17122#discussioncomme...
> Can you list any weird behavior/bugs that lead to frustration and confusion?
> And examples of the documentation being outdated/wrong?
Since you wrote
> The documentation is outdated, missing or wrong.
> using it for any real world project is an exercise in frustration and confusion
that shouldn't be hard
People that build the OS don't work on the compiler, not sure what that was about.
Though you've clearly invested much more time and effort into the language than me, so either it's gotten better, we haven't run into the same issues, or we have different thresholds for what constitutes an issue. I'm certainly keeping an eye on V, and I might try it out again in a few years.
It is easy to check and see that Zig, Go, etc... Have thousands of open issues. That, or are lesser known languages like Odin, with less contributors, stars, and vetting. Anybody can take several open issues from any language and create a blog post that pretends the sky is falling.
Real reviewers, would have reviewed multiple other languages and preferably are recognized for doing so. Below are examples of fair and real reviewers of the V language, along with others:
[1] Is V Lang Better Than Go And Rust? Let's Find Out
https://www.youtube.com/watch?v=puy77WfM1Tg
[2] V - Best Programming Language to Learn in 2023?
https://www.youtube.com/watch?v=jr1EBaLkjfc
[3] First Impression - V programming language
https://www.youtube.com/watch?v=dmVKerNY-fQ
For example
https://github.com/vlang/v/releases/latest/download/v_linux....
V is very easy to install from source and to bootstrap. And it changes fast. So we're not big fans of package managers yet.
Oh, the vaporware thing?
BTW I checked the Patreon page. It says "V 1.0 release is planned for 2020". Might want to change that. :D
After reading various related threads, the strange abrasiveness and negativity often seems to be from others, not the other way around.
Clearly, many people are paying attention to V. It is quite popular at GitHub with over 36.2k stars, 2.2k forks, and 775 contributors.
[1] https://github.com/vlang/v/discussions/7610
https://github.com/vlang/v/tree/master/vlib/net
chaotic-neutral dictator/chief dev categorizes any criticism (regardless of merit) as trolling and bans; language design far exceeds technical merit of implementation details; basically, things only look good on paper, but fall apart once you get past the shallow end of the pool.
I went to Nim instead for similar use-cases.
"What don't you like about V / what would you like to be changed?"
https://github.com/vlang/v/discussions/7610
What exactly do you think only looks good on paper?
I have a toddler demanding 99% of my free time so I apologize in advance for the LLM shortcut but this looks correct based on my experience
I have a toddler demanding 99% of my free time so I apologize in advance for the LLM shortcut but this looks correct based on my experience
Good counterpoints. I did investigate it just a few months ago but then found criticisms about its translation of V to C being quite subpar, but eh
[1]: https://www.youtube.com/watch?v=TR0C76I59AI
I'm in a weird position, where I have no personal bias or stake towards V, I just like using it, but I frequently get attacked or questioned for making a choice that people find offensive or incomprehensible. It's almost like they see my not choosing something they like, like Rust, or Zig, etc., is my way of attacking them for choosing it for their own projects. No, not at all. In my opinion, the more languages that exist the better, the better the range of choice. This isn't a war guys, holy or otherwise. Let's just try and stay in our lane. There is work to do, we just need to get it done.
Your right and freedom to choose V (Vlang) or any other should be respected. Many, including myself, find using it enjoyable too.
> It's almost like they see my not choosing something they like, like Rust, or Zig, etc., is my way of attacking them for choosing it for their own projects.
It has gotten almost out of control, where evangelists or rivals think they can force or shame others into not using a language or choosing their language. Some of us need to accept that others can want to use different things, for different reasons, and that's good too.
Reminds me of Flow Control (https://flow-control.dev/), which is really nice and comfortable to use! It looks and feels more mature than a 0.x release.
Looking into it, it seems to have Async/Await, std.threads and channels.