[mawfig]

Every evaluation in my blog is fully reproducible from the version of V I linked to and I've included all the source code used as well. My post stands on it's own.

Instead of insinuating I'm some kind of competitor or have a personal agenda, I would encourage you to respond to the actual points raised in my post.

[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.

[xena]

Good news: I'm never going to write about V again: https://xeiaso.net/blog/against-toxicity-programming-languag...

[yjftsjthsd-h]

I don't see how that follows? That blog post basically says "don't be toxic about languages". Unless you're using a much broader definition of "toxic" than I'd expect, that doesn't mean you can't write about languages, including fair critiques and even comparisons. I mean, take... "old school" PHP. By all accounts, PHP used to have a lot of sharp edges (in the sense that it was easy to "cut yourself" on it and accidentally do something bad). This was a legitimate, valid problem. It didn't mean that PHP was irredeemably bad, it didn't mean that a dev was A Bad Programmer for writing PHP, but it was true. You can discuss languages, even comparing them to others and pointing out flaws where they exist, without being "toxic" about it.

[xena]

A lot of that post is actually me wanting to be sure that my legacy isn't one of perceived toxicity. When you are in as many minority groups as I am, then you end up becoming an unpaid existential ambassador and you need to be hyper careful to not look like an asshole or do things that could possibly make you look like an asshole because people will assume that being an asshole is a representative sample of those groups. It is not, but logic is not this species' strong suit.

Plus, writing about how V is outright lying in its documentation gets boring because it's too easy. There's no real nuance or the like to it. It's someone overpromising and underdelivering, and then you also get the V cult going after you and sending so much hatemail. It's not worth it.

[yjftsjthsd-h]

Okay, fair; those are good reasons. I don't think those fall under the "toxic" label, but they stand on their own regardless.

(Not meant as an attack. I suspect that I might be splitting hairs too finely here; I can be a little overenthusiastic about terminology. If so, sorry.)

[delian66]

Hate mail? Really? Care to post an example?

[ghusbands]

Hate mail is fairly typical in these circumstances. So is people asking for evidence. The possible next stages are also predictable:

1. They don't post it, and get accused of lying.

2. They post one of the tamer examples, and get accused of overreacting to nothing.

3. They post a median example, and get told that people reacting with vigour is normal and it's not about them.

4. They post a very strong example, hurting some readers and get responses claiming that you clearly can't take threats at face value.

5. They get accused of making it up, anyway.

6. They don't include personal details, so you can't do anything, anyway.

7. They include personal details and get accused of doxxing or making it personal.

There's just no good outcome from your request.

[Ta2000]

Well if you really felt that way I think you'd take any toxic programming articles down. They are etched into your GitHub at this point, so people will still reference them if eager... But at least taking that action of pulling such posts off your website will speak volumes about your character and standing by your words. Otherwise it's just more lip-service; not much different than Alex's lip-service you draw attention to.

[pwdisswordfish9]

Implying here that any post about V is necessarily going to be toxic, because there aren’t any nice things to be said about it?

[maleldil]

Any post criticising V is seen as toxic by their supporters, apparently. You can see many examples of this in this thread.

[theamk]

What do you mean "falsely accusing"? Looks like Xe's blog was correct, V was vaporware back than.

According to this post, it still kinda is.. At least the most interesting parts like unique memory management is 100% vaporware.

[amedvednikov]

It wasn't vaporware back then, it isn't now.

Here's a 1.5 year old demo of V's autofree working:

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

[super_flanker]

Again!! Same video you've been throwing on whoever asks about "autofree", knowing very well that it doesn't work.

I asked this question before and was banned on discord, do you have control flow graph analysis anywhere in V? If not, how do you suppose your autofree engine would work flawlessly?

[amedvednikov]

Also, we now have an operating system Vinix, which uses autofree. Does that work as a proof for you or is that also not enough?

[super_flanker]

And that's why vinix [1] is full of manual free calls? That tells how good autofree is, isn't it? Can you compile v compiler with autofree? Last time I checked, you can't.

[1] https://github.com/vlang/vinix/search?q=free&type=code

[amedvednikov]

Nobody bans for questions.

And the video I posted proves that it works. Keeping saying "it doesn't work" is ridiculous.

[vlang1dot0]

Your demo includes code that uses manual memory management because of autofree bugs.

https://github.com/vlang/ved/blob/9b85e6291c9fe9135db1e300de...

[super_flanker]

And how did you conclude that author is "falsely" making any accusation? Is it similar to your last claim (1) that V doesn't have "null" (which has been debunked)?

(1): https://news.ycombinator.com/item?id=31084446

[delian66]

> 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?

[delian66]

> 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.

[jacknews]

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.

[joshuamorton]

For what its worth, the zig site has what is functionally this blog post for its own language: https://ziglang.org/learn/overview/. There's maybe a few spots where I think they could be clearer about some tradeoffs, but overall its very explicit about what the language can and cannot do, and if I were using this post's style, we'd end up with lots of green checks and 1-2 yellow squares, but nothing red.

Which really is the issue here: v makes a big talk but doesn't do what it says on the tin, while other languages, generally speaking, do. There's a difference between goals and features, and Zig distinguishes those well.

[mawfig]

Sorry, not yet. New to blogging and this took quite a long time to complete to a level I was satisfied with so it will probably be a while before I complete another one.

[_dain_]

It is a very good first blogpost! I look forward to reading more in this genre. I would particularly like to see similar reviews of the Nim, Odin, Zig, and Janet languages.

[delian66]

> 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

[ptx]

Hmm. So the claim article was examining here was "no undefined values", and you point out that the value is actually initialized to 0 and is thus not undefined.

However, the vlang.io page also makes the separate claim (as mentioned in the article) of "no null". But you seem to be saying that the bug in this case was actually a null pointer?

[delian66]

Yes, it is a null pointer, produced by the initialization to 0, as you noticed.

That is the current state - V wants to prevent setting pointers to arbitrary values, including 0, outside of unsafe code, but not all cases are checked yet, and you can get one. For example, you can also still cast numbers to pointers without unsafe{}:

    x := voidptr(0)
    println(x)

... and that will compile without an error, and produce `0x0`.

You can also search the issues, and find other examples of code, that ultimately produced null pointers.

[Tozen]

> ...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...

You would think that someone taking that long to do an evaluation of claims would reach out to the V developers in some way. Like via bug report, e-mail, discord, or discussion... If a person doesn't want to give the appearance of doing an attack or "hit piece", you would think they would at least create some plausible deniability for themselves, by taking in account the perspective or response of the language developers.

I'm glad you are taking the time to do counter points and add issues on GitHub (https://github.com/vlang/v/issues), as this situation can be turned to being helpful for V. Whatever is in the evaluation that has some validity, can then be corrected or V developers can point how the evaluation was in error or mistaken.

[delian66]

> 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