[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...)