Comment by tene
3 years ago
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
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.
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:
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.
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.
> 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?
9 replies →