Their site is clearly showing the language is in beta. The V documentation also states that autofree is WIP, and to use the GC instead. This isn't a corporate created language, but looks to be a true volunteer open source effort from people around the world.
Their community, in comparison to others, even has their discussions open and open threads for criticism. Example.
"outdated article" the commit tested is 3 months old.
This is a standard V community tactic: all negative feedback is "bashing", anything older than a week is "outdated", anything up to date shouldn't have been written and posted on the issue tracker to be ignored instead.
Stop trying to control everyone else's speech and just work on fixing the long list of issues folks already took the time to report.
> it will process events while waiting for syscall
How does that work?
According to the source code quoted in the article, there is a separate "coroutine-safe version of time.sleep", which seems like it shouldn't be needed if V has a general solution for unblocking blocking syscalls.
> 1. what exactly does not works? This is so unhelpful 2. then report an issue on GitHub 3. exactly for that purpose `-skip-unused` exists, but Rust generates large binaries too 4. please read how coroutines work under hood, it will process events while waiting for syscall. 5. we welcome folks that aren't bashing on V using outdated "articles aganist V"
The GP was merely summarizing the article. They are not making any claims themselves.
Lots of people have commented on the level of anger directed at V. Personally I do think the lies justify it, and it's definitely part of the picture, but in practice mere marketing BS (unfortunately) doesn't usually raise this level of anger. I don't think that's the full reason.
I think part of the reason is that a lot of us want to believe something like V is possible, powerful safety features in a small conceptual and complexity footprint. So the first time we heard about V, we got excited, thinking maybe it could really be the cool thing it claims to be...
No one likes false hope. It really stings, actually. Then you find out they're not correcting their mistakes, which means they're doing it on purpose, which means they did it to you on purpose... that's the kind of thing that gets people pissed.
Can someone explain the backstory of what V is and why someone took the time to write this? To the uninitiated this sounds like someone criticizing some kid’s side project.
I’m picking up some context clues that V is widely used / famous / notable / significant somehow, but the only time I have ever heard of it before this is Xe Iaso’s similarly negative posts. Did V receive some huge funding grant that made it the target of ire? Is the author otherwise well-known? What am I missing?
When the V project started out the creator of V made some big claims that raised a few eyeballs, they've gained a reasonable following over the years, have a pretty serious looking website (https://vlang.io), a beer-money level Patreon following and some corporate partnerships/sponsors. However they have experienced some pretty brutal takedowns over the years, with some of the bolder claims about the language/compiler often being exposed as untrue and some functionality being broken.
A word I keep seeing in relation to V is "aspirational" - the project aspires to be a serious language and it aspires to have some serious features, so I think it's fair to approach it with a more critical eye than one would a kid's side-project. I think HN would have been pretty understanding if they were open about the state of the various features and were a little less defensive when they encounter articles that review it like a Real Language.
If the authors don't want this kind of feedback they can just say front-and-centre (or on their FAQ @ https://github.com/vlang/v/wiki/FAQ) "this is a toy" or "this is pre-alpha" or "this is for research purposes". There are plenty of projects like this which are open about their intent and which don't have posts like this written about them. But I don't think that'll happen, so as it stands the pattern will continue - someone revisits the language every year or so, finds some things that doesn't meet expectations, writes about it and we discuss it on HN again.
We can’t just appreciate that someone took the time to evaluate the technical merits of a particular technology? What the hell does all of this peripheral stuff (“is the author otherwise well-known?”) matter?
I for one appreciate this article. It sheds light on the history of V and its undelivered promises; and save me wasted time trying it or reading their site.
Interesting article, except I didn't like the last part. It sounded too personal. I would have preferred if OP had kept a neutral tone and allowed the reader to make their own opinion.
Agree with your assessment. Things about this seems way too personal, unknowns involved, or very clear ties back to its competition. A good review should be from known persons, who are actual neutral 3rd parties.
Possibly some are:
[1] Is V Lang Better Than Go And Rust? Let's Find Out
Thank you for this. Saved me a lot of time and hassle - definietly steering clear of V land. A similar review for Nim would be of interest to me. Should not be that bad I‘d hope.
Nim shouldn't really be used in the same sentence as V. I've never used Nim, but I've never seen anyone out right say anything negative like that's said of V. The only thing close to "negative" regarding Nim I've seen is this, https://en.wikipedia.org/wiki/Nitter
I've written a few projects in Nim. Unfortunately there seems to be a big "civil war" happening right now in Nim land where it's the creator vs big-names going at it for some reason. Can't remember. Like if Chris McCord suddenly started fighting with Jose Valim and Elixir became split right down the middle.
I stopped using Nim because I couldn't get over how bad the documentation was. Hard to navigate, hard to find what you need if you don't already know what it's called and examples are extremely convoluted instead of showing you the basics barebones first. I thought this problem would have less of an impact the longer I used Nim but years later it's still a thorny problem.
The creator not being able to community manage was why I left Nim - not "forever", but I moved on to other things. The language has some good ideas, but at that time development seemed to be heavily guided by two trolls who hung out in the IRC and complained, every day, about how they would never ever be able to do their projects without this one feature. Eventually I got into it with them and nobody got banned...which, of course, said to me that he was OK with toxicity, so I couldn't be bothered to stay.
That, and a lot of the more advanced features were just broken.
> Unfortunately there seems to be a big "civil war" happening right now in Nim land
I believe the war is already over, the other side forked the language and seems to move in their own direction to create something new - https://github.com/nim-works/nimskull . That's probably for the better.
I've been around Nim communtiy around a year and I haven't seen any major conflicts break out since these people left. Nim is still actively developed and a joy to use.
And even the creator of the language, deemed as dictator or asshole by some, comes off only as grumpy old man (show me an old man who isn't grumpy, duh). Who also realizes his flaws and is willing to compromise.
V's claims have always been dubious on their face.
It promised the programming language equivalent of magic with no overhead.
I'm glad that someone took the time to print receipts.
The author clearly wants a reckoning, but he's unlikely to receive satisfaction. The people that still use or evangelize V are locked in, the contradictions will only make their belief stronger. Alex is a bullshitter, and arguing with someone like that is pointless.
To top it all off, prominent folks from the V community often engage in flamewars on this exact site. dang has threatened to ban the topic entirely before [1], and honestly at this point I'm pretty supportive of it.
The V devs have promised a lot, have missed a lot but have also achieved a lot. I have written a few short programs in V. IMHO, the V syntax is concise and intuitive and the performance is good. It is lightweight and easy to install and to use. The blog post is probably right that V has many rough edges but I would say the core features in V are well planned. I actually prefer it over some other more popular languages. That said, because V hasn't reached 1.0, it is probably too early to use it in production.
The language is worked on by a group of people from around the world, not just Alex. It has to be looked at as a group effort. The total contributor count is at 722, as of today. There is a lot of rhetoric thrown around as criticism or being attributed to the language creator, but it's not anything he actually wrote. So the point of it, where and why, comes across as really strange.
For instance, not understanding why try so hard to push a 2023 review for an old version of the language, when we are in 2024. But ok, here this is. It comes across as not being neutral because of the very personal dispute against V's creator, as revealed at the bottom of the blog. The super strange ranting displayed by the reviewer at the bottom, destroys all sense of neutrality, and disputably its credibility.
The review itself has various errors or problems that people gloss over or haven't caught some of: 1) It's weird to be complaining about autofree, when the documentation says its WIP and go use the GC for now. They clearly are giving user options for managing memory. 2) He was using the wrong or ignoring other compiler options. 3) The reviewer seems to be intentionally distorting or misrepresenting the coroutine situation; it's WIP and will be used on the Windows OS. 4) It's open source. Report to them or go help fix whatever is the issue, as other people have (hundreds of contributors).
For example, with the coroutines part, research (site and documentation) shows the V project will be using both OS threads and green threads for concurrency. Right now, they use OS threads, with the `spawn` and `go` keywords. In the future, the `go` keyword will only be for green threads, which the critic is referring to (corounties). At V's site, they are working on coroutines (green threads) for the Windows OS and are steadily working on implementing that into the language.
I would think most reasonable people would cut a volunteer open source project some slack and allow them time to improve upon what they are doing, but there appears to be some weird rush and other intent going on. Don't see V's community attacking anybody, just them happily focusing on their language, but it seems a lot of people are going after them, really hard.
Whoa there. It's just a programming language. No need to spill vitriol over that.
I have no skin in the game. Got into V very recently, because it appeals to me at face value.
And in some ways better than other "better C" languages of today.
For me it's just good enough. The syntax is sane, the compiler doesn't want to maniacally ruin my day, the standard library is already quite rich, and finally wrapping C code is a breeze.
Isn't it about the authors have been overpromising and underdelivering since the beginning? https://mawfig.github.io/2022/06/18/v-lang-in-2022.html is a year older than this article, still interesting and it links to some other articles right at the beginning.
V claims to be the next best thing that ever happened since sliced bread, but instead its development over years is just yak shaving on steroids. These review posts just prove that.
"a summary of my experience with the language over 6 months " -- I was only able to use it for a week around Christmas before hitting compiler bugs. I like the look of it, but I can't currently use it.
To be fair, I ran into a compiler bug in Zig within a few hours of using it. I'd still expect Zig to be a lot less buggy than V, based on what I heard.
Last time I looked at V it just seemed like the language wanted to have it all. No tradeoffs, just "The best parts of Rust and Go" with no explanation how that's remotely achievable (and it wasn't, judging by the attempts to make "auto free" memory management happen, and having to discover first hand that this is not a good approach, and the problem is turing complete).
Then again, out of the C alternative languages Zig, Odin and C3 - Zig’s always been the one with the most open bugs despite (or due to?) having by far the most amount of people working on it.
Ironic now when the compiler is written in Zig considering how Zig is advertising itself as being better at stability and reliability than C/C++ (the C3 compiler is written in C and Odin’s compiler is a C-like C++)
I know it's a meaningless metric, but I still find myself wondering how, exactly, vlang got to 35K stars on github, very much in the same order of magnitude as, say, cpython with 58K.
A lot of vlang-related statistics are very suspicious, probably some of the metrics are boosted by a click farm or something similar. For example, 99% of the global google searches about "vlang" are from Beijing.
https://trends.google.com/trends/explore?date=today%205-y&q=...
This makes very little sense to me. Keep in mind that Google is blocked in China, and has been for a long time, except maybe specific special machines from the government that may have unlimited access. Even if there is a lot of search interest from people using VPNs, it shouldn't show up as China.
So I'm not sure if that's evidence of metric boosting by a click farm, or anything else. Clicking on the question mark, it looks like it's not really a ranking of "where do searches come from", but rather "how popular is it in this region":
> Numbers represent search interest relative to the highest point on the chart for the given region and time. A value of 100 is the peak popularity for the term. A value of 50 means that the term is half as popular. A score of 0 means there was not enough data for this term.
Was curious, so checked up. V has Chinese contributors[2] and who have also translated their documentation from English to Chinese[1]. As was mentioned, other languages have Chinese followings too.
I've been comparing various projects in a particular domain and noticed that stars aren't the best indicator for adoption/maturity level. More interesting:
- number of contributors
- number of open/closed pull requests
- number of open/closed issues
Most of the time they scale with stars, but sometimes there will be 1k+ stars but only a few pull requests, which is odd.
I joined Vlang GitHub organisation after I was invited. I was aware of the "V for Vaporware" articles [1] that already existed, but at that point they were more than a year old, so things had probably changed. It didn't take long for me to disagree with the way things were moderated, with many negative responses by the moderators to the people with criticism (often valid). I'm talking about moderators calling people "idiots" in the general publicly available chat.
I loved the idea of simplicity, autofree, the UI framework, the browser, Volt app, GitHub alternative, operating system and so much more. But it just didn't seem to go anywhere. The syntax however was simple, I really admired it and by 0.3 they would have a syntax freeze, but I do see that some major syntax has changed after 0.3 multiple times. I left the same day another developer did, and having talked with multiple V developers shortly after, four of them said they agreed to my criticism about moderation and broken promises. Alex (the creator) wrote to me personally, but denied all the criticism which was mentioned in the "V for Vaporware" articles.
In the moderator channel Alex mentioned that autofree wouldn't be delivered in 0.3 and this became my main criticism in the DMs. He could not see why I found it important to notify the community about this, while also telling me to "grow up" for not supporting offensive language, referencing some of the ways Linus Torvalds has written responses.
Shortly thereafter he blocked me privately. It wasn't clear to me if I was blocked though, as Discord just told me I couldn't reach him. So I contacted one of the moderators, who told me that it's due to culture differences.
At one point I even searched in the Discord for messages by Alex that contained "this week", "this month" and "this year", also using "next" instead of "this". It came out to 50+ times that deadlines had been missed (closer to 80+ probably). Even with some major projects such as Gitly from 2019 if I remember correctly, which still isn't done.
A good faith look at V is that it's very much a work-in-progress, and that at times the documentation is "aspirational" rather than "factual". I'm reminded by an remark from Bill Joy in an old interview talking about writing vi: "I wrote manual pages for all the great features we were going to do but never implemented".[1] We've all done that, right? I certainly have, including in public projects.
There's a lot to be said about the wisdom of publishing material like this, and it's fine to object. But phrasings like "they were able to lie in every sentence" do not sit well with me, especially since the bit that follows doesn't actually disprove the claims all that well. It's assuming the worst possible motivation (intentional deception) rather than the much more likely motivation (small team, tad too much enthusiasm, and perhaps at times, inexperience). I'm not entirely trusting the objectivity of an author who describes these sort of things as "lies". Even worse are things like:
> He lies that coroutines work with IO. I’ll clarify that by working, I personally mean context switching when necessary, and not the fact that the program does not crash.
So the functionality is correct, but not in a way the author would like it to, therefore it's a lie to claim it works. Eh? It's fine to criticize that the implementation isn't any good, of course, but employing such narrow definition of "works" and then calling someone a "liar" over it seems rather, eh, much.
In short: not a fan.
I'm not saying the V people have always smelled of roses either, but this article is definitely part of the problem with the general drama and toxicity surrounding V. I find it more than a little sad that vlang.io apparently needs Cloudflare DoS protection (I assume they didn't add it for the craic).
I don't know, if you say you have build a language that solved memory and safety issues without any overhead and performance impact, but in reality everything is a noop, you're lying. You can't claim you have solved some of the most difficult problems in language design but when challenged just say this was an aspirational statement.
Apitational statements require that you have an idea how to get there. Even if you have that idea (why are you not at least saying how it would work), state that this is a goal, not a current status, otherwise it's a clear lie.
But then why isn't the documentation updated? If the developer can start projects for UI and 3D graphics before the language is complete, surely there's also time to show at least the will to fix the constantly criticised honesty & transparency issues?
> "I wrote manual pages for all the great features we were going to do but never implemented"
Your source also mentions there were just two people working on the code and the manual was finished at release, so nobody except two people had access to unfinished documentation for a program that was done within two years...I don't think this is comparable.
I can believe that it’s just overconfidence and optimism gone too far.
The problems they claim to solve look deceptively easy on the surface. Something like escape analysis (required for automatic borrowing without GC or refcounting) has many easy cases, but also incredibly hard or literally unsolvable edge cases.
They may have been encouraged by progress on the easy cases, and assumed the rest is just a matter of a few bug fixes, rather than hitting the halting problem.
I agree with this perspective, in theory. Not liking how something is implemented is different than suggesting it isn't implemented. The real damning aspect of this is that criticism surrounding these decisions seems to result in the silencing of the critic. There are times where moderation and banning are necessary, such as when the critic resorts to name calling or trolling. Criticism can lead to more awareness which could lead to a better implementation down the pike, even if there's alot of headbutting in the process. Outright silencing the dissent is counterproductive.
I also don't think reporting about being banned/silenced for such criticism is perpetuating the drama/toxicity of the community for the sake of it when it's a real world outcome.
I've seen this play out a few times now in a few different communities: systemd, Gnome/GTK, wider JavaScript and PHP communities, and probably some others.
There is legitimate reasonable criticism of these things, even today.
However, they have also been subject to profoundly unreasonable – even unhinged – criticism, and this has created a rather unhealthy dynamic where both reasonable and unreasonable criticism are all treated the same by the developers. You kind of need to insulate yourself to some degree.
For example, consider my write-up of the "GTK thumbnail issue" at [1] (I since deleted my account there, but that was written by me). It's easy to come off with a bad impression of the Gnome/GTK developers based on that, but at the same time ... they've been subject to so much unreasonable whining and criticism that it has also created this dynamic.
There's tons of examples like this. Also see: every time GIMP comes up on HN, with people ranting and whining about all sorts of things. I wouldn't be surprised if the GIMP devs don't even bother reading HN any more.
I don't think intentionally misrepresenting projects in their documentation is something "we've all done". Making mistakes in documentation is one thing, but turning a readme into an "aspirational" sales pitch with no disclaimers is baldly dishonest and worthy of scorn.
>So the functionality is correct, but not in a way the author would like it to, therefore it's a lie to claim it works. Eh? It's fine to criticize that the implementation isn't any good, of course, but employing such narrow definition of "works" and then calling someone a "liar" over it seems rather, eh, much.
As far as I understood the article the coroutines don't work?
If I write asynchronous code via a coroutine and one coroutine with io prevents all other coroutines from running that is not a working coroutine.
None of these points apply in this context. The context is that this project has been going on for many years, is popular (using the GitHub stars proxy), and has been criticized before. This isn’t a fourteen year old kid trying to make a language and being naive about what it takes to achieve it.
> I'm not saying the V people have always smelled of roses either, but this article is definitely part of the problem with the general drama and toxicity surrounding V.
Meh. Complaining about the tone is so boring. The author is a bit upset but no one is disputing their technical arguments (I’m relying on others since they know more about it than me).
Some highlights:
Their site is clearly showing the language is in beta. The V documentation also states that autofree is WIP, and to use the GC instead. This isn't a corporate created language, but looks to be a true volunteer open source effort from people around the world.
Their community, in comparison to others, even has their discussions open and open threads for criticism. Example.
[1]https://github.com/vlang/v/discussions/7610
[flagged]
"outdated article" the commit tested is 3 months old.
This is a standard V community tactic: all negative feedback is "bashing", anything older than a week is "outdated", anything up to date shouldn't have been written and posted on the issue tracker to be ignored instead.
Stop trying to control everyone else's speech and just work on fixing the long list of issues folks already took the time to report.
5 replies →
> it will process events while waiting for syscall
How does that work?
According to the source code quoted in the article, there is a separate "coroutine-safe version of time.sleep", which seems like it shouldn't be needed if V has a general solution for unblocking blocking syscalls.
> 1. what exactly does not works? This is so unhelpful 2. then report an issue on GitHub 3. exactly for that purpose `-skip-unused` exists, but Rust generates large binaries too 4. please read how coroutines work under hood, it will process events while waiting for syscall. 5. we welcome folks that aren't bashing on V using outdated "articles aganist V"
The GP was merely summarizing the article. They are not making any claims themselves.
Lots of people have commented on the level of anger directed at V. Personally I do think the lies justify it, and it's definitely part of the picture, but in practice mere marketing BS (unfortunately) doesn't usually raise this level of anger. I don't think that's the full reason.
I think part of the reason is that a lot of us want to believe something like V is possible, powerful safety features in a small conceptual and complexity footprint. So the first time we heard about V, we got excited, thinking maybe it could really be the cool thing it claims to be...
No one likes false hope. It really stings, actually. Then you find out they're not correcting their mistakes, which means they're doing it on purpose, which means they did it to you on purpose... that's the kind of thing that gets people pissed.
Can someone explain the backstory of what V is and why someone took the time to write this? To the uninitiated this sounds like someone criticizing some kid’s side project.
I’m picking up some context clues that V is widely used / famous / notable / significant somehow, but the only time I have ever heard of it before this is Xe Iaso’s similarly negative posts. Did V receive some huge funding grant that made it the target of ire? Is the author otherwise well-known? What am I missing?
When the V project started out the creator of V made some big claims that raised a few eyeballs, they've gained a reasonable following over the years, have a pretty serious looking website (https://vlang.io), a beer-money level Patreon following and some corporate partnerships/sponsors. However they have experienced some pretty brutal takedowns over the years, with some of the bolder claims about the language/compiler often being exposed as untrue and some functionality being broken.
A word I keep seeing in relation to V is "aspirational" - the project aspires to be a serious language and it aspires to have some serious features, so I think it's fair to approach it with a more critical eye than one would a kid's side-project. I think HN would have been pretty understanding if they were open about the state of the various features and were a little less defensive when they encounter articles that review it like a Real Language.
If the authors don't want this kind of feedback they can just say front-and-centre (or on their FAQ @ https://github.com/vlang/v/wiki/FAQ) "this is a toy" or "this is pre-alpha" or "this is for research purposes". There are plenty of projects like this which are open about their intent and which don't have posts like this written about them. But I don't think that'll happen, so as it stands the pattern will continue - someone revisits the language every year or so, finds some things that doesn't meet expectations, writes about it and we discuss it on HN again.
There is a summary at the top of this post from 2019:
https://andrewkelley.me/post/why-donating-to-musl-libc-proje...
> To the uninitiated this sounds like someone criticizing some kid’s side project.
As someone uninitiated, you may not appreciate what a devastating burn that is.
We can’t just appreciate that someone took the time to evaluate the technical merits of a particular technology? What the hell does all of this peripheral stuff (“is the author otherwise well-known?”) matter?
"Sounds like someone criticizing some kid’s side project."
That's a really big "kid's side project". Looking at V's GitHub stats:
35.2k Stars
722 Contributors
2.1k Forks
I for one appreciate this article. It sheds light on the history of V and its undelivered promises; and save me wasted time trying it or reading their site.
Seems little has changed since Xe's article back in 2019
https://xeiaso.net/blog/v-vaporware-2019-06-23/
Interesting article, except I didn't like the last part. It sounded too personal. I would have preferred if OP had kept a neutral tone and allowed the reader to make their own opinion.
Agree with your assessment. Things about this seems way too personal, unknowns involved, or very clear ties back to its competition. A good review should be from known persons, who are actual neutral 3rd parties.
Possibly some are:
[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
Thank you for this. Saved me a lot of time and hassle - definietly steering clear of V land. A similar review for Nim would be of interest to me. Should not be that bad I‘d hope.
Nim shouldn't really be used in the same sentence as V. I've never used Nim, but I've never seen anyone out right say anything negative like that's said of V. The only thing close to "negative" regarding Nim I've seen is this, https://en.wikipedia.org/wiki/Nitter
I’ve used Nim in the past. It is definitely not vaporware like V. It’s a pretty pleasant language although I’ve since moved on to Zig.
[flagged]
I've written a few projects in Nim. Unfortunately there seems to be a big "civil war" happening right now in Nim land where it's the creator vs big-names going at it for some reason. Can't remember. Like if Chris McCord suddenly started fighting with Jose Valim and Elixir became split right down the middle.
I stopped using Nim because I couldn't get over how bad the documentation was. Hard to navigate, hard to find what you need if you don't already know what it's called and examples are extremely convoluted instead of showing you the basics barebones first. I thought this problem would have less of an impact the longer I used Nim but years later it's still a thorny problem.
The creator not being able to community manage was why I left Nim - not "forever", but I moved on to other things. The language has some good ideas, but at that time development seemed to be heavily guided by two trolls who hung out in the IRC and complained, every day, about how they would never ever be able to do their projects without this one feature. Eventually I got into it with them and nobody got banned...which, of course, said to me that he was OK with toxicity, so I couldn't be bothered to stay.
That, and a lot of the more advanced features were just broken.
> Unfortunately there seems to be a big "civil war" happening right now in Nim land
I believe the war is already over, the other side forked the language and seems to move in their own direction to create something new - https://github.com/nim-works/nimskull . That's probably for the better.
I've been around Nim communtiy around a year and I haven't seen any major conflicts break out since these people left. Nim is still actively developed and a joy to use. And even the creator of the language, deemed as dictator or asshole by some, comes off only as grumpy old man (show me an old man who isn't grumpy, duh). Who also realizes his flaws and is willing to compromise.
[dead]
V's claims have always been dubious on their face. It promised the programming language equivalent of magic with no overhead. I'm glad that someone took the time to print receipts.
The author clearly wants a reckoning, but he's unlikely to receive satisfaction. The people that still use or evangelize V are locked in, the contradictions will only make their belief stronger. Alex is a bullshitter, and arguing with someone like that is pointless.
To top it all off, prominent folks from the V community often engage in flamewars on this exact site. dang has threatened to ban the topic entirely before [1], and honestly at this point I'm pretty supportive of it.
[1] https://news.ycombinator.com/item?id=37335249
The part when he suggests removing comments in HN is hilarious. Like accepting his rotten behavior as the norm everywhere.
[flagged]
What's amazing is how large the community became and how strong their love and belief was.
The V devs have promised a lot, have missed a lot but have also achieved a lot. I have written a few short programs in V. IMHO, the V syntax is concise and intuitive and the performance is good. It is lightweight and easy to install and to use. The blog post is probably right that V has many rough edges but I would say the core features in V are well planned. I actually prefer it over some other more popular languages. That said, because V hasn't reached 1.0, it is probably too early to use it in production.
7 replies →
[flagged]
2 replies →
The language is worked on by a group of people from around the world, not just Alex. It has to be looked at as a group effort. The total contributor count is at 722, as of today. There is a lot of rhetoric thrown around as criticism or being attributed to the language creator, but it's not anything he actually wrote. So the point of it, where and why, comes across as really strange.
For instance, not understanding why try so hard to push a 2023 review for an old version of the language, when we are in 2024. But ok, here this is. It comes across as not being neutral because of the very personal dispute against V's creator, as revealed at the bottom of the blog. The super strange ranting displayed by the reviewer at the bottom, destroys all sense of neutrality, and disputably its credibility.
The review itself has various errors or problems that people gloss over or haven't caught some of: 1) It's weird to be complaining about autofree, when the documentation says its WIP and go use the GC for now. They clearly are giving user options for managing memory. 2) He was using the wrong or ignoring other compiler options. 3) The reviewer seems to be intentionally distorting or misrepresenting the coroutine situation; it's WIP and will be used on the Windows OS. 4) It's open source. Report to them or go help fix whatever is the issue, as other people have (hundreds of contributors).
For example, with the coroutines part, research (site and documentation) shows the V project will be using both OS threads and green threads for concurrency. Right now, they use OS threads, with the `spawn` and `go` keywords. In the future, the `go` keyword will only be for green threads, which the critic is referring to (corounties). At V's site, they are working on coroutines (green threads) for the Windows OS and are steadily working on implementing that into the language.
I would think most reasonable people would cut a volunteer open source project some slack and allow them time to improve upon what they are doing, but there appears to be some weird rush and other intent going on. Don't see V's community attacking anybody, just them happily focusing on their language, but it seems a lot of people are going after them, really hard.
Is the author better at marketing/sales/promising or programming (delivering)?
Whoa there. It's just a programming language. No need to spill vitriol over that.
I have no skin in the game. Got into V very recently, because it appeals to me at face value.
And in some ways better than other "better C" languages of today.
For me it's just good enough. The syntax is sane, the compiler doesn't want to maniacally ruin my day, the standard library is already quite rich, and finally wrapping C code is a breeze.
I remember there was some controversy or drama with V a couple of years ago regarding the language.
I forgot what it was about but I haven’t heard about V since then. This article was interesting to read!
Isn't it about the authors have been overpromising and underdelivering since the beginning? https://mawfig.github.io/2022/06/18/v-lang-in-2022.html is a year older than this article, still interesting and it links to some other articles right at the beginning.
If the author wanted e-fame (the good kind or the bad kind), they absolutely got it.
Overpromise and underdeliver.
And lots of funding for then vaporware
Isn't that our entire industry though?
1 reply →
V claims to be the next best thing that ever happened since sliced bread, but instead its development over years is just yak shaving on steroids. These review posts just prove that.
[flagged]
"a summary of my experience with the language over 6 months " -- I was only able to use it for a week around Christmas before hitting compiler bugs. I like the look of it, but I can't currently use it.
To be fair, I ran into a compiler bug in Zig within a few hours of using it. I'd still expect Zig to be a lot less buggy than V, based on what I heard.
Last time I looked at V it just seemed like the language wanted to have it all. No tradeoffs, just "The best parts of Rust and Go" with no explanation how that's remotely achievable (and it wasn't, judging by the attempts to make "auto free" memory management happen, and having to discover first hand that this is not a good approach, and the problem is turing complete).
Then again, out of the C alternative languages Zig, Odin and C3 - Zig’s always been the one with the most open bugs despite (or due to?) having by far the most amount of people working on it.
Ironic now when the compiler is written in Zig considering how Zig is advertising itself as being better at stability and reliability than C/C++ (the C3 compiler is written in C and Odin’s compiler is a C-like C++)
8 replies →
I know it's a meaningless metric, but I still find myself wondering how, exactly, vlang got to 35K stars on github, very much in the same order of magnitude as, say, cpython with 58K.
A lot of vlang-related statistics are very suspicious, probably some of the metrics are boosted by a click farm or something similar. For example, 99% of the global google searches about "vlang" are from Beijing. https://trends.google.com/trends/explore?date=today%205-y&q=...
This makes very little sense to me. Keep in mind that Google is blocked in China, and has been for a long time, except maybe specific special machines from the government that may have unlimited access. Even if there is a lot of search interest from people using VPNs, it shouldn't show up as China.
"golang" seems to have similar statistics: https://trends.google.com/trends/explore?date=today%205-y&q=...
So I'm not sure if that's evidence of metric boosting by a click farm, or anything else. Clicking on the question mark, it looks like it's not really a ranking of "where do searches come from", but rather "how popular is it in this region":
> Numbers represent search interest relative to the highest point on the chart for the given region and time. A value of 100 is the peak popularity for the term. A value of 50 means that the term is half as popular. A score of 0 means there was not enough data for this term.
1 reply →
Was curious, so checked up. V has Chinese contributors[2] and who have also translated their documentation from English to Chinese[1]. As was mentioned, other languages have Chinese followings too.
[1] https://www.bookstack.cn/search/result?wd=Vlang
[2] https://lydiandylin.gitbook.io/
[dead]
I've been comparing various projects in a particular domain and noticed that stars aren't the best indicator for adoption/maturity level. More interesting:
- number of contributors
- number of open/closed pull requests
- number of open/closed issues
Most of the time they scale with stars, but sometimes there will be 1k+ stars but only a few pull requests, which is odd.
They have more starts than C# at 10k
Then Mojo also has more stars than C#. I guess GitHub stars don't mean much.
1 reply →
I joined Vlang GitHub organisation after I was invited. I was aware of the "V for Vaporware" articles [1] that already existed, but at that point they were more than a year old, so things had probably changed. It didn't take long for me to disagree with the way things were moderated, with many negative responses by the moderators to the people with criticism (often valid). I'm talking about moderators calling people "idiots" in the general publicly available chat.
I loved the idea of simplicity, autofree, the UI framework, the browser, Volt app, GitHub alternative, operating system and so much more. But it just didn't seem to go anywhere. The syntax however was simple, I really admired it and by 0.3 they would have a syntax freeze, but I do see that some major syntax has changed after 0.3 multiple times. I left the same day another developer did, and having talked with multiple V developers shortly after, four of them said they agreed to my criticism about moderation and broken promises. Alex (the creator) wrote to me personally, but denied all the criticism which was mentioned in the "V for Vaporware" articles.
In the moderator channel Alex mentioned that autofree wouldn't be delivered in 0.3 and this became my main criticism in the DMs. He could not see why I found it important to notify the community about this, while also telling me to "grow up" for not supporting offensive language, referencing some of the ways Linus Torvalds has written responses.
Shortly thereafter he blocked me privately. It wasn't clear to me if I was blocked though, as Discord just told me I couldn't reach him. So I contacted one of the moderators, who told me that it's due to culture differences.
At one point I even searched in the Discord for messages by Alex that contained "this week", "this month" and "this year", also using "next" instead of "this". It came out to 50+ times that deadlines had been missed (closer to 80+ probably). Even with some major projects such as Gitly from 2019 if I remember correctly, which still isn't done.
[1] https://xeiaso.net/blog/v-vaporware-2019-06-23/
I got banned from their telegram channel because I posted this link, they are not open to criticisms.
Hey banning someone for suggesting use of Go doesn't make sense. That is quite sad.
Shameless plug:
Please take a kind look at https://yakshalang.github.io/. I'd like to receive some criticism.
[flagged]
A good faith look at V is that it's very much a work-in-progress, and that at times the documentation is "aspirational" rather than "factual". I'm reminded by an remark from Bill Joy in an old interview talking about writing vi: "I wrote manual pages for all the great features we were going to do but never implemented".[1] We've all done that, right? I certainly have, including in public projects.
There's a lot to be said about the wisdom of publishing material like this, and it's fine to object. But phrasings like "they were able to lie in every sentence" do not sit well with me, especially since the bit that follows doesn't actually disprove the claims all that well. It's assuming the worst possible motivation (intentional deception) rather than the much more likely motivation (small team, tad too much enthusiasm, and perhaps at times, inexperience). I'm not entirely trusting the objectivity of an author who describes these sort of things as "lies". Even worse are things like:
> He lies that coroutines work with IO. I’ll clarify that by working, I personally mean context switching when necessary, and not the fact that the program does not crash.
So the functionality is correct, but not in a way the author would like it to, therefore it's a lie to claim it works. Eh? It's fine to criticize that the implementation isn't any good, of course, but employing such narrow definition of "works" and then calling someone a "liar" over it seems rather, eh, much.
In short: not a fan.
I'm not saying the V people have always smelled of roses either, but this article is definitely part of the problem with the general drama and toxicity surrounding V. I find it more than a little sad that vlang.io apparently needs Cloudflare DoS protection (I assume they didn't add it for the craic).
[1]: https://begriffs.com/pdf/unix-review-bill-joy.pdf
I don't know, if you say you have build a language that solved memory and safety issues without any overhead and performance impact, but in reality everything is a noop, you're lying. You can't claim you have solved some of the most difficult problems in language design but when challenged just say this was an aspirational statement.
Apitational statements require that you have an idea how to get there. Even if you have that idea (why are you not at least saying how it would work), state that this is a goal, not a current status, otherwise it's a clear lie.
But then why isn't the documentation updated? If the developer can start projects for UI and 3D graphics before the language is complete, surely there's also time to show at least the will to fix the constantly criticised honesty & transparency issues?
> "I wrote manual pages for all the great features we were going to do but never implemented"
Your source also mentions there were just two people working on the code and the manual was finished at release, so nobody except two people had access to unfinished documentation for a program that was done within two years...I don't think this is comparable.
I can believe that it’s just overconfidence and optimism gone too far.
The problems they claim to solve look deceptively easy on the surface. Something like escape analysis (required for automatic borrowing without GC or refcounting) has many easy cases, but also incredibly hard or literally unsolvable edge cases.
They may have been encouraged by progress on the easy cases, and assumed the rest is just a matter of a few bug fixes, rather than hitting the halting problem.
Do not say that your software does something that in fact, it does not do.
That should be one of the n commandments of software development.
I agree with this perspective, in theory. Not liking how something is implemented is different than suggesting it isn't implemented. The real damning aspect of this is that criticism surrounding these decisions seems to result in the silencing of the critic. There are times where moderation and banning are necessary, such as when the critic resorts to name calling or trolling. Criticism can lead to more awareness which could lead to a better implementation down the pike, even if there's alot of headbutting in the process. Outright silencing the dissent is counterproductive.
I also don't think reporting about being banned/silenced for such criticism is perpetuating the drama/toxicity of the community for the sake of it when it's a real world outcome.
I've seen this play out a few times now in a few different communities: systemd, Gnome/GTK, wider JavaScript and PHP communities, and probably some others.
There is legitimate reasonable criticism of these things, even today.
However, they have also been subject to profoundly unreasonable – even unhinged – criticism, and this has created a rather unhealthy dynamic where both reasonable and unreasonable criticism are all treated the same by the developers. You kind of need to insulate yourself to some degree.
For example, consider my write-up of the "GTK thumbnail issue" at [1] (I since deleted my account there, but that was written by me). It's easy to come off with a bad impression of the Gnome/GTK developers based on that, but at the same time ... they've been subject to so much unreasonable whining and criticism that it has also created this dynamic.
There's tons of examples like this. Also see: every time GIMP comes up on HN, with people ranting and whining about all sorts of things. I wouldn't be surprised if the GIMP devs don't even bother reading HN any more.
[1]: https://lobste.rs/s/ky5yop/gnome_has_no_thumbnails_file_pick...
6 replies →
I don't think intentionally misrepresenting projects in their documentation is something "we've all done". Making mistakes in documentation is one thing, but turning a readme into an "aspirational" sales pitch with no disclaimers is baldly dishonest and worthy of scorn.
>So the functionality is correct, but not in a way the author would like it to, therefore it's a lie to claim it works. Eh? It's fine to criticize that the implementation isn't any good, of course, but employing such narrow definition of "works" and then calling someone a "liar" over it seems rather, eh, much.
As far as I understood the article the coroutines don't work?
If I write asynchronous code via a coroutine and one coroutine with io prevents all other coroutines from running that is not a working coroutine.
None of these points apply in this context. The context is that this project has been going on for many years, is popular (using the GitHub stars proxy), and has been criticized before. This isn’t a fourteen year old kid trying to make a language and being naive about what it takes to achieve it.
> I'm not saying the V people have always smelled of roses either, but this article is definitely part of the problem with the general drama and toxicity surrounding V.
Meh. Complaining about the tone is so boring. The author is a bit upset but no one is disputing their technical arguments (I’m relying on others since they know more about it than me).
that's musk approach, which is double edged sword
interesting that bill joy did use a similar way, but i assume that an incomplete text editor is a lot less critical than a failing compiler :)
I don't know what "musk approach" is, presumably referring to Elon Musk?
> interesting that bill joy did use a similar way, but i assume that an incomplete text editor is a lot less critical than a failing compiler :)
I think it's very common. GitHub is probably full of projects that do this to some degree. But most people also don't pay attention to these projects.
I'm not saying the V people are without blame or couldn't have be better, but there's definitely a lot of toxic feedback looping going on here.
4 replies →
Strangely super vigorous rant about a language that fell into obscurity early on.
I'm awed at how far people would go both in studying, analyzing and writing about a language they clearly dislike.
Having a few people willing to go to absurd lengths to debunk bullshit and generally stand for truth is a group-adaptive trait.
Oh no. Someone had the grit to document their experiences with a technology that they dislike and share it with us. What a tragedy.
Most people don’t have the energy for that and just move on. Which doesn’t help others.
I didn't think badly of it, I was awed by how deep and thorough it was.
1 reply →