Slightly off-topic but this whole thing made me curious.
I keep seeing V being "attacked" by various people with these kind of blogposts (or even HN accounts dedicated to criticizing V), with broad range of claims or counter-claims to what V wants to achieve.
While this is maybe not completely absent when other new languages comes up (like Golang or Rust), it feels like V really brings out the people to come up with ways of criticizing it.
Do you have any ideas about why or how come? Have you noticed anything in particular that makes people want to (almost) aggressively "prove" V to be wrong?
Basically, do you have any guesses to why V seems to have more "enemies" out there, compared to lets say Rust or Go?
IMO, it's pretty simple. At the beginning, V was making huge claims that turned out to be false or misleading. The developer clarified that many of those features were actually goals. Fair enough.
There's also the whole issue with blocking people who criticized the language (eg. Xe) because V was being "attacked" as if there's some conspiracy to destroy V. The claims may be outdated, but the response by the developers put many people off.
V has made huge strides since then, but people are very resentful.
Yeah he was the first to call me a scammer and claimed V had a dependency on glfw.
He was really persistent with his attacks, even received a warning from dang.
I found it really surprising, because before the release he wrote:
> Wow, that's incredibly fast. Self-hosted in 2 weeks? Hot code reloading? This is everything I plan to do with Zig, but apparently done already. How did you do it so quickly?
Can you provide a link for that quote? I want to read it in context, and my attempts searching the web only brings me back here and another place with this quote without a reference. Thanks!!
I'll also add, my personal reading of the quote has more than a note of "this sounds too good to be true." But that could well be a matter of interpretation.
Don't think was an apology. I find it dubious Zigs README on GitHub reads "never to exploit them financially". What a weird comment... Notwithstanding the whole readme comes off like a weird socialist manifesto.
V seeking (and receiving) Patreon or GitHub donations is not exploiting anyone. Neither mechanism is a contract. Either can be cancelled anytime, immediately. So like it or not, the sponsorship is a pretty accurate reflection of satisfied people (unless one is simply too lazy to cancel their pledge...).
You posted lower down asking to be called out for specific behaviour that people find objectionable.
This.
It’s complete nonsense that there is a conspiracy to kill v off. You know it. We know it. Saying it is just drama for the sake of drama.
> And the issues discussed are questionable at best. Half the article is about a type checker bug, which was a 3 line fix.
> Then false claims like being able to modify array.len.
This.
You’re just creating drama saying things like this.
Just say: “The issues in that review have been fixed now, please have a look and submit bugs in the issue tracker if you find them”.
If someone has a legitimate thing to say, and at the time they say it it’s valid… that’s fine. If was wrong at the time, then by all means call it out.
…but here’s the good story about v: you fix bugs. A lot. Quickly. You build lots of stuff. It’s very impressive.
Things aren’t always perfect; it’s v0.3 for goodness sake. It’s fine. Just a) don’t claim it’s perfect when it’s not, and b) just clearly point out when issues that have been raised are fixed.
I’m really sorry you feel that way; I honestly respect the work you do and I’m convinced you’re not correct about this… but hey; you’re deeper into it than me. Maybe there is? I don’t know.
…but, please also stop and read what I said.
You asked for specific examples where your interactions are causing problems.
this is it. Don’t post like this. You’re accusing people of attacking you, attacking other people (for example your comments on the author of Zig below).
This is what causes people to have bad interactions with you.
I think you don't fully understand or know of the scale of the attacks and trolling carried out by detractors and competitors. Which includes hiding what they do and their true purposes, and attempting to instigate and influence others to perpetuate attacks, drama, and smears for them. There is also the gaslighting whenever people recognize some of their actions, recognize their throwaway or troll accounts, or against attempts to call them out. This includes doing such on other websites, not just HN.
I don't know you, but I think you should PR-manage the situation without being confrontational. Writing a blog post about it just invites the trolls to write an answer!
Do you know how many "X is better than Rust", "X language is trash" articles are out there?
Just be passive-aggressive like "Hey! thank you for the bug report and for taking the time to make V a better language! We'll check these errors!". Dismiss them and go your road.
It's funny because in the previous discussion I got lots of "what's the problem? fix the bugs and publish your own post going through the points in this one".
I think it’s OK to write a blog post about your progress, with a positive attitude. A very different thing is to write a blog post refuting a troll. “Don’t feed the troll” is as old as the internet.
I sincerely hope you reconsider posting it. Even if you're a 100% right from your POV, it will still give off a negative energy and hurt your project. I think @wokwokwok has a good point, why not just focus on fixing bugs and building stuff instead?
Because these articles are meant to stay for years.
People will keep linking to them and say "didn't you see? V uses shell to do http requests! what a joke"
This most recent article by an anonymous author had all of the issues fixed within several days, but it wasn't updated, it'll stay like this forever, as planned.
I do understand that that must be frustrating. What I don't understand is why you think writing a blog post about it will have a positive effect on your project.
Hey.... even if people are attacking V-lang, don't worry. Any good thing that disrupts existing "kings" gets thrashed initially. That's human behavior. Ignore it.
But, if lead dev replies in ways that seems offensive, or attacking, that is something that actually creates permanent dent in the adoption. Even if you are right in saying what you are saying, it still matters, a lot, to be polite.
I'm someone who really really wants V to succeed. I love what rust is able to achieve, but not the complexity it brings. V-lang gives me what I want from a language.
Language is beautiful, now it's your turn to be the same. Ignore the trolls. Many of them are paid.
And best wishes.... keep the good work. It never goes in-vain.
You made that claim a couple of weeks ago, somebody investigated your claim, it turned out that you were grossly distorting the actual comment when paraphrasing. And given you continued to be active on that thread, you're clearly aware of this. Why continue spreading the lie? At this point you can't even claim it was an honest mistake.
Yes, it's very different. Xe is predicting that V will die in obscurity, and recommending that people ignore it due to that prediction. Look at the second half of that comment:
> There are good ideas there, but if you sell someone the moon and give them a block of cheese that's kind of a scam.
Xe says "There are good ideas there". What do you think the metaphor of being sold the moon and receiving a block of cheese was intended to express? What does it mean to you? To me, it very clearly expresses that the language described by V's marketing would be extremely valuable and desirable, and that Xe is disappointed that V does not live up to what they expected. It's bizarre to me that you somehow see this as consistent with "should die".
What is your evidence that there's a conspiracy? Why do you believe that people are secretly coordinating on secret plans to destroy you?
Everything I've seen is completely consistent with individuals disapproving of what they see as you repeatedly claiming that V is far more capable and ready than it actually is and ignoring others who point out their perception of the same exaggerations.
I'll be curious to read your upcoming blog post about this topic, as I have yet to see you describe any justification for your conspiracy claims besides you finding it implausible that people could actually disapprove of how you talk about your work.
The blog posts that you keep claiming are maliciously-motivated conspiracy seem entirely normal criticism to me. They describe their goals and motivations, and those goals and motivations seem like very normal and reasonable motivations that explain the content of the blog post. I don't see anything that would need speculated malicious conspiracy to explain it.
Creating a blog, with an obvious smear title like "V is Vaporware" and making comments like "I recommend against using it for anything...", is not "normal" criticism. That is attempting to go above and beyond, with drama and smearing.
To include following such blog posts up with more linking, smearing, drama posts, and attempts to use such to get more attention for one's self at the expense of the V language.
There are things that are actually vaporware. It is reasonable and normal for people to actually say when they believe that something has a lot of signs of being vaporware.
Are there really, truly no tools that you personally recommend against using?
> There actually is such a conspiracy. People who wrote these articles literally wrote they wanted V to die.
That's not a conspiracy[0], but a review[1]. You should be glad for the people that actually spend time to market your product, raise your credibility, tell you how you see from outside, and provide independent checks. For free.
We cannot know what the blog author was hoping for, we can only know what they wrote. And what they wrote is not anywhere near what amedvednikov repeatedly claims. Why are you ok with such blatant misrepresntation? If this conspiracy actually exists, isn't there some evidence that actually stands on its own rather than needing to be lied about?
It doesn't. But there's a more important point: you're paraphrasing somebody you clearly have a great deal of personal animosity toward, completely changing the meaning in the process, and with no indication that this is what's happening. You've continued doing that even when it's pointed out to you. There are two options I can see:
- You genuinely are not fluent enough in the language to either understand the original statement, or to write a fair paraphrase, and are not willing to believe this mistake.
- You know exactly what you're doing. That is, if you gave the actual quote, nobody would for a moment take it as a proof of your conspiracy claims.
Neither of the above is acting in good faith. I'd ask again whether you'll stop lying about what Xe said, but at this point the answer feels pretty obvious...
While wishing V would die is extreme, many people are just resentful about how V treated criticism in the beginning.
Not to mention that a conspiracy requires a coordinated effort. It's a lot more likely that blog writers are upset about something and decide to go on rants about other minutiae they find instead of submitting GitHub issues.
There are coordinated efforts on discords to brigade such threads, there are entire new accounts created just to reply to each of my comments negatively (luckily just today HN banned such an account), this very post about V 0.3 was mass flagged 3 times and removed from the front page 3 times, there are articles that take a simple bug fixed by a 3 line commit, and make a huge deal out of it spending a month writing an attacking post. Who would spend a month to write an article about a type checker bug?
> Who would spend a month to write an article about a type checker bug?
I have no horse in this race, have never heard of V, and frankly find the emotional charge in this comment section extraordinary... odd.
But I am a PL person.
Bugs in the type checker are pretty unambiguously a big deal. I totally understand why the examples in the blog post are alarming. The point isn't that they can be fixed by 3 lines; the point is that there were obvious soundness bugs in the type checker implementation and the language designer's attitude seems to be "NBD if the patch is small enough". Given the post and reaction, I would not be surprised if there are many more soundness bugs lurking. So, that's an issue if I want to use the language for anything serious.
That said, it looks like a hobby language in its early stages of approaching maturity, so the degree of divisiveness is seriously confusing. My reaction to all the drama is closer to "yup some soundness bugs; type systems get subtle fast, what a great thing to learn from" than "I hope V dies / the V critics are terrible".
I'm guessing there are weird personality/politics at play, but don't care enough to find out.
Simply, V is very divisive. So, some people who peruse HN but don't have an account will see a V post, and make an account just to comment. Humans are just irrational.
There's definitely trolls; I wasn't trying to imply otherwise. There's always going to be people who think your project is stupid, and it'll only get worse as the project grows. I think the best solution is to just ignore them.
It's great you're level headed on this. As an indirect measure, I've perused the Discords of competing languages and the vibe is a world apart in terms of maturity, age group, topics (bullying is very prevailing, talking politics rampant, excessive anime) - essentially unmoderated reflections of character. So it's no wonder that if that's the community forged behind the scenes (in those competing languages), that it's going to bleed out and become issues elsewhere - and V is one such topic that seems to be commonly targeted by those groups.
It's because V made impossible promises, and used those to get donations.
For example from wayback machine http://web.archive.org/web/20190520021931/https://vlang.io/d...: "(Work in progress) There's no garbage collection or reference counting. V cleans everything up during compilation. If your V program compiles, it's guaranteed that it's going to be leak free."
When people called him out for this saying that this was impossible he doubled down on it and said that it's fine to say things like that because of the "work in progress", as if it was coming.
It turns out, it was impossible. V eventually had to add reference counting.
The worst part is that he used lies like this to get thousands of dollars from Patreon sponsors.
It seems like he's trying to clean up his act, but he's still making some dubious claims. He claims to have invented an "innovative and flexible memory management" reference counting algorithm that removes 80-90% of overhead. But there's no way to do that with mutable data, as far as i know. And sure enough, it doesn't work, users are still told to use the garbage collection option. If that turns out to be true, I might change my mind, but I fully expect that it's a false promise too.
V backer here. I've never ever felt remotely scammed or deceived. So people who bring up the scamming topic can continue to do so with the imaginary money they did not pledge/donate.
Also I see the Patreon topic a lot - Patreon is not a contract. If one is unhappy they can stop pledging ANY time, immediately. So like it or not, the Patreon support you see is a very accurate representation of satisfied backers as well.
Your claim of "(Work in progress) There's no garbage collection or reference counting. V cleans everything up during compilation. If your V program compiles, it's guaranteed that it's going to be leak free." was absolutely a lie. That's why you had to eventually fall back to reference counting.
The newer reference counting system has an example but it's very easy to conjure a working example of a system that has fundamental holes. When people use it for larger programs it crashes or leaks even today. Is that incorrect?
V has "enemies" because that's how they respond to people giving them constructive criticism and questioning their claims. Most authors would relish of thorough technical analysis of where their issues where so they could improve their new language and compiler, but not V it seems.
They mostly seem to deflect with denial or claims the issues were 'nothingburgers', but if that's the case, it should be trivial to offer a rebuttal in the form of a blog post, but instead we get ad hominems and conspiracy theories.
Completely not true. We welcome criticism and feedback, we even have a topic with 800 messages called "What don't you like about V / what would you like to be changed?"
Out of curiosity, I checked the discussion in which you referred to by link. The person in question is not a developer or contributor, but appears to be passionate about the discussion. I don't think it's bad to have a difference of opinion, even among good friends. In addition, we can't always be right on every issue, and sometimes we have to "agree, to disagree".
The other person in that discussion on V's GitHub even apologized for appearing harsh, seems to have begged you to come back, and gave you a compliment.
Also deleting your part of the discussion also robs other readers from evaluating the full merits of your side. There will usually be people on your side of the discussion as well or see your point of view. I think you will find that overall and from what I've seen, people in the V community can be appreciative and welcoming, but like anywhere its a mix of different personalities and characters.
Just like work, and in life, you're going to come across a myriad of people who handle criticism in different ways. Be it for cultural differences, deductive reasoning differences, even down to childhood upbringing, you know the story... We all do. It's 2022.
Not that you've done so; but others seem to reciprocate back with bullying, and with twice the force of any denials. A lot of people need to get the wisdom that others are different from them, and simply move on. The same threads, blogs, comments have come up on every single V post - living rent free in many people's heads.
The "nothingburger" you quoted is a single word you took from a reply chain in which amedvednikov explained the 800 byte "memory leak" was actually just GC overhead and expected.
So it wasn't a memory leak, it is GC overhead, hence it being labeled as a "nothingburger".
What specifically do you feel hasn't been resolved or addressed properly?
>What specifically do you feel hasn't been resolved or addressed properly?
The author responding constructively to criticism. The bugs may be fixed, but if the author can't calmly engage and link to the fixed commit, or give evidence that, for example, everything compiled with GCC leaks those 800 bytes, well that's a major red flag about the project management of V.
I think the highly aspirational nature of the claims about V upon its original launch are why it attracted so much scrutiny. It claimed to do a lot of things and didn't clearly separate things that might be delivered in the future from those that would be features present in the language today.
And, judging by the review linked upthread, as of last month this has remained the case. For this reason, I'm not surprised that the scrutiny continues.
If you look at other posts in this thread, you'll see that this review is completely irrelevant since the bugs it complained about were fixed in several 3 line commits.
I won't pretend to be up to date on your language and what is fixed or working, but if it was so easy to fix these bugs that were apparently so trivial, why weren't they fixed before announcing / releasing the features? Even just communicating that a feature isn't done yet and may need a little more time (e.g. a beta tag) would go a long way in rebuilding trust with people outside your community.
Meanwhile, defensive reactions like those I see in and around this thread make me feel like I trust you less.
As I said in my previous reply, you're more than welcome to stick a beta tag on something that isn't ready for prime time yet. Take a look at Rust and their releases as an example of the ultimate in building a stable foundation that people trust.
I'm not asking you to never ship a bug. I'm saying I don't trust you or your language and giving you an example of how you might regain my trust. Feel free to ignore my advice, but if your goal is to encourage more people to use your language instead of encouraging more people to fight you, maybe you could at least give the impression that you were willing to hear someone out instead of telling them their opinion doesn't make any sense at all.
> Though you may just be asking somewhat rhetorically to probe for a response from a supporter
No, I was genuinely asking the question directly at the creator of the project, to understand their view of the contention they seem to be at the receiving end of.
I know the history of the project, but it seems to me like most languages in their pre 1.0 make claims about what they would like the language to be, not what it currently is, but they still don't receive their criticism in such manner. Or maybe I'm just reading into it too much. Hence the question :)
> most languages in their pre 1.0 make claims about what they would like the language to be, not what it currently is, but they still don't receive their criticism in such manner
That's because those languages make those claims in future-tense rather than past tense; they explicitly state them as goals, rather than presenting them as if they're already implemented. For example, I wrote a tiny scripting language for Erlang/OTP apps called OTPCL, and I make it clear in the README which features are actually implemented (like the parser and interpreter) v. which ones are in progress (like the standard library) v. which ones haven't been started at all yet (like the compiler). Same deal with up-and-coming languages closer to V's use case, like Zig; there's a clear distinction between those three levels of completeness.
V did not make that distinction originally; a large number of its radically ambitious goals were presented on the website as if they were already implemented, only to later be revealed to be "WIP" at best. A lot of people - including, at one point, Zig's creator - assumed malice here, figuring the disparity between the website v. the actual releases to be an attempt to swindle Patreon backers (I can't read the mind of V's author, but I would guess that it was more of a language/communication thing than anything outright malicious). In any case, that left a pretty negative first impression for a lot of folks, myself included - and while it seems V is making some progress, it's hard to get that bad taste out of my mouth and consider even trying it out when languages like Zig and Odin and Nim and Crystal seem to be a lot more transparent and realistic from the outset.
> You might want to look into the very dodgy history of the language. The negativity is not surprising.
This is a mostly content-free reply that casts vague aspersions; it's not especially helpful when someone asks, essentially, hey, what's going on here? to then respond that they may be interested in looking into what's going on. Of course they're interested—that's where the question comes from, after all. Please respond meaningfully, then, and abstain from replying with non-specific ad hominem.
Look, I'm not hostile towards the initiator or the language. I'm happy to give V a chance in the future.
But it started out with huge promises that could never be kept, and were tied to fund raising. This is why there was so much skepticism in the beginning, and why you are facing so much hostility now.
The way to change that is by professionalism and convincing arguments, benchmarks, showing how the promises are kept and responding to criticism in a good faith manner by providing technical explanations.
Not by responding with more hostility.
It's also perfectly fine for fans of the language to support it here, but there are many "content-free" posts in this submission that just hype up V with minimal value-add...
I'll publish a big blog post about this. It will debunk all these "V is a scam" articles.
Basically V appeared out of nowhere and got popular very fast. It took a lot of shortcuts: it was self hosted on release, GitHub started supporting it 1 month after the release, it had hot code reloading, fast compilation (v self is <1s [0]) and so on.
People developing other languages and their communities didn't like it, and decided to attack it.
There were 2 strategies: making completely false statements (like claiming that the V compiler has a dependency on glfw, so the no dependency claim is false, and claiming that V programs use libc, system's only official API, therefore again the no dependency claim is false) and nitpicking over bugs that are inevitable in a 0.1 language, and sometimes complaining that features explicitly marked as [wip] are not ready yet. One of the common questions I saw is "why release it if it's not ready". While that's the whole point of open source. I got lots of help from 500+ contributors and got to this point a lot faster.
Then there was also a misunderstanding with the "preview" release one week before the source code was released, and many thought V was going to be closed source. Over this week unfinished features were not marked as [wip]. They were marked so after the open source release, and now there're no [wip] features on the website. Everything listed there is working in latest V.
> People developing other languages and their communities didn't like it, and decided to attack it.
I honestly doubt this is the case. Aside from some cargo-culters (which are far from being a majority), most programming language enthusiasts are very welcoming to new languages and ideas they bring with them. I have never seen a "language war" happening this way.
Personally, I admire the V's ambitions (if the autofree() ever reaches production-quality it would be a total triumph over Golang's garbage collection approach), but I dislike the unprofessional approach to the community (explained in many other comments - particularly false claims about language capabilities, deleting criticisms, unwillingness to admit shortcomings and making up excuses for each of them, etc.).
There are 0 false claims about language capabilities on the website or in the docs.
If you can link one, that'd be great, and it'll be fixed. I've spent a lot of time verifying all claims are valid.
For example there was the "functions are pure by default except IO" which caused lots of criticism and memes. I simply changed the wording to a more verbose but correct phrase. So we do admit shortcomings and not make up excuses "for each of them"
We do not delete criticisms, we actually welcome them and any kind of feedback:
Saying "no undefined behavior" when what you really mean is "We define our language's behavior to be the same as C's" (in other words, you just punt undefined behavior to the C compiler) is deceptive at best. I'm specifically thinking of signed integer overflow here, but that makes me think there may be other cases as well.
You said there are false claims about language capabilities, I asked you to list them. It's a reasonable request. I don't want to have false claims on the website.
In my opinion, the current documentation on the autofree engine [0] constitutes a false claim about language capabilities:
> Most objects (~90-100%) are freed by V's autofree engine: the compiler inserts necessary free calls automatically during compilation. Remaining small percentage of objects is freed via reference counting.
> The developer doesn't need to change anything in their code. "It just works", like in Python, Go, or Java, except there's no heavy GC tracing everything or expensive RC for each object.
So, I am not entirely sure the best way to quantify whether this is true. However, I thought a fun test would be recreating "my first memory leak" -- the first memory leak I can remember fixing in code that I wrote. Specifically, I was essentially leaking some bespoke heap-allocated iterators I had created (inside of an infinite game loop).
So here is my little test:
struct Iter {
mut:
pointer int
}
fn main() {
my_array := [ 1, 2, 3, 4, 5, 6, 7, 8, 9, 10 ]
for true { // simulated game loop
mut iter := &Iter { 0 }
// heap allocated iterator
for iter.pointer < my_array.len {
print(my_array[iter.pointer])
print(" ")
iter.pointer += 1
}
println("")
}
}
I compiled this with -autofree -gc none, with V 0.3. Checking it with valgrind, it continuously leaks memory.
So, from what I can tell, this description of the autofree engine in the documentation does not accurately describe the existing functionality available in V.
I am curious where the 90%-100% figure comes from. It is such a specific number that it implies to me, as a reader, that it comes from an empirical measurement of an existing system. But, there is no link to where this measurement was taken. In my opinion, the documentation should include some details about how these figures were generated.
So, to be clear, is the intended reading of the documentation as follows?
> Most objects (~90-100%) are freed by V's autofree engine: the compiler inserts necessary free calls automatically during compilation. Remaining small percentage of objects is freed via reference counting.
> The developer doesn't need to change anything in their code. "It just works", like in Python, Go, or Java, except there's no heavy GC tracing everything or expensive RC for each object.
> These points are both currently untrue, and should not be relied on in code.
I'm hoping I don't come off as flippant here. I just don't see any way to interpret these claims as an accurate description without adding that third bullet point.
Okay, I really don't understand what you're saying here.
The claims are objectively false. The autofree engine objectively does not free 90%-100% of objects, it is objectively not true that "It just works."
If I understand you, you're saying that autofree doesn't work because of bugs in the compiler. But, the fact that the claims are false as a result of bugs in the compiler does not somehow make those claims true.
Autofree exists and does work (https://youtu.be/gmB8ea8uLsM), however, it doesn't work where a user can have a complete lack of understanding about memory management like various GCs do or have never used it before. Autofree, as it is, also requires looking at examples of usage in various programs.
The website and documentation does explain the situation, for those that cared to actually read them. "Right now allocations are handled by a minimal and well performing GC until V's autofree engine is production ready." This should be enough to understand that autofree is WIP and not enabled by default (which is referred to in the documentation).
The other issue, is that people who have never used V or autofree (not even talking outright detractors), might interject or repeat uninformed opinions about the situation. Where those that have more thoroughly experimented with autofree and have used V or are in the V community, would likely understand the situation and history of it (have read other things about it on V's GitHub or asked about it on discord).
I understand that autofree is WIP. I read that part of the docs, and I have watched the demo.
But I don't really understand what the intended reading of the documentation is.
If I were to completely take these two paragraphs out of context, they are factually untrue:
> Most objects (~90-100%) are freed by V's autofree engine: the compiler inserts necessary free calls automatically during compilation. Remaining small percentage of objects is freed via reference counting.
> The developer doesn't need to change anything in their code. "It just works", like in Python, Go, or Java, except there's no heavy GC tracing everything or expensive RC for each object.
So, what does this mean? Well, nothing, necessarily. If the context clarifies that these points are all untrue, then, the documentation could be considered perfectly accurate as far as I'm concerned.
However, when I asked if the intended reading of the documentation was that these points are untrue, the answer was--no, these points are all actually true.
I don't understand that position. These claims are straightforwardly untrue.
To me, your response is reinforcing my original proposed reading. That is--to me, your response indicates that I should read these claims as being false, and that the documentation is acknowledging them as false.
Now to me, that is a perfectly good response to my original comment. If this part of the documentation is not intended to be read as a statement of fact, that makes perfect sense to me, even though I do think it could be communicated better.
As it stands, though, I'm not really sure what I'm meant to get from this[0] comment.
When a person new to V reads the documentation (which they should be doing), they would also see the following.
"Note 2: Autofree is still WIP. Until it stabilises and becomes the default, please avoid using it. Right now allocations are handled by a minimal and well performing GC until V's autofree engine is production ready."
So, autofree (as a WIP) is not at this point working as intended, which is described by, "The developer doesn't need to change anything in their code. "It just works"..." I don't take this as any attempt to mislead or deceive, like you seem to be doing. The documentation is even telling people to avoid using autofree, as it's WIP.
Yes, there is a difference between how autofree is suppose to work versus how it is presently working. Yes of course, I can totally see how people get very excited about autofree, and want it 100% working or want its development accelerated. But, it should be obvious that at this point, when a person is using it, they are experimenting. When a person takes it upon themselves to enable autofree, in an alpha status language, they shouldn't be surprised there are issues.
Then bringing it back to what I had typed about earlier, using autofree at this point, requires that the person understands something about memory management and looks at examples of its usage. Particularly when a person is going to enable it, against the recommendation of the documentation.
It seems we are essentially in agreement on how the documentation is meant to be read, which is that the points it makes about autofree are not meant to be statements of fact.
Not exactly, because what I'm saying is that the V website and documentation is explaining what autofree does, describing what autofree is, and how it works.
It appears you are implying that if autofree doesn't work perfectly as it is described, then that indicates a false claim or deception.
The counter to that (and what I'm saying) is that the website and documentation states that autofree is WIP and even recommends not to use it, and tells users that at this time GC is used instead. There is no deception, they are being clear. So if the user goes against the recommendation of the documentation, they should not be surprised that WIP autofree in alpha status V, is not working perfectly.
Furthermore, autofree does exist. We are not talking about a lie or false claim, where something is not in existence. Autofree does function, so here too, we are not talking about something that does not work at all. We are now talking about to the degree it is working or how well it works. Which on that point, the website and documentation both indicate WIP, so a user should not yet expect it to fully function.
I further elaborated that if you experiment with it, you may get autofree to work well. But, that can depend on: the program, can require experience using V, some memory management knowledge, and/or going through examples of V programs that use it. The expectation (and what those in the V community are aware of) is that as V goes to higher versions on its way to beta status, we will see better performing versions of autofree that requires less to no needed user knowledge about details.
Should the null hypothesis be that all languages deserve equal praise & blame and thus equal amounts of negative & positive critique?
Maybe this language deserves more criticism. Or people are biased against it. Could be either explanation, or something else. But there ain’t just one single possibility.
> ...it feels like V really brings out the people to come up with ways of criticizing it.
V is an up and coming language in the categories of both C and Go alternatives. This means a wide range of competitors and "acolytes" who may "come out of the woodworks" to take a shot at a rival, at anytime. The more popular they believe V is becoming or the more threatened by it that they may feel, the more likely we are to see "shots fired".
This is not to say that various criticisms are not or will not be valid. In fact, constructive criticism can be good and healthy. Among them, bringing bugs and issues to the attention of developers or having technical discussions with the language's community.
But, the negative or non-constructive acts (attack blogs, downvoting, flagging, gaslighting, trolling, etc...) do shed light on some of the odd heavy-handed, sneaky, or aggressive vibes that many of us can see. It demonstrates the intentions of bad actors or those acting in bad faith.
> ...absent when other new languages comes up (like Golang or Rust)...
Golang and Rust are backed by major companies. They do have plenty of "enemies" and competitors taking shots at them, but they aren't given the media "airtime" for their negative narratives to stick and their attempts get drowned out by the size of the language's userbase or amount of "infomercials".
Various other newer languages simply lack the popularity, userbase, or sponsors for most to even take notice or care. So they are simply not talked about.
> Basically, do you have any guesses to why V seems to have more "enemies" out there, compared to lets say Rust or Go?
You have to keep in mind that V is an up and coming language, that is an alternative to Go, and somewhat to Rust. V is in the categories of C and Go alternatives. There are many other competing languages in V's categories, such as Zig, Odin, Nim, etc...
Not too hard to see how "enemies" and rivals can "pop out of the woodwork" to take shots, the more popular that V becomes or the more they might feel that V is a threat to their interests.
As for Go and Rust, they are backed by major companies, where "enemies" of their language will simply not get any or little media "airtime" nor enough traction to establish a negative public narrative that can stick. You can attempt to say something negative about them, but will be ignored or drowned out in various ways.
I keep seeing V being "attacked" by various people with these kind of blogposts (or even HN accounts dedicated to criticizing V), with broad range of claims or counter-claims to what V wants to achieve.
While this is maybe not completely absent when other new languages comes up (like Golang or Rust), it feels like V really brings out the people to come up with ways of criticizing it.
Do you have any ideas about why or how come? Have you noticed anything in particular that makes people want to (almost) aggressively "prove" V to be wrong?
Basically, do you have any guesses to why V seems to have more "enemies" out there, compared to lets say Rust or Go?