[Xevi]

V looks interesting, and I wish it the very best. However the attitude of the lead developers toward criticism or negative feedback (even if it's not valid) is highly off-putting imo. Everything negative that people say appear to be taken as an "attack", and as far as I've seen they are quick on the trigger in regards to banning or blocking people that they disagree with. And at the very least they just completely disregard all negative feedback as lies, scams, conspiracies, etc.

The responses I've read by the devs are in stark contrast to what I've seen in other languages I use, such as Rust. I hope that as the language evolves, the developers will start reflecting on the way that they interact with others and how it impacts people's view of V. I could never justify using a language like V in production if I couldn't even trust the lead developers to be level-headed during criticism.

I'm sorry for ranting, I really wish the best for V and its maintainers.

[richbell]

> I'm sorry for ranting, I really wish the best for V and its maintainers.

I appreciate you posting this. I like the premise of V and really want for it to suceed, but this is a good summary of why I think so many people dislike V: the lead dev and community do not engage criticism in good faith.

I'm sure V receives its fair share of unwarranted criticism, but a lot of legitimate criticism and questions are either met with a) hostility or b) incredulity, which causes people to dislike the language for fundamental reasons.

Both the creator and community members gaslight (for lack of a better word) and act as if they're happy to receive questions or feedback, but even in this thread you can see people being treated like I mentioned above.

E.g. https://news.ycombinator.com/item?id=31947510, https://news.ycombinator.com/item?id=31947121, https://news.ycombinator.com/item?id=31947212, https://news.ycombinator.com/item?id=31947014, https://news.ycombinator.com/item?id=31946715, https://news.ycombinator.com/item?id=31947977

[johnfn]

I don't have the time to go through every link, but let's just look at one or two:

> https://news.ycombinator.com/item?id=31947177

I mean, the article linked at the top is just outrageous - just read through it. For instance, it claims that V misleads by claiming that it has no null. But really what the author has done is found a bug in V that allows a variable to be set to null. A bug that unintentionally leads to creation of null is wildly different than V not supporting non-nullability at all. It'd be like using FFI in Rust to set a non-nullable variable to null and claiming that meant Rust had no type safety. It's absurd.

I can understand the maintainer's frustration.

> https://news.ycombinator.com/item?id=31947212

OP claims V has "huge promises it hasn't kept". V is version 0.3. This seems wildly unfair.

> https://news.ycombinator.com/item?id=31946715

OP kicks a conversation in poor faith with "Wanna know something funnier also posted in previous thread?" about a V bug - which HN turns a blind eye to - and then suddenly the HN community pounces on the V maintainer when he gets frustrated in return? What?

[richbell]

> > https://news.ycombinator.com/item?id=31947212

> OP claims V has "huge promises it hasn't kept". V is version 0.3. This seems wildly unfair.

Keep in mind that V didn't start out as a v0.1 with an ambitious roadmap, it popped up as website with a bunch of exciting features that made it seem further along than it actually was (https://web.archive.org/web/20190315194630/https://vlang.io/ and https://web.archive.org/web/20190315173156/https://volt-app....). I suspect that's what OP is referring to. Incidentally, this is also what prompted articles like "V is for Vaporware".

>> https://news.ycombinator.com/item?id=31946715

> OP kicks a conversation in poor faith with "Wanna know something funnier also posted in previous thread?" about a V bug - which HN turns a blind eye to - and then suddenly the HN community pounces on the V maintainer when he gets frustrated in return? What?

I specifically linked to the_duke's comment offering some good-faith feedback.

---

But I digress. My intention isn't to argue that V is bad, just to provide context to why it's such a divisive topic.

[johnfn]

> I specifically linked to the_duke's comment offering some good-faith feedback.

My point with this thread is it follows a common pattern. A HN user will post something in bad faith. The maintainer will respond with annoyance. Then someone like the_duke will moralize about how the maintainer shouldn't be so antagonistic. Then GP will put it in a list and say "the lead dev and community do not engage criticism in good faith."

What is going on here?

[sph]

There are some repeating thought patterns on some hot topics in this forum that makes me question whether it's work of trolls or naive people asking the same questions that end always the exact same way.

When it happens, it feels like living in Groundhog Day.

See any Brave post. There's a comment about BAT stealing money, people debunking it and the same arguments over 10 comments. Just below that someone mentions Eich's history at Mozilla, same pattern.

See any Urbit post.

See any V post.

See any foone post.

In these threads you find always the same archetypes of comments and posturing it makes me wonder if we're really living in a simulation of not very good AI. Or that a group of people is collectively pretty dumb and more predictable than you'd think.

[_gabe_]

> The maintainer will respond with annoyance.

The maintainer is the face of the product in certain ways. We would never defend a corporate CEO responding in annoyance to their free/paid users because it's unprofessional and puts the brand in a negative spotlight. In the same way, if you're leading/promoting a project you are held to a higher standard. You can choose to ignore bad faith comments, or respond in a positive way to bring the discussion to a higher level of civility.

Yes, it's annoying to have people give bad faith criticisms. But if you want a product to succeed and you want to foster a positive community, you should always elevate the level of civil discourse. So I disagree with your sentiment that other users are moralizing here.

If I'm going to engage with a product, it gives me much higher confidence knowing that the maintainers conduct themselves in a professional manner, even when a user is unprofessional.

[InefficientRed]

> A bug that unintentionally leads to creation of null is wildly different than V not supporting non-nullability at all.

You have the "badness" ordering here totally the wrong way around. Soundness is about trust.

A known-unsound system is not necessarily bad. I use C and Python. I know the tooling can't give me very many guarantees, and that I have to do the book keeping myself. "Caveat emptor".

In a much, much stronger sense: there is absolutely nothing wrong with a sound system with explicit escape hatches. Bothing. I use sorry in Isabelle and admit in Coq. I do type casts in Java. I know where I can and cannot trust the tooling, and there are clear flags where I need to do my own book keeping. FFI in Rust is an explicit escape hatch.

I can't think of a single system that doesn't have some sort of explicit escape hatch from soundness. As long as it's explicit and understood and above all intentional, this is a feature rather than a bug.

But it's very hard to justify using a system that's supposed to be sound and isn't! I don't know where to trust the tooling.

And the blog's examples are not contrived. They are actually very straight-forward mistakes as far as type systems go... most production type system bugs are much subtle.

[johnfn]

> But it's very hard to justify using a system that's supposed to be sound and isn't! I don't know where to trust the tooling.

At the point V was version 0.2. Of course it has bugs - even bad bugs.

The article went through each feature of V, found one bug per feature, and claimed that V failed to have that feature.

There are constructive and non-constructive ways to start a conversation about bugs in a language. One constructive way is to open Github issues. Writing an article claiming that a language fails to have those features at all is one of the least constructive ways I can imagine.

[InefficientRed]

> There are constructive and non-constructive ways to start a conversation about bugs in a language. One constructive way is to open Github issues. Writing an article claiming that a language fails to have those features at all is one of the least constructive ways I can imagine.

Github issues vs. articles must be a generational thing; I have never used Github's issue tracker even for FOSS projects (admittedly not because we had better alternatives). I'm not even particularly old, but I am old enough to pre-date GH issue trackers as the de facto FOSS issue tracking solution.

Certainly, I would reach out to the author of a project -- especially a personal not-for-profit FOSS project -- before putting them on alert with a highly critical blog post. Except in exceptional circumstances (eg intentional spyware or backdoors embedded into the project).

But I don't think of articles as better or worse than GH issues in terms of form.

This kind of reminds me a tame version of the "disclosure debate" in security in the 90s/00s, I guess. Just because a lot of that debate was claimed to be about protecting users but was actually often about protecting egos (and "look how smart I am" zine articles that weren't entirely written in good faith or professional ethos). Except, of course, that in this case I think a simple cultural difference could explain a lot without any ill intent on either side.

(FWIW I'm not saying either of us is right or wrong. Perception is inherently subjective and all culture is relative. But I think I better understand how this project became so controversial...)

[amedvednikov]

How's the first link an attack for asking simple questions?

(By the way there's not a single question there.)

[richbell]

Initially my intention was to link questions, but I decided to link to any genuine comments that reflect the GP's sentiment.

I've updated the language in my comment.

[amedvednikov]

Only I can ban, and I haven't banned anyone in 2 years. You can read my comments here about the attacks.

There's actual valid criticism and feedback like in https://github.com/vlang/v/discussions/7610

But there's also trolling, harassment, and completely baseless attacks.

[mst]

The way Cadey was treated by your community entirely ended my interest in your language.

[amedvednikov]

Who's Cadey? Do you have a link?

[neven]

mst probably meant this: https://xeiaso.net/blog/vlang-update-2020-06-17

[Tozen]

I think what was being referred to was any V GitHub posts, which would involve the V community. The V community has nothing to do with nor have any control over blogs and websites owned by others.

As for Cadey, it appears the person is continually self promoting, to include odd accounts continually linking to old and outdated blog posts on its website, at the expense of the V language and any chance given (see almost any HN post on V).

Cadey (or under various names) was the one that started off smearing V's author and the language with things like "V is vaporware", "V is lying", "recommend against using it for anything", hoping V would die off type nonsense, etc... Mind you, the attacks started against the very first released Alpha, as if it was supposed to be instantly production ready (and that is very much not how programming languages work).

So other programming languages are given the benefit of the doubt of even after say 5 or 10 years of development, while V was supposed to be a finished polished language from day 1? Just plain ridiculousness and clear bad intentions.

[colejohnson66]

Xe/Christine never claimed V had to be polished on release. That's patently ridiculous. What they said was: the original features were not called out as being goals, so they took them as features that (obviously) didn't work. Those claims were eventually marked as "WIP" or whatever, which is exactly what Xe wanted. No one is claiming an alpha/beta doesn't have bugs, but V promoters like yourself claim any reminder of V's prior actions are saying that.

IMO, V has made great strides since the initial release, but none of Xe's claims were inaccurate. All Xe's first post ("V is for Vaporware") did was call out the website as being misleading.

Sure, people could see that it's a 0.x release and know it's an alpha/beta, but that's not the point! It didn't say that the features were WIP until after Xe's post. Compare vlang.io two days before Xe's post[0], and the day after their post[1] (notice the addition of "WIP" markers and a new paragraph about 1.0 above the fold).

It also doesn't help that any time a post about V comes up, people try to explain these things, but the author and people like you refuse to acknowledge it. What most people want is for V to admit the website was misleading at the beginning, but it is now a bit more clear. What we get instead are conspiratorial claims of brigading to destroy V. Unless people can point to some Discord or Reddit group that actually does conspire to destroy V, it's a hoax. As much as the author wishes, posting negatively about V because of its past is not a conspiracy.

[0]: https://web.archive.org/web/20190621013937/https://vlang.io/

[1]: https://web.archive.org/web/20190624052507/https://vlang.io/

[johnfn]

I don't really agree. V seems to attract a much larger than normal swath of people who enjoy trying to score points off of technicalities. e.g. people claiming the entirety of V is an unsafe language because they found a single bug in the compiler, etc. Languages like Rust never garner this sort of point scoring in the comments.

> as far as I've seen they are quick on the trigger in regards to banning or blocking people that they disagree with

Do you have any source for this claim? Without a source this simply reads as another person trying to sow uncertainty and doubt. I haven't seen anyone banned or blocked on Github.

[wb13579]

That's because V already lied once about its memory management, see https://news.ycombinator.com/item?id=31947048. Any highlighting of that fact is met with deflection and dodging.

V is still making dubious claims: his newly invented autofree isn't stable even today after years and users are encouraged to use garbage collection instead. It's hard to trust that when we've been lied to already.

[Tozen]

V is not 1.0, so why so bothered that autofree isn't stable enough? Especially if the person is not even using V. Clearly the majority of V supporters and users are not bothered, and are finding V useful to them.

Autofree exists and somewhat works (https://youtu.be/gmB8ea8uLsM), it's a matter of perfecting it so that it requires minimum user knowledge about memory management. You can enable Autofree and use it, but the user must understand what they are doing and reference examples of code and programs that do use it.

So in the mean time, the V developers decided to experiment with and select GC as an alternative memory management method. That should not be a problem for a language in Alpha, nor for anybody "outside looking in", that understands language development. GC usage worked out great for them and the users, so they made it the default. Autofree and manual, would be the other options that users can choose, but they must enable those.

Furthermore, other languages like Nim, have multiple memory management options. I don't see people on HN getting so hot and bothered about that, just for some strange reasons, they seem oddly bothered by V adopting and having multiple options (GC, Autofree, and manual) instead of one.

[johnfn]

What? "After years and years"... It's version 0.3. Not even stable 1.0. The conversation you had with the maintainer puts you in a worse light than him, in my opinion.

[wb13580]

He's already promised something too good to be true and it turned out to be a lie. From wayback machine https://web.archive.org/web/20190520021931/https://vlang.io/...: "(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."

I was excited for that. We were all excited for that. Then it wasn't true. I would forgive him but he seems to be continuing.

Then he walks that promise back, pretends he never said it and suddenly invents this magical "autofree" system but gives no details on how it works. Rust was never that secretive, it was based on published theory.

He claims it removes 90% of reference counting but if that was possible then Swift or Python or anyone else would have done it.

If it was based on solid precedent, or there was any research, or he published anything about how it works, or he didn't take donations, or it wasn't advertised on the website, it would be fine. But that's not the case.

[sime2009]

Let me get this straight. Someone is running an open source project. They said they are working on some ambitious feature. Said ambitious feature hasn't materialised up to your standards, and now you feel like you've been cheated or lied to?

Maybe you should ask for your money back.

[Tozen]

So are we saying that open source programming languages are not allowed to make changes to their goals, features, or roadmaps?

And if they do make any changes, then people should go to the wayback machine and hold them accountable to what was in the past, and not what they are showing and saying in the present?

Seems to be very unrealistic, and more of a personal grudge or pet peeve.

[richbell]

These aren't mutually exclusive. What isn't captured in individual posts about V is the historical context of previous discussions.

I think many people feel scorned or resentful towards the attitudes, which means they're more likely to speak negatively of it in the future.

When V was first announced, there was a lot of hype about "Volt": a cross-platform Slack app written in V (https://web.archive.org/web/20190315173156/https://volt-app....). It was slated to be released 'soon', but months went by and there was nothing. When it eventually did release, it was nowhere near as complete or polished as people were being lead on to believe. Same thing with V itself, and people were attacked for pointing this out.

There's a long history of over-promising or hyping things that don't exist, and not handling constructive criticism well. So there's a number of people who actively dislike V.

[mst]

Right, people who dislike me will call me a massive arsehole (and not necessarily be wrong) but V-lang stans leave -me- cold.

[amedvednikov]

Exactly. The amount of nitpicking is ridiculous.

There's an entire article half of which is about a single checker bug that has already been fixed.

Or claims like "it uses official system api (libc), therefore you can't say it doesn't have dependencies".

[mllllv]

I think the problem initially was that people accused the creator of malice for no reason other than not being more specific about which features were a work in progress. I agree that it's not good to treat every criticism as an attack, but sometimes criticism of V (as an outsider, I've never used it) feels more like anger towards the creator rather than a helpful suggestion. For example, there's a difference between saying "I've found a bug in an advertised feature" and "You're a liar", which is how much of V's critics sound to me.

[corford]

That's not at all the vibe I get from one of the lead devs posting here. I see it more as frustration from dealing with low effort snipes/trolls.

The language used on the main vlang site also seems calm, clear and unsensational (at least to me).

[option_key]

>The language used on the main vlang site also seems calm, clear and unsensational (at least to me).

It wasn't always like this. Back in 2019, its website looked like this:

https://web.archive.org/web/20190303184805/https://vlang.io/

As you can see the website claimed that its compiler is "200x faster" than C compilers, while neglecting to mention that it merely translates V code to C, so you still have to run a C compiler.

"400 KB compiler with zero dependencies" (apart from a C compiler and libc).

"As fast as C" - a lie.

Apart from deceptive marketing, there were serious issues with the code quality of the compiler:

https://github.com/vlang/v/blob/d32e538073e55c603992b5b65ebc...

[amedvednikov]

"As fast as C" is not a lie. It literally translates to C.

The 200x compile speed up referred to C++ compilers, this was vague and hard to measure, since the languages are so different, and was removed.

The code may not have been perfect at the time of the 0.0.1 release, but it worked. V could compile itself.

Now it's much better and more organized.

[option_key]

>"As fast as C" is not a lie. It literally translates to C.

No, just because it outputs C it doesn't mean it's as fast as hand-written C. Using that logic, every language that outputs machine code is as fast as assembly, which is obviously not true.

[gompertz]

If you look at the C that's generated using -keepc flag, I think you will be hard pressed to find any glaring inefficiencies to "hand coded C"; especially none of which GCC optimization wouldn't handle with -prod compiler flag. Even if there were, for the very large majority of users who are not highly proficient in C (which is becoming more and more common these days - Grey beards are rare), the V way is going to outperform novice to intermediate-skilled C programmers hands down.

[vlang1dot0]

I don't see how that really follows. V heap allocates any value which is address taken. You don't need to be an advanced C programmer to use pointers.

[amedvednikov]

But it is true. V doesn't add any overhead. You can verify with `v -o file.c file.v`.

As long as you use the same data structures and algos, you'll get the same perf.

There's stuff like bounds checking, but it can be disabled, and it adds like 5%.

[amedvednikov]

> frustration from dealing with low effort snipes/trolls

That's exactly what it is :)

[bakul]

FWIW, my view is that even the best programmers don't always have perfect non-programming skills and it is better to give them specific objective feedback via bug reports/technical comments etc and not focus on how they are not doing the expected thing or behaving in an expected manner. Focus on and encourage their good work if possible.

[Tozen]

> However the attitude of the lead developers toward criticism or negative feedback...

I disagree about that, because there is a major difference between submitting a bug or disagreeing about a claim or feature versus outright trolling, smearing, instigating drama, or trying desperately to create negative public perception.

Issues and discussions can be brought to V's GitHub (https://github.com/vlang/v/issues, https://github.com/vlang/v/discussions), but instead what various competitors and detractors do is create drama filled smear blogs or bad joke posts (on various websites) against the author or language. That's not any attempt at being helpful or constructive, that's more about slander or to create such negative sentiment in the hope of killing off the language.

When issues and discussions are brought peacefully to V's GitHub, they are discussed and debated intelligently. If any such issues have any validity, then they are usually fixed.

> Everything negative that people say appear to be taken as an "attack"...

That's simply not true. What does happen, is various competitors and detractors do specifically attack and smear the language or author, and who have no intention to want to be helpful or make any improvements. To include engaging in downvoting or trolling those who appear to be V supporters.

Such attacks and smears are not about fixing anything, their point is to be destructive, create negative publicity, and dissuade others from using a rival language.

If there are those that don't think that is the case, then simply ask yourself why many of those engaging in such attacks and smearing who claim to be technically knowledgeable or interested in using the language are not making their case on V's GitHub? That's where a person can go to improve V and get it production ready. Continually engaging in smearing is not about fixing, improving, nor reaching out to V's developers or community.