> Variables aren’t immutable in any significant way because you can trivially turn an immutable reference into a mutable one.
To be fair, they didn't claim that the values were immutable, only the variables. Isn't the example in the article basically the same as Java's final variables, i.e. immutable references to mutable values?
> No global variables [...] Evaluation: V does not prevent you from creating and mutating globally shared state in any meaningful way.
Although I agree with the evaluation, the claim of "no global variables" might still hold, assuming it refers to mutable global variables. The global constant holds an immutable reference to a mutable value, just like how in Java a singleton object (or a class with mutable static fields) can be used to simulate global variables.
If I understand the example code correctly, it's modifying a heap-allocated struct that's pointed to by a global const. So the global const contains an address which is not modified, but the thing at that address is modified. Right?
What does the intended behaviour (after the fix) look like? Are mutable fields in structs disallowed if the struct is pointed to by a const?
The check to fix the issue is indeed 8 lines long, and not one, the bulk of the patch is updating the places where the compiler was relying on this behaving with unsafe blocks and the rest is adding tests.
The patch adds two consecutives if statements to forbid the behaviour and could surely be written as a 2 lines or one line patch.
Not checked the timeline. It it is a bit irrelevant, I am not here to score point for either author.
I have a test project of around 5k lines of V, taken from a prototype in Go. Using V has been much more pleasant than Go or Zig, but I like zig comptime features. V is a nice language syntactically. Go has better tooling and is mature. I also rewrote the same code in Zig which I would trust today for production. Finally, I really like zig (and Jai) build system, and Jai very logical design and meta-programming features (no, I am not in the beta).
Hopefully from that statement, everyone can see that I am rooting for the adversarial team and therefore you can all discard my commment as biased
While I would agree with many of the comments regarding how the V site is not clear enough on the level of maturity for each of the attempted goal, and very quick to celebrate work in progress, I feel that balanced comments on this thread are mixed with some which would probably trigger me should I have invested lots of energy in trying to make V successful.
Thanksfully I only contributed one AST optimisation as curious bystander, so I can read this thread as most will do: noting how people are capable of listening without hearing.
All this discussion did was to radicalise even more both parties. I would hope V developers will take the time to review what was posted in this thread, when the minds have cooled down, and will try to understand the cultural differences which can exist between people when it comes to reviewing public claims made.
I attempted once to bring this exact topic in the discord channel but reading the room there was zero appetite for change, so I stopped as I felt I would be alienating people if I continued. I self censored to not damage my standing on discord ~ so why am I ruining it with this post: to say that asking people to meet you on your ground to discuss problems is not going to work (general statement)
People with nuanced opinion will often shut up when the discussion hits up.
When points are not understood, the tension rises and the quality of argumentation reduces very quickly.
My view, and feel free to disagree, is that the V community has been burned out and does not welcome criticism anymore, trust in other developers is broken, from here no constructive discussion can happen anymore and for some participants of this thread the same can be said the other way round.
This is absurd. It is now a V team's job to continue with, not the other way around. In fact, this kind of outsider perspective is very valuable to growing language communities because it's plain impossible to attain by themselves. As long as the article is not written in a derogatory tone (and I believe not) the OP's job is done by now.
To be fair, they didn't claim that the values were immutable, only the variables. Isn't the example in the article basically the same as Java's final variables, i.e. immutable references to mutable values?
> No global variables [...] Evaluation: V does not prevent you from creating and mutating globally shared state in any meaningful way.
Although I agree with the evaluation, the claim of "no global variables" might still hold, assuming it refers to mutable global variables. The global constant holds an immutable reference to a mutable value, just like how in Java a singleton object (or a class with mutable static fields) can be used to simulate global variables.