V Language Review

1) It is the author of the blog, that also created this thread on HN.

It shows the intent to disseminate his negative review as far and as wide as possible. And to do so outside of the V community.

2) If the OP was as eager to use the language as you believe, and was disappointed, he could have brought those issues to the V GitHub.

Who is going to the fix those issues that the OP (or anyone else) believes is a problem? It is going to be the V developers. So if the OP wanted those things that he believes are a problem fixed, that's who he has to bring them to.

Just outright mounting a smear campaign or crapping on the V language wherever possible, will never get any of the issues fixed on its own. Instead, as has been shown (by other places linking to the OP's blog), it will only invite more smearing and attacks.

3) The OP starts the review by linking to a number of very contentious posts from competitors and detractors of V, to include those that smear the author and language.

To do such will clearly set off drama, and makes the negative review part of the past drama. It now links them all together. This is not the intent of a person that wishes to "come in peace" or be helpful, this comes across as one having the purpose to set off a blazing fire of more drama.

4) The OP has shown no interest in working with V developers, and that's prior to publishing the review and spreading links to it.

The OP has demonstrated no intent to modify his review for correctness, fairness, or language version. This then puts "at this time", in the context that the review can stay as it is, indefinitely, regardless.

Add to that, the OP is purposely using a throwaway account on GitHub. He simply can disappear, without ever making changes to the review. We all know who the creator of V is and a number of its developers, they are all held accountable, as you are trying to do now. The OP on the other hand, has no accountability nor any "skin in the game".

5) The OP's review is without the necessary context and highly opinionated.

Without feedback or the opinions of the V developers, this is a one-sided negative review full of many debatable points about the claims made. The many gray areas can only gain context, when compared with what the V developers are showing their intentions are and in their responses to what are believed to be issues.

For more clarity at what I'm getting at, I'm not saying there are no issues with various claims or marketing, but rather what is claimed can be a matter of opinion. Because a person or reviewer disagrees with a claim, does not make them or their review 100% right either. Readers are left with a situation as to what percentage of either side is correct.

And no matter at what percentage either side is correct, who is going to fix any discovered issues? Right, it will be the V developers. So if the point was not to do any harm and help create production-quality V, then that's who needed/needs to be informed and worked with. If the OP is not interested in working with V developers, and rather produce and disseminate drama or facilitate smearing, then that's a reflection of their real intent.

It also appears you prefer to see negative opinions or commentary about V, and are getting overly upset or obsessed with those you believe are defending the language in any way. I'm simply responding to a thread on HN (as you are), that was not made by me, and calling out things that I see or believe to be unfair.

The V community has open discussions that anybody can join and make comments on. You can also freely create an appropriate discussion at the V GitHub. This is something that it appears you don't know about (and what the OP purposely avoided), as you're "talking in circles" with me and giving your opinions about "whining". The link to it is below.

What don't you like about V / what would you like to be changed? (https://github.com/vlang/v/discussions/7610)

You can also interact with the V community on discord as well. (https://discord.com/invite/vlang)

You are free to go there and submit your many opinions about what the members of the V community should or should not be doing. Even better, as you seem to describe yourself as very technical and knowledgeable. You would be commenting directly to them. In general, they are very receptive, open, and friendly.

Unfortunately for you, the V community is small and you tend to come here on HN, so you are who we see as an ambassador for V. You are a defacto representative of the community even if you do t see yourself as such. The way you comport yourself here reflects on the entire community. Fair? No. But if you read the comments here and in other threads, you’re definitely leaving an impression as to the entire V community.

> You are free to go there and submit your many opinions about what the members of the V community should or should not be doing.

I don’t have many opinions, I have one opinion and I have given it to you. Stop arguing on the internet and just make your claims bulletproof.

First of all, most of those erorors are about stack overflows in the compiler not the compiled program. And secondly, stack overflow isn't a memory safety issue like, say use-after-free, uninitialized variables, data races, etc. If you allow recursive function calls, you can't really prevent stack overflows.

> alloca() is dangerous for a reason

Rust doesn't have an equivalent of alloca.

> unsafe vec, really??

I'm not sure what you are referring to here.

> mutexes in threads, really??

What does this have to do with memory safety? The only language with threads I know of that doesn't have mutexes is Erlang. And rust Mutexes are better than mutexes in most other languages because you can't access the data protected by the mutex at all, unless you have a lock. And the lock is automatically freed when it goes out of scope.

> concurrent blocking IO in this decade??

Again, what does this have to do with memory safety? And for many applications blocking IO is fine. You don't always need the performance of async I/O which adds complexity. And if you do need async i/o, rust has options there too (just not in the standard library).

> also read their docs about their unsafeties, and concurrency deficiencies.

The Rust Programming Language book has one section of one chapter on "unsafety", and that is specifically on using the `unsafe` escape hatch. Yes, there is a separate book about how to write a `unsafe` code that maintains rust's safety garantees. but that is limited to `unsafe` blocks, which in many cases you can just avoid using. As compared to c or c++, where the entire language is full of potential safety problems.

> compare that to the docs of real safe languages. you won't find such chapters, because safe languages are safe, not just almost-safe.

What "real safe languages" would those be? Can they be used in all the same domains as rust?