V looks interesting, and I wish it the very best. However the attitude of the lead developers toward criticism or negative feedback (even if it's not valid) is highly off-putting imo. Everything negative that people say appear to be taken as an "attack", and as far as I've seen they are quick on the trigger in regards to banning or blocking people that they disagree with. And at the very least they just completely disregard all negative feedback as lies, scams, conspiracies, etc.
The responses I've read by the devs are in stark contrast to what I've seen in other languages I use, such as Rust. I hope that as the language evolves, the developers will start reflecting on the way that they interact with others and how it impacts people's view of V. I could never justify using a language like V in production if I couldn't even trust the lead developers to be level-headed during criticism.
I'm sorry for ranting, I really wish the best for V and its maintainers.
> I'm sorry for ranting, I really wish the best for V and its maintainers.
I appreciate you posting this. I like the premise of V and really want for it to suceed, but this is a good summary of why I think so many people dislike V: the lead dev and community do not engage criticism in good faith.
I'm sure V receives its fair share of unwarranted criticism, but a lot of legitimate criticism and questions are either met with a) hostility or b) incredulity, which causes people to dislike the language for fundamental reasons.
Both the creator and community members gaslight (for lack of a better word) and act as if they're happy to receive questions or feedback, but even in this thread you can see people being treated like I mentioned above.
I mean, the article linked at the top is just outrageous - just read through it. For instance, it claims that V misleads by claiming that it has no null. But really what the author has done is found a bug in V that allows a variable to be set to null. A bug that unintentionally leads to creation of null is wildly different than V not supporting non-nullability at all. It'd be like using FFI in Rust to set a non-nullable variable to null and claiming that meant Rust had no type safety. It's absurd.
OP kicks a conversation in poor faith with "Wanna know something funnier also posted in previous thread?" about a V bug - which HN turns a blind eye to - and then suddenly the HN community pounces on the V maintainer when he gets frustrated in return? What?
> OP kicks a conversation in poor faith with "Wanna know something funnier also posted in previous thread?" about a V bug - which HN turns a blind eye to - and then suddenly the HN community pounces on the V maintainer when he gets frustrated in return? What?
I specifically linked to the_duke's comment offering some good-faith feedback.
---
But I digress. My intention isn't to argue that V is bad, just to provide context to why it's such a divisive topic.
> I specifically linked to the_duke's comment offering some good-faith feedback.
My point with this thread is it follows a common pattern. A HN user will post something in bad faith. The maintainer will respond with annoyance. Then someone like the_duke will moralize about how the maintainer shouldn't be so antagonistic. Then GP will put it in a list and say "the lead dev and community do not engage criticism in good faith."
There are some repeating thought patterns on some hot topics in this forum that makes me question whether it's work of trolls or naive people asking the same questions that end always the exact same way.
When it happens, it feels like living in Groundhog Day.
See any Brave post. There's a comment about BAT stealing money, people debunking it and the same arguments over 10 comments. Just below that someone mentions Eich's history at Mozilla, same pattern.
See any Urbit post.
See any V post.
See any foone post.
In these threads you find always the same archetypes of comments and posturing it makes me wonder if we're really living in a simulation of not very good AI. Or that a group of people is collectively pretty dumb and more predictable than you'd think.
The maintainer is the face of the product in certain ways. We would never defend a corporate CEO responding in annoyance to their free/paid users because it's unprofessional and puts the brand in a negative spotlight. In the same way, if you're leading/promoting a project you are held to a higher standard. You can choose to ignore bad faith comments, or respond in a positive way to bring the discussion to a higher level of civility.
Yes, it's annoying to have people give bad faith criticisms. But if you want a product to succeed and you want to foster a positive community, you should always elevate the level of civil discourse. So I disagree with your sentiment that other users are moralizing here.
If I'm going to engage with a product, it gives me much higher confidence knowing that the maintainers conduct themselves in a professional manner, even when a user is unprofessional.
> A bug that unintentionally leads to creation of null is wildly different than V not supporting non-nullability at all.
You have the "badness" ordering here totally the wrong way around. Soundness is about trust.
A known-unsound system is not necessarily bad. I use C and Python. I know the tooling can't give me very many guarantees, and that I have to do the book keeping myself. "Caveat emptor".
In a much, much stronger sense: there is absolutely nothing wrong with a sound system with explicit escape hatches. Bothing. I use sorry in Isabelle and admit in Coq. I do type casts in Java. I know where I can and cannot trust the tooling, and there are clear flags where I need to do my own book keeping. FFI in Rust is an explicit escape hatch.
I can't think of a single system that doesn't have some sort of explicit escape hatch from soundness. As long as it's explicit and understood and above all intentional, this is a feature rather than a bug.
But it's very hard to justify using a system that's supposed to be sound and isn't! I don't know where to trust the tooling.
And the blog's examples are not contrived. They are actually very straight-forward mistakes as far as type systems go... most production type system bugs are much subtle.
> But it's very hard to justify using a system that's supposed to be sound and isn't! I don't know where to trust the tooling.
At the point V was version 0.2. Of course it has bugs - even bad bugs.
The article went through each feature of V, found one bug per feature, and claimed that V failed to have that feature.
There are constructive and non-constructive ways to start a conversation about bugs in a language. One constructive way is to open Github issues. Writing an article claiming that a language fails to have those features at all is one of the least constructive ways I can imagine.
> There are constructive and non-constructive ways to start a conversation about bugs in a language. One constructive way is to open Github issues. Writing an article claiming that a language fails to have those features at all is one of the least constructive ways I can imagine.
Github issues vs. articles must be a generational thing; I have never used Github's issue tracker even for FOSS projects (admittedly not because we had better alternatives). I'm not even particularly old, but I am old enough to pre-date GH issue trackers as the de facto FOSS issue tracking solution.
Certainly, I would reach out to the author of a project -- especially a personal not-for-profit FOSS project -- before putting them on alert with a highly critical blog post. Except in exceptional circumstances (eg intentional spyware or backdoors embedded into the project).
But I don't think of articles as better or worse than GH issues in terms of form.
This kind of reminds me a tame version of the "disclosure debate" in security in the 90s/00s, I guess. Just because a lot of that debate was claimed to be about protecting users but was actually often about protecting egos (and "look how smart I am" zine articles that weren't entirely written in good faith or professional ethos). Except, of course, that in this case I think a simple cultural difference could explain a lot without any ill intent on either side.
(FWIW I'm not saying either of us is right or wrong. Perception is inherently subjective and all culture is relative. But I think I better understand how this project became so controversial...)
I think what was being referred to was any V GitHub posts, which would involve the V community. The V community has nothing to do with nor have any control over blogs and websites owned by others.
As for Cadey, it appears the person is continually self promoting, to include odd accounts continually linking to old and outdated blog posts on its website, at the expense of the V language and any chance given (see almost any HN post on V).
Cadey (or under various names) was the one that started off smearing V's author and the language with things like "V is vaporware", "V is lying", "recommend against using it for anything", hoping V would die off type nonsense, etc... Mind you, the attacks started against the very first released Alpha, as if it was supposed to be instantly production ready (and that is very much not how programming languages work).
So other programming languages are given the benefit of the doubt of even after say 5 or 10 years of development, while V was supposed to be a finished polished language from day 1? Just plain ridiculousness and clear bad intentions.
Xe/Christine never claimed V had to be polished on release. That's patently ridiculous. What they said was: the original features were not called out as being goals, so they took them as features that (obviously) didn't work. Those claims were eventually marked as "WIP" or whatever, which is exactly what Xe wanted. No one is claiming an alpha/beta doesn't have bugs, but V promoters like yourself claim any reminder of V's prior actions are saying that.
IMO, V has made great strides since the initial release, but none of Xe's claims were inaccurate. All Xe's first post ("V is for Vaporware") did was call out the website as being misleading.
Sure, people could see that it's a 0.x release and know it's an alpha/beta, but that's not the point! It didn't say that the features were WIP until after Xe's post. Compare vlang.io two days before Xe's post[0], and the day after their post[1] (notice the addition of "WIP" markers and a new paragraph about 1.0 above the fold).
It also doesn't help that any time a post about V comes up, people try to explain these things, but the author and people like you refuse to acknowledge it. What most people want is for V to admit the website was misleading at the beginning, but it is now a bit more clear. What we get instead are conspiratorial claims of brigading to destroy V. Unless people can point to some Discord or Reddit group that actually does conspire to destroy V, it's a hoax. As much as the author wishes, posting negatively about V because of its past is not a conspiracy.
And here we are again, like it's one the movies of Groundhog Day or Edge of Tomorrow, where somebody keeps hard pushing Cadey/Xe/Christine (and whatever other connected names) old blog posts to promote the website at V's expense.
V is an open source programming language. Of course the V developers and contributors are going to have continual discussions among themselves and then make changes to their goals, roadmaps, features, and timelines. To include make mistakes and have to do corrections. This should be common sense and understood, but apparently not, or least not when it comes to discussions involving the V language.
It's insanity to continually run through the wayback machine on any alpha version of a programming language's website and run around: "Why is there a change in this language feature?" or "But, you said the language would do this before." or "Why you changed the date?". What is more relevant is the present website and present version of the programming language, because things continually change and that's how development works.
In regards to your conspiratorial claims, lets check the previous posts:
1) Mst made a claim that somebody named Cadey was mistreated by the V community.
This looks to be false. Doubtful if anybody in the V community even knows who Cadey is. Furthermore, the "V community" is not in control of random blogs, websites, or posts on the internet or their content. If you are going to refer to the "V community" it needs to be at least somewhere officially recognized by them (like V's GitHub) or at least where one can prove they significantly congregate at.
2) The V creator didn't know who in the world Mst was talking about and asked for a link as proof.
3) This was then used as an opportunity by an odd account from 2010 (Neven) with only a few posts (really odd) to then re-push and promote upon us again the Cadey/Xe/Christine website.
Which drudges up 3 year old mostly non relevant crude, that nobody really cares about except V detractors that seem to get off on it, that is pushed on every HN thread involving V that I've seen.
Note- And it's such a repeating pattern, of what V detractors do (even without mentioning the downvoting, flagging, trolling, and gaslighting), that others are noticing it too. Among them, sph and johnfn, and check out their posts above.
I'd note that my attempt at "I'm not actually mad at you, but here's an explanation of why your current attitude is counterproductive" (with the obvious caveat I may've been complete wrong) got flagged to death rather than argued with.
Which is the original repeating pattern, I'm afraid :(
I don't really agree. V seems to attract a much larger than normal swath of people who enjoy trying to score points off of technicalities. e.g. people claiming the entirety of V is an unsafe language because they found a single bug in the compiler, etc. Languages like Rust never garner this sort of point scoring in the comments.
> as far as I've seen they are quick on the trigger in regards to banning or blocking people that they disagree with
Do you have any source for this claim? Without a source this simply reads as another person trying to sow uncertainty and doubt. I haven't seen anyone banned or blocked on Github.
That's because V already lied once about its memory management, see https://news.ycombinator.com/item?id=31947048. Any highlighting of that fact is met with deflection and dodging.
V is still making dubious claims: his newly invented autofree isn't stable even today after years and users are encouraged to use garbage collection instead. It's hard to trust that when we've been lied to already.
V is not 1.0, so why so bothered that autofree isn't stable enough? Especially if the person is not even using V. Clearly the majority of V supporters and users are not bothered, and are finding V useful to them.
Autofree exists and somewhat works (https://youtu.be/gmB8ea8uLsM), it's a matter of perfecting it so that it requires minimum user knowledge about memory management. You can enable Autofree and use it, but the user must understand what they are doing and reference examples of code and programs that do use it.
So in the mean time, the V developers decided to experiment with and select GC as an alternative memory management method. That should not be a problem for a language in Alpha, nor for anybody "outside looking in", that understands language development. GC usage worked out great for them and the users, so they made it the default. Autofree and manual, would be the other options that users can choose, but they must enable those.
Furthermore, other languages like Nim, have multiple memory management options. I don't see people on HN getting so hot and bothered about that, just for some strange reasons, they seem oddly bothered by V adopting and having multiple options (GC, Autofree, and manual) instead of one.
What? "After years and years"... It's version 0.3. Not even stable 1.0. The conversation you had with the maintainer puts you in a worse light than him, in my opinion.
He's already promised something too good to be true and it turned out to be a lie. From wayback machine https://web.archive.org/web/20190520021931/https://vlang.io/...: "(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."
I was excited for that. We were all excited for that. Then it wasn't true. I would forgive him but he seems to be continuing.
Then he walks that promise back, pretends he never said it and suddenly invents this magical "autofree" system but gives no details on how it works. Rust was never that secretive, it was based on published theory.
He claims it removes 90% of reference counting but if that was possible then Swift or Python or anyone else would have done it.
If it was based on solid precedent, or there was any research, or he published anything about how it works, or he didn't take donations, or it wasn't advertised on the website, it would be fine. But that's not the case.
Let me get this straight. Someone is running an open source project. They said they are working on some ambitious feature. Said ambitious feature hasn't materialised up to your standards, and now you feel like you've been cheated or lied to?
So are we saying that open source programming languages are not allowed to make changes to their goals, features, or roadmaps?
And if they do make any changes, then people should go to the wayback machine and hold them accountable to what was in the past, and not what they are showing and saying in the present?
Seems to be very unrealistic, and more of a personal grudge or pet peeve.
These aren't mutually exclusive. What isn't captured in individual posts about V is the historical context of previous discussions.
I think many people feel scorned or resentful towards the attitudes, which means they're more likely to speak negatively of it in the future.
When V was first announced, there was a lot of hype about "Volt": a cross-platform Slack app written in V (https://web.archive.org/web/20190315173156/https://volt-app....). It was slated to be released 'soon', but months went by and there was nothing. When it eventually did release, it was nowhere near as complete or polished as people were being lead on to believe. Same thing with V itself, and people were attacked for pointing this out.
There's a long history of over-promising or hyping things that don't exist, and not handling constructive criticism well. So there's a number of people who actively dislike V.
I think the problem initially was that people accused the creator of malice for no reason other than not being more specific about which features were a work in progress. I agree that it's not good to treat every criticism as an attack, but sometimes criticism of V (as an outsider, I've never used it) feels more like anger towards the creator rather than a helpful suggestion. For example, there's a difference between saying "I've found a bug in an advertised feature" and "You're a liar", which is how much of V's critics sound to me.
As you can see the website claimed that its compiler is "200x faster" than C compilers, while neglecting to mention that it merely translates V code to C, so you still have to
run a C compiler.
"400 KB compiler with zero dependencies" (apart from a C compiler and libc).
"As fast as C" - a lie.
Apart from deceptive marketing, there were serious issues with the code quality of the compiler:
>"As fast as C" is not a lie. It literally translates to C.
No, just because it outputs C it doesn't mean it's as fast as hand-written C. Using that logic, every language that outputs machine code is as fast as assembly, which is obviously not true.
If you look at the C that's generated using -keepc flag, I think you will be hard pressed to find any glaring inefficiencies to "hand coded C"; especially none of which GCC optimization wouldn't handle with -prod compiler flag. Even if there were, for the very large majority of users who are not highly proficient in C (which is becoming more and more common these days - Grey beards are rare), the V way is going to outperform novice to intermediate-skilled C programmers hands down.
FWIW, my view is that even the best programmers don't always have perfect non-programming skills and it is better to give them specific objective feedback via bug reports/technical comments etc and not focus on how they are not doing the expected thing or behaving in an expected manner. Focus on and encourage their good work if possible.
> However the attitude of the lead developers toward criticism or negative feedback...
I disagree about that, because there is a major difference between submitting a bug or disagreeing about a claim or feature versus outright trolling, smearing, instigating drama, or trying desperately to create negative public perception.
Issues and discussions can be brought to V's GitHub (https://github.com/vlang/v/issues, https://github.com/vlang/v/discussions), but instead what various competitors and detractors do is create drama filled smear blogs or bad joke posts (on various websites) against the author or language. That's not any attempt at being helpful or constructive, that's more about slander or to create such negative sentiment in the hope of killing off the language.
When issues and discussions are brought peacefully to V's GitHub, they are discussed and debated intelligently. If any such issues have any validity, then they are usually fixed.
> Everything negative that people say appear to be taken as an "attack"...
That's simply not true. What does happen, is various competitors and detractors do specifically attack and smear the language or author, and who have no intention to want to be helpful or make any improvements. To include engaging in downvoting or trolling those who appear to be V supporters.
Such attacks and smears are not about fixing anything, their point is to be destructive, create negative publicity, and dissuade others from using a rival language.
If there are those that don't think that is the case, then simply ask yourself why many of those engaging in such attacks and smearing who claim to be technically knowledgeable or interested in using the language are not making their case on V's GitHub? That's where a person can go to improve V and get it production ready. Continually engaging in smearing is not about fixing, improving, nor reaching out to V's developers or community.
This is a big one. 5769 commits pushed to master, 1697 bugs closed. The highlights of this release are C2V, a fully automatic C => V source code translator, closures, and no more memory leaks by default.
The "autofree" memory management [1] seems quite interesting, and a very cool mixture between garbage collection with static memory management. Has been there been any seminar / conference talk held on this topic related to the pros / cons of this approach vs a pure GC memory management strategy, since it seems like it could be used in _almost_ all modern GC languages.
I tried c2v on some very simple commands in freebsd /usr/src/bin/ such as ls and pwd and it failed. Still, very good to see this progress! May be you can add some FreeBSD commands to your test cases?
This is why I don't believe a word from the author. I don't even know if the demo is actually translating it or a demo of how he wants it to work. I have no idea if 90% of it is hand translated (SDL, some complex routines, etc) with the easy 10% actually translated.
Or maybe 100% of it isn't translated but compiled to object files with a compiler with V generating wrapper functions. I have no idea what to expect
I just never heard of anyone using V and it actually working as they expect
So you are commenting on something about which you have no direct experience, nor are you planning to change that. Why even “bother” repeating something you may have read or heard; why not just stay silent or learn something new?
My original comment was confirming to a poster that other people experience matches his. I never asked a (non rhetorical) question here or said anything untrue
This isn't a criticism, but what's the purpose of using c2v? As in, anything outside c2v just to compile it. The example of DOOM is taking the C code, converting it to V, then compiling it (which internally converts V to C before passing it off).
Generating V wrappers on top of C libraries in order to use them. Otherwise all functions and types would have to be manually converted.
Migrating older projects from C to a nicer newer language.
By moving from C to V you get rid of complex makefiles, headers (you get nice clean modules instead), you get a modern stdlib with strings etc (although C strings aren't converted to V strings by C2V yet), much easier cross compilation, etc.
How do you handle function-like macros and concatenation? Also, both D and Zig seem to have switched to including a full C compiler instead due to issues with translating C source wise, is that a possible direction for this in V or is the source translation good enough?
For libraries this can be useful if it means that you don't need to deal with a separate C toolchain in the build process. Instead you just bundle a copy of the library transpiled from C.
If it works, devs can move to a safer language for future development of the project. Anyways, code as a sacred artifact perspective needs to go - by that I mean, having tools to modify/convert and answer questions about code much more easily. May be with AI that would finally be possible.
Thank you for digging!
I really appreciate your attention.
There are lots of bug fix in 1 year, and will be better time by time.
I started to use Vlang 1 year ago, and I created lots of ISSUES on GitHub, and most of them are already fixed.
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.
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.
V minor contributor here.
My 2 cents: I do get the feeling claims were founded/solid but am not an expert on the subject.
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.
> For what it's worth, every GitHub project has a mechanism for submitting issues. It's better Open Source spirit to utilize these tools as intended.
Are project issues the right place for reviews of claims? Negative point sure would be nice to have as github issues (and checking for some easily searchables: they seem to exist [1,2]) but many of the points in the review don't suite issues well. I don't think "you can open tickets" would be a useful response to "wat" [3] either.
Alternatively your suggestion was for me to wade through the issues to figure out if the critizism holds, which I find is not a helpful suggestion either, as many of them are not particularly well searchable. Also, I assumed, as the review got a bit of attention and the creator was in the thread, it would lead to an interesting response a-la "we are aware, fixing it, many fixed already, here is our roadmap" with possible discussion. I am a bit saddened that it turned out to be much more hostile and negative.
The post’s example of undefined behavior via signed integer overflow still holds in current V master.
$ cat test.v
fn main() {
x := i32(2147483647) + 1
println(x)
}
$ ./v version
V 0.3.0 f0cee25
$ ./v -o test.c test.v
$ cc -fsanitize=undefined -Lthirdparty/tcc/lib -Ithirdparty/libgc/include test.c -lgc
test.c: In function 'main__main':
test.c:12073:37: warning: integer overflow in expression of type 'int' results in '-2147483648' [-Woverflow]
12073 | int x = ((i32)(2147483647)) + 1;
| ^
$ ./a.out
test.c:7577:33: runtime error: signed integer overflow: -2147483648 - 2147483600 cannot be represented in type 'int'
-2147483648
That V code has compiled to this C code, which is indeed undefined behavior.
VV_LOCAL_SYMBOL void main__main(void) {
int x = ((i32)(2147483647)) + 1;
println(int_str(x));
}
“If you need the value to be modified outside the function, use a reference. Warning: you need to make sure the reference is always valid, otherwise this can result in undefined behavior.”
So it shouldn’t be surprising that people call out the “No undefined behavior” claim on the home page as dubious.
> What's wrong with the division by zero issue? It works just like in Go?
As I understand it, V's emitted C code (in release mode) does not handle the possibility of a divide by zero. As such, according to the C spec, you've now entered territory where literally anything could happen depending on how the compiler or platform is implemented.
Go, alternatively, detects a divide by zero and panics (like V does in debug mode) which will consistently occur regardless of compiler or platform because it is defined behavior.
In the case of the user in the issue, he got a SIGILL but other OSes, compiler versions, architectures, etc. could result in some other outcome entirely.
I'm not familiar with where V is ported to, do all the supported platforms result in the same behavior?
I disaggree [1] with your claim that all issues have been fixed, but maybe I misunderstand what "No nulls" means and other things.
> What's wrong with the division by zero issue?
It is undefined behavior in C. [2] section 6.5.5 the 5th paragraph. V generates code that is undefined behavior in the intermediate language, some people might consider that "undefined behavior".
> It works just like in Go?
I read this argument in the issue too. How is that remotely relevant?
> What about the openssl issue?
I linked issues of things that were mentioned in the initial review. Not issues that were problematic, remarkable or anything else.
Not the parent poster, but there seems to be some misunderstanding. The GitHub issue creator explained that they're getting two different behaviors depending on C compile flags. That's already not "the same behavior as Go" AFAIK.
> What kind of behavior do you expect?
Defined behavior, I assume. If V uses C as an intermediate, and the generated C code invokes undefined behavior, then V can not guarantee "no UB" in that case at all. It is completely up to the C compiler what happens. Even if the compiled app behaves "properly, like Go" with the specific C compiler, with the specific flags, on that specific machine, does not mean this behavior is defined and consistent.
> What's wrong with the division by zero issue? It works just like in Go?
In fact it does not work like in Go, and that's the entire point. In Go, division by zero is well-defined[1]:
If the divisor is zero at run time, a run-time panic occurs.
As pointed out by others[2], divide by zero in C is in contrast explicitly undefined behavior. So the statement "it works just like in Go" is false.
It may do the same thing as Go on your machine, with the C compiler you used on the day that is today. But the fact remains the generated C code produces undefined behavior, and thus this happy accident of yours is entirely irrelevant.
What makes this extra egregious is the fact that "no undefined behavior" is listed as a key feature, and that the relevant issue[3] was closed as wont-fix.
Now, there are several ways to properly fix this.
One is to keep the current behavior and change the wording of the key feature listing to remove "no undefined behavior" or modify it to something like "no additional undefined behavior compared to C".
Another way would be to clearly define the behavior of divide by zero, similar to how Go did. The V transpiler then has to generate extra C code that ensures this well-defined behavior, for example by inserting a check for zero. This should be in place before 1.0 release at least.
Sure, will do. However I can't help but feel a large majority of the posting on anything V is mostly flame war and personal attacks which is far more egregious than commenting on votes, and against the guidelines you linked.
Yes, the topic is lamentably flame-prone. I've been trying to persuade some of the key commenters not to handle it that way.
HN moderation is necessarily inconsistent because we can only read a small sample of what gets posted to the site. If you see a post that ought to have been moderated but hasn't been, the likeliest explanation is that we didn't see it. You can help by flagging it or emailing us at hn@ycombinator.com.
The claims made in that blog post are easily verifiable. Your claim that all issues have been fixed was hard to believe, so I checked myself. The first two have indeed been fixed (these involve printing "nil" for a null pointer rather than crashing), but the third (undefined behavior on integer overflow) still reproduces. I didn't go through the rest of them, but expect a similar pattern.
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.
Thank you for posting such a beautiful example of a false claim about your language.
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.
Your website says on the homepage "No undefined behavior". Integer overflow in C is explicitly undefined behavior. What does the phrase "undefined behavior" mean to you? Because it's clearly something very different from what it means to the rest of the industry.
I think there's a communication issue on your end here.
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 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.
Hey, I went through another one of the examples, the lack of SFINAE, here's how I tested: I used the same methodology as the linked blog post. I'm getting the same compiler error as the blog post. Are you able to reproduce this?
So, the review was my only contact with V until today, and I have to say your response seems unnecessarily hostile. I understand there night have been a lot of negativity around your project and it seems to be successful despite these, so nice for you.
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.
The post is unnecessarily hostile. Created by a new anonymous account, with the goal of attacking V and "not recommending to use it". Also with referencing the notorious ridiculous "V is vaporware" articles, it's pretty clear what the goal of the author was.
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.
This is all around a terrible and nonconstructive attitude.
> 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.
> 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...
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?
>It'd take 10 minutes to submit github issues, instead they spent a month on this.
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.
I think you're missing the point here Alex. The amount of work you've put in, the number of projects you've made, and the drive you have are amazing. Everyone wants you and V to succeed but you make claims that are not true yet. You claim V has safety features but if it's trivially easy to exploit those safety features, then you don't actually have safety features. You claim V is as fast as C but there are many many many cases where V is slower than C. On average, V seems to be much slower than any compiled language. You claim V can compile a million lines of code in a second when that is not the average case. You claim V can do so many things but each time someone actually tries to verify those claims, it turns out there are many cases where it's not true or only true in one very narrow, specialized case.
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.
> You claim V is as fast as C but there are many many many cases where V is slower than C. On average, V seems to be much slower than any compiled language.
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".
Slightly off-topic but this whole thing made me curious.
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?
IMO, it's pretty simple. At the beginning, V was making huge claims that turned out to be false or misleading. The developer clarified that many of those features were actually goals. Fair enough.
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.
Yeah he was the first to call me a scammer and claimed V had a dependency on glfw.
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?
Can you provide a link for that quote? I want to read it in context, and my attempts searching the web only brings me back here and another place with this quote without a reference. Thanks!!
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.
Don't think was an apology. I find it dubious Zigs README on GitHub reads "never to exploit them financially". What a weird comment... Notwithstanding the whole readme comes off like a weird socialist manifesto.
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...).
You posted lower down asking to be called out for specific behaviour that people find objectionable.
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.
I’m really sorry you feel that way; I honestly respect the work you do and I’m convinced you’re not correct about this… but hey; you’re deeper into it than me. Maybe there is? I don’t know.
…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.
I think you don't fully understand or know of the scale of the attacks and trolling carried out by detractors and competitors. Which includes hiding what they do and their true purposes, and attempting to instigate and influence others to perpetuate attacks, drama, and smears for them. There is also the gaslighting whenever people recognize some of their actions, recognize their throwaway or troll accounts, or against attempts to call them out. This includes doing such on other websites, not just HN.
I don't know you, but I think you should PR-manage the situation without being confrontational. Writing a blog post about it just invites the trolls to write an answer!
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.
It's funny because in the previous discussion I got lots of "what's the problem? fix the bugs and publish your own post going through the points in this one".
I think it’s OK to write a blog post about your progress, with a positive attitude. A very different thing is to write a blog post refuting a troll. “Don’t feed the troll” is as old as the internet.
I sincerely hope you reconsider posting it. Even if you're a 100% right from your POV, it will still give off a negative energy and hurt your project. I think @wokwokwok has a good point, why not just focus on fixing bugs and building stuff instead?
Because these articles are meant to stay for years.
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.
I do understand that that must be frustrating. What I don't understand is why you think writing a blog post about it will have a positive effect on your project.
Hey.... even if people are attacking V-lang, don't worry. Any good thing that disrupts existing "kings" gets thrashed initially. That's human behavior. Ignore it.
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 made that claim a couple of weeks ago, somebody investigated your claim, it turned out that you were grossly distorting the actual comment when paraphrasing. And given you continued to be active on that thread, you're clearly aware of this. Why continue spreading the lie? At this point you can't even claim it was an honest mistake.
Yes, it's very different. Xe is predicting that V will die in obscurity, and recommending that people ignore it due to that prediction. Look at the second half of that comment:
> 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.
There are things that are actually vaporware. It is reasonable and normal for people to actually say when they believe that something has a lot of signs of being vaporware.
Are there really, truly no tools that you personally recommend against using?
> There actually is such a conspiracy. People who wrote these articles literally wrote they wanted V to die.
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.
We cannot know what the blog author was hoping for, we can only know what they wrote. And what they wrote is not anywhere near what amedvednikov repeatedly claims. Why are you ok with such blatant misrepresntation? If this conspiracy actually exists, isn't there some evidence that actually stands on its own rather than needing to be lied about?
It doesn't. But there's a more important point: you're paraphrasing somebody you clearly have a great deal of personal animosity toward, completely changing the meaning in the process, and with no indication that this is what's happening. You've continued doing that even when it's pointed out to you. There are two options I can see:
- 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...
While wishing V would die is extreme, many people are just resentful about how V treated criticism in the beginning.
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 coordinated efforts on discords to brigade such threads, there are entire new accounts created just to reply to each of my comments negatively (luckily just today HN banned such an account), this very post about V 0.3 was mass flagged 3 times and removed from the front page 3 times, there are articles that take a simple bug fixed by a 3 line commit, and make a huge deal out of it spending a month writing an attacking post. Who would spend a month to write an article about a type checker bug?
> Who would spend a month to write an article about a type checker bug?
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.
Simply, V is very divisive. So, some people who peruse HN but don't have an account will see a V post, and make an account just to comment. Humans are just irrational.
There's definitely trolls; I wasn't trying to imply otherwise. There's always going to be people who think your project is stupid, and it'll only get worse as the project grows. I think the best solution is to just ignore them.
It's great you're level headed on this. As an indirect measure, I've perused the Discords of competing languages and the vibe is a world apart in terms of maturity, age group, topics (bullying is very prevailing, talking politics rampant, excessive anime) - essentially unmoderated reflections of character. So it's no wonder that if that's the community forged behind the scenes (in those competing languages), that it's going to bleed out and become issues elsewhere - and V is one such topic that seems to be commonly targeted by those groups.
It's because V made impossible promises, and used those to get donations.
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.
V backer here. I've never ever felt remotely scammed or deceived. So people who bring up the scamming topic can continue to do so with the imaginary money they did not pledge/donate.
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.
Your claim of "(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." was absolutely a lie. That's why you had to eventually fall back to reference counting.
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?
V has "enemies" because that's how they respond to people giving them constructive criticism and questioning their claims. Most authors would relish of thorough technical analysis of where their issues where so they could improve their new language and compiler, but not V it seems.
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.
Completely not true. We welcome criticism and feedback, we even have a topic with 800 messages called "What don't you like about V / what would you like to be changed?"
Out of curiosity, I checked the discussion in which you referred to by link. The person in question is not a developer or contributor, but appears to be passionate about the discussion. I don't think it's bad to have a difference of opinion, even among good friends. In addition, we can't always be right on every issue, and sometimes we have to "agree, to disagree".
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.
Just like work, and in life, you're going to come across a myriad of people who handle criticism in different ways. Be it for cultural differences, deductive reasoning differences, even down to childhood upbringing, you know the story... We all do. It's 2022.
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.
The "nothingburger" you quoted is a single word you took from a reply chain in which amedvednikov explained the 800 byte "memory leak" was actually just GC overhead and expected.
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?
>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.
I think the highly aspirational nature of the claims about V upon its original launch are why it attracted so much scrutiny. It claimed to do a lot of things and didn't clearly separate things that might be delivered in the future from those that would be features present in the language today.
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.
If you look at other posts in this thread, you'll see that this review is completely irrelevant since the bugs it complained about were fixed in several 3 line commits.
I won't pretend to be up to date on your language and what is fixed or working, but if it was so easy to fix these bugs that were apparently so trivial, why weren't they fixed before announcing / releasing the features? Even just communicating that a feature isn't done yet and may need a little more time (e.g. a beta tag) would go a long way in rebuilding trust with people outside your community.
Meanwhile, defensive reactions like those I see in and around this thread make me feel like I trust you less.
As I said in my previous reply, you're more than welcome to stick a beta tag on something that isn't ready for prime time yet. Take a look at Rust and their releases as an example of the ultimate in building a stable foundation that people trust.
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.
> Though you may just be asking somewhat rhetorically to probe for a response from a supporter
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 :)
> 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
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.
> You might want to look into the very dodgy history of the language. The negativity is not surprising.
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.
Look, I'm not hostile towards the initiator or the language. I'm happy to give V a chance in the future.
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'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.
> People developing other languages and their communities didn't like it, and decided to attack it.
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.).
There are 0 false claims about language capabilities on the website or in the docs.
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:
Saying "no undefined behavior" when what you really mean is "We define our language's behavior to be the same as C's" (in other words, you just punt undefined behavior to the C compiler) is deceptive at best. I'm specifically thinking of signed integer overflow here, but that makes me think there may be other cases as well.
You said there are false claims about language capabilities, I asked you to list them. It's a reasonable request. I don't want to have false claims on the website.
In my opinion, the current documentation on the autofree engine [0] constitutes a false claim about language capabilities:
> 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, 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("")
}
}
I compiled this with -autofree -gc none, with V 0.3. Checking it with valgrind, it continuously leaks memory.
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.
So, to be clear, is the intended reading of the documentation as follows?
> 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.
Okay, I really don't understand what you're saying here.
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.
Autofree exists and does work (https://youtu.be/gmB8ea8uLsM), however, it doesn't work where a user can have a complete lack of understanding about memory management like various GCs do or have never used it before. Autofree, as it is, also requires looking at examples of usage in various programs.
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).
I understand that autofree is WIP. I read that part of the docs, and I have watched the demo.
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.
When a person new to V reads the documentation (which they should be doing), they would also see the following.
"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 seems we are essentially in agreement on how the documentation is meant to be read, which is that the points it makes about autofree are not meant to be statements of fact.
Not exactly, because what I'm saying is that the V website and documentation is explaining what autofree does, describing what autofree is, and how it works.
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.
Should the null hypothesis be that all languages deserve equal praise & blame and thus equal amounts of negative & positive critique?
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.
> ...it feels like V really brings out the people to come up with ways of criticizing it.
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.
> Basically, do you have any guesses to why V seems to have more "enemies" out there, compared to lets say Rust or Go?
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.
I've been following vlang's GitHub issues lately and it feels like every second issue is about broken codegen in areas which seem so basic you wonder why it was even merged in that state. So I have mixed feelings about this. On one hand, the list of features/fixes is impressive and there's a growing community, and even a book, on the other hand there are endless edge cases which weren't properly thought out/tested and which break the compiler. Maybe vlang needs some sort of fuzzing?
Right now on the very first issues page 5 issues out of 21 (if we skip feature requests) are about broken codegen (i.e. C errors). I'd expect a stable implementation to have very few codegen problems, not like this; I'd expect something like subtle correctness issues or various bugs in the standard library to be much more common (larger surface area).
Passing a variable to a function works, but passing a string literal doesn't. I wonder why stuff like that even happens, it leaves an impression that the compiler has hardcoded special cases internally and breaks on input which wasn't foreseen by the implementation authors. Your solution is to get rid of the method entirely instead of fixing it, which is also somewhat strange to me. Can you explain?
>Interesting. I have always felt the opposite. It's always been stable for me
It could be that the patterns you use when writing V code are well-tested but when someone strays from the path and does something you wouldn't do when writing V code it easily breaks the compiler.
Are there plans for docs to be updated? The 0.3 release notes claim:
> Option and Result are now separate types: ?Foo and !Foo respectively. Old code will continue working for 1 year and will result in a warning/hint.
Yet, doc/docs.md still states:
> V combines Option and Result into one type, so you don't need to decide which one to use.
Is there an up-to-date doc, or how does one find out more about these types? I found parts of the RFC overhauling the error handling [0] pretty bizarre, so I'm interested to see how the implementation turned out.
Combining them in general makes sense to me, at least to the extent of having an Optional<T> be an alias of Result<T, ()>.
There are some obvious cases where a none optional is separate from failure, like a hash map lookup or an element from an iterator. But I often also see optionals used to signal e.g. an unparseable string, where it would seem equally reasonable to return a Result or throw an error.
I’ve been writing a lot of Swift lately, and because it uses `throws` rather than a Result type, it’s made the often arbitrary choice of returning an optional value or raising an error more noticeable to me. Especially when using `async`, as pretty much everything declared `async` also throws, so if an Optional is actually what you want to return, you get some fairly gross boilerplate at the site of use:
guard let value = try await getValue() else { … }
This has turned into a bit of a ramble but my main point is that implementing Optional as a Result with void error type makes a lot of sense in my head.
I've had my eye on this language for a couple months; in particular, V UI subproject, a SwiftUI-like code-first framework for doing GUIs, caught my eye, since I rather like SwiftUI and I still need to make a human-friendly KyuWeb client for the server to be of any use. Unfortunately V UI doesn't seem to have progressed much since I last had a look on it. Here's hoping it gets the attention it deserves, because from what I've researched of GTK, it looks about as fun as a kidney stone to use, and having a modern low-level language with a closely-integrated, cross-platform modern GUI framework could really put V above the rest (SwiftUI does not have first-class support outside of Apple platforms currently).
Wow. Despite a lot of the negativity here, V looks great. I might take a stab at writing something over the weekend with it. Congratulations on the release.
Lovely language, but above scares me off for now. Respect to all involved and hope one day will be a day where there will be only a super sophisticated bugs left that affects 0.01% of users.
Before using V I had a similar concern. However I then looked at Go and see it has 7.5k issues on GitHub. Granted much bigger user base = more stuff uncovered.... So for right or wrong, 7.5k issues in 100K stars versus 750 issues on 30k stars... It doesn't look so crazy suddenly. Personally I like to see issues as it means people are actually using the language, finding bugs, and driving incremental improvement.
A project with 0 issues barely indicates flawless implementation no more than the possibility it simply has 0 users.
I'm using V mostly for data science related applications (in production). Honestly my biggest fear is that this constant V backlash is going to do serious harm to the community and seriously impede development/adoption... I have no concerns with the language itself or the development thereof - only the consequences of threads such as these, which surface every other week. I entered in with realistic expectations from something that is version 0.3; unlike others who seem to think version 0.3 means "Mars lander ready".
I think V will persevere, because the community has enough support and momentum to continue, and because the direction and syntax of the language will continually attract as well.
Even the outrageous trolling and harsh criticisms also brings attention and curiosity about the language, that other developing languages can't and don't get. V will stay in people's minds and on their lips, keeping it popular. Many critics will say one thing, but will also be trying and using V, and it has been the case they become contributors to the language or are eager to see its next release. As the language makes corrections and continually improves, it's "baptism by fire", will make it even more viable and useful upon each release and in the long run.
TBH, I have criticized V before, because when it launched things and claims were weird and maybe inflated, honestly don't quite remember looking at V in a good light is still hard for me.
But I am willing to give it a try, so here's a shot.
Can you pls, explain a few things in short really don't want to read all of the docs to figure out the basics.
1. What platforms are well supported by V and how does it work non traditional or extension based C code?
2. What happens for edge cases where the C compiler quirks are being used for code when you transpile C to V?
3. How safe is V really? Like is it memory safe, if so maybe a quick description as to how, does it provide a memory model? What about an ABI? does it match the platform C ABI or something?
4. What happens to linking to C code, is it as easy as Zig? maybe something like zig cc?
5. How is the multithreading in V? Does it have something like openmp atleast something like rayon or do we use platform threads?
6. What about the C++ interop? anything interesting more than what other languages can do?
7. What's the current state of the compiler in terms of stability? And especially the std lib?
8. Lastly anything you want to point out as a very interesting feature in V that is not hype but so comfy that I would like to atleast use V somewhere in my stack? Maybe something like Zig's cc or Nim's metaprogramming or Haskell's mind bending type system, Idris's dependent types, etc.?
Preferrably not like Rust's safety thing, I love Rust but just saying things like it's safer is very weird claim without any context. Just some details are fine no need to waste your time on making a hater change their mind.
Personally I am trying to keep open mind to things, I might be harsh because of ignorance or preference or just because of being a young douchey programmer but being mean to something that has stuck around, and where a bunch of people seem to be putting in effort somehow seems worse than just shitty on it, even if it's a scam.
2. For stuff like i++ expressions, V allows them. Some stuff gets translated to adapted V code. Some (~2% of the syntax) will result in an error. Those will be fixed this year.
3. Memory safe, bounds checking, C ABI.
4. Ridiculously easy. The main reason it was created (was using Go before). Just run `C.foo(1,2,3)`. Use C2V to generate V wrappers.
5. Only system threads for now.
6. Same as with C. Need export "C".
7. Very stable, at least for me. Never had a crash/segfault.
8. Hard to pick. Fast compilation, hot code reloading, nice clean sum types, clean json serialization and ORM (mysql,sqlite,postgres).
Fixed the formatting, reading the docs takes time and in case of languages they don't give a lot of critical information about it's state in the docs, I have worked from Haskell to Rust to C++ professionally never has the language docs told me all the key details about the language to make a selection I was only able to get into them after months if not years of trial and error.
I am not gonna pretend I have any love for V, but I will say I might look into it but spending several months or years with the language when I have such limited free time is not an option for me and many others.
I fixed the formatting so it should be more clear as well. If no one wants to answer then fine I didn't ask the questions to get a definite answer as I said I am not entitled to an answer I just would like to know those things.
I can wait for V to one day take over the world, die off, or someone to just make more fun memes. I don't really have a dog in this fight.
With 30K stars on GH, I feel late to the party but Vlang looks amazing. Given this is the 0.3 release, it's almost shocking how much has already been achieved.
The comparison page was very useful to quickly get a feel for V's "aesthetic" and design goals: https://vlang.io/compare
Which ones? The positive ones or the negative ones? I posted one of the positive ones.
I've been following V with interest for a while (a few years, maybe?). It got a lot of shade early on, somewhat justifiably-- the initial claims were highly suspect. Past V comment threads on HN leaned very negative.
That said, I like V. I'm glad to see the maintainers are still chugging along despite the criticisms. It gets better with each release.
I'm still not doing anything in production with it, as it's pre 1.0, and the Postgres performance issues are still a blocker for my production use-cases. But, I really hope to someday have V in my toolbelt for the places where I currently reach for Go.
Great job with the language. I’ve always found the controversy quite interesting. You know you’re doing something right when everyone attacks you. How did you get GitHub to support V just one month after release?
Can I suggest: On your github homepage (https://github.com/vlang/v) you should put some sample code, I scrolled all the way through it and did see anything.
Also view the Docs link just below the V logo, on the link you provided. It's true quite a bit of projects these days put sample code in the readme... But it probably isn't where code examples belong. Certainly wasn't the trend in 90s or early 00s.
I'm curious about the status and/or roadmap of REPL for vlang? Do you plan for an expressive experience with the REPL, like in interpreted languages (python, ruby...), or it just compiles each line?
I find it funny that as soon as you [0] asked someone to list these major bugs in V especially when it turned out that they haven't used the language, they begin to continue their regular deflection and dodging of the question.
It is a pattern I keep seeing here on HN, but its great that V hasn't given up and it is still active and maintained. No idea why this post was flagged.
Wanna know something funnier also posted in previous thread? The hello_world.v has potential memory leaks. I tried it myself and got a similar result. Somehow the creator cannot reproduce this.
==57519== LEAK SUMMARY:
==57519== definitely lost: 0 bytes in 0 blocks
==57519== indirectly lost: 0 bytes in 0 blocks
==57519== possibly lost: 816 bytes in 3 blocks
==57519== still reachable: 0 bytes in 0 blocks
==57519== suppressed: 0 bytes in 0 blocks
"Probably" doesn't cut it if someone is going to user your language. Let's agree that this isn't a serious matter though. The compiler leaking is nothing as well?
My post wasn't about this concrete issue, which can also be explained.
My point is about a civil discourse culture driven by (precise) technical arguments,not hostility or deflection. Which I am not seeing, which is why you only increase the skepticism here rather than change minds.
Unless the leak was actually unintended and is a bug.
But that's also fine, any language (old or new) has heaps of bugs in all corners of the codebase. But then just own up, explain and fix it.
To my defense the GP to which this was answer to led off with
> I find it funny that as soon as you asked someone to list these major bugs [...] they begin to continue their regular deflection and dodging of the question.
which I found dishonest (especially since those bugs are well described in the post the commenter linked) as the exact opposite happened in the same thread.
Why is this a nothingburger? If you're making the claim that it's safe and it actively leaks memory, how do we know it doesn't also allow buffer overruns or double frees?
It would be nice if you allowed an option to compile with memory tracking so that as a user of the language you can debug this sort of stuff to make sure it's not a big deal waiting to happen.
You do not engage with criticism in good faith. This is a reoccurring problem in all your threads. This is why you get down voted and flagged. It's not a conspiracy against V, it is your own behavior.
I'm not even sure what to say about thread, you got all hostile on someone who was basically on your side because the blogs post you hate made him think something that you yourself agree with which that V is not production ready?
This person might have come back to check out your 1.0, but I doubt they will now! https://news.ycombinator.com/item?id=31930435
And just the level of cognitive dissidence here. Why are you mad about someone calling your 0.3 not production ready software immature?
It's interesting how you can call the language immature without even trying it.
0.3 pretty clearly means it's not production ready software.
I'm not even that far back in your comment history. That's all the free emotional labor I'm willing to do for you today.
Edit: Also I don't want to be the tone police, but I stepped past a lot of comments that seemed to run afoul of the "it's not what you said it's the way you said it" rule. My last piece of advice would be to read through your comments and ask yourself if the tone of them is best for achieving your (I presume) goal of promoting V.
It's interesting how the language author of V was bullied and harrassed for his early language [0] and with time V has made very substantial progress with C2V [1], and an OS written in V [2] and various language improvements.
This (and many future updates of V) has now rendered pretty much most criticisms in this attack post irrelevant, after all of this V is gaining traction, a community forming around the language and with great backing, It goes to show that programmers are far too quick to jump the gun on languages.
Yet we see this harassment continuing on this thread. The article I linked is just a drop in the ocean.
Nitpicking over leaking bytes and language features every release is exhausting for the language author when we both know these will be fixed in another release.
The fact I see activity in language and that the author is active gives me confidence in V.
> Yet we see this harassment continuing on this thread. The article I linked is just a drop in the ocean.
Which comments on this thread were Xe Iaso's?
> Nitpicking over leaking bytes and language features every release is exhausting for the language author when we both know these will be fixed in another release.
I don't know what will be fixed in another release. Nitpicking to you was useful to decide if V was worth my time now.
You said Xe Iaso bullied and harassed the V author. I said the articles weren't bullying and harassment. You said this harassment continued. Did you mean you were wrong about Xe Iaso but other harassment started?
> The harassment is still continuing on this thread
I saw little or none. I understand it feels like harassment when someone believes their critics are conspiring and malicious.
Yes, it did, it is bullying and harassment no matter if it was past or present. I would also go to say it is pretty much toxic behavior as well, and yet it is still continuing on the V author by others in this thread.
> I saw little or none.
I've assumed you read the comments against V in this thread and it seems like you clearly haven't.
Also, you're not the person being harassed about memory leaks after the author said this was fixed already.
Hi, I'm Xe Iaso. I'm never going to write about V again. I'm only keeping my old articles up out of a desire to not break links. Even if I took it down, it's still in the internet archive's wayback machine, so there is no point in me removing my articles.
If the V person unblocks me and unbans me from the places I've been banned from (at least Twitter, GitHub and Discord), I'd be happy to add a disclaimer about the post being "out of date".
I want V to succeed because competition is good, but I also need to call out misleading statements for what they are.
Believe what you want, but I did not write those articles in an attempt to "smear" or "defame" V or its team. I regret writing these articles as they have created negativity and hate that is slung around like candy for no real reason. I have no plans to write anything about V on my blog in the future and this experience has taught me many things about how to write about programming languages in the future.
Except that it's incredibly hard to search for if people just call it "V" and not something like "vlang". I was trying to search for a thread I saw about it on Twitter and failed miserably, even with the "posts by people you follow" filter, because all the results were about various "X v. Y" court cases.
Well, how do people google for C, or D, or R? Normally with a query like "d language", right? And indeed, googling for "v language" gives me vlang.io as the first result.
I intentionally didn't use Google as an example. Major search engines obviously have tricks to index things like this, though I'll note there are still gaps. For example, googling "v language data structures" produces nothing related to V itself.
That said, I'm specifically talking about trying to search things that Google doesn't index, like a Discord server, an internal wiki, or a specific non-textual filter on a public site. As mentioned, I tried searching for a specific Twitter thread about V from people I follow and didn't find it because they just called it "V", which on Twitter returns a ton of results for things like court cases.
I'm sure if I spent forever massaging my query I could track it down, but if it was called "vlang" or "VL" or something similarly distinct it wouldn't be a problem. For example, PHP, Perl, OCaml, SQL, Prolog, etc. are all quite easy to find regardless of where and how I'm looking.
Feels like so many great languages are coming out at the moment, or at least I'm only just learning about them. Though a language that can be learnt in an hour and has the speed of C might just bump this one up to the top of my todo list
Or, if you like to see the world as a playground for collaboration rather than arena for competition: V is slowly becoming yet another language to play with, together with Rust and all the other fun languages that are coming alive
VLang is genius language. It's less boilerplate than Go, safer than C, simpler than Rust, and it's fun to use. Waiting for a Monad tutorial in V, ahh no, it's built-in.
VLang is the best language to me now to develop server-side application.
The responses I've read by the devs are in stark contrast to what I've seen in other languages I use, such as Rust. I hope that as the language evolves, the developers will start reflecting on the way that they interact with others and how it impacts people's view of V. I could never justify using a language like V in production if I couldn't even trust the lead developers to be level-headed during criticism.
I'm sorry for ranting, I really wish the best for V and its maintainers.