[sergiotapia]

Nah that article is old as hell - time for new information. Things change.

I also despise how many people want to shit on this new language before it even takes off. Why are so many people frothing at the chance to disparage this language and it's author? Never seen something like this.

[unclad5968]

Mostly because the author completely scammed the shit out of people by promising a ton of things to garner patreon support before open sourcing what was essentially a hobby project at the time. I haven't followed it very closely, but last I heard about it was not delivering on the "autofree" feature.

I dont really care about the language. I've tried it a couple times and it's nothing special (to me) so I moved on, but I definitely understand where the hate comes from. The author essentially lied for at least months about his project to get financial support.

Quick edit: to actually add to the discussion, I think the weirdest thing about V is the odd support it does get. Most projects, especially compilers, with as much controversy as V would never get any support. I'm very curious what its proponents are using it for and why they choose V over pretty much any other language.

[amedvednikov]

you heard wrong, it's been delivering quite well

https://www.youtube.com/watch?v=gmB8ea8uLsM

no one has been scammed, whatever that means in opensource development

[tene]

Oh, that's really cool to hear! I'm glad that they've turned around.

So, where can I download the version of V with non-nullable references, no uninitialized memory, no mutation without call-site mutability annotations, that can compile 1M loc/sec, and a functional autofree?

[amedvednikov]

All the features you listed are there, maybe with bugs, which is expected for a 0.2/0.3 version, but they are there.

[tene]

If someone advertises their language as having no Null, no reading from uninitialized memory, and no mutation of immutable values, then I really do expect to be able to rely on those being completely absent. It is dishonest and shameful to say "No null" on the front page of the website when the developers are well aware of ways that their system fails to actually prevent null references.

If I'm buying a sandwich advertised as "no cockroaches", then I think it's appropriate to be pissed off about there being bugs in my sandwich, especially when it's clear that the sandwich shop knows all about the bugs in the sandwich and they just prefer to falsely claim their absence.

I would have no complaints if the developers would just describe these things as ambitious goals they haven't actually accomplished yet, instead of declaring that they've completed work they know they have not completed.

[amedvednikov]

No, you would look at the version of the language, realize it's 0.2 and not production ready yet.

[tene]

> Why are so many people frothing at the chance to disparage this language and it's author?

It's because of all the lying. The author keeps claiming that their language has features that it definitely does not have.

Why do so many people consider "I checked several notable claims, and most of them are false" to be some kind of hateful disparaging attack?

[amedvednikov]

Can you list the false claims here? 1. 2. 3.

Shouldn't be hard, if "most claims" are false according to you.

[tene]

I was referring to both the original post, and Xe's older post that this comment thread is about. They both list claims made by V and describe details how they tested those claims and what their results were.

https://mawfig.github.io/2022/06/18/v-lang-in-2022.html https://xeiaso.net/blog/v-vaporware-2019-06-23

[amedvednikov]

Do you have anything more legit because these posts have nonsense like "setting array length on creation is a terrible idea" (Go with its `make([]int, 5)` must be a terrible scam language as well) and measuring the performance of a debug build, with slow backend, without vlib cached, and with vfmt on.

You can see that V is actually as fast as is claimed on the website:

https://www.youtube.com/watch?v=pvP6wmcl_Sc

Same with other points from the author that publicly claimed that "V has to die".

Like I said, if "most claims are false" on vlang.io, as you claim, it shouldn't be hard to list 3 of them here.

[tene]

I tried to find the source of the "V has to die" comment, and I see that you linked this in a previous claim that Xe said "V should die": https://news.ycombinator.com/item?id=27442724

Actual quote from this comment:

  Personally I think it is something that should be ignored until it dies into obscurity
  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

This is definitely not "has to die". This is "should be ignored" and a prediction that V will die, justified by disappointment at the large gap between their interpretation of V's marketing vs the reality of the current state of V.

[tene]

You've misunderstood my intent. In "I checked several notable claims, and most of them are false", I was trying to say that most of the notable claims that the author decided to check were false.

This is very different from saying most of the statements on the website are false, which would be a completely absurd accusation, as you correctly point out.

The summary section is literally a list of specific claims and the author's evaluation of these specific claims: https://mawfig.github.io/2022/06/18/v-lang-in-2022.html#summ...

My comment was refuting that these posts are not "frothing at the chance to disparage this language and it's author". I stand by my refutation that these posts are appropriate, specific, relevant criticism, and that they cite specific evidence for their specific disagreements with the stated claims.

You are certainly welcome to disagree with this author's claims! That sounds like appropriate, specific, relevant criticism of this author's claim. Would you say that you are "frothing at the chance to disparage this author"? I don't.

I'll admit to some satire in my top comment on this subthread. By saying "It's because of all the lying", I was partly satirically reacting to what I saw as inappropriate hyperbole in "frothing at the mouth to disparage". I broadly agree that the V website is fine, just a little distasteful by my aesthetic.

If you think it's fine for V documentation and advocacy to overstate their case and not mention significant gaps in what they claim the language has, I can't see how you'd call it inappropriate for other people who care about the production-suitability of a language to explicitly document what they believe to be major gaps in the production-readiness of a language claiming to have important safety features people want to rely on.

For some context on my interpretation of these posts, I think about how many times over my career I've had to deal with software that claims to have "just a few bugs" on something important, but somehow the bugs never actually get fixed, and the fully general solution just never appears. These things really are genuinely difficult to design and build a fully general solution for. It takes time and engineering work, as we can see by these people finding a lot of holes as soon as they looked.

As an engineer, I've had a lot of frustration from dealing with bugs and outages and maintenance issues that can be significantly improved by a good language. That's why I care so much about really wanting these things that V claims to have, and also why I care so much about the details of how exactly the claims currently fall short. It's so easy to overpromise, so I'm skeptical of any marketing for a new still-in-development tool that just claims to have solutions, with no big disclaimers about how they're still incomplete.

Regarding your specific example, the problem that's being implied by the "setting array length on creation is a terrible idea" is that every time you're setting an array length in V, any mistake will not be caught by the compiler, and can be an exploitable memory safety violation. Memory safety vulnerabilities really truly have been and continue to be a serious ongoing source of serious computer security problems. V making various memory safety claims like no null and no reading from uninitialized memory, and then that being trivially broken on literally the most obvious possible violation, without even any safety marker to make sure it's obvious that this is a place where you can violate memory safety, means that it's just not a language I want to use.

I agree that these posts are very passionate. I assert that these posts come from a passionate interest in what V aspires to be, and they hold V to a high standard, and find it believable that V can actually hit that high standard, and so they've checked it, and here are the places where you'll need to be extremely careful if you want to really rely on this in a high-reliability setting. It is not frothing at the mouth, and it is not disparagement; it is accurate and precise and specific and appropriate feedback, along with some emotional expression that I find relatable and appropriate.

[amedvednikov]

> every time you're setting an array length in V, any mistake will not be caught by the compiler

What mistake? Does this apply to literally every other language, like Go with its `make([]int, len)`.

> If you think it's fine for V documentation and advocacy to overstate their case and not mention significant gaps in what they claim the language has

Can you link to such examples in V documentation?

[theamk]

Because no other new languages lied that much?

[forgotpwd16]

>Things change.

Based on submitted link, they don't.

[kizer]

It's been around for a few years now.