Thanks for linking Xe's blog here! It's a few years old and I've seen a lot of comments on HN that suggest V has improved significantly since 2019 so I thought it might be worth looking into for myself and writing down a review of what I found.
> The three securities they guarantee and cannot hold.
Could you elaborate?
> null pointer segfaults
They are not segfaults and are not related to memory safety. Segfault stands for "segmentation fault", not "runtime exception". https://en.m.wikipedia.org/wiki/Segmentation_fault
If you know of a case where rust code violates memory safety without the use of an unsafe block, file a bug and it will probably be fixed within a release or two.
"Fearless concurrency" is more subjective, but rust code (again with the caveat that there isn't unsafe code, or unsafe cose upholds all unvariants) dows eliminate certain classes of concurrency bugs. Although, dreadlocks are definitely possible, and certain kinds of race conditions could potentially exist. But I don't know of any claims that concurrency bugs are impossible in rust.
do you your self a favor and search their ticket system for stack overflow.
the list gets longer, not smaller.
and looking at their compiler it's clear why. stack-allocation of vars is fine and dandy, but comparable to vlang's famous unbounded autofree system.
alloca() is dangerous for a reason.
unsafe vec, really?? mutexes in threads, really?? concurrent blocking IO in this decade??
also read their docs about their unsafeties, and concurrency deficiencies.
compare that to the docs of real safe languages. you won't find such chapters, because safe languages are safe, not just almost-safe.
> do you your self a favor and search their ticket system for stack overflow
First of all, most of those erorors are about stack overflows in the compiler not the compiled program. And secondly, stack overflow isn't a memory safety issue like, say use-after-free, uninitialized variables, data races, etc. If you allow recursive function calls, you can't really prevent stack overflows.
> alloca() is dangerous for a reason
Rust doesn't have an equivalent of alloca.
> unsafe vec, really??
I'm not sure what you are referring to here.
> mutexes in threads, really??
What does this have to do with memory safety? The only language with threads I know of that doesn't have mutexes is Erlang. And rust Mutexes are better than mutexes in most other languages because you can't access the data protected by the mutex at all, unless you have a lock. And the lock is automatically freed when it goes out of scope.
> concurrent blocking IO in this decade??
Again, what does this have to do with memory safety? And for many applications blocking IO is fine. You don't always need the performance of async I/O which adds complexity. And if you do need async i/o, rust has options there too (just not in the standard library).
> also read their docs about their unsafeties, and concurrency deficiencies.
The Rust Programming Language book has one section of one chapter on "unsafety", and that is specifically on using the `unsafe` escape hatch. Yes, there is a separate book about how to write a `unsafe` code that maintains rust's safety garantees. but that is limited to `unsafe` blocks, which in many cases you can just avoid using. As compared to c or c++, where the entire language is full of potential safety problems.
> compare that to the docs of real safe languages. you won't find such chapters, because safe languages are safe, not just almost-safe.
What "real safe languages" would those be? Can they be used in all the same domains as rust?
Someone pointed out an obvious one: You can open the file "/dev/mem" or equivalent on many Unix systems and break things horribly, and rust can't tell that you're doing it or stop you. Someone used this to write an unsafe-free transmute, which is probably at least two different war crimes.
How would anyone go about preventing you from doing that?
Keep in mind /dev/mem is just a convention, I can just mknod it at any place in the filesystem I want. I can even put a FUSE overlay on it that would turn it into a regular file instead of a device node, so you wouldn't have any possible way of telling what you're about to do.
There is no "defense" against /dev/mem, that's just something you don't do as a sane programmer.
But you can get away with that in most languages that are generally considered memory safe, so a sane interpretation of the term "memory safety" wouldn't care about that.
> Remember, the competition between various younger languages has become a bit fierce and dirty.
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.
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.
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.
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.
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.
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.)
Yes, there is a good possible outcome - they post it, we see it, and then, if possible, we take corrective actions.
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???
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.
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?
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.
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)?
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.
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.
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.
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.
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.
> 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.
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?
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.
> ...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.
> 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.
You say it "comes off as part of an effort ... to mount another attack". Maybe it does to you, but I don't know why. I've never heard of this "fierce and dirty" competition between young languages. I've never seen anything even a bit like that. I've only seen fierce fighting between advocates of large well-established languages.
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 are not doing yourself any favor by harassing people, if anything it makes you look like a fan-boy. Do yourself a favor, read the article then present a constructive criticism, if any.
> I see though that V supports closures. What are the rules for shadowing variables in closures?
fn main() {
x := 1
y := fn (x int) {
println(x)
}
y(x)
y(2)
}
I am not sure I follow - the `x` parameter for the anonymous function, is entirely different, than the `x` in the main function. For me, there is no way for it to be confused with the `x` inside main.
...
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.
Is 'Xe' the name or the preferred pronoun of the person in question? Is this like Latinx but race neutral? Gender identity accommodations seem to get more complex and confusing by the month...
[correction] on their GitHub page I see: Please call me (order of preference): Xe/xer, They/them or She/her please.
[edit] obscure to have your pronoun also be your name (or maybe your title?). Or maybe it is all just satire, given: "I am an ordained minister with the Church of the Latter-day Dude. This allows me to officiate religious ceremonies in at least the United States." - https://dudeism.com
To be honest having a person's name be the same as their nominative case pronoun is kind of cool from a whole different perspective than you normally get to see. By doing this experiment I get to see how bad of an idea it is to do that. So far the xe/xer pronouns don't seem to stick as well, but it looks cool so I'm gonna keep up the experiment.
> To be honest having a person's name be the same as their nominative case pronoun is kind of cool
The whole point of a person's name is to sufficiently differentiate them from the other persons. Using pronoun as name (or vice versa) just totally negates this goal.
To be fair, the name came first. Then I found out it conflicted with people's pronouns and I sat on the idea for a while. Now I'm throwing science at the wall to see what sticks, and this is a fairly amusing experiment. So I'm gonna keep it going.
Who gives. Just use 'they' or 'them', or whatever. It is a universal catch all, gender neutral, i18n inclusivity conformant, ISO 69420 compliant, race neutral, etc.
At this point, all of it is basically designed to further confuse and only create a very monthly chaotic outcome for everyone.
Xe has been in use as a gender neutral pronoun for nearly thirty years. I, a startlingly ordinary person, was familiar with it as early as the late 90s.
Why in the world do competitors of this programming language insist on dragging out evaluations from 3 years ago, which state that V is vaporware and before the language was even released? This is 2022, not 2019, and we are talking a hundred releases later (https://github.com/vlang/v/releases).
At least stick to the current evaluation (or attack), which is more relevant, and make points from there. But, keep in mind that these attacks are on a young language that isn't 1.0 yet, so even with this we are talking about a moving target. The language is still evolving.
I don't have a horse in this race, but when a language makes present-tense claims about its features I assume that they're already functioning features.
People are poking holes in V because its claims are unfounded, not because they've decided they're in competition with the language. A simple "work in progress" sign on the features in question would draw a lot of fire away from the language and its creator.
After I criticized the project for collecting donations on deceitful information, the author put purple "WIP" labels next to a bunch of stuff [1] which led me to make this statement [2]. However, it looks like medvednikov has since removed the "WIP" labels.
From his perspective, he's been Working on them ;)
Credit to both you and him for the passion and effort put in. I just think his excitement bubbles over into an unfortunate way of communicating (lets call it cute)
Communication is something you're excellent at, in a large part due to your truthfulness
I just think vlang is living in and expressing dreams and visions. Which I agree has problems, but creating a language is an aspirational endeavour
You know something, some of us are HAPPY donators for 3 years now and we're fine and feel that our investment is worthy. I really think you are terribly misrepresenting the situation.
Your keep calling people "competitors." I don't think you're using the word right. Perhaps "detractors" is what you mean, but "reviewers" is more neutral. Xe and mawfig don't appear to be offering their own languages to compete with V. At one point, Andy Kelly (a "competitor") criticized the author's behavior, but he's also gone silent on the topic of V because of the vitriol he encountered.
One reason that people highlight older criticism is because it's useful to examine past behavior, past promises, and contrast them to current behavior and current promises. If V is going to improve its reputation, it's going to do it by (a) making good on the promises it can, (b) coming clean on the promises it can't, and (c) offer a clear win for some distinguishing featureset. Badgering people to shut up about the past isn't on that list.
> Andy Kelly (a "competitor") criticized the author's behavior, but he's also gone silent on the topic of V because of the vitriol he encountered
AFAIK your stated reason for the silence is not accurate. Andy’s criticisms were always based on V making claims that no one could evaluate because it was closed source/unreleased (and then used those claims to solicit money from people). Once V was made open source, those criticisms no longer applied, as things like TFA could be written.
No, he also had criticisms like "the V compiler depends on an OpenGL context creation library, so the claim that it has zero dependencies is false, the author is a scammer".
Financial supporter of V here. I don't feel scammed or misled at all. So keep speaking for yourself with the imaginary money you did not donate nor lose.
Nah that article is old as hell - time for new information. Things change.
I also despise how many people want to shit on this new language before it even takes off. Why are so many people frothing at the chance to disparage this language and it's author? Never seen something like this.
Mostly because the author completely scammed the shit out of people by promising a ton of things to garner patreon support before open sourcing what was essentially a hobby project at the time. I haven't followed it very closely, but last I heard about it was not delivering on the "autofree" feature.
I dont really care about the language. I've tried it a couple times and it's nothing special (to me) so I moved on, but I definitely understand where the hate comes from. The author essentially lied for at least months about his project to get financial support.
Quick edit: to actually add to the discussion, I think the weirdest thing about V is the odd support it does get. Most projects, especially compilers, with as much controversy as V would never get any support. I'm very curious what its proponents are using it for and why they choose V over pretty much any other language.
Oh, that's really cool to hear! I'm glad that they've turned around.
So, where can I download the version of V with non-nullable references, no uninitialized memory, no mutation without call-site mutability annotations, that can compile 1M loc/sec, and a functional autofree?
If someone advertises their language as having no Null, no reading from uninitialized memory, and no mutation of immutable values, then I really do expect to be able to rely on those being completely absent. It is dishonest and shameful to say "No null" on the front page of the website when the developers are well aware of ways that their system fails to actually prevent null references.
If I'm buying a sandwich advertised as "no cockroaches", then I think it's appropriate to be pissed off about there being bugs in my sandwich, especially when it's clear that the sandwich shop knows all about the bugs in the sandwich and they just prefer to falsely claim their absence.
I would have no complaints if the developers would just describe these things as ambitious goals they haven't actually accomplished yet, instead of declaring that they've completed work they know they have not completed.
No, I really wouldn't, and don't. This is the kind of thing that reads to me as honest for a new in-development language: https://github.com/cruxlang/crux#status
Features are explicitly listed as working, partially done, and not yet implemented. You're really truly allowed to say "This doesn't work yet, but we're working on...", and it is legitimate to criticize people for choosing to lie instead.
I was referring to both the original post, and Xe's older post that this comment thread is about. They both list claims made by V and describe details how they tested those claims and what their results were.
Do you have anything more legit because these posts have nonsense like "setting array length on creation is a terrible idea" (Go with its `make([]int, 5)` must be a terrible scam language as well) and 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:
I tried to find the source of the "V has to die" comment, and I see that you linked this in a previous claim that Xe said "V should die": https://news.ycombinator.com/item?id=27442724
Actual quote from this comment:
Personally I think it is something that should be ignored until it dies into obscurity
There are good ideas there, but if you sell someone the moon and give them a block of cheese that's kind of a scam
This is definitely not "has to die". This is "should be ignored" and a prediction that V will die, justified by disappointment at the large gap between their interpretation of V's marketing vs the reality of the current state of V.
You've misunderstood my intent. In "I checked several notable claims, and most of them are false", I was trying to say that most of the notable claims that the author decided to check were false.
This is very different from saying most of the statements on the website are false, which would be a completely absurd accusation, as you correctly point out.
My comment was refuting that these posts are not "frothing at the chance to disparage this language and it's author". I stand by my refutation that these posts are appropriate, specific, relevant criticism, and that they cite specific evidence for their specific disagreements with the stated claims.
You are certainly welcome to disagree with this author's claims! That sounds like appropriate, specific, relevant criticism of this author's claim. Would you say that you are "frothing at the chance to disparage this author"? I don't.
I'll admit to some satire in my top comment on this subthread. By saying "It's because of all the lying", I was partly satirically reacting to what I saw as inappropriate hyperbole in "frothing at the mouth to disparage". I broadly agree that the V website is fine, just a little distasteful by my aesthetic.
If you think it's fine for V documentation and advocacy to overstate their case and not mention significant gaps in what they claim the language has, I can't see how you'd call it inappropriate for other people who care about the production-suitability of a language to explicitly document what they believe to be major gaps in the production-readiness of a language claiming to have important safety features people want to rely on.
For some context on my interpretation of these posts, I think about how many times over my career I've had to deal with software that claims to have "just a few bugs" on something important, but somehow the bugs never actually get fixed, and the fully general solution just never appears. These things really are genuinely difficult to design and build a fully general solution for. It takes time and engineering work, as we can see by these people finding a lot of holes as soon as they looked.
As an engineer, I've had a lot of frustration from dealing with bugs and outages and maintenance issues that can be significantly improved by a good language. That's why I care so much about really wanting these things that V claims to have, and also why I care so much about the details of how exactly the claims currently fall short. It's so easy to overpromise, so I'm skeptical of any marketing for a new still-in-development tool that just claims to have solutions, with no big disclaimers about how they're still incomplete.
Regarding your specific example, the problem that's being implied by the "setting array length on creation is a terrible idea" is that every time you're setting an array length in V, any mistake will not be caught by the compiler, and can be an exploitable memory safety violation. Memory safety vulnerabilities really truly have been and continue to be a serious ongoing source of serious computer security problems. V making various memory safety claims like no null and no reading from uninitialized memory, and then that being trivially broken on literally the most obvious possible violation, without even any safety marker to make sure it's obvious that this is a place where you can violate memory safety, means that it's just not a language I want to use.
I agree that these posts are very passionate. I assert that these posts come from a passionate interest in what V aspires to be, and they hold V to a high standard, and find it believable that V can actually hit that high standard, and so they've checked it, and here are the places where you'll need to be extremely careful if you want to really rely on this in a high-reliability setting. It is not frothing at the mouth, and it is not disparagement; it is accurate and precise and specific and appropriate feedback, along with some emotional expression that I find relatable and appropriate.
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:
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.
> 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.
I strongly disagree with you about the intent of the OP. I'm not saying you don't have other valid points, but want to focus on this particular aspect of your post. I think it's important to not assign benevolence, to what is possible malevolence. Why?
1) It is the author of the blog, that also created this thread on HN.
It shows the intent to disseminate his negative review as far and as wide as possible. And to do so outside of the V community.
2) If the OP was as eager to use the language as you believe, and was disappointed, he could have brought those issues to the V GitHub.
Who is going to the fix those issues that the OP (or anyone else) believes is a problem? It is going to be the V developers. So if the OP wanted those things that he believes are a problem fixed, that's who he has to bring them to.
Just outright mounting a smear campaign or crapping on the V language wherever possible, will never get any of the issues fixed on its own. Instead, as has been shown (by other places linking to the OP's blog), it will only invite more smearing and attacks.
3) The OP starts the review by linking to a number of very contentious posts from competitors and detractors of V, to include those that smear the author and language.
To do such will clearly set off drama, and makes the negative review part of the past drama. It now links them all together. This is not the intent of a person that wishes to "come in peace" or be helpful, this comes across as one having the purpose to set off a blazing fire of more drama.
4) The OP has shown no interest in working with V developers, and that's prior to publishing the review and spreading links to it.
The OP has demonstrated no intent to modify his review for correctness, fairness, or language version. This then puts "at this time", in the context that the review can stay as it is, indefinitely, regardless.
Add to that, the OP is purposely using a throwaway account on GitHub. He simply can disappear, without ever making changes to the review. We all know who the creator of V is and a number of its developers, they are all held accountable, as you are trying to do now. The OP on the other hand, has no accountability nor any "skin in the game".
5) The OP's review is without the necessary context and highly opinionated.
Without feedback or the opinions of the V developers, this is a one-sided negative review full of many debatable points about the claims made. The many gray areas can only gain context, when compared with what the V developers are showing their intentions are and in their responses to what are believed to be issues.
For more clarity at what I'm getting at, I'm not saying there are no issues with various claims or marketing, but rather what is claimed can be a matter of opinion. Because a person or reviewer disagrees with a claim, does not make them or their review 100% right either. Readers are left with a situation as to what percentage of either side is correct.
And no matter at what percentage either side is correct, who is going to fix any discovered issues? Right, it will be the V developers. So if the point was not to do any harm and help create production-quality V, then that's who needed/needs to be informed and worked with. If the OP is not interested in working with V developers, and rather produce and disseminate drama or facilitate smearing, then that's a reflection of their real intent.
Okay so do something about it. It’s been over 3 days since the blog post was written and all you’ve done since then is mount the same complaints here about how unfair the blog was.
Go write your own blog post. Submit it to hn. Refute all the points in the blog with evidence and code. Then we can have a follow up discussion with more substance.
At this point, you’ve made your position clear and you’re talking in circles. The way you combat a negative story is with a positive story. Whining about how unfair everyone is being to your favorite new language is a perfect way to limit its growth.
As such a small community, your personal behavior on public forums defines the tone of the entire V community for outsiders. You should critically analyze your posts here and ask yourself if they leave the impression of a community people would want to join.
I'm not here to speak for all members of the V community, as it appears your are trying to pigeonhole me as doing, for your narrative. My personal opinions are in no way reflective of their entire community.
It also appears you prefer to see negative opinions or commentary about V, and are getting overly upset or obsessed with those you believe are defending the language in any way. I'm simply responding to a thread on HN (as you are), that was not made by me, and calling out things that I see or believe to be unfair.
The V community has open discussions that anybody can join and make comments on. You can also freely create an appropriate discussion at the V GitHub. This is something that it appears you don't know about (and what the OP purposely avoided), as you're "talking in circles" with me and giving your opinions about "whining". The link to it is below.
You are free to go there and submit your many opinions about what the members of the V community should or should not be doing. Even better, as you seem to describe yourself as very technical and knowledgeable. You would be commenting directly to them. In general, they are very receptive, open, and friendly.
> My personal opinions are in no way reflective of their entire community.
Unfortunately for you, the V community is small and you tend to come here on HN, so you are who we see as an ambassador for V. You are a defacto representative of the community even if you do t see yourself as such. The way you comport yourself here reflects on the entire community. Fair? No. But if you read the comments here and in other threads, you’re definitely leaving an impression as to the entire V community.
> You are free to go there and submit your many opinions about what the members of the V community should or should not be doing.
I don’t have many opinions, I have one opinion and I have given it to you. Stop arguing on the internet and just make your claims bulletproof.
There is no "we", everybody on here does not think as you do. Better to clearly speak for yourself.
> ...defacto representative of the community...
If you bothered to read and pay attention, the creator of V posted on this thread. This includes other V contributors (that debated some technical points), and long time proud paying supporters of V (who have identified themselves as such).
I have also clearly (and now repeatedly) told you that I'm not the V community nor do my personal opinions represent them. I'm expressing my opinions on HN, as you are, which refer to the actions of the OP and the topic of this thread. Anybody with common sense should understand that. Stop being so upset that there are people with different opinions about V and are supportive, not everybody gets off on smearing others or clings to negativity.
> ...make your claims bulletproof
It is not my position nor place to make any claims bulletproof, in reference to V, to your personal satisfaction. If anybody wants to actually address the V community, and tell them their opinions about what they could be doing or share their technical knowledgeable on the subject, then instead of just trying to argue me down specifically, they can go over to where they are at (V Github or discord).
100% right. It's sick. As a donor and supporter of this VALIANT AND VALID effort, I applaud the V community. It's full of sincere passion, love and is putting forth a great effort to realize something useful and needed in this sector.
You're going round the comments and telling everybody how wrong they are. Do you have any thing to say about concerns raised in the blog post? Or would you say that it's a lie and all the points raised are based on falsehood?
She doesn't pull any punches, but I think she was quite prescient in capturing the vibe of the project.