As someone who works full time on one relatively young language, has created a couple more, and knows people working on many others, this is 100% wrong in my personal experience.
Most young language teams work very hard to communicate accurately and to set appropriate expectations because they know that user trust is a hard requirement for adoption.
V is the outlier here.
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.
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.
(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.)
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.
Especially after writing "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."
=> xena does acknowledge, that most people will assume that the whole V community is hateful, and even then, used terms like "V cult" and "hatemail".
Accusing an entire community of people of hate, for the actions of a single one, is not nice at all, especially, when it is done without evidence, with just vague descriptions.
Have you considered, that in all these, it may be the V developers, that are in the minority???
According to this post, it still kinda is.. At least the most interesting parts like unique memory management is 100% vaporware.
Here's a 1.5 year old demo of V's autofree working:
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?
The resulting executable however does segfault - try it with:
./v -autofree -o x cmd/v
./x version
Doesn't give lot of confidence that it works, does it?
> You seem to talk a lot about things, that you are not well informed about.
Unlucky for you, it's not discord, you can't ban me here. So freaking deal with it.
Letting them speak and reveal how vile they are is better in my experience.
And the video I posted proves that it works. Keeping saying "it doesn't work" is ridiculous.
https://github.com/vlang/ved/blob/9b85e6291c9fe9135db1e300de...
fn main() {
x := []&int { len: 10, cap: 0 }
println(x[4])
}
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?
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.
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.
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)
}
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)
}
Edit: I've filed this in https://github.com/vlang/v/issues/14786
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?
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)
You can also search the issues, and find other examples of code, that ultimately produced null pointers.
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.
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)
}
Edit: filed under https://github.com/vlang/v/issues/14785
Xe's post struck me as accurate at the time, and having that context to compare with makes V look a little better now, because it at least establishes that progress is being made towards those claims.
I don't know where you're getting the idea that this is based on some kind of sinister "personal agenda" other than "this thing sounds interesting, I investigated it, it seems less cool now", which is a pretty defensible position for someone to reach.
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".
fn main() {
x := 1
y := fn (x int) {
println(x)
}
y(x)
y(2)
}
... y := fn [x] (x int) { println(x) } ...
> Well, that seems like it should be disallowed. It makes sense that x can be captured but to then shadow the argument with the same name without error or warning doesn’t seem inline with the rest of V’s behavior.
I see what you mean now, yes, that does seem like another good issue candidate. Filed in https://github.com/vlang/v/issues/14787
update: I've responded to the wrong comment, it should have been under https://news.ycombinator.com/item?id=31794565