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.
> Everything described here is correct for the b66447cf11318d5499bd2d797b97b0b3d98c3063 commit. This is a summary of my experience with the language over 6 months + information that I found on Discord while I was writing this article.
> 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://news.ycombinator.com/item?id=36563796 and the thread it links to https://forum.nim-lang.org/t/10312
I could be wrong of course. Maybe someone can point to actual negative aspects of the language or the community that I'm not aware of.
Honestly if you're interested in Nim, go learn it. I've definitely seen it being used for a number of project, the most used that I know of is (was) nitter[1]
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.
Yeah, when the article skipped over the first two memory management strategies to point out issues with manual memory management and an "automatic" strategy that is unfinished or broken, it really struck me that it's quite impressive for a single author to have a functional, fast language with a working garbage collector and arena allocator (with some issues) in only a few years.
The criticisms in the article, which I just read beginning to end, are largely about features it claims to provide (or claims are in development) that either no other language has, are an improvement on other languages, or are state of the art features in world class languages with hundreds to thousands of times more developer hours.
On the one hand, it's not wrong to criticize the overly ambitious nature of V's plans nor criticize the poor attitude and self-advertising strategies of its lead author. On the other hand, I'm not sure that the article is doing that, it seems much more interested in taking one of these features, showing that it doesn't work, and saying "so there!". But the fact that these are the features being complained about, not the core of the language, says something in itself.
Likewise, the fact that a hobbyist language with a single primary developer has terrible documentation is at the very least par for the course. Heck, I've found the Zig documentation horrific (in the past), and that has way more developer time and mindshare. Compare it to, say, the Oil shell (at least, where it was a few years ago), if you want to be fair.
I'm not convinced that the blog author isn't a troll, in some sense of the word. Clearly, many of their criticisms are well founded. Clearly, Alex does not react well to criticism. Clearly, V kinda sucks for practical use right now in a lot of ways that do matter. But the post (especially the end) feels like an excuse to stir the pot, not well-intentioned criticism. The author seems to want to use this post to counteract people they feel have mistreated them (with some justification).
Note: I say all this as a complete outsider. I've never written a line of V code and probably never will. My only prior experience is that I'm familiar with the controversy around V, especially on this site.
> quite impressive for a single author to have a functional, fast language with a working garbage collector
From what I gather from the article, they didn't implement a garbage collector, but rather integrated the Boehm GC. This is a conservative collector, so it doesn't collect all garbage.
> But the fact that these are the features being complained about, not the core of the language, says something in itself.
Memory management is a core part of a language. According to the article this core part doesn't work, which is a pretty big flaw.
The problems with V has always been that its marketing is full of lies and its main selling points don't work as advertised. The same source code, but without the deception, might very well be an alright language.
Just like how healing crystals are perfectly fine if what you want is decoration and you think they look pretty. It doesn't make the deceptive marketing okay.
> it's quite impressive for a single author to have a functional, fast language with a working garbage collector and arena allocator (with some issues) in only a few years.
As the included code shows, the gc is boehm gc, and checking their repo shows they just include libgc/bdwgc. This is absolutely not a knock against anyone here, it's just about the standard library for this need, and I think it is a far smarter move to use it than for most to attempt to make their own general-purpose gc (though boehm can't catch all leaks).
I feel it would be wrong, however, to characterise this as being a single author having made a language with a gc and arenas, as if those were significant parts of the author's own developments, rather than using a well-picked import and a half-baked implementation of "arenas", which here are really just a global linked list of buffers, freed only at exit, and so everything leaks [0]. They're not really arenas, you can't use them locally in a region of code or as scratchpads, let alone multi-thread it. By their code's own admission, it's just a little pre-allocation to batch mallocs for all the little heap allocations of a GC-assuming codebase, so they're not really arenas like you'd use in C or elsewhere.
Not unimpressive, it's a valid approach for some uses (though not general purpose), it's just different from a language with their own gc and actual arenas. Indeed, just implementing an arena barely even registers in the complexity, I feel, as arenas really should be very simple in most use cases [1]. It would be far more impressive to have them actually integrated and be available as a true alternative to a GC for memory management, particularly integrating common patterns (e.g. [2]) in a way that could serve as a drop-in replacement, such that we can actually provide bounded lifetimes and memory safety without a full GC, let alone support multiple concurrencies with it from multi-threading to coroutines -- this would likely still be unsafe without a GC compared to, say, Rust or Vale, let alone Pony or SPARK, and would likely require a cultural shift in manual management akin to Zig or Odin, as it may be largely moot if dependencies end up enforcing the gc themselves. Still, again, making anything substantial is never unimpressive, we just need to retain the perspective of what was achieved and how.
As to the rest, well, I think it's fair to say that there should be a clear delineation between statements of "we can do this and here's how" and roadmaps with "we're aiming to do these things and here's our current progress". In my experience, people are quick to get these mixed up when they're excited about making something, and none of us are fully immune to this. It's not some moral failing or anything in and of itself, it can very easily be an honest mistake, but humans see patterns everywhere, so we often need to be receptive when others are trying to help us be level-headed and clear things up; otherwise a reputation begins to form. Especially in this industry, reproducibility matters, as we're all too familiar with the smoke-and-mirrors of demos (not to personally claim there is any here, just that it obviously helps dispel such concerns).
And, of course, second chances are always offered if someone is willing to amend mistakes.
How do you feel about the basic stuff not working as demonstrated in the article? What's so special about V that you prefer using a literally broken language? (The perma memory leaks are basically enough already to qualify it as broken)
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++)
Since you don't want to use HN as intended, I've banned the account.
If you don't want to be banned, you're welcome to email hn@ycombinator.com and give us reason to believe that you'll follow the rules in the future. They're here: https://news.ycombinator.com/newsguidelines.html.
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.
> 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.
If you need to insulate yourself to the degree that you ban someone for answering the question “V or Go?” with “Go, obviously”[1] then what’s the point of even maintaining a community? All you’ll end up with is a bunch of yes-women.
[1] Is V production-ready?—no. Is Go? Yes, for a long time.
> 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.
What he is saying rings true. There is a level to all of this "that's beyond the pale".
> Is V production-ready?—no. Is Go? Yes, for a long time.
Go is a 10 years older (from 2009) corporate creation. It's not an apples to apples comparison, which can easily set the stage for tension in an interaction. It does not make sense to compare how production-ready a much older language is to a younger volunteer open source language in beta (and whose site and version number indicate that's so).
As I said, some grief is deserved in all these cases. But unreasonable criticism makes people also not listen to more reasonable (deserved) criticism. That was my entire point.
That you're completely ignoring this and instead just reply with an unsubstantial and off-topic dig at gnome is an excellent demonstration of my point.
I dunno, I've been using gimp for literally decades and for about a year recently, it couldn't paste from the clipboard. I didn't even bother reporting the bug because I knew I'd come across like an entitled whiner in today's atmosphere.
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).
Musk says "full self driving car next year for 60k" means "partial self driving in 5 years for 75"
I don't have a full explanation of why V made me so angry, but coming up with so many bold claims invalidating whole decades of an entire industry is mind boggling for sure.
Ah right. Well, Tesla is a company, whereas V is basically just a few people working on it in their spare time. I don't think you can really compare the two or hold them to exactly the same standards.
Or to put it in another way: people can be flawed, and I think that's okay. I don't think it's right to jump on that with assumptions of malice.
I think people (and designers of other languages, in particular) were outraged that not only did V have the very aspirational claims, but there was also a Patreon (or similar) and the general attitude of the newly forming V community that felt undeserved for that level of...aspiration. I think that doesn't quite fall under malice, but I imagine it felt unfair to many.
"v" claims to be a language in which you can choose between an "arena", "garbage" and "don't care, do it for me" memory handling, on compile time, without taking care of your code base at all.
That's an extraordinary claim, to say the least. And, as we all know, extraordinary claims require extraordinary proofs.
