Comment by amedvednikov

Tene’s post is the most reasonable and valuable feedback you’ve gotten in this entire thread. Your reply should have been one of thanks and appreciation, not confrontational and argumentative.

Honestly, from the outside reading this thread you probably shouldn’t have come here in the first place. I get you want to defend your language, but there’s a fine line between defending your creation and being argumentative with people who don’t actually mean you harm, and who aren’t trying to take you down.

Your posts here are very defensive, and your tone is argumentative to the point when someone gave you accurate info about using tcc, you refused to believe it and argued about it for several posts. Just listen instead of arguing.

Look, I get you want to defend your creation. But my advice from one lang dev to another is stop posting on hn, and do what you’re good at by working on making your claims about your language bulletproof instead. People have been giving you this advice since you started V years ago but you haven’t taken it. Let V speak for itself. Stop arguing with people on the internet.

If you accidentally make a mistake when setting an array length in V, your program can read from uninitialized memory, as discussed in this article. This program, quoted from the article we're discussing, is accepted by the V compiler, and attempts to read from uninitialized memory:

  fn main() {
      x := []&int { len: 10, cap: 0 }
      println(x[4])
  }

In this case, the program crashes with a segfault, because the program is simple enough that the memory after the heap allocation was not mapped. The point of these examples is to be minimal tests cases clearly demonstrating that the language does the wrong thing. This is a general category of bug that permits memory unsafety, and in more-complex real-world programs, this could be exploitable. In general, any time you see a segfault, it's a strong signal that there could be an exploitable memory safety vulnerability.

This does not apply to every other language. The specific problem is that V lets you directly adjust the array length without doing anything to ensure that the array capacity is at least as large as the newly-specified length. Go's `make([]int, len)` ensures that the produced array's capacity is at least len. Go does have some memory safety issues (data races), but this specific issue is not a problem that Go has.

> Can you link to such examples in V documentation?

I agree with the article we're discussing that the "Safety" section prominently displayed on https://vlang.io/ immediately after the header is significantly overstating its case. Here is the list, each item of which is discussed specifically in this blog post, with minimal source code you can run to check their work:

  - No null
  - No undefined values
  - No undefined behavior
  - No variable shadowing
  - Bounds checking
  - Immutable variables by default
  - Immutable structs by default
  - Pure functions by default  --  This has since been removed from the list, but was present when the author started this review: https://web.archive.org/web/20220305171852/https://vlang.io/
  - Option/Result and mandatory error checks
  - Sum types
  - Generics
  - Immutable function args by default, mutable args have to be marked on call
  - No global variables

"No Null" is misleading because the compiler does not actually prevent null references.

"No Undefined Values" is misleading because the compiler does not actually prevent reading uninitialized memory.

"No Undefined Behaviour" is misleading because the C code generated by the V compiler does include behaviour that is undefined according to the C language standard.

"No Variable Shadowing" is correct; the V compiler rejects programs that would shadow variables. I don't actually see this as a benefit, as I use shadowing all the time, but it's an accurate statement about the current V compiler.

"Bounds Checking" is mostly correct, but slightly misleading because the bounds are exposed to your code, and it's up to you to make sure you manipulate them correctly.

"Immutable variables by default" and the other immutability points are misleading because functions that accept immutable arguments can still mutate those arguments.

Compared to languages with real mutability tracking, this is far less helpful in designing misuse-resistant APIs, and avoiding hard-to-diagnose bugs caused by unexpected mutation.

"Pure functions by default" is misleading because the V developer has chosen to use their own special nonstandard meaning for "Pure" that includes IO, and because of the mutability tracking not actually being effective.

"Option/Result and mandatory error checks" is correct and fine; I have no problems with this.

"Sum Types" is kind of okay, but they look kinda janky and limited. This article's example of sum types not being able to hold references is pretty concerning.

"Generics" is kind of okay, but it similarly is a very early very limited implementation.

"No global variables" is just false. V has "constants", which are just "immutable" global variables, and as we've already seen, V's "immutability" is very mutable.

This blog post also addresses the "Performance", "Fast Compilation", and "Innovative memory management" sections of https://vlang.io/.

Broadly speaking, https://vlang.io/ seems to very clearly present the language as one that is suitable for use today. I don't see anything on the main page of https://vlang.io/ that says anything even vaguely similar to "This is a very early language, these features are aspirational but still very much under serious development, and there are many known gaps we have not built solutions to yet".

By my personal standards of epistemic integrity, the front page of https://vlang.io/ is misleading and dishonest. I recognize that many people consider this kind of "marketing" to be acceptable, and I'm fine with letting people do that as long as they're not complaining about people actually checking their claims.

I really love the ambition of V, and I would be very happy to use it if it were actually production-ready. I have sometimes used early-development tools in production when I've had a good understanding of what the actual gaps and deficiencies and defects in the under-development software are. V's aggressive marketing that goes out of its way to avoid discussing its weaknesses means that I can't actually rely on what I read from them about the language's suitability for high-reliability use. When someone shows me that they're happy and willing and eager to mislead people about the flaws in something, then I believe them!

To me, these posts seem to be written from a perspective of eagerly wanting to use the language that seems to be advertised, and being disappointed at the big gap between the marketing and reality. The two big messages I see in these blog posts are "Here are problems I found that make me concerned about using V" and also, separately, "V appears to be marketed as if it were a polished product suitable for production use, and that's concerning, given the problems found."

Notice the end of this post: "At this time, I would not recommend spending time on V. I would also be very cautious when taking claims made by the authors at face value."

This author explicitly says "At this time" they don't think V is suitable to rely on or will be soon, and they encourage skepticism when interpreting claims made by the author. This does not read at all like someone hateful to me. This very much reads like someone who really wants a production-quality V language to use, and hopes that the project someday succeeds.