I'm a tiny bit worried by the way they are pushing development of so many products not directly related to core language development (a GitHub clone! A kernel!) and not focusing on creating a proper compiler. Maybe they are fine with leaving V as a transpired language indefinitely, but I think that developing this extra stuff is not going to persuade users to switch to V. With that being said, it's quite possible that the core maintainers aren't touching the extra fun stuff and are still focusing on language development.
Maybe someday I should try learning V again. I was going to learn it over the summer of 2020 to expand my repertoire beyond C++, but I gave up fairly quickly and ended up learning Qt instead, which has proved to be a very wise choice - knowing Qt why I have my current job (for multiple reasons).
Why? Correct me if I’m wrong but this language has literally no unique attributes that would make it different than D or Go, so you won’t improve as a developer from it at all.
Not trying to dissuade you from it, afaik most of the initial false claims have been debunked and now V is a real thing, but what is left from it is.. really not that interesting to my eyes.
> this language has literally no unique attributes that would make it different than D or Go
I'm not familiar with D, but compared to Golang, it seems to have a bunch of goodies compared to it. Small list: immutability by default for lots of things, no null, small and fast compiler, "4 ways to manage memory", hot code reloading and repl.
These are just the ones I could find on a quick skim, I'm sure there is more.
> Not trying to dissuade you from it
You are literally saying that it's not "interesting to my eyes" but then before that you say "you won’t improve as a developer from it at all", how is this not trying to dissuade someone?
Let me preface it: go is a thoroughly uninteresting and in my opinion bad language from a PL perspective - it demonstrably failed at many things we have known for 40 years before it.
Adding some of that back to V only “fixes” where Go went wrong, so I would need something additional on top to consider this language.
If your language is too simplistic, essential complexity will just live in your ad hoc program instead, which is objectively worse. Especially that you will realize it later that you are missing some core utils and have to patch it up (e.g. generics in case of go).
There are dynamic languages with zero compile times, but Java builds just as fast for me as Go and it is a much more expressive language than Go, which is a shame.
Uh, C is not really small nowadays. ISO C specification is about 200 pages long even without all the library. (It's hard to compare directly, but Go is probably around 50~100 pages long when formatted similarly.) C could have been small enough, but ISO C is not.
Also, most of what? Besides OSs, tiny tools, DBs and embedded, C is not used all that much. Where truly high performance is required, the de facto language of choice is C++ (see e.g. browsers) and business applications (which are the most numerous) are definitely not written in C in most cases.
Not understanding the need to be dismissive of someone else's plans. Part of the fun of programming is checking things out, if we maintain an open-mind.
> this language has literally no unique attributes that would make it different than D or Go, so you won’t improve as a developer from it at all...
Such a statement can be perceived as highly inflammatory. V clearly has different features from D and Go. Additionally, V is among the most popular programming languages on GitHub[1], based on stars. And has been so for some years now. Other people clearly use and experiment with it. What you and I like, doesn't mean that others don't or can't have different preferences.
I'm fairly familiar with both V and D (even made some minor contributions to the V compiler), and I can't think of a single notable feature that isn't also available in D. V has a more modern and straightforward syntax, but that's the only major advantage imo. In terms of what you can _do_, I'm pretty sure D is almost strictly more powerful.
V can produce JavaScript, and it has an interpreter, but those are pretty experimental features. V has built in markup templates (like Mustache but worse), basic built in JSON reflection (D's CTFE can implement this), and built in portable inline SQL (for some reason), but that might be less desirable than targeting one specific ORM with its entire feature set. V also has a built in Sokol shader compiler, and can run `.vsh` files in a special script mode that works very slightly differently than normal V, but those aren't exactly killer features compared to D imo.
transpiling to C actually makes adoption much easier. if you create an entirely new compiler auditing and verifying that takes many years and tons of money before it can be used for anything serious.
> transpiling to C actually makes adoption much easier.
Well, maybe.
I like transpiling to C because it brings with it all the hyper-optimisation that has gone into C compilers over decades.
As a solo on-again/off-again language designer, I can attest that you really cannot fixate on language purity or similar stuff like that: the goal is to write a program in your new language as soon as possible, and implement the features that motivated you to create a new language in the first place.
Transpiling to C is, in practice, no different from transpiling to assembler, with the advantage of portability and instant environment support (can call C libraries).
I've got a featurelist I'd like to implement. Focusing on emitting machine-code or assembly eats away valuable time I could have instead used to create a feature, or 10.
> I'm a tiny bit worried by the way they are pushing development of so many products not directly related to core language development (a GitHub clone! A kernel!) and not focusing on creating a proper compiler.
So showcasing what the language and compiler can do is a bad thing?
Not at all. I just am worried for them that they are going to get wrapped up in complex projects like Vinix and end up putting too much time into a project that few people are actually going to benefit from. A basic text editor (which I think they also have implemented) is going to be a much more practical way to demo your language without dumping lots of time into a complex task.
> by the way they are pushing development of so many products...
"They" are many different people (developers or contributors). As an open-source project, people focus on what they like or may need.
Furthermore, V has a native backend, in addition to others: C, JavaScript, WASM, etc... They've stated (on their website) that their plan is to eventually make the native backend the primary, as they close in on 1.0. The other backends can be seen, for those that have actually used or know of the language, by checking out the -b flag.
It is important to note that (at the time of writing this comment) the native backend can compile only three examples in the `examples/` directory in the V compiler codebase:
hello_world.v
fizz_buzz.v
rune.v
All the other examples fail to compile when V is used with the `-b native` flag.
Sure (although I can't find anything like that on vlang.io myself), but your post was that "[n]one of the claims in this article are relevant now."
It is still relevant that autofree does not work on heap-allocated structs. In particular, this is relevant to the day-to-day usage of the V programming language.
Whether this is well-documented by V itself does not change that it is relevant, in my opinion.
In both the review itself and in V's documentation, from which the example came, it states that autofree is still WIP. It's arguably disingenuous to pretend otherwise or present unintended usage.
The normal "day-to-day" situation would be to have the GC on or as fallback, and to do otherwise (like -gc none or -prealloc), one should know what they are doing or be prepared to deal with such issues.
Those parts of the review, considered relevant in normal usage were resolved:
But even beyond that, the intent of the so-called review was arguably malevolent. It was not done in good faith, to be helpful to the developers or community, but done to spur on drama (thus adding the vaporware link and spamming it) and knowingly looking for ways to bash an alpha version of the language.
But I'm not pretending that autofree isn't documented as WIP, nor am I suggesting that anybody should use anything unintended.
I am simply pointing out that a single claim from the article is still relevant to how V functions today. To be more specific, the still-relevant claim is: "So forcing the value to be allocated on the heap reveals that autofree leaks the values."
The post I am replying to did not say "almost none of the claims in this article are relevant now," it specifically said "none" without qualification.
Maybe I am just unusual in how I use the English language, but I would unquestionably consider this to be a case where you should really qualify the word none, because otherwise it's just not true.
Whether autofree is completely in alpha and intended not to be used or not, the claim from the article that it doesn't work for everything is relevant. I don't see how it couldn't be.
Surely if autofree is WIP, it's no big deal to simply agree that the fact it doesn't work on heap-allocated structs is relevant to its current state?
Now, to be clear, I am aware that arguing over a single extremely small point is, to some degree, missing the point of the comment I was originally replying to. But this is also just how I talk about things on the internet. If part of your claim is untrue, even to an extremely minor degree, I will point that out. This is why when I personally claim things, I almost always qualify what I am saying. (See? Even here I said "almost always," because I just naturally add qualifications so as not to overstate my case).
I stopped looking long ago but to my limited understanding, when V says it does X in 1s, it means they delegated the job to gcc faster than others doing the whole work.
Either that or V author is up for a few ACM turing awards.
If you mean the table under "For comparison, space and time required to build each compiler", I think, that it is about what each compiler took in time and disk space to compile itself, on the same hardware, so it is about P compiling P sources.
V can not compile C or Go, Go can not compile C, and C compilers can not compile V or Go, so it can not be otherwise.
We need new languages and ideas to keep developing, obviously if someone is willing to put a lots of time and effort they found existing ones lack in something. Even if the difference is only 20%.
Talking specifically about Go, how much time did it take for Go team to acknowledge and make some workarounds to support generics? And this is not a new concept it exists for more than 30 years. I can not imaging Go actually developing and incorporating new things, it is a simple and "completed" language.
So what are the new ideas around V? It literally does the same thing as Go, and as you correctly recognize, Go was already thoroughly uninteresting when it came out from a PL perspective, the only remotely interesting part is its goroutines (though not even that is unique).
V doesn’t even have that, so there are like 10 languages just like that with slightly different syntax.
I don't know much about V, I was answering why new languages are a good thing in general, even if they seem very similar to another.
And I don't think every new language has to have some unique feature too. You can compare almost any modern "scripting" language for example to Common Lisp and ask why they exist, but they do and they enable lots of developers just fine.
They don’t need a unique feature, but they do need at least a unique combination of existing features — languages are as much determined by what features they have as what they don’t.
But V fails to make me interested on this count as well.
It has been over 4 years since I've commented on the V language proper. I still think Alex need to greatly improve his public relation skills, but otherwise the only thing matter is that the language is still alive after years. It took way longer than the original claim (which again is a PR issue) but it is now a language that has advertised features and may fill some niche. I'd like to applaud the perseverance.
I don't know about a long-term plan, but it seems that V will now need one if there isn't already one. Many languages start out fresh and either die out (metaphorically) or get crushed on their own features. Planning seems to be necessary to avoid either fates, and yet is not sufficient to guarantee survival. I personally witnessed this from D firsthand back when a stdlib divide was threatening its future, and believe every successful language author need to answer this question (for example, Rust would say the coevolution with Servo was massively beneficial). So Alex---or other core developers if any---, do you have any thoughts on this?
That still sounds like mission statements. Many enough languages have similar missions and their plans to achieve them would vary a lot. I'll assume you are still figuring them out then, and share my humble opinions.
"Simple"---and yet usable---is very hard to define and achieve. If the language has to fit all domains, it seems that the best approach is to identify versatile, multi-use features (better explained by Guy Steele's Growing a Language talk). And such features are relatively uncommon! So most languages tend to have many features only for specific uses and pray that they don't clash with other features, i.e. ditching the simplicity. It is not really impossible, but I'd rather have it as a guiding principle other than a mission.
"Fast to compile" is good to have, but I hope you to use it just as a guide as well. The critical threshold is the apparent interactivity (about 100 ms), and anything faster than that is not worthwhile as is. Slow languages can also create an illusion of interactivity with many efforts (e.g. incremental compilation), so you would rather want to identify and avoid the global cause of latency. For example header files have a large impact on C/C++'s compilation speed, even when everything is cached and using loglinear algorithms or faster. I think V got a general idea right, so don't be too fixated about concrete numbers.
"C/C++ perf" needs more quantification. First of all, many C/C++ programs are actually slow for many reasons. It is just that many performance-sensitive programs were also written in C/C++. Many other languages tend to use other related statements like "no language runtimes", "no hidden control flows" or "no allocations". Not very satisfactory, but still better because they imply actual actions. And please be aware that this goal is in general directly contradictory to the simplicity, another reason to ditch it...
"Fits all domains" is what I'm most unsure about. I believe attempts to write everything in V are related, but they won't ever be sufficient (let's talk about writing a proof-certified mathematical routine :-). Many languages provide the extensibility as a primary solution, but it is not enough---I mean, unless you think PyTorch tracing CPython bytecode and producing a fused CUDA kernel as extensibility. Many domains do share common requirements in terms of programming, so multi-paradigmatic approaches would scale better... unless new programming paradigm can be hard to retrofit to the existing language. (Lisp doesn't count because it generates a family of languages.) As a concrete goal, I think you should instead pick a small number of distinct domains and advertise as "fits many domains" instead.
"Flexible memory management" is probably the easiest to achieve. Existing languages are surprisingly hard to mix and match multiple memory management schemes primarily because they didn't start with multiple schemes after all. (I believe a GC extension of Rust will be extremely valuable in this regard.) This is something V can directly provide now, keep pursuing it.
"Batteries included" is a cross-cutting concern that touches on almost all other missions except for performance. While this has been one of Python's mottos, it is evident that Python's "batteries" are now too old. Thankfully this issue is also relatively well-understood: you need a good package manager and standard libraries should also use that machinary. Many consider Cargo as the model solution, though not every aspect is appreciated (e.g. single identifier namespace, YMMV). Ironically though Rust itself didn't have Cargo at the beginning, so its standard library situation is not actually ideal. But at least you have a good example to agree or disagree with.
"Readability and development speed of python" is half the anti-simplicity and half the tooling concern. Readability is as subjective as simplicity and development speed has two factors (global and local), where global factor is more about the modularity problem, so let's consider the tooling, the local factor. Tooling is something people like to have and no one likes to appreciate at the same time. It is one of the most labor-intensive tasks in PL and, while you can prepare for them in advance, the actual work needs to be done one by one until approaches like JetBrain MPS become much more viable. It can however happen completely independently from the language development itself as well, so I believe it's of less concern.
The last thing I want to say is that, it's fine to miss all those checkboxes! Many languages are mediocre in all aspects and yet still useful and popular. Some languages even develop a completely unexpected niche out of nothing, like JavaScript and Python. You may still want to retain some good characteristics (which by itself would be an impressive achievement), but you can't know in advance whether they were worthwhile or not. So checkboxes are not as important as they seem---the perseverence to keep them in sight is more important.
What I find interesting is the cross platform UI from V which also compiles for Android:
https://github.com/vlang/ui
It does seem to be still in its very early stages but if they are able to make this a more mature library, it may actually be quite useful for tiny, fast apps.
It is really striking, the difference in *everything* between some beta quality programming language projects and approaches of people behind them.
- Effort applied; To be tailored for certain kinds of projects; Solve problems in existing languages; Approaches to prevent/force adoption of beta quality project; Philosophical approaches behind project or lack thereof.
Now on the personal, subjective note, the more I look, the more I want to avoid V and get my hands on Jai [1][2]
I like many things about the language but haven’t yet written a significant amount of code in it to properly evaluate it. V feels a lot like Go. Plus a language that can replace C/C++ for bare metal programming.
By default it does use tcc on most platforms, because tcc is awesome for quickly compiling C, and so iteration while prototyping with it is usually much more enjoyable than with gcc, clang or msvc.
You can pass `-cc gcc` to use another C compiler for example, instead of tcc.
There is also a native backend, that generates executables directly, without generating C, then using a C compiler to compile it. You can use `-b native` to try it, instead of the more developed C backend. Note that the native backend, is still work in progress though and it does not support some language constructs.
What's the status of autofree engine becoming the default? It's perhaps the most discussed feature of the language. Last year it was mentioned the GC it's temporary until autofree engine is production ready.
I am thrilled to see so much progress on V! I remember being excited about this language and seeing an immense amount of hatred, skepticism and doubt, and unfortunately being taken in by it.
Is this hatred still present?
Has anyone used the language extensively that can comment on its usability?
I'm not sure if "hatred" is the correct word here. Yes, there has been a ton of skepticism and doubt about V here in HN, but this is very different from hatred. In my opinion, skepticism is not only okay, but desirable in a community like HN. Skepticism is also a core principle in science. Skepticism can be respectful and encouraging.
I count myself among the skeptics of V. Mostly because in the initial communications about it, some of the claims were hard to believe. For example, they used to claim that V was memory safe without GC, but also without borrow checker, and it was never explained how they achieved such thing. Now I see that they claim that the language is very similar to Go, so I assume that they went with a GC. That's really cool, I actually think that GCs are a massive boon for language ergonomics. But there remain some unexplained topics, for example, how is that they achieve being "free of data races" [1]. It's nice to see a new language in the area and I hope the language succeed. But I'll continue to be skeptical until I see proper explanation of some of their claims.
I'll always be skeptical of the claims. Much less of a trust but verify, but a "you have to verify every little thing" [1]. The analogy that came to my head is how Elon always says self-driving is coming right around the corner [2]. Sure, some progress is made towards it, and maybe it'll come true one day... but don't take any of the claims at face value.
You should always verify every little thing for any new language you’re thinking of using, if only to understand its behavior in details, warts and all. I did the same when I first learned C, C++, Go etc. etc. But one must separate (what I consider) marketing fluff from reality. Evaluate for yourself whether the new language is worth learning, whether its development is going in the direction you can mostly agree with, whether it has promise, whether it is developing an ecosystem etc.
All I'll add is that whether or not that specific example holds up today matters little to the wider point: which is, that the language makes promises, and you need to verify each claim due to the repeated [0] ambiguity/inaccuracies about them.
It is very easy to verify. Just have a working C compiler + git + make:
git clone https://github.com/vlang/v
cd v
make
./v your_program.v
On a modern machine with good network, it will take you under a minute, to have your own copy of latest V, and less than 200MB, including the .git/ folders.
You can also download .zip releases from https://github.com/vlang/v/releases , without needing git. The .zips there are <15MB, and contain a prebuilt V executable, so you do not even need make to use it.
That particular word was used back when V was not yet really open-sourced and only the playground and prebuilt binary was available [1]. The author falsely stated (among others) that it was already open-sourced, and while I believe it was a simple misunderstanding the reaction was not really far-fetched back then. That specific claim was retracted once the compiler was properly open-sourced [2].
V was never a "scam" or "vaporware", that's a false characterization and misuse of the terms. Such is being done for the purpose of attempting to hurt the public image of competition, for the benefit of certain parties.
V has been open-sourced, on GitHub, and downloadable since June 22nd of 2019. The language creator publicly stated he would put it out in late June, and did.
There was some excessive fuss about, around June of 2019, over a Patreon supporter early release. That was his right to do such a release, and it was specific for those supporters, but detractors were "angry" that it wasn't for them or open-sourced.
What some detractors were trying to do, was claim that V would never be released because it was somehow a "scam" or "vaporware". That is, there was nothing to release. They were of course wrong, because V was publicly released. That's when targets were switched or the goal posts moved. Anything that could be used to attempt to justify the earlier vitriol, inhibit the rising popularity, or hurt the public image of the language was used.
Furthermore, no programming language is released as a finished product. And an alpha version of any language, is understood by most, as work in progress (WIP) by default. There is no "scam" there. For open-source projects, any person is free to contribute, if they are really so technically knowledgeable as they claim or give the appearance of being. Everyone is free to donate or sponsor a project that they like, there's nothing nefarious about that.
My exact statement is that: people had good reasons to believe V is a scam or vaporware before 2019-06-22. Note that this is completely distinct from the statement that V was a scam or vaporware in the same period [1]. I believe this is true. If you don't think so, I'd like to hear your rationales for that---not the reason that V is not a scam or vaporware.
[1] I should point out that vaporware can be a temporary status, that is, something can become a vaporware until it no longer is. So the exact pinpointing is necessary.
It was never known to everybody else that the source code would be available 2 days later. I still remember my surprise [1] back then. I, among others to which you still seem to have bad feelings, now believe that you were indeed not malicious and just bad at public relations like many of us. But that is the hindsight and no one would know it at that time.
It was a combination between Patreon and Github Sponsors for solo the lead developer at the time making several thousand USD per month. Those campaigns are still ongoing AFAIK, but the contribution amounts are now private.
This right here is why people have a problem with you and your language. You did make outrageous claims, and to now say you didn't is gaslighting. Accordingly, people do not trust you.
Here's just one. On an early version of your webpage you said in big bold font:
> V can translate your entire C/C++ project and offer you the safety, simplicity, and up to 200x compilation speed up.
When people called you out, it turned into this small subscript:
> C++ to V translation is at an early stage.
And it's been in an "early stage" ever since.
I'm sorry, but when you said "can translate your entire C/C++ project" did you mean "can" or did you mean "one day will be able to". Because those are completely different, and to say one when you mean the other is grossly misleading. To now say that you never said the former outrageous claim is gaslighting. We're not idiots or goldfish.
I responded to the post where he said "There were no outrageous claims".
"V can translate your entire C/C++ project" is an outrageous claim because it wasn't true then, it isn't true now, and it doesn't appear it will ever be true.
it is typical for experimental/beta/alpha projects that features don't work or/and later found not to be feasible and later dropped from road map, there is nothing "outrageous" here.
From another hand, you clearly tried to manipulate narrative by changing context and specificity.
everything in early stage not prod-ready experimental project is on roadmap, there is no guarantee anything works or will work, this is only healthy expectations for such projects.
Now, can you tell why you and similar folks follow val author in every post even issue has been resolved long ago?
>everything in early stage not prod-ready experimental project is on roadmap
There's an archive link posted in this thread that shows the specific feature mentioned (transpilation) was on main site front page and presented as ready and working.
>can you tell why you
Not sure why this became personal. My comments are public and can easily check this isn't the case.
> There's an archive link posted in this thread that shows the specific feature mentioned (transpilation) was on main site front page and presented as ready and working.
my reading of archive is that this was in active work, he had examples of translation, and some now dead link on leveldb translation, and some c++ to val translation implementation but removed it lately: https://web.archive.org/web/20190226163127/https://vlang.io/...
> Not sure why this became personal. My comments are public and can easily check this isn't the case.
You just made a "scam" claim about issue which has been resolved long ago. So, this is the case, and I am wondering what is your motivation.
Developers are allowed to get or ask for contributions, donations, or sponsors.
To add to the strangeness of how its being mischaracterized, was the apparent jealousy (back in 2019) over the amount of donations that other developers got. Then for certain ones to have got so upset at getting less, they started to bash and publicly ask people to give them their money instead.
Somehow, it's OK for X to get money for their competing language, but it's "wrong" for Y to get money for their language.
All open-source programming languages are allowed to get or ask for donations and have sponsors, not just the languages that one is a fan of.
It's also ethically wrong to engage in falsely labeling or making false accusations, such as "scam" or "vaporware". Particularly, when the actual intent or agenda is that such persons are detractors or competitors from rival languages.
Lastly, various financial supporters of the V language have even come on HN to tell and explain how proud they are of the language and the progress it has made. Despite detractors and competitors, V is still making fantastic progress, and that's great to see.
> All open-source programming languages are allowed to get or ask for donations and have sponsors, [...]
> Particularly, when the actual intent or agenda is that such persons are detractors or competitors from rival languages.
V was not open-sourced when the accusation was made, and there were probably two or three people qualifying your description of "rivals" (even after assuming bad intents). Stop diluting the context.
> Lastly, various financial supporters of the V language have even come on HN to tell and explain how proud they are of the language and the progress it has made.
This is not different from how many investors to failed crowdfunding campaigns would behave before the actual failure. They will either acknolwedge risks (but few actually evaluate them) or "answer" every criticism with non sequiturs. It is not really their fault, but still useless as an evidence.
The "early access" thing makes sense in closed-source projects but not much in F/OSS projects. Now I understand what you meant, but as I've said it was not technically open-sourced for two days and no one would be sure whether you are sincere or not.
This confusion should have been temporary and could have been easily resolved, but your reaction arguably made things worse. For example back then I actually asked you about the exact generic compilation strategy [1], and your answer was unnecessarily aggressive and content-free. It turns out that my later guess (to which you never replied) was right, i.e. the initial V compiler maintained a partial C code template that can be patched. If you had actually answered as such, people would have less reasons to disbelieve you because you have demonstrated a necessary understanding. This was also why other language developers were particularly harsh to you at the beginning.
> You have previously claimed that the V compiler uses no AST. However, most of the features that you claim would require a form of AST to even work, including generics and interfaces. [...] It's pretty much impossible to not have unless you have a very basic language or doing naïve transformations into another similar language.
You have misinterpreted this as follows:
> Claims like it's not possible to build features without AST or codegen json decoders are just ridiculous.
GingerBill pointed out that you have misread his comments and restated that:
> [...] if you language does not have an AST, which is technically possible, then you cannot have a lot of the features you have been advertising.
This is not saying "impossible". He is claiming that it is possible, but some features will be lacking. I considered this is inaccurate because he was unclear about which features will be affected, so I quantified the original claim as follows and asked you for the confirmation:
> For example, you can implement generics without an AST if you don't care about performance; [...] [T]hose features can be implemented without an AST, but an AST is a standard and reasonable way to do them and not using an AST would require a strong rationale. So what's that rationale? (And amedvednikov, this is my question for you.)
Now, I knew the discussion can often go awry even without bad intents and tried to make it constructive as much as I could. There were many reasonable answers, like "yeah, that's how I did and that makes compilation much faster" or "none of both, the compiler doesn't directly emit binaries". The latter would trigger other questions and at the end everyone could have a much better understanding of what the V compiler actually does.
Instead you replied:
> No you don't understand :) It's IMPOSSIBLE without AST. The Odin creator says so. That's why I'm a liar.
I still don't know why you said that. I even explicitly said that gingerBill has another misconception! You've said that you have no bad feelings to me, and I wish it's true, but this is a typical way to convey that you are angry at me (and gingerBill). "Aggression" generally refers to any action or response that makes someone else unpleasant, and your comment was clearly aggressive to me.
On the other hand, I can see why you have bad feeling about gingerBill. That's another reason I wanted to step in because confirmation bias is pervasive and continuous counterarguments are needed to avoid that---gingerBill initially didn't question your intents. I wanted to make you distracted and not vent your apparent anger by throwing another question, but it didn't work.
For that reason I chose to entirely ignore that paragraph in my reply and asked for the confirmation again, but you never replied back. Others may consider this as another evidence that you were indeed angry at me. I don't, to be explicit, but such an unnecessarily aggressive discourse is often colloquially called a drama.
----
I still can't believe I have to explicitly write this comment, but after multiple interactions I feel it's necessary and hope it helps. It is very hard to effectively communicate only with texts, and I had been there years ago. I only sort-of-learned this after decades of shitposting and fruitless debates. I believe one can learn this without all my hassles.
They overpromised, which is quite frowned upon in foss circles where there's usually no incentive to do that. Personally, I'm quite happy that any attempts to normalize a culture of lying gets a strong reaction.
The response by the creator and others against the critics was also frowned upon. I'm interested in how this language will go, but those actions a year or so ago still leave a bad taste.
And yet, all that would be nothing but temporary noise if the resulting artifact that delivers gets made. I'm more of a dynamic tech guy but I see this language as something that needs to exist.
If that article hasn't been changed since the publication, the strongest statement is "as it stands I recommend against using it for anything" AFIAK, and it is far from saying "it must die". She even gave many suggestions for improvement, some of which are shared with mine. I think you are reading too much from those criticisms.
I failed to locate such a comment. And even if there was one and got removed later, the last known position is that she regret to write an article that can be perceived as toxic, no matter her intent [1].
Thank you for the explicit pointer (I searched for "die" already, but it seems that "dies" was not stemmed). And yet it is not same to "V should die"; it is rather V "should be ignored until it dies into obscurity". It is no different from "do not feed the trolls"---if V fails to prove to be something viable there would be no reason to make comments at all. And that comment predates her last position anyway, so I still think you are reading too much.
Come on. She was already aware that it is not literally ("kind of") a scam, but pointing out that there is a parallel ("if you sell someone the moon and give them a block of cheese", I believe advertisements were not yet fulfilled in 2021). If she was meant to mercilessly bash V why did she rather mention "there are good ideas there" and give suggestions for improvement?
That is your interpretation of what is being said, where "prove to be something viable" is being added, and graciously giving the benefit of the doubt to the person who wrote the statement.
I took it, as possibly many others, as "ignore V until it dies". Thus, "V should die", would also be near enough to the intent, malice, and vitriol be conveyed. If someone said something similar to me or about something I created, "Ignore X until it dies", would not interpret it as anything other than ill intent.
Of course if she only said that your interpretation is more likely. But she first stated "I hope this feedback can help make V a productive tool for programming" in 2019, and the last post in June 2020 stated that:
> I would like to see this situation result in a net improvement for everyone involved. V is an interesting take on a stagnant field of computer science, but I cannot continue to comment on this language or give it any of the signal boost I have given it with this series of posts.
This exactly aligns with what she said in the comment I quoted (the only addition is "[V] should be ignored", which is another way to say "no more signal boost"). You are free to disagree with my interpretation, but your interpretation doesn't seem to explain this paragraph.
---
> If someone said something similar to me or about something I created, "Ignore X until it dies", would not interpret it as anything other than ill intent.
I also have my share of people saying mean things to me (as I've said elsewhere, I also went through lots of shitposts), and I learned that I have only a finite amount of time to deal with them. Salvage what you can learn from them (positive or not), but otherwise minimize useless interactions because it is often the case that actually I was at fault, or even that no one is at fault and the human language is just so imperfect. I believe the latter was indeed the case for aforementioned reasons.
(In the case anyone wondering why I'm trying to interact this much then, I still want V to be successful and my experience suggests that no one said something like my comments so far. It is sort of a folk knowledge and many take or assume it granted, but it has to be learned and few will tell you that fact.)
In the last 15 minutes I’ve read a few blog posts and reddit threads and am saddened. It does seem there are many false or misleading claims, though there does appear to be steady progress, or at least the appearance of it.
I hope the language or another like it eventually can fill this niche. I’ve been dreaming of a similar language myself..
Ignore all the pro/con noise. git clone its repo, compile it locally and play with it. Write some code. You’ll be pleasantly surprised (at least I was). Its progress is pretty good (few tests break now and then and once in a while the self-compile breaks and I have to run make). If you know Go, it is very easy to pick up but don’t expect it to be exactly like go and it has its own idioms.
Note: I’m interested in V but not involved in V development.
A lot of the false accusations, spamming of negative links, and misinformation arguably comes from those with competing or hidden interests. It's a lot of language war antics, that got out of control.
Various competing languages use reddit as a forum, because their language didn't previously have one or their developers didn't open up discussions on GitHub. Evangelists of competing languages can be allowed to bash, flame, or troll opposing languages on various subreddits.
If they outnumber a rival language, in a place they often congregate and the mods will allow such behavior, then they can get away with typing the most outrageous or foul statements for points. It came become a bash and troll festival, and anyone that dares oppose, can get intentionally downvoted away or punished by their mods who have control.
People that are casuals or don't know what's going on behind the scenes, may see only their side. There is often no balanced discussion. Any opposing view points to the false accusations, extreme negative positions, misinformation, or wrong statements may not be allowed to be seen.
> A lot of the false accusations, spamming of negative links, and misinformation arguably comes from those with competing or hidden interests. It's a lot of language war antics, that got out of control.
Arguably? According to who? What evidence supports such a claim?
When V was first announced, the author made a lot of outlandish claims about what the language was able to do. Experienced language developers saw this immediately and pointed out correctly that the claims ranged from exaggerated and premature, to impossible based on current PL theory. Apparently the V community has decided that constructive and valid criticism from peers is an act of "war", and it's to be discounted because they are "competitors" and
"rivals" who are "salty".
Notably the criticism died down a little (from the Zig author in particular) when the Vlang devs backed off some of the more outlandish claims and correctly added "WIP" labels to them instead of implying that they were actually working and implemented. So the Vlang devs/community at the time at least recognized they were doing something wrong in how they were communicating their work; although today in this thread it seems like they are trying to back peddle.
V has the right to exist, have its supporters, and do things its own way. The creator and developers of V, from what I have seen, have responded well to actual constructive criticism. Their language has discussions opened at their GitHub, unlike those for various other languages. They even have a thread for what people don't like and want improved about the language[1], again, something many other languages don't have.
A lot of what was going on initially, was coming from obvious competitors and evangelists, to include being uncivil, inflammatory, and directly insulting. The initial "criticism" was not so much that, but false accusations of the language being a scam, vaporware, fraud, or didn't really exist. To include attacks and jealousy over donations, rising popularity, and having supporters. This was not any kind of "valid" criticism, that the creator or contributors of the language could reason about with instigators.
The "criticism" never died down, but rather V was open-sourced and established itself on GitHub. The initial series of false accusations could not stand nor could the support it was getting be stopped. So, the rhetoric and targets shifted to whatever could be found to go after on the newly released alpha version of the language and its new website. In that new mix of what was being thrown at it, there were indeed some very valid criticisms, as can be found with any new language and many sites.
Constructive and valid criticism, is not the same as insults, trolling, misinformation, rivalry, or false accusations. There is clearly a difference. It's disingenuous to pretend something from one group is the same as the other, or that the intent behind what is being done is not different.
A big reason this drama still exists on HN is your style of evangelism. You are not a good ambassador for this language, and if you care about it you should stop.
You’re not going to change my mind that the initial promises were outlandish unless you implement them (you haven’t yet in 4 years), and claiming today they weren’t (as Alex is) is literally the worst approach you could take to build trust in your language. People weren’t mad about V they were mad about the exaggerations, prevarications, shifting explanations, aggressive tone, and now gaslighting from the V author. And if you turn it back around on me yet again you’re proving my point.
Well, that's because the reason behind the criticism was never really the language. It was the attitude of its author and proponents. Sadly, this very thread proves that that attitude has not changed [1] one bit, so it's no wonder the criticisms remain.
> The initial "criticism" was not so much that, but false accusations of the language being a scam, vaporware, fraud, or didn't really exist.
Backlash is to be expected whenever extraordinary claims get made with nothing to back them up. Apparently V is supposed to be able to translate entire C & C++ projects to V and run as fast as C, but with memory freed automatically by the compiler. Now, combine such impossible claims with the initial unavailability of the source code, asking for donations, refusing to elaborate on how exactly this would work, and the fact that none of is is true even today.
That's because none of the outrageous claims are possible. They weren't possible back when V was announced either and when the programming community immediately pointed it out, the response was the same as we've seen in every thread since then - gaslighting.
It's one thing to make hopeful and starry-eyed, but misguided claims, it's another to double down on them, deny any mistakes, and play a victim.
I would appreciate, for you to not speak about the V community and V devs, which consists of many people (660 contributors currently), with various positions and attitudes, including me.
I have not spoken about anyone being a salty rival, whatever that means.
The lead developer and very vocal community members brigade HN every time V is mentioned. They form the basis of my opinion of your whole community — you maybe should send some more measured voices here if you feel they don’t represent you. The impression they give off has informed my opinion, and if you don’t like that it’s your job to change my opinion through positive interactions. Meanwhile I’ll voice my opinion as much as I like thank you very much.
The words in quotes are from what appear to be ambassadors of the V language here on HN. If you feel they don’t represent your community, maybe ask them to stop brigading instead of asking me to shut my mouth? Just another example of the V community I guess…
My job, thank God, is not to please entitled rude people on HN.
If you have some problem, you can simply address people individually, without attacking an entire community of many, that share a common interest in a programming language.
Sadly, that's not how community management and representation works, and you should know that. If the people in the V community who post here aren't representative of the V community, then maybe send community members who have better people skills.
The people you send are the people who represent all of you. Sorry if you think that's unfair, but that's the reputation you're building. That's not on me, that's on you.
Think all you want about me, I'm nobody. But it's clear that the same handful of V community members (including the lead dev) show up every single time V is mentioned. So if you feel their voices don't represent the V community, talk to them instead of telling me to (in so many words) STFU. Cause that aint happening. Because they're all I see of V.
@ModernMech, you can just address people here individually, and not refer to them as V developers or V community - that currently is already too broad and paints people that you do not know at all, with the same paint, be it bright or dark.
It is the same, as asking you to not talk about all Australians, all Chinese or all Bulgarians, when you mean the actions of specific people/individuals.
That is all I am asking for, and I think that is not difficult to understand.
What you and your community do on HN reflects on you, regardless of what anyone else does. You're earning your reputation one post at a time. I mean, several of your posts here are dead and flagged. Take a hint. Your evangelism isn't working here, it's doing the opposite of what you want.
My suggestion is to work on your C++ to V translation engine instead of posting here. Maybe you'll move it past the early stage.
> You're spamming this thread and with your anti V attacks, have a bunch of them downvoted and flagged, and are teaching me about communication...
> So rude indeed.
I count ~10 comments across three comment threads, most of which are responses. It's a bit scummy to characterize this as "spamming anti-V attacks".
I never claimed to be anything, and I have no dead or flagged comments.
But I'm an asshole. I'm very rude and blunt. That's a given. Never claimed otherwise. But I'm not the leader of a community I'm trying to build. That's you. You need to take a higher road if you want to build a positive reputation. Or you can roll around with pigs like me and get a reputation for being muddy.
The fact that you turn it back to me personally when you should be standing on the merits of your work says everything I need to know about you and your community. Change my mind.
> I never claimed to be anything, and I have no dead or flagged comments.
You just said yourself, that you are an asshole, rude and blunt, after insulting a whole community of people ... Have you thought, that maybe you should stop?
> Or you can roll around with pigs like me and get a reputation for being muddy.
I am a farmer. I live in a village in Bulgaria, and I've had to deal with actual pigs before from time to time... Pigs should know their place, and it is not, where people discuss ideas.
Think it's way more about detractors trying to push a negative narrative on the language, than it's any kind of reflection of the community, who are elsewhere.
I believe you that as a user you don't care, but for the community that implements the features, they exist in the imagination of the devs, design, planning and early implementation attempts for a long time before you can use them.
Right in the sense that it can take a really long time to release a work in progress feature.
Wrong that some of the claims made initially were phantasmagorical and also debunked very quickly.
Also, vaporware is a a thing. I'm perfectly willing to stay by the claim that GNU Hurd will be useless to me until the day I die.
For reference GNU Hurd has been in "dev, design, planning and early implementation attempts" for 33 years, and I imagine I'll live 50 more years (fingers crossed!).
It feels like an enthusiast project, where the developers didn't know some things are hard or impossible, and they claimed their language will solve them (or that it already solves them). Looks like they've learned something now :)
I think lang author is asking to not start flame wars, but there are bunch of people (you included) attacking him first in this topic, and he can't respond?
He can't respond if he doesn't want to engage in a flame war. I'm a dog on the internet, he's the dev of a project he's pushing that is trying and failing to build a reputation as someone trustworthy.
or he just became a target of some salty internet mob which is now following him everywhere, and many other people(me included) actually find his work interesting.
I think language which these people are using (scam, outrageous and frequently false claims, lying) is hard to call "mildly critical", and given they appear in multiple posts and their claims are not directly relevant to post, and proactively initiate all these toxic exchanges, this is exactly stalking.
It became one of those hate memes. A target of irrational fervor among anyone caught in between. If you ask those angered they pull out a list of petty grievances a mile long composed of misleading or highly interpretive wrongs.
I haven’t had the pleasure to try out V yet but I hope this discussion can rise above. Endless bickering leaves a sour taste in my mouth.
> If you ask those angered they pull out a list of petty grievances a mile long composed of misleading or highly interpretive wrongs.
How can you assert that they're misleading or highly interpretive wrongs if you haven't dug into them yourself and actually used V? All the negative press I've seen on V has been highly detailed and reproducible.
You don’t need to have touch it to see. Just browse this thread. A big one mentioned is over promising, which is pretty interpretive for a language only on version 0.4 of its development cycle. Most other complaints are slight variations of this. Promising magic performance or magic features without a good explanation, is another variation. This would be well and good for a fully released language, which this is not. All that tells me is the creator is overly ambitious for their own good and possibly naive, which I hardly classify as a sin.
Whenever this topic comes up I’m at a loss to understand why anyone would waste so much energy mud slinging over some personal language project. It only makes sense if it’s become a hate meme. My pocket word for an event that’s a sort of social singularity. It occurs when enough popular voices have directed the entirety of a community to shame a target based on some perceived wrong, real or otherwise.
Wherever it comes up I’m pretty taken aback by how tribal and ego focused we can be, even among the smartest of us. And that thought isn’t meant be taken as condescending. After all, we’re only human. And for a larger span of human history, that word has meant “hairless ape” more than anything else.
They got lot of push back because what the core devs were describing Vlang to be was technically close to impossible, and their implementation was missing lot of properties they were advertising. If you would look at their sources or try out V when they released it you would have seen how outrageous their claims were.
Last time I looked was beginning of 2022, and I read their stdlib implementation and tried the compiler. They advertised their non-GC solution, “auto free”, but it literally didn’t work, your program would just leak. And if you actually look at what they meant by “autofree”, it is a reference counting GC. They advertised Rust memory management ergonomics but without relying on linear types? Their way to do system calls was by running commands in shells.
Unless things changed drastically V lang, as described by their documentation, is a vapor ware.
I'm still waiting for that CS breakthrough to happen - Rust guys will be so mad they spent their time writing lifetime annotations for the borrow checker :)
You can look up vlang.io on web archive and see that it never said GC-less autofree. It actually explicitly said that RC/GC are used for stuff that can't be freed during compile time.
> No. V's memory management is similar to Rust but much easier to use. More information about it will be posted in the near future.
May 2019
> No. V manages memory at compilation time (like Rust). Right now only basic cases are handled. For others, manual memory management is required for now. The right approach to solve this will be figured out in the near future.
April 2020
> No. V manages memory at compilation, like Rust:
vlang.io/docs#memory
August 2023
> You can look up vlang.io on web archive and see that it never said GC-less autofree
Here's a direct quote from the documentation [0] from 2021:
> 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.
So most objects are freed by the autofree engine, and the rest are freed via reference counting. This implies that no objects are freed by the GC, which is exactly what I've said.
> What's written is correct, what's the issue again?
The fact that the feature promised is impossible. I'm quoting some comments from which this whole discussion has started, since you don't seem to be able to follow:
> dgellow: They got lot of push back because what the core devs were describing Vlang to be was technically close to impossible
> amedvedikov: There were no close to impossible/missing features.
Static analysis (autofree) with reference counting, by itself, cannot theoretically free all of the objects during the runtime of the program. And I know that you know that since you've made the decision to switch to a tracing garbage collector.
The choice of tracing garbage collection makes the initial claim much less impressive and innovative - Go already has escape analysis, which is basically an implementation of autofree. But Go used a garbage collection from the start, so escape analysis is just an optimization - exactly what autofree is for the current V with GC.
V promised something impossible, it's not a big deal, we all make technical mistakes and learn from them. What makes it a big deal is your stubborn attempts to rewrite history and gaslight people.
> It can't, that's what it says on the home page. Stuff that can't be freed during compile time is handled via GC.
The documentation I've quoted and posted a source to specifically says that all objects are freed either by 1) autofree or 2) reference counting.
> What's the impossible claim?
The impossible claim is that all objects are freed either by 1) autofree or 2) reference counting. As I've mentioned, neither static analysis (which is what autofree is) nor reference counting is capable of completely freeing all unreachable objects at runtime - reference counting is in particular unable to handle cyclic references.
> What's the issue again?
The issue is you vehemently claiming that V has never, ever promised a feature that was impossible - which is false, as I've demonstrated and cited with reference to archive.org of V lang documentation. So can you stop doing that, please?
> You pointed to an old version of the documentation
Yes, because that version of documentation specified a feature that was impossible, which is exactly what we're discussing.
> V never promised autofree without GC or RC
First of all, I never mentioned "autofree without RC". I am strictly speaking about "autofree without GC".
Second of all, V documentation has had the "autofree frees 90% of objects, RC frees everything else" segment, which clearly implies no GC. So the documentation has clearly specified that feature, which was an impossible feature.
Even the next paragraph says:
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.
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.
Which explicitly implies that objects are exclusively freed only by autofree and reference counting.
2) Your emphasis of "everything" seems to imply a contrast to Python or Go method of memory deallocation:
"It just works", like in Python, Go, or Java, except there's no heavy GC tracing everything
which would mean that Python, Go and Java trace everything, which isn't true. None of the three languages (Python, Go, or Java) use GC to trace everything - there are multiple optimizations (such as escape analysis and reference counting) that allow a certain percentage of objects to be freed by means other than tracing GC.
V is not a finished product nor 1.0 yet. It's unproductive to act like things were carved in stone, from day 1. Programming languages go through development phases, where things do change and lead developers are allowed to make changes.
But gaslighting people and pretending that overly grandiose claims/promises haven't been made in the past leaves a bitter taste, and doesn't inspire trust in core developers. Instead, it makes me think that the core devs are incapable of admitting a mistake - which would make their language a hazard.
For example, what if V gets huge and a serious security bug gets discovered - how can I trust that the developers will properly communicate the existence of such a bug and not just keep quiet about it, consider how they aren't even willing to admit that V has made some impossible claims/promises in the past? If I discover a bug, will they also pretend that the bug doesn't exist, even when confronted with indisputable evidence, because it threatens to damage their reputation?
As long as that attitude doesn't change, I'm not touching V with a 10 foot pole.
You're still pretending that V has never made an impossible claim, which I have clearly demonstrated that it has.
See my numerous replies to you in this thread, where I have quoted the documentation, provided the archive.org link and explained why the claim is impossible.
Do you have any other argument except "nuh-uh, didn't happen, lol"?
The homepage still makes the claim that "[autofree] takes care of most objects (~90-100%): the compiler inserts necessary free calls automatically during compilation."
There is no citation for where this 90-100% number comes from, it seems to be pulled completely out of thin air.
Autofree, as it currently exists, cannot handle structs at all, so any program whose memory allocations consist of more than 10% structs unfortunately proves this claim false.
For a specific example, a while ago I wrote a minimax tictactoe program[1] in V, which specifically used a struct to store the board state rather than an array.
In this case, with the minimax running for 4 total moves, valgrind tells me:
==8518== HEAP SUMMARY:
==8518== in use at exit: 2,250,360 bytes in 68,544 blocks
==8518== total heap usage: 161,756 allocs, 93,212 frees, 4,762,235 bytes allocated
So only 93212/161756 allocations were freed, which is 57%.
... Now, I don't actually care that much that autofree doesn't work on structs. I think that's quite reasonable, as it's a very difficult thing to implement!
But, in my opinion, your website should really cite where this 90-100% number comes from, i.e. which benchmarks were used to generate it, so that it is clear that it isn't just completely made up.
(As it currently stands, I would argue this is false advertising specifically because there's no citation for this number!)
Why isn't there a citation for this 90-100% number? I really am extremely curious where it comes from.
As for why I am posting a similar message (not nearly the same post, though) to you here as I did a year ago:
It is because I am very, very curious about where this number comes from and why there is no citation for it! It is fascinating to me.
(And, more generally, I have empirical experience with autofree that many users don't seem to have... so it seems useful to post about that experience to provide extra context for everyone else on this website).
You've also done a great deal, unfortunately, to feed these flamewars. For example, you posted 36 (!) times in this one: https://news.ycombinator.com/item?id=37292351, which was not started by your critics. Worse, of the 52 comments you posted in this thread overall, all but a few were not flamewar. I tried to count the good ones but there were so many flamey ones that I ran out of steam.
I'm sure a ton of good work has gone into your lanugage, but we don't need a perennial flamewar on HN, so please stop feeding it. More at https://news.ycombinator.com/item?id=37344925, which applies to several of you, not just Tozen.
The responsibility to fix this lies with you guys because you're the ones who (rightly) care most about the topic. The way I see it, there are two options: either (1) you give up on taking bait, focus 100% on the interesting parts of your work and 0% (and I do mean zero) on defensiveness and provocation, or (2) we just ban this topic from HN. Personally I'm fine either way, and I'm pretty sure the bulk of the community would be also. What I don't want is this status quo headache that comes up every couple months or so.
2) ModernMech, about 20 flamewar posts. This thread is very telling, where I ask not to start another pointless flamewar, get flagged, and ModernMech goes on:
The comment by riku_iki is spot on: "You are stalking him with toxic attacks on the minor issues which were resolved long ago; I think language which these people are using (scam, outrageous and frequently false claims, lying) is hard to call "mildly critical", and given they appear in multiple posts and their claims are not directly relevant to post, and proactively initiate all these toxic exchanges, this is exactly stalking."
3) richbell, 11 posts.
4) and a couple of new accounts that were thankfully flagged.
I'm not saying that all criticism of V should be flagged, just posts by such accounts, whose only purpose is to start flame wars.
You're doing exactly what I asked you not to do, perpetuating this pointless dispute. It's taking up a ridiculous number of cycles. If this keeps up, we'll ban the topic completely from HN.
My hypothesis is that if you guys stop responding defensively, the problem will simmer down and eventually go away. Stop focusing on criticism. Stop responding to it externally and stop reacting to it internally. Just ignore it. Work on your thing and keep your comments focused on what you've done.
If you want to do that, I'm willing to help you. But you have to actually do it. Responding like this is the opposite.
In the link you posted (id=36816398), never saw it until this, as the entire series of posts were deleted away from the main thread. So was not aware of the situation, and that it was being blamed on me specifically.
If you review those chain of posts, surely the account that first named V directly (not to even go into the list of many other antagonists), initiated and provoked by specifically targeting the V language. Including posting provocative or inflammatory links (which are spammed on most V threads).
I'm concerned that the definition of what constitutes instigating or being found at fault for starting a flamewar, appears directed at those who may respond with or show any support for V.
Those that are clearly instigating, continually snarky, or even directly insulting in their posts seem to go unpunished or ignored. Though, as a user, don't have the greater perspective on this.
Apologies on the rule violation, as often attempt to avoid crossing the line, and was just attempting to provide at least a contrasting point of view to what is continually taking place on the subject. After review, do see which rule was violated, which was not the original intent.
If you would be kind of enough to, can you instruct on how you view this situation?
I'm sure V is a very nice language but HN doesn't need to have threads about it, and HN does need to not have flamewars, so this dynamic needs to stop. I'm talking about puerile drama like https://news.ycombinator.com/item?id=37292351 (which incidentally was kickstarted by someone on your side, not the other side).
The best way for it to stop would be for those of you who feel aggrieved by unfair criticism to stop being provoked. The internet is the internet—critics will never go away, shit will always get repeated. But you guys have the power to stop feeding it. That would solve the problem, at least from an HN point of view, because the fires wouldn't keep growing if you didn't flood them with oxygen. But it means developing the capacity not to be so easily provoked, which (I know well from my own experience) is not so easy. It's worth the effort though.
In any case, it's off topic and destructive for HN. If the only way for us to be free of it is to never discuss that programming language at all, that would be a shame, but it would at least be better than the status quo, and a price we'll pay if we have to.
Dang, I'm confused in how it appears V is regarded very differently from other languages and possible desire to completely censor it. I'm, however, highly sympathetic to moderation efforts at HN (for higher quality debates and opinions).
> I'm sure V is a very nice language but HN doesn't need to have threads about it
It looks to be giving the impression (maybe unintentionally) that threads about V are unwanted on HN. Where it's fine to have threads about other languages, despite them clearly having issues, controversy, or need of moderation as well.
All threads about V or posts initiated in a thread which concerns V, are not posted by "V's people" and definitely not by me. For that matter, I'm completely independent, despite what might be the perception. I have no relation nor any connection to who created this thread, or many others about V. I just was commenting on a topic that I saw on HN and expressing opinions.
> which incidentally was kickstarted by someone on your side, not the other side...
I have zero ideal who manofmanysmiles or modinfo are (both accounts existing years before mine), nor am I on their side or rather it's unfair to categorize us as being on the same side.
That someone posts something that contains a bit of support or is positive about V, can be completely unrelated to them being teamed up or in collusion, but just coincidental opinions or observations.
In fact, it appears manofmanysmiles is not a user of the language, but an outsider asking for opinions. Which then people posted their opinions in response, as would be expected for just about any topic or that kind of post.
> would be for those of you who feel aggrieved by unfair criticism to stop being provoked...
Would this not be true for both sides, not the side that is perceived as being supportive of V?
I thought the point of HN was to allow and respectfully give different opinions about a topic, not to censor a particular side or topic.
This definition could be interpreted that the positive side be removed. And purposefully allow damaging or negative information to be unchallenged and spread by default.
> critics will never go away
Totally agree, as this is the nature of human discussion.
> But it means developing the capacity not to be so easily provoked, which (I know well from my own experience) is not so easy.
If the meaning is to "grow a thicker skin" in response to criticism, on that we agree. A higher quality of respectful and informative discussion should be aspired to and engaged in, as part of maintaining the desired standard of HN. And would be why many, like myself, have enjoyed or have come here to see.
> The story comes across as very strange, to say the least. But a point that should not be missed, and why I made this post, is the reasons behind what is being attempted by telling such stories and painting such a narrative.
> It's indicative of what the V language has been facing, and the hidden assault on it's public image (as part of an ongoing language war) that many casuals don't realize is going on.
You have made numerous comments in this thread dismissing any criticism of V as coordinated effort from jealous competitors. Again, what _proof_ do you have of this "language war"? How is a single comment indicative of a "hidden assault"?
On June 20th of 2019, and prior to the open-source release of V on June 22nd of 2019, the creators of competing languages, and various supporters of theirs made very disparaging remarks against V and it's creator[1].
V was falsely characterized and accused of being a "scam", "vaporware", or "fraud" that really didn't exist or its source would not be released to the public. To include, V's creator was allowed to be heavily and repeatedly insulted on the thread.
The creator of one of the languages made a direct plea to not give money to the V project, and instead give that money to himself and another creator[1]. Which, was way beyond the usual lines of civility. This was later added to, with the other creator (back in 2019) making a somewhat similar plea for people to give him their money instead while doing harsh attacks on V, from his website[2].
Surrounding that, was angry talk over how much monetary support V was getting[1]. "He's up to 56% of the income I make on Patreon..., and I've been busting my ass for years..."[1]. This can be viewed as jealousy over the amount another developer was getting, so early on.
Such behavior by language creators, against another, is clearly and extremely irregular. While both creators later on kind of walked backed their earlier statements and attempted to remove themselves from heightened drama and initiating a language war, it was arguably way too late. The statements were walked back a bit, because they were in error. V's creator made an early release for his Patreon supporters, which he has the right to, that was taken out of context. Furthermore, he did release the source for V, 2 days later and in June (as was promised). Despite this, the goal posts were moved, to continually find anything else to attack V on (from when it was an alpha) as a newer competing language.
Over the years, the drama has persisted. To include HN accounts dedicated for the purpose of attacking or insulting V (to include sleeper or newly created accounts), in the frame of an overall wider effort spanning years and various different websites. From time to time, the opposition against V, has also mistakenly or nonchalantly identified themselves as such (can be seen through search). Casual readers on HN or other websites, often don't know of the motives behind unnecessary or odd vitriol, so this can be "hidden" to them.
Lastly, the V language has every right to exist and flourish, as those other languages. V has numerous developers, contributors, and supporters who make it continually better.
Maybe someday I should try learning V again. I was going to learn it over the summer of 2020 to expand my repertoire beyond C++, but I gave up fairly quickly and ended up learning Qt instead, which has proved to be a very wise choice - knowing Qt why I have my current job (for multiple reasons).