How up-to-date is this [1] review from earlier this year for 0.3? Honestly, the review read nicely but left quite a questionable impression of V.
I like Vlang (also like Rust and ...) so, I'm happy for your attention & deep insight. I hope you to dig and share again sometime.
1) The "review" is now significantly wrong and already outdated.
Doesn't mention it is reviewing an Alpha or even the version.
Anything of substance in the review was mostly minor and has already been fixed:
https://github.com/vlang/v/issues/14803 https://github.com/vlang/v/issues/14787 https://github.com/vlang/v/issues/14786
2) The author of the "review" used a throwaway account for the apparent purposes of recommending to not use V.
The author of the "review" can run away and hide, where the creators and developers of V are accountable to the public and supporters.
This includes that the author of the review never has to update or make corrections to his hit piece, while still spreading links to it all over the internet.
3) The "review" is used as a linked reference document for further attacks by competitors and detractors. And as has already happened on various other internet sites, including here.
4) If the author of the "review" was really eager to use and fix the V language, he could have brought those issues (he has a GitHub account) to the V GitHub (https://github.com/vlang/v/issues).
Who is going to fix any issues that the author believes is a problem?
It is going to be the V developers. So if the author of the review wanted those things that he believes are a problem fixed, that's who he has to bring them to.
5) The author of the "review" starts it by linking to a number of very contentious posts from competitors and detractors of V, to include those that smear the author and language.
This turned the "review", right off the bat, into setting off drama. A smear campaign on the V language will never get any of the issues fixed on its own, just only invite more drama, smearing, and attacks. Which looks like the original intent.
6) The author of the "review" has shown no interest in working with V developers, and that's prior to publishing the review and spreading links to it.
No intent has been shown to modify his review for correctness, fairness, or language version.
7) The author's review doesn't provided the necessary context and is highly opinionated.
Without feedback or the opinions of the V developers, this is a one-sided negative review full of many debatable points, that does little to help readers outside of trying to produce a negative impression and smear the language.
If the review author 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.
Article's author citation related to V's version which got tested:
> I’ll be using the current version of V built from git which is 50ab2cfd1ae02d4f4280f38c60b8dbd17f7599f6.
To be perfectly fair to the language, for me, it was love at first sight. Syntax is beautiful.
If ever V reaches maturity (0 segfaults + addresses concerns raised in Reddit, HN and other sources such as ^), I would definitely prefer it to Golang, potentially even Rust.
Not to mention its future is secured if C projects are ported to V.
Since it was another anonymous attack, it's not going to be updated and will stay like this for years.
And the issues discussed are questionable at best. Half the article is about a type checker bug, which was a 3 line fix.
Then false claims like being able to modify array.len.
I keep seeing V being "attacked" by various people with these kind of blogposts (or even HN accounts dedicated to criticizing V), with broad range of claims or counter-claims to what V wants to achieve.
While this is maybe not completely absent when other new languages comes up (like Golang or Rust), it feels like V really brings out the people to come up with ways of criticizing it.
Do you have any ideas about why or how come? Have you noticed anything in particular that makes people want to (almost) aggressively "prove" V to be wrong?
Basically, do you have any guesses to why V seems to have more "enemies" out there, compared to lets say Rust or Go?
There's also the whole issue with blocking people who criticized the language (eg. Xe) because V was being "attacked" as if there's some conspiracy to destroy V. The claims may be outdated, but the response by the developers put many people off.
V has made huge strides since then, but people are very resentful.
I'll make a detailed post about this next week.
Not to mention that a conspiracy requires a coordinated effort. It's a lot more likely that blog writers are upset about something and decide to go on rants about other minutiae they find instead of submitting GitHub issues.
There are now V contributors who used to troll V back in the day.
How is an open-source programming language divisive?
Seems the people brigading are toxic and divisive, not the language or it's maintainers.
I have no horse in this race, have never heard of V, and frankly find the emotional charge in this comment section extraordinary... odd.
But I am a PL person.
Bugs in the type checker are pretty unambiguously a big deal. I totally understand why the examples in the blog post are alarming. The point isn't that they can be fixed by 3 lines; the point is that there were obvious soundness bugs in the type checker implementation and the language designer's attitude seems to be "NBD if the patch is small enough". Given the post and reaction, I would not be surprised if there are many more soundness bugs lurking. So, that's an issue if I want to use the language for anything serious.
That said, it looks like a hobby language in its early stages of approaching maturity, so the degree of divisiveness is seriously confusing. My reaction to all the drama is closer to "yup some soundness bugs; type systems get subtle fast, what a great thing to learn from" than "I hope V dies / the V critics are terrible".
I'm guessing there are weird personality/politics at play, but don't care enough to find out.
Anyways. I liked the Android examples.
This.
It’s complete nonsense that there is a conspiracy to kill v off. You know it. We know it. Saying it is just drama for the sake of drama.
> And the issues discussed are questionable at best. Half the article is about a type checker bug, which was a 3 line fix.
> Then false claims like being able to modify array.len.
This.
You’re just creating drama saying things like this.
Just say: “The issues in that review have been fixed now, please have a look and submit bugs in the issue tracker if you find them”.
If someone has a legitimate thing to say, and at the time they say it it’s valid… that’s fine. If was wrong at the time, then by all means call it out.
…but here’s the good story about v: you fix bugs. A lot. Quickly. You build lots of stuff. It’s very impressive.
Things aren’t always perfect; it’s v0.3 for goodness sake. It’s fine. Just a) don’t claim it’s perfect when it’s not, and b) just clearly point out when issues that have been raised are fixed.
…but, please also stop and read what I said.
You asked for specific examples where your interactions are causing problems.
this is it. Don’t post like this. You’re accusing people of attacking you, attacking other people (for example your comments on the author of Zig below).
This is what causes people to have bad interactions with you.
Do you know how many "X is better than Rust", "X language is trash" articles are out there?
Just be passive-aggressive like "Hey! thank you for the bug report and for taking the time to make V a better language! We'll check these errors!". Dismiss them and go your road.
People will keep linking to them and say "didn't you see? V uses shell to do http requests! what a joke"
This most recent article by an anonymous author had all of the issues fixed within several days, but it wasn't updated, it'll stay like this forever, as planned.
But, if lead dev replies in ways that seems offensive, or attacking, that is something that actually creates permanent dent in the adoption. Even if you are right in saying what you are saying, it still matters, a lot, to be polite.
I'm someone who really really wants V to succeed. I love what rust is able to achieve, but not the complexity it brings. V-lang gives me what I want from a language.
Language is beautiful, now it's your turn to be the same. Ignore the trolls. Many of them are paid.
And best wishes.... keep the good work. It never goes in-vain.
- You genuinely are not fluent enough in the language to either understand the original statement, or to write a fair paraphrase, and are not willing to believe this mistake.
- You know exactly what you're doing. That is, if you gave the actual quote, nobody would for a moment take it as a proof of your conspiracy claims.
Neither of the above is acting in good faith. I'd ask again whether you'll stop lying about what Xe said, but at this point the answer feels pretty obvious...
That's not a conspiracy[0], but a review[1]. You should be glad for the people that actually spend time to market your product, raise your credibility, tell you how you see from outside, and provide independent checks. For free.
> 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.
Xe says "There are good ideas there". What do you think the metaphor of being sold the moon and receiving a block of cheese was intended to express? What does it mean to you? To me, it very clearly expresses that the language described by V's marketing would be extremely valuable and desirable, and that Xe is disappointed that V does not live up to what they expected. It's bizarre to me that you somehow see this as consistent with "should die".
What is your evidence that there's a conspiracy? Why do you believe that people are secretly coordinating on secret plans to destroy you?
Everything I've seen is completely consistent with individuals disapproving of what they see as you repeatedly claiming that V is far more capable and ready than it actually is and ignoring others who point out their perception of the same exaggerations.
I'll be curious to read your upcoming blog post about this topic, as I have yet to see you describe any justification for your conspiracy claims besides you finding it implausible that people could actually disapprove of how you talk about your work.
The blog posts that you keep claiming are maliciously-motivated conspiracy seem entirely normal criticism to me. They describe their goals and motivations, and those goals and motivations seem like very normal and reasonable motivations that explain the content of the blog post. I don't see anything that would need speculated malicious conspiracy to explain it.
Creating a blog, with an obvious smear title like "V is Vaporware" and making comments like "I recommend against using it for anything...", is not "normal" criticism. That is attempting to go above and beyond, with drama and smearing.
To include following such blog posts up with more linking, smearing, drama posts, and attempts to use such to get more attention for one's self at the expense of the V language.
Are there really, truly no tools that you personally recommend against using?
There was a lot of jealousy when V was announced
Looks like the ones who need to self-reflect is Zig, they still don't have a self hosted compiler, meanwhile V compiles itself in less than a second
He was really persistent with his attacks, even received a warning from dang.
I found it really surprising, because before the release he wrote:
> Wow, that's incredibly fast. Self-hosted in 2 weeks? Hot code reloading? This is everything I plan to do with Zig, but apparently done already. How did you do it so quickly?
I'll also add, my personal reading of the quote has more than a note of "this sounds too good to be true." But that could well be a matter of interpretation.
https://twitter.com/andy_kelley/status/1142503808901308418
I can't find the article where he mentions that it is a scam, i also remember people attacking the patreon backers
This tweet seems to be an apology so i guess we can move on
EDIT: there i found it: https://news.ycombinator.com/item?id=20230351
V seeking (and receiving) Patreon or GitHub donations is not exploiting anyone. Neither mechanism is a contract. Either can be cancelled anytime, immediately. So like it or not, the sponsorship is a pretty accurate reflection of satisfied people (unless one is simply too lazy to cancel their pledge...).
Though you may just be asking rhetorically to probe for a response from the founder, in which case, never mind.
No, I was genuinely asking the question directly at the creator of the project, to understand their view of the contention they seem to be at the receiving end of.
I know the history of the project, but it seems to me like most languages in their pre 1.0 make claims about what they would like the language to be, not what it currently is, but they still don't receive their criticism in such manner. Or maybe I'm just reading into it too much. Hence the question :)
That's because those languages make those claims in future-tense rather than past tense; they explicitly state them as goals, rather than presenting them as if they're already implemented. For example, I wrote a tiny scripting language for Erlang/OTP apps called OTPCL, and I make it clear in the README which features are actually implemented (like the parser and interpreter) v. which ones are in progress (like the standard library) v. which ones haven't been started at all yet (like the compiler). Same deal with up-and-coming languages closer to V's use case, like Zig; there's a clear distinction between those three levels of completeness.
V did not make that distinction originally; a large number of its radically ambitious goals were presented on the website as if they were already implemented, only to later be revealed to be "WIP" at best. A lot of people - including, at one point, Zig's creator - assumed malice here, figuring the disparity between the website v. the actual releases to be an attempt to swindle Patreon backers (I can't read the mind of V's author, but I would guess that it was more of a language/communication thing than anything outright malicious). In any case, that left a pretty negative first impression for a lot of folks, myself included - and while it seems V is making some progress, it's hard to get that bad taste out of my mouth and consider even trying it out when languages like Zig and Odin and Nim and Crystal seem to be a lot more transparent and realistic from the outset.
This is a mostly content-free reply that casts vague aspersions; it's not especially helpful when someone asks, essentially, hey, what's going on here? to then respond that they may be interested in looking into what's going on. Of course they're interested—that's where the question comes from, after all. Please respond meaningfully, then, and abstain from replying with non-specific ad hominem.
But it started out with huge promises that could never be kept, and were tied to fund raising. This is why there was so much skepticism in the beginning, and why you are facing so much hostility now.
The way to change that is by professionalism and convincing arguments, benchmarks, showing how the promises are kept and responding to criticism in a good faith manner by providing technical explanations.
Not by responding with more hostility.
It's also perfectly fine for fans of the language to support it here, but there are many "content-free" posts in this submission that just hype up V with minimal value-add...
I personally don't see an ad-hominem in my post.
1. 2. 3.
> This is why[...] you are facing so much hostility now.
You are confused about something. You seem to think I'm someone else.
I'll publish a big blog post about this. It will debunk all these "V is a scam" articles.
Basically V appeared out of nowhere and got popular very fast. It took a lot of shortcuts: it was self hosted on release, GitHub started supporting it 1 month after the release, it had hot code reloading, fast compilation (v self is <1s [0]) and so on.
People developing other languages and their communities didn't like it, and decided to attack it.
There were 2 strategies: making completely false statements (like claiming that the V compiler has a dependency on glfw, so the no dependency claim is false, and claiming that V programs use libc, system's only official API, therefore again the no dependency claim is false) and nitpicking over bugs that are inevitable in a 0.1 language, and sometimes complaining that features explicitly marked as [wip] are not ready yet. One of the common questions I saw is "why release it if it's not ready". While that's the whole point of open source. I got lots of help from 500+ contributors and got to this point a lot faster.
Then there was also a misunderstanding with the "preview" release one week before the source code was released, and many thought V was going to be closed source. Over this week unfinished features were not marked as [wip]. They were marked so after the open source release, and now there're no [wip] features on the website. Everything listed there is working in latest V.
I honestly doubt this is the case. Aside from some cargo-culters (which are far from being a majority), most programming language enthusiasts are very welcoming to new languages and ideas they bring with them. I have never seen a "language war" happening this way.
Personally, I admire the V's ambitions (if the autofree() ever reaches production-quality it would be a total triumph over Golang's garbage collection approach), but I dislike the unprofessional approach to the community (explained in many other comments - particularly false claims about language capabilities, deleting criticisms, unwillingness to admit shortcomings and making up excuses for each of them, etc.).
If you can link one, that'd be great, and it'll be fixed. I've spent a lot of time verifying all claims are valid.
For example there was the "functions are pure by default except IO" which caused lots of criticism and memes. I simply changed the wording to a more verbose but correct phrase. So we do admit shortcomings and not make up excuses "for each of them"
We do not delete criticisms, we actually welcome them and any kind of feedback:
Unless you demonstrate an honest effort to understand, I will not continue this pointless argument.
> Most objects (~90-100%) are freed by V's autofree engine: the compiler inserts necessary free calls automatically during compilation. Remaining small percentage of objects is freed via reference counting.
> The developer doesn't need to change anything in their code. "It just works", like in Python, Go, or Java, except there's no heavy GC tracing everything or expensive RC for each object.
[0]: https://github.com/vlang/v/blob/master/doc/docs.md#memory-ma...
So, I am not entirely sure the best way to quantify whether this is true. However, I thought a fun test would be recreating "my first memory leak" -- the first memory leak I can remember fixing in code that I wrote. Specifically, I was essentially leaking some bespoke heap-allocated iterators I had created (inside of an infinite game loop).
So here is my little test:
struct Iter {
mut:
pointer int
}
fn main() {
my_array := [ 1, 2, 3, 4, 5, 6, 7, 8, 9, 10 ]
for true { // simulated game loop
mut iter := &Iter { 0 }
// heap allocated iterator
for iter.pointer < my_array.len {
print(my_array[iter.pointer])
print(" ")
iter.pointer += 1
}
println("")
}
}
So, from what I can tell, this description of the autofree engine in the documentation does not accurately describe the existing functionality available in V.
I am curious where the 90%-100% figure comes from. It is such a specific number that it implies to me, as a reader, that it comes from an empirical measurement of an existing system. But, there is no link to where this measurement was taken. In my opinion, the documentation should include some details about how these figures were generated.
> until V's autofree engine is production ready.
> Most objects (~90-100%) are freed by V's autofree engine: the compiler inserts necessary free calls automatically during compilation. Remaining small percentage of objects is freed via reference counting.
> The developer doesn't need to change anything in their code. "It just works", like in Python, Go, or Java, except there's no heavy GC tracing everything or expensive RC for each object.
> These points are both currently untrue, and should not be relied on in code.
I'm hoping I don't come off as flippant here. I just don't see any way to interpret these claims as an accurate description without adding that third bullet point.
The claims are objectively false. The autofree engine objectively does not free 90%-100% of objects, it is objectively not true that "It just works."
If I understand you, you're saying that autofree doesn't work because of bugs in the compiler. But, the fact that the claims are false as a result of bugs in the compiler does not somehow make those claims true.
The website and documentation does explain the situation, for those that cared to actually read them. "Right now allocations are handled by a minimal and well performing GC until V's autofree engine is production ready." This should be enough to understand that autofree is WIP and not enabled by default (which is referred to in the documentation).
The other issue, is that people who have never used V or autofree (not even talking outright detractors), might interject or repeat uninformed opinions about the situation. Where those that have more thoroughly experimented with autofree and have used V or are in the V community, would likely understand the situation and history of it (have read other things about it on V's GitHub or asked about it on discord).
But I don't really understand what the intended reading of the documentation is.
If I were to completely take these two paragraphs out of context, they are factually untrue:
> Most objects (~90-100%) are freed by V's autofree engine: the compiler inserts necessary free calls automatically during compilation. Remaining small percentage of objects is freed via reference counting.
> The developer doesn't need to change anything in their code. "It just works", like in Python, Go, or Java, except there's no heavy GC tracing everything or expensive RC for each object.
So, what does this mean? Well, nothing, necessarily. If the context clarifies that these points are all untrue, then, the documentation could be considered perfectly accurate as far as I'm concerned.
However, when I asked if the intended reading of the documentation was that these points are untrue, the answer was--no, these points are all actually true.
I don't understand that position. These claims are straightforwardly untrue.
To me, your response is reinforcing my original proposed reading. That is--to me, your response indicates that I should read these claims as being false, and that the documentation is acknowledging them as false.
Now to me, that is a perfectly good response to my original comment. If this part of the documentation is not intended to be read as a statement of fact, that makes perfect sense to me, even though I do think it could be communicated better.
As it stands, though, I'm not really sure what I'm meant to get from this[0] comment.
"Note 2: Autofree is still WIP. Until it stabilises and becomes the default, please avoid using it. Right now allocations are handled by a minimal and well performing GC until V's autofree engine is production ready."
So, autofree (as a WIP) is not at this point working as intended, which is described by, "The developer doesn't need to change anything in their code. "It just works"..." I don't take this as any attempt to mislead or deceive, like you seem to be doing. The documentation is even telling people to avoid using autofree, as it's WIP.
Yes, there is a difference between how autofree is suppose to work versus how it is presently working. Yes of course, I can totally see how people get very excited about autofree, and want it 100% working or want its development accelerated. But, it should be obvious that at this point, when a person is using it, they are experimenting. When a person takes it upon themselves to enable autofree, in an alpha status language, they shouldn't be surprised there are issues.
Then bringing it back to what I had typed about earlier, using autofree at this point, requires that the person understands something about memory management and looks at examples of its usage. Particularly when a person is going to enable it, against the recommendation of the documentation.
It appears you are implying that if autofree doesn't work perfectly as it is described, then that indicates a false claim or deception.
The counter to that (and what I'm saying) is that the website and documentation states that autofree is WIP and even recommends not to use it, and tells users that at this time GC is used instead. There is no deception, they are being clear. So if the user goes against the recommendation of the documentation, they should not be surprised that WIP autofree in alpha status V, is not working perfectly.
Furthermore, autofree does exist. We are not talking about a lie or false claim, where something is not in existence. Autofree does function, so here too, we are not talking about something that does not work at all. We are now talking about to the degree it is working or how well it works. Which on that point, the website and documentation both indicate WIP, so a user should not yet expect it to fully function.
I further elaborated that if you experiment with it, you may get autofree to work well. But, that can depend on: the program, can require experience using V, some memory management knowledge, and/or going through examples of V programs that use it. The expectation (and what those in the V community are aware of) is that as V goes to higher versions on its way to beta status, we will see better performing versions of autofree that requires less to no needed user knowledge about details.
And, judging by the review linked upthread, as of last month this has remained the case. For this reason, I'm not surprised that the scrutiny continues.
Meanwhile, defensive reactions like those I see in and around this thread make me feel like I trust you less.
That's not how the world works. And it's open source, where hundreds of contributors help you find and fix these bugs. That's the whole point.
I'm not asking you to never ship a bug. I'm saying I don't trust you or your language and giving you an example of how you might regain my trust. Feel free to ignore my advice, but if your goal is to encourage more people to use your language instead of encouraging more people to fight you, maybe you could at least give the impression that you were willing to hear someone out instead of telling them their opinion doesn't make any sense at all.
They mostly seem to deflect with denial or claims the issues were 'nothingburgers', but if that's the case, it should be trivial to offer a rebuttal in the form of a blog post, but instead we get ad hominems and conspiracy theories.
So it wasn't a memory leak, it is GC overhead, hence it being labeled as a "nothingburger".
What specifically do you feel hasn't been resolved or addressed properly?
The author responding constructively to criticism. The bugs may be fixed, but if the author can't calmly engage and link to the fixed commit, or give evidence that, for example, everything compiled with GCC leaks those 800 bytes, well that's a major red flag about the project management of V.
https://github.com/vlang/v/discussions/7610
Wishing V to die and making false accusations is not "constructive criticism".
There will be a blog post next week.
In the cited thread, I've deleted my contribution because of the tone of the discussion (passive-agressive know-it-alls with smirk emojis): https://github.com/vlang/v/discussions/7610#discussioncommen...
Is this how you welcome people to the community?
I enjoy V and contributed several PRs which got merged, but there's definitely an attitude problem there. I gave up contributions because of it.
He enjoys language development and submits his feedback and ideas, discusses other ideas etc.
I do not work as a big censor and read every single of the thousands of messages, and I do not have time to do it.
The other person in that discussion on V's GitHub even apologized for appearing harsh, seems to have begged you to come back, and gave you a compliment.
Also deleting your part of the discussion also robs other readers from evaluating the full merits of your side. There will usually be people on your side of the discussion as well or see your point of view. I think you will find that overall and from what I've seen, people in the V community can be appreciative and welcoming, but like anywhere its a mix of different personalities and characters.
Not that you've done so; but others seem to reciprocate back with bullying, and with twice the force of any denials. A lot of people need to get the wisdom that others are different from them, and simply move on. The same threads, blogs, comments have come up on every single V post - living rent free in many people's heads.
Maybe this language deserves more criticism. Or people are biased against it. Could be either explanation, or something else. But there ain’t just one single possibility.
For example from wayback machine http://web.archive.org/web/20190520021931/https://vlang.io/d...: "(Work in progress) There's no garbage collection or reference counting. V cleans everything up during compilation. If your V program compiles, it's guaranteed that it's going to be leak free."
When people called him out for this saying that this was impossible he doubled down on it and said that it's fine to say things like that because of the "work in progress", as if it was coming.
It turns out, it was impossible. V eventually had to add reference counting.
The worst part is that he used lies like this to get thousands of dollars from Patreon sponsors.
It seems like he's trying to clean up his act, but he's still making some dubious claims. He claims to have invented an "innovative and flexible memory management" reference counting algorithm that removes 80-90% of overhead. But there's no way to do that with mutable data, as far as i know. And sure enough, it doesn't work, users are still told to use the garbage collection option. If that turns out to be true, I might change my mind, but I fully expect that it's a false promise too.
https://www.youtube.com/watch?v=gmB8ea8uLsM
0 GC is used.
None of the people who ever donated or are still donating felt they were being scammed. They often write about this here on HN.
Last time it seemed impossible, you said it was "work in progress" for years, and it turned out to be a lie.
This time it seems impossible, and it's been "work in progress" for 1.5 years. You can see why that's suspicious.
Autofree hasn't been a priority because of how unexpectedly well the GC is performing with V, but it will be finished.
All this is clearly stated on the website.
The newer reference counting system has an example but it's very easy to conjure a working example of a system that has fundamental holes. When people use it for larger programs it crashes or leaks even today. Is that incorrect?
Also I see the Patreon topic a lot - Patreon is not a contract. If one is unhappy they can stop pledging ANY time, immediately. So like it or not, the Patreon support you see is a very accurate representation of satisfied backers as well.
You have to keep in mind that V is an up and coming language, that is an alternative to Go, and somewhat to Rust. V is in the categories of C and Go alternatives. There are many other competing languages in V's categories, such as Zig, Odin, Nim, etc...
Not too hard to see how "enemies" and rivals can "pop out of the woodwork" to take shots, the more popular that V becomes or the more they might feel that V is a threat to their interests.
As for Go and Rust, they are backed by major companies, where "enemies" of their language will simply not get any or little media "airtime" nor enough traction to establish a negative public narrative that can stick. You can attempt to say something negative about them, but will be ignored or drowned out in various ways.
V is an up and coming language in the categories of both C and Go alternatives. This means a wide range of competitors and "acolytes" who may "come out of the woodworks" to take a shot at a rival, at anytime. The more popular they believe V is becoming or the more threatened by it that they may feel, the more likely we are to see "shots fired".
This is not to say that various criticisms are not or will not be valid. In fact, constructive criticism can be good and healthy. Among them, bringing bugs and issues to the attention of developers or having technical discussions with the language's community.
But, the negative or non-constructive acts (attack blogs, downvoting, flagging, gaslighting, trolling, etc...) do shed light on some of the odd heavy-handed, sneaky, or aggressive vibes that many of us can see. It demonstrates the intentions of bad actors or those acting in bad faith.
> ...absent when other new languages comes up (like Golang or Rust)...
Golang and Rust are backed by major companies. They do have plenty of "enemies" and competitors taking shots at them, but they aren't given the media "airtime" for their negative narratives to stick and their attempts get drowned out by the size of the language's userbase or amount of "infomercials".
Various other newer languages simply lack the popularity, userbase, or sponsors for most to even take notice or care. So they are simply not talked about.
I encourage people following the progress of the V language to look at actual facts rather than trying to evaluate claims based on the language of those claims. One of the reasons why V is so divisive is that a lot of untrue claims are being made (unusually so for a programming language), and people don't respond well to that being called out.
> I didn't go through the rest of them, but expect a similar pattern.
You verified two issues were fixed, ran into one issue and then you expect a similar pattern of what exactly...?
Why didn't your comment go like this:
"Hey I went through to verify the these issues were fixed and I'm getting an undefined behaviour on integer overflow, here is how I tested (show code), are you able to reproduce this?"
That would be much less divisive and result in a proper discussion.
I think you'll find if you try to "call" people out instead of asking questions you'll be met with the same tone you gave them.
-- EDIT - replying to @paskozdilar below --
It could be that GP tested incorrectly? Since things are getting so serious shouldn't we see the code GP used to test before mob shaming?
You seem to be jumping to the conclusion the issue is not fixed. I don't think hurling "narcissism" is needed at all here.
Author has clearly stated that "all issues are fixed". The other guy found one unfixed issue. That makes the author's statement false.
I don't trust a person that lies, especially when they lie with such conviction and confidence. Reeks of narcissism.
-- EDIT - replying to @hunterb123 above --
I have reproduced the same error as in blogpost.
The front page of vlang.io has prominently featured under "Safety" the line "No undefined behavior". Saying that C-like undefined behavior[1] is "expected" directly contradicts that. I'll also point out that Nim, another language which compiles to C as a target, addresses this correctly.
[1]: https://raphlinus.github.io/programming/rust/2018/08/17/unde...
If someone raises an issue re: integer overflows, and you don't change the behavior, it's not 'fixed'. It may be 'addressed' or 'resolved' by responding with with something like "it's working as designed" or "if it's good enough for C, it's good enough for me!", but it's _not_ fixed. I don't think you should claim:
> All of the issues there were fixed several days ago
I really do like V FWIW.
They may just come from a fundamental lack of knowledge about low level development.
The post seems to spend quite a lot of time on the V language and discussing it, so I got curious and put in some of the examples into V for windows. The results seem to be different, but my knowledge on V is too low to understand the implications fully.
The "No null" experiment does not give a segmentation faul, instead it prints &nil. That seems to be effectively a null value to me though. Adding another layer of null dereferencing creates an access violation/sefault.
The undefined behaviour for integer overflow is the exact same as in the post. (edit: and in the github issues it is marked as "won't fix" it seems V does not care about creating undefined behavior in the generated C code, just that the behavior is defined within V.)
The overwriting of len for the array seems to be fixed as the capacity is increased to the value of len seems to return nil references now.
The immutable->mutable trick seems to be caputred by the type checker.
The remarks on included libraries seems to hold, as well as the "simple webserver" being 2MB when compiling (although openssl seems to be included now).
I have no motivation to redo all the other experiments in the blog post. And your response as well as the small checks leave me not-very-impressed with V, as I can't take any of the claims on the website seriously like that. If you claim it is a v0.1 or v0.3 language, sure, make a list of features that actually exist or a roadmap when they are reached. This is especially true for the "novel memory management" which seems optimistically to assume it worked before when a changenote is included that the compiler doesn't leak memory anymore by default. That is not particularly instilling confidence, although it's the right direction.
It'd take 10 minutes to submit github issues, instead they spent a month on this.
Null is only allowed in unsafe code.
Overwriting of len was never fixed, because it was never an issue in the first place. The author made it up. It's always worked like in Go.
Included libraries, you mean the json library that's part of vlib. So each Go program that uses net.http also has library dependencies by this logic.
If the author put in the work, I don't see the problem with it being a blog post. Also, given the history of github comments / issues being removed from the vlang github project, I don't blame them for wanting to keep their post for posterity.
One and only time a github comment was removed was before the open source release and I just started this new job of an open source maintainer.
Actually, sorry, I did remove one issue recently. It said "Delete this project, it's a joke".
> The post is unnecessarily hostile. Created by a new anonymous account, with the goal of attacking V and "not recommending to use it".
What about it was hostile? It was written in a very neutral tone and was almost exclusively fact based, with just a couple of summative comments about the author's overall impressions at the end.
How could you possibly know the motives of an anonymous author? Seems like the author was smart to remain anonymous too, given the amount of vitriol the V community has directed his/her way for writing the review.
> Also with referencing the notorious ridiculous "V is vaporware" articles, it's pretty clear what the goal of the author was.
Of course a review will mention a widely circulated previous review. As much as you might like to pretend that it never existed, this isn't the CCP where we can expunge things that we don't particularly like from the historical record.
> It'd take 10 minutes to submit github issues, instead they spent a month on this.
I see, reviews are only okay if they are positive. Otherwise they must be github issues. What a convenient way to make sure that no negative review is ever "by the rules" and to question the motivations of anyone who dare write one.
The review started out hostile by links to blogs and posts that smear V and the author from outright competitors and detractors! Completely unnecessary, if the purpose of the review was to stand on its own merits. It also sets the tone, of not being neutral, from the very start. And, links itself with other attack blogs and threads from the past. It made itself the newest link in the chain of attacks.
The review is highly opinionated. It's an evaluation of claims, where the author gives his opinions on their validity. The author never gives readers his qualifications for even being able to properly evaluate the language, and uses a throwaway account, where he can easily run away. The V developers are held accountable for their opinions, but not the reviewer. You can never hold the author of the review accountable for anything he got wrong, was mistaken about, or is missing.
It's also not a fair or objective evaluation, where he sought to get any input from V developers to clarify their positions about claims made. So it's his own one-sided perspective. He is going to be one-man judge, jury, and executioner. And that one-man judge's sentence is, "...I would not recommend spending time on V". Which is clearly very negative. It is also very presumptuous, that readers should come to his same negative conclusions, versus do their own evaluation, check out what the V community has to say, or check out the latest version of V.
> I see, reviews are only okay if they are positive. Otherwise they must be github issues.
Nobody said that reviews must only be positive. What is being conveyed is that if the reviewer really had a problem with using V, wanted it to become production-ready, or wanted something fixed then the way to do it is to submit issues or discussions to V's GitHub.
Otherwise, it shows the intention that one's purpose is not to fix anything, but to spread drama and smear. The reviewer has a throwaway GitHub account, where it would have been easy for them to verify various conclusions with developers, submit issues, or create a discussion at V's GitHub site.
That’s clearly not the case, as the exact code in the post prints ‘&nil’ in current V master, and if you add a dereference you get a segfault (which someone else just filed as https://github.com/vlang/v/issues/14911).
> Overwriting of len was never fixed, because it was never an issue in the first place. The author made it up.
The home page claims the language has “no null (allowed in unsafe code)”. println(*[]&int{len: 1}[0]) is not marked unsafe, yet it still segfaults by dereferencing a null pointer. Can you explain why you say this was never an issue?
(I’ve filed this as https://github.com/vlang/v/issues/14914. A related issue in maps was filed a year ago: https://github.com/vlang/v/issues/10837.)
> It's always worked like in Go.
Go is not a language that claims to have no null.
Just add the immutable variable's reference to a mutable array, now mutate the immutable variable using array[0], magic!!
The compiler is so basic and naive, it's laughable how their authors have guts to fight everyone about it's stability.
When people read "V compiles itself in less than a second", they expect V to compile itself in less than a second for the general case (not just one very specific case). When people read "as fast as C", they expect V programs to have the same runtime as equivalent programs directly written in C. When people read "no null, no globals, no undefined behavior, immutability by default", they expect there to be no issues with this 99% of the time. When people read "Despite being at an early development stage, the V language is relatively stable", they don't expect this number of issues. I could go on, but the V documentation is filled with this.
In my opinion, if you keep going in this direction, no one will ever take V seriously. You might get some GitHub stars, you might get some inexperienced language developers helping you out, but if people can't trust V's claims, if V's claims continue to not hold up, no one will use V anything more than casually.
The simple solution to this is to walk back your claims and preface everything as unstable which is more accurate. Your GitHub description should make it obvious this is an experimental language with many issues. You should only list features in your README which are true and work for the average or general case. Any other features can be listed somewhere else as in progress or testing. Toning down your marketing is all it takes to earn back some trust.
This is false.
> Everyone wants you and V to succeed
The same people who write articles about V and say V should die?
Ok could you provide some benchmarks supporting this? I admit the article could be cherry picking benchmarks.
> The same people who write articles about V and say V should die?
Anyone saying that is probably fed up with the inaccurate claims. If you just make it clear to the user what features are in progress and that V is in an experimental state, I don't think anyone reasonable would have a problem with it.
Do you understand what I'm saying with the rest of my comment? Languages typically have a lot higher threshold of quality (a lot less bugs) when they say they have a feature implemented or when they say the language is "relatively stable".
https://www.youtube.com/watch?v=pvP6wmcl_Sc
> they expect V to compile itself in less than a second for the general case (not just one very specific case).
What on earth are you talking about? There's no specific case. Check the video. Try it yourself. Have you actually tried it?
Can you list the inaccurate claims here please and in progress features that are not clear to the user?