Comment by Tozen

That's interesting or telling, because if you read what I posted carefully, I was not insinuating anything about your evaluation. Instead, the point was being made that you probably don't want to be associated with an old evaluation from 3 years ago, which is falsely accusing V of being vaporware, and where the author and the developer of V clearly have beefs with each other.

> Bounds checking

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

Again, a bug caused by the auto generated string conversion method for arrays of pointers, that does not check for nil pointers. Once https://github.com/vlang/v/issues/14786 is fixed, that will work too.

It has nothing to do with bounds checking, as you can see if you just use `x := []int { len: 10, cap: 0 }` instead.

> Allowing the user to control the len property is a really bad idea.

Can you clarify what you mean by that?

> No undefined behavior

You do have a point here, and we should update the site and the documentation. The current state of V, is that most of the undefined behaviors of C for numbers are also undefined in V too.

Are there any other language evaluations in your blog, or a plan for any, etc? I'd like to read other reviews, but I only see this one post.

> I would encourage you to respond to the actual points raised in my post.

ok, here is the first thing that I noticed, reading your blog post/review.

> No undefined values ... > C allows you to use an uninitialized variable which can result in Undefined Behavior. I’ll assume that’s what this means. ... > Typically, uninitialized values come from a memory allocation that hasn’t been written to. ... > Let’s see if we can get the V compiler to allocate memory for us without writing to it:

    fn main() {
        a := []&int { len: 1 }
        println(a)
    }

That program segfaulted in the automatically generated string conversion method for the println() call (you created a 1 element array of pointers, and since each of the elements is initialized to 0, you got a 0 pointer, then println tried to show that, but the automatically generated string conversion method did not check for 0 pointers -> the segfault).

TLDR: the autogenerated string conversion method has a bug, that will be fixed soon.

Ironically, the cause is the opposite of what you intended to show - the memory for the new array was initialized to 0.

I would have appreciated a bug report in https://github.com/vlang/v/issues , that could be properly tracked till resolution, but apparently people these days have an entire month to dedicate on writing a "review" with a "Rules of engagement" section, but do not have 5 minutes to submit a github issue ¯\_(ツ)_/¯ ...

btw, if you instead of the above did:

    fn main() {
        a := []int { len: 1 }
        println(a)
    }

the program (printing `[0]`) will have worked correctly.

Edit: I've filed this in https://github.com/vlang/v/issues/14786

> No null > The V docs indicate V has references and “in general, V’s references are similar to Go pointers and C++ references”.

The V documentation also has this: https://github.com/vlang/v/blob/master/doc/docs.md#structs-w...

> Structs with references require explicitly setting the initial value to a reference value unless the struct already defines its own initial value.

> Zero-value references, or nil pointers, will NOT be supported in the future, for now data structures such as Linked Lists or Binary Trees that rely on reference fields that can use the value 0, understanding that it is unsafe, and that it can cause a panic.

    struct Node {
        val   int
        left  &Node
        right &Node
    }

    fn main() {
        n := Node { 123, 0, 0 }
        println(n.left)
    }

This is also another example of a program, that would have been perfect as a bug/issue report, so thanks for that I guess.

Edit: filed under https://github.com/vlang/v/issues/14785

It's not accurate. For example, 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".