[HN Gopher] V Language Review (2023)
       ___________________________________________________________________
        
       V Language Review (2023)
        
       Author : thunderbong
       Score  : 146 points
       Date   : 2024-02-24 16:18 UTC (6 hours ago)
        
 (HTM) web link (n-skvortsov-1997.github.io)
 (TXT) w3m dump (n-skvortsov-1997.github.io)
        
       | Alifatisk wrote:
       | I remember there was some controversy or drama with V a couple of
       | years ago regarding the language.
       | 
       | I forgot what it was about but I haven't heard about V since
       | then. This article was interesting to read!
        
         | mratsim wrote:
         | Overpromise and underdeliver.
         | 
         | And lots of funding for then vaporware
        
           | gnuvince wrote:
           | Isn't that our entire industry though?
        
             | klyrs wrote:
             | Speak for yourself, some of us have principles.
        
         | ck45 wrote:
         | Isn't it about the authors have been overpromising and
         | underdelivering since the beginning?
         | https://mawfig.github.io/2022/06/18/v-lang-in-2022.html is a
         | year older than this article, still interesting and it links to
         | some other articles right at the beginning.
        
           | MuffinFlavored wrote:
           | If the author wanted e-fame (the good kind or the bad kind),
           | they absolutely got it.
        
         | artemonster wrote:
         | V claims to be the next best thing that ever happened since
         | sliced bread, but instead its development over years is just
         | yak shaving on steroids. These review posts just prove that.
        
       | jug wrote:
       | Strangely super vigorous rant about a language that fell into
       | obscurity early on.
        
       | archsurface wrote:
       | "a summary of my experience with the language over 6 months " --
       | I was only able to use it for a week around Christmas before
       | hitting compiler bugs. I like the look of it, but I can't
       | currently use it.
        
         | TwentyPosts wrote:
         | To be fair, I ran into a compiler bug in Zig within a few hours
         | of using it. I'd still expect Zig to be a lot less buggy than
         | V, based on what I heard.
         | 
         | Last time I looked at V it just seemed like the language wanted
         | to have it all. No tradeoffs, just "The best parts of Rust and
         | Go" with no explanation how that's remotely achievable (and it
         | wasn't, judging by the attempts to make "auto free" memory
         | management happen, and having to discover first hand that this
         | is not a good approach, and the problem is turing complete).
        
       | chrisaycock wrote:
       | Some highlights:                 - autofree doesn't work       -
       | memory arenas (prealloc) isn't thread safe       - compiler
       | produces large binaries       - coroutines invoke blocking calls
       | - community behavior is, uh, "unwelcoming"
        
       | lkey wrote:
       | V's claims have _always_ been dubious on their face. It promised
       | the programming language equivalent of magic with no overhead. I
       | 'm glad that someone took the time to print receipts.
       | 
       | The author clearly wants a reckoning, but he's unlikely to
       | receive satisfaction. The people that still use or evangelize V
       | are locked in, the contradictions will only make their belief
       | stronger. Alex is a bullshitter, and arguing with someone like
       | that is pointless.
        
         | agumonkey wrote:
         | What's amazing is how large the community became and how strong
         | their love and belief was.
        
           | attractivechaos wrote:
           | The V devs have promised a lot, have missed a lot but have
           | also achieved a lot. I have written a few short programs in
           | V. IMHO, the V syntax is concise and intuitive and the
           | performance is good. It is lightweight and easy to install
           | and to use. The blog post is probably right that V has many
           | rough edges but I would say the core features in V are well
           | planned. I actually prefer it over some other more popular
           | languages. That said, because V hasn't reached 1.0, it is
           | probably too early to use it in production.
        
             | bscphil wrote:
             | Yeah, when the article skipped over the first two memory
             | management strategies to point out issues with manual
             | memory management and an "automatic" strategy that is
             | unfinished or broken, it really struck me that it's quite
             | impressive for a single author to have a functional, fast
             | language with a working garbage collector _and_ arena
             | allocator (with some issues) in only a few years.
             | 
             | The criticisms in the article, which I just read beginning
             | to end, are largely about features it claims to provide (or
             | claims are in development) that either no other language
             | has, are an improvement on other languages, or are state of
             | the art features in world class languages with hundreds to
             | thousands of times more developer hours.
             | 
             | On the one hand, it's not wrong to criticize the overly
             | ambitious nature of V's plans nor criticize the poor
             | attitude and self-advertising strategies of its lead
             | author. On the other hand, I'm not sure that the article
             | _is_ doing that, it seems much more interested in taking
             | one of these features, showing that it doesn 't work, and
             | saying "so there!". But the fact that _these_ are the
             | features being complained about, not the core of the
             | language, says something in itself.
             | 
             | Likewise, the fact that a hobbyist language with a single
             | primary developer has terrible documentation is at the very
             | least par for the course. Heck, I've found the Zig
             | documentation horrific (in the past), and that has way more
             | developer time and mindshare. Compare it to, say, the Oil
             | shell (at least, where it was a few years ago), if you want
             | to be fair.
             | 
             | I'm not convinced that the blog author _isn 't_ a troll, in
             | some sense of the word. Clearly, many of their criticisms
             | are well founded. Clearly, Alex does not react well to
             | criticism. Clearly, V kinda sucks for practical use right
             | now in a lot of ways that _do_ matter. But the post
             | (especially the end) feels like an excuse to stir the pot,
             | not well-intentioned criticism. The author seems to want to
             | use this post to counteract people they feel have
             | mistreated them (with some justification).
             | 
             | Note: I say all this as a complete outsider. I've never
             | written a line of V code and probably never will. My only
             | prior experience is that I'm familiar with the controversy
             | around V, especially on this site.
        
               | ptx wrote:
               | > _quite impressive for a single author to have a
               | functional, fast language with a working garbage
               | collector_
               | 
               | From what I gather from the article, they didn't
               | implement a garbage collector, but rather integrated the
               | Boehm GC. This is a conservative collector, so it doesn't
               | collect all garbage.
               | 
               | > _But the fact that these are the features being
               | complained about, not the core of the language, says
               | something in itself._
               | 
               | Memory management is a core part of a language. According
               | to the article this core part doesn't work, which is a
               | pretty big flaw.
        
               | jokethrowaway wrote:
               | I wouldn't say it's impressive.
               | 
               | I've seen tons of computer science graduates hooking up
               | gc to their languages in uni when they learn about
               | compilers and programming languages
        
               | remexre wrote:
               | "link the Boehm GC" got one line on an assignment in my
               | University's compiler's course; it's literally a matter
               | of changing                   exec ["ld"; "-o"; out_file;
               | obj_file]
               | 
               | to                   exec ["ld"; "-o"; out_file;
               | obj_file; "-lgc"]
               | 
               | ...
        
               | mort96 wrote:
               | The problems with V has always been that its marketing is
               | full of lies and its main selling points don't work as
               | advertised. The same source code, but without the
               | deception, might very well be an alright language.
               | 
               | Just like how healing crystals are perfectly fine if what
               | you want is decoration and you think they look pretty. It
               | doesn't make the deceptive marketing okay.
        
               | babel_ wrote:
               | > _it 's quite impressive for a single author to have a
               | functional, fast language with a working garbage
               | collector and arena allocator (with some issues) in only
               | a few years._
               | 
               | As the included code shows, the gc is boehm gc, and
               | checking their repo shows they just include libgc/bdwgc.
               | This is absolutely not a knock against anyone here, it's
               | just about the standard library for this need, and I
               | think it is a far smarter move to use it than for most to
               | attempt to make their own general-purpose gc (though
               | boehm can't catch all leaks).
               | 
               | I feel it would be wrong, however, to characterise this
               | as being a single author having made a language _with_ a
               | gc and arenas, as if those were significant parts of the
               | author 's own developments, rather than using a well-
               | picked import and a half-baked implementation of
               | "arenas", which here are really just a global linked list
               | of buffers, freed only at exit, and so everything leaks
               | [0]. They're not really arenas, you can't use them
               | locally in a region of code or as scratchpads, let alone
               | multi-thread it. By their code's own admission, it's just
               | a little pre-allocation to batch mallocs for all the
               | little heap allocations of a GC-assuming codebase, so
               | they're not _really_ arenas like you 'd use in C or
               | elsewhere.
               | 
               | Not unimpressive, it's a valid approach for some uses
               | (though not general purpose), it's just different from a
               | language _with_ their own gc and actual arenas. Indeed,
               | just implementing an arena barely even registers in the
               | complexity, I feel, as arenas really should be very
               | simple in most use cases [1]. It would be far more
               | impressive to have them actually integrated and be
               | available as a true alternative to a GC for memory
               | management, particularly integrating common patterns
               | (e.g. [2]) in a way that could serve as a drop-in
               | replacement, such that we can actually provide bounded
               | lifetimes and memory safety without a full GC, let alone
               | support multiple concurrencies with it from multi-
               | threading to coroutines -- this would likely still be
               | unsafe without a GC compared to, say, Rust or Vale, let
               | alone Pony or SPARK, and would likely require a cultural
               | shift in manual management akin to Zig or Odin, as it may
               | be largely moot if dependencies end up enforcing the gc
               | themselves. Still, again, making anything substantial is
               | never unimpressive, we just need to retain the
               | perspective of what was achieved and how.
               | 
               | As to the rest, well, I think it's fair to say that there
               | should be a clear delineation between statements of "we
               | can do this and here's how" and roadmaps with "we're
               | aiming to do these things and here's our current
               | progress". In my experience, people are quick to get
               | these mixed up when they're excited about making
               | something, and none of us are fully immune to this. It's
               | not some moral failing or anything in and of itself, it
               | can very easily be an honest mistake, but humans see
               | patterns everywhere, so we often need to be receptive
               | when others are trying to help us be level-headed and
               | clear things up; otherwise a reputation begins to form.
               | Especially in this industry, reproducibility matters, as
               | we're all too familiar with the smoke-and-mirrors of
               | demos (not to personally claim there is any here, just
               | that it obviously helps dispel such concerns).
               | 
               | And, of course, second chances are always offered if
               | someone is willing to amend mistakes.
               | 
               | [0]: prealloc.c.v is barely over 100 lines long and quite
               | manageable, https://github.com/vlang/v/blob/master/vlib/b
               | uiltin/prealloc...
               | 
               | [1]: Chris Wellons, "Arena allocator tips and tricks",
               | https://nullprogram.com/blog/2023/09/27/
               | 
               | [2]: Ryan Fleury, "Untangling Lifetimes: The Arena
               | Allocator", https://www.rfleury.com/p/untangling-
               | lifetimes-the-arena-all...
        
               | firebaze wrote:
               | The V lang author implicitly claims to understand CS
               | theory better than quite a lot of people including Go and
               | Rust lang devs.
        
         | MuffinFlavored wrote:
         | Is the author better at marketing/sales/promising or
         | programming (delivering)?
        
         | mirashii wrote:
         | To top it all off, prominent folks from the V community often
         | engage in flamewars on this exact site. dang has threatened to
         | ban the topic entirely before [1], and honestly at this point
         | I'm pretty supportive of it.
         | 
         | [1] https://news.ycombinator.com/item?id=37335249
        
         | odiroot wrote:
         | Whoa there. It's just a programming language. No need to spill
         | vitriol over that.
         | 
         | I have no skin in the game. Got into V very recently, because
         | it appeals to me at face value.
         | 
         | And in some ways better than other "better C" languages of
         | today.
         | 
         | For me it's just good enough. The syntax is sane, the compiler
         | doesn't want to maniacally ruin my day, the standard library is
         | already quite rich, and finally wrapping C code is a breeze.
        
       | arp242 wrote:
       | A good faith look at V is that it's very much a work-in-progress,
       | and that at times the documentation is "aspirational" rather than
       | "factual". I'm reminded by an remark from Bill Joy in an old
       | interview talking about writing vi: "I wrote manual pages for all
       | the great features we were going to do but never implemented".[1]
       | We've all done that, right? I certainly have, including in public
       | projects.
       | 
       | There's a lot to be said about the wisdom of publishing material
       | like this, and it's fine to object. But phrasings like "they were
       | able to lie in every sentence" do not sit well with me,
       | especially since the bit that follows doesn't actually disprove
       | the claims all that well. It's assuming the worst possible
       | motivation (intentional deception) rather than the much more
       | likely motivation (small team, tad too much enthusiasm, and
       | perhaps at times, inexperience). I'm not entirely trusting the
       | objectivity of an author who describes these sort of things as
       | "lies". Even worse are things like:
       | 
       | > He lies that coroutines work with IO. I'll clarify that by
       | working, I personally mean context switching when necessary, and
       | not the fact that the program does not crash.
       | 
       | So the functionality is correct, but not in a way the author
       | would like it to, therefore it's a lie to claim it works. Eh?
       | It's fine to criticize that the implementation isn't any good, of
       | course, but employing such narrow definition of "works" and then
       | calling someone a "liar" over it seems rather, eh, much.
       | 
       | In short: not a fan.
       | 
       | I'm not saying the V people have always smelled of roses either,
       | but this article is definitely part of the problem with the
       | general drama and toxicity surrounding V. I find it more than a
       | little sad that vlang.io apparently needs Cloudflare DoS
       | protection (I assume they didn't add it for the craic).
       | 
       | [1]: https://begriffs.com/pdf/unix-review-bill-joy.pdf
        
         | agumonkey wrote:
         | that's musk approach, which is double edged sword
         | 
         | interesting that bill joy did use a similar way, but i assume
         | that an incomplete text editor is a lot less critical than a
         | failing compiler :)
        
           | arp242 wrote:
           | I don't know what "musk approach" is, presumably referring to
           | Elon Musk?
           | 
           | > interesting that bill joy did use a similar way, but i
           | assume that an incomplete text editor is a lot less critical
           | than a failing compiler :)
           | 
           | I think it's very common. GitHub is probably full of projects
           | that do this to some degree. But most people also don't pay
           | attention to these projects.
           | 
           | I'm not saying the V people are without blame or couldn't
           | have be better, but there's definitely a lot of toxic
           | feedback looping going on here.
        
             | agumonkey wrote:
             | Musk says "full self driving car next year for 60k" means
             | "partial self driving in 5 years for 75"
             | 
             | I don't have a full explanation of why V made me so angry,
             | but coming up with so many bold claims invalidating whole
             | decades of an entire industry is mind boggling for sure.
        
               | arp242 wrote:
               | Ah right. Well, Tesla is a company, whereas V is
               | basically just a few people working on it in their spare
               | time. I don't think you can really compare the two or
               | hold them to exactly the same standards.
               | 
               | Or to put it in another way: people can be flawed, and I
               | think that's okay. I don't think it's right to jump on
               | that with assumptions of malice.
        
               | vacuity wrote:
               | I think people (and designers of other languages, in
               | particular) were outraged that not only did V have the
               | very aspirational claims, but there was also a Patreon
               | (or similar) and the general attitude of the newly
               | forming V community that felt undeserved for that level
               | of...aspiration. I think that doesn't quite fall under
               | malice, but I imagine it felt unfair to many.
        
         | pharrington wrote:
         | Do not say that your software does something that in fact, it
         | does not do.
        
           | fuzztester wrote:
           | That should be one of the n commandments of software
           | development.
        
         | RodgerTheGreat wrote:
         | I don't think intentionally misrepresenting projects in their
         | documentation is something "we've all done". Making _mistakes_
         | in documentation is one thing, but turning a readme into an
         | "aspirational" sales pitch with no disclaimers is baldly
         | dishonest and worthy of scorn.
        
         | nazgulsenpai wrote:
         | I agree with this perspective, in theory. Not liking how
         | something is implemented is different than suggesting it isn't
         | implemented. The real damning aspect of this is that criticism
         | surrounding these decisions seems to result in the silencing of
         | the critic. There are times where moderation and banning are
         | necessary, such as when the critic resorts to name calling or
         | trolling. Criticism can lead to more awareness which could lead
         | to a better implementation down the pike, even if there's alot
         | of headbutting in the process. Outright silencing the dissent
         | is counterproductive.
         | 
         | I also don't think reporting about being banned/silenced for
         | such criticism is perpetuating the drama/toxicity of the
         | community for the sake of it when it's a real world outcome.
        
           | arp242 wrote:
           | I've seen this play out a few times now in a few different
           | communities: systemd, Gnome/GTK, wider JavaScript and PHP
           | communities, and probably some others.
           | 
           | There is legitimate reasonable criticism of these things,
           | even today.
           | 
           | However, they have also been subject to profoundly
           | unreasonable - even unhinged - criticism, and this has
           | created a rather unhealthy dynamic where both reasonable and
           | unreasonable criticism are all treated the same by the
           | developers. You kind of _need_ to insulate yourself to some
           | degree.
           | 
           | For example, consider my write-up of the "GTK thumbnail
           | issue" at [1] (I since deleted my account there, but that was
           | written by me). It's easy to come off with a bad impression
           | of the Gnome/GTK developers based on that, but at the same
           | time ... they've been subject to so much unreasonable whining
           | and criticism that it has also created this dynamic.
           | 
           | There's tons of examples like this. Also see: every time GIMP
           | comes up on HN, with people ranting and whining about all
           | sorts of things. I wouldn't be surprised if the GIMP devs
           | don't even bother reading HN any more.
           | 
           | [1]: https://lobste.rs/s/ky5yop/gnome_has_no_thumbnails_file_
           | pick...
        
             | rstat1 wrote:
             | I would argue that at least some of the grief GNOME gets is
             | deserved. Especially given their attitude towards their
             | users.
        
               | arp242 wrote:
               | As I said, _some_ grief is deserved in all these cases.
               | But _unreasonable_ criticism makes people also not listen
               | to more reasonable (deserved) criticism. That was my
               | entire point.
               | 
               | That you're completely ignoring this and instead just
               | reply with an unsubstantial and off-topic dig at gnome is
               | an excellent demonstration of my point.
        
             | avgcorrection wrote:
             | > However, they have also been subject to profoundly
             | unreasonable - even unhinged - criticism, and this has
             | created a rather unhealthy dynamic where both reasonable
             | and unreasonable criticism are all treated the same by the
             | developers. You kind of need to insulate yourself to some
             | degree.
             | 
             | If you need to insulate yourself to the degree that you ban
             | someone for answering the question "V or Go?" with "Go,
             | obviously"[1] then what's the point of even maintaining a
             | community? All you'll end up with is a bunch of yes-women.
             | 
             | [1] Is V production-ready?--no. Is Go? Yes, for a long
             | time.
        
             | klyrs wrote:
             | I dunno, I've been using gimp for literally decades and for
             | about a year recently, it couldn't paste from the
             | clipboard. I didn't even bother reporting the bug because I
             | knew I'd come across like an entitled whiner in today's
             | atmosphere.
        
         | pornel wrote:
         | I can believe that it's just overconfidence and optimism gone
         | too far.
         | 
         | The problems they claim to solve look deceptively easy on the
         | surface. Something like escape analysis (required for automatic
         | borrowing without GC or refcounting) has many easy cases, but
         | also incredibly hard or literally unsolvable edge cases.
         | 
         | They may have been encouraged by progress on the easy cases,
         | and assumed the rest is just a matter of a few bug fixes,
         | rather than hitting the halting problem.
        
         | cycomanic wrote:
         | I don't know, if you say you have build a language that solved
         | memory and safety issues without any overhead and performance
         | impact, but in reality everything is a noop, you're lying. You
         | can't claim you have solved some of the most difficult problems
         | in language design but when challenged just say this was an
         | aspirational statement.
         | 
         | Apitational statements require that you have an idea how to get
         | there. Even if you have that idea (why are you not at least
         | saying how it would work), state that this is a goal, not a
         | current status, otherwise it's a clear lie.
        
         | bpfrh wrote:
         | >So the functionality is correct, but not in a way the author
         | would like it to, therefore it's a lie to claim it works. Eh?
         | It's fine to criticize that the implementation isn't any good,
         | of course, but employing such narrow definition of "works" and
         | then calling someone a "liar" over it seems rather, eh, much.
         | 
         | As far as I understood the article the coroutines don't work?
         | 
         | If I write asynchronous code via a coroutine and one coroutine
         | with io prevents all other coroutines from running that is not
         | a working coroutine.
        
         | alpaca128 wrote:
         | But then why isn't the documentation updated? If the developer
         | can start projects for UI and 3D graphics before the language
         | is complete, surely there's also time to show at least the will
         | to fix the constantly criticised honesty & transparency issues?
         | 
         | > "I wrote manual pages for all the great features we were
         | going to do but never implemented"
         | 
         | Your source also mentions there were just two people working on
         | the code and the manual was finished at release, so nobody
         | except two people had access to unfinished documentation for a
         | program that was done within two years...I don't think this is
         | comparable.
        
         | avgcorrection wrote:
         | None of these points apply in this context. The context is that
         | this project has been going on for many years, is popular
         | (using the GitHub stars proxy), and has been criticized before.
         | This isn't a fourteen year old kid trying to make a language
         | and being naive about what it takes to achieve it.
         | 
         | > I'm not saying the V people have always smelled of roses
         | either, but this article is definitely part of the problem with
         | the general drama and toxicity surrounding V.
         | 
         | Meh. Complaining about the tone is so boring. The author is a
         | bit upset but no one is disputing their technical arguments
         | (I'm relying on others since they know more about it than me).
        
       | whiterock wrote:
       | Thank you for this. Saved me a lot of time and hassle -
       | definietly steering clear of V land. A similar review for Nim
       | would be of interest to me. Should not be that bad I'd hope.
        
         | frfl wrote:
         | Nim shouldn't really be used in the same sentence as V. I've
         | never used Nim, but I've never seen anyone out right say
         | anything negative like that's said of V. The only thing close
         | to "negative" regarding Nim I've seen is this,
         | https://news.ycombinator.com/item?id=36563796 and the thread it
         | links to https://forum.nim-lang.org/t/10312
         | 
         | I could be wrong of course. Maybe someone can point to actual
         | negative aspects of the language or the community that I'm not
         | aware of.
         | 
         | Honestly if you're interested in Nim, go learn it. I've
         | definitely seen it being used for a number of project, the most
         | used that I know of is (was) nitter[1]
         | 
         | [1] https://en.wikipedia.org/wiki/Nitter
        
           | yogorenapan wrote:
           | I've used Nim in the past. It is definitely not vaporware
           | like V. It's a pretty pleasant language although I've since
           | moved on to Zig.
        
           | fao_ wrote:
           | OH, Nim is the one with the asshole creator? I thought that
           | was Zig, I get those two mixed up a lot
        
         | sergiotapia wrote:
         | I've written a few projects in Nim. Unfortunately there seems
         | to be a big "civil war" happening right now in Nim land where
         | it's the creator vs big-names going at it for some reason.
         | Can't remember. Like if Chris McCord suddenly started fighting
         | with Jose Valim and Elixir became split right down the middle.
         | 
         | I stopped using Nim because I couldn't get over how bad the
         | documentation was. Hard to navigate, hard to find what you need
         | if you don't already know what it's called and examples are
         | extremely convoluted instead of showing you the basics
         | barebones first. I thought this problem would have less of an
         | impact the longer I used Nim but years later it's still a
         | thorny problem.
        
           | crq-yml wrote:
           | The creator not being able to community manage was why I left
           | Nim - not "forever", but I moved on to other things. The
           | language has some good ideas, but at that time development
           | seemed to be heavily guided by two trolls who hung out in the
           | IRC and complained, every day, about how they would never
           | ever be able to do their projects without this one feature.
           | Eventually I got into it with them and nobody got
           | banned...which, of course, said to me that he was OK with
           | toxicity, so I couldn't be bothered to stay.
           | 
           | That, and a lot of the more advanced features were just
           | broken.
        
       | 12_throw_away wrote:
       | I know it's a meaningless metric, but I still find myself
       | wondering how, exactly, vlang got to 35K stars on github, very
       | much in the same order of magnitude as, say, cpython with 58K.
        
         | dsp_person wrote:
         | I've been comparing various projects in a particular domain and
         | noticed that stars aren't the best indicator for
         | adoption/maturity level. More interesting:
         | 
         | - number of contributors
         | 
         | - number of open/closed pull requests
         | 
         | - number of open/closed issues
         | 
         | Most of the time they scale with stars, but sometimes there
         | will be 1k+ stars but only a few pull requests, which is odd.
        
         | Cavallium wrote:
         | A lot of vlang-related statistics are very suspicious, probably
         | some of the metrics are boosted by a click farm or something
         | similar. For example, 99% of the global google searches about
         | "vlang" are from Beijing.
         | https://trends.google.com/trends/explore?date=today%205-y&q=...
        
           | alwayslikethis wrote:
           | This makes very little sense to me. Keep in mind that Google
           | is blocked in China, and has been for a long time, except
           | maybe specific special machines from the government that may
           | have unlimited access. Even if there is a lot of search
           | interest from people using VPNs, it shouldn't show up as
           | China.
        
           | arp242 wrote:
           | "golang" seems to have similar statistics: https://trends.goo
           | gle.com/trends/explore?date=today%205-y&q=...
           | 
           | So I'm not sure if that's evidence of metric boosting by a
           | click farm, or anything else. Clicking on the question mark,
           | it looks like it's not really a ranking of "where do searches
           | come from", but rather "how popular is it in this region":
           | 
           | > Numbers represent search interest relative to the highest
           | point on the chart for the given region and time. A value of
           | 100 is the peak popularity for the term. A value of 50 means
           | that the term is half as popular. A score of 0 means there
           | was not enough data for this term.
        
         | metaltyphoon wrote:
         | They have more starts than C# at 10k
        
       | epolanski wrote:
       | I'm awed at how far people would go both in studying, analyzing
       | and writing about a language they clearly dislike.
        
         | andrewflnr wrote:
         | Having a few people willing to go to absurd lengths to debunk
         | bullshit and generally stand for truth is a group-adaptive
         | trait.
        
       | alchemio wrote:
       | I for one appreciate this article. It sheds light on the history
       | of V and its undelivered promises; and save me wasted time trying
       | it or reading their site.
        
       | nbittich wrote:
       | Interesting article, except I didn't like the last part. It
       | sounded too personal. I would have preferred if OP had kept a
       | neutral tone and allowed the reader to make their own opinion.
        
       | rozab wrote:
       | Seems little has changed since Xe's article back in 2019
       | 
       | https://xeiaso.net/blog/v-vaporware-2019-06-23/
        
       | ianthehenry wrote:
       | Can someone explain the backstory of what V is and why someone
       | took the time to write this? To the uninitiated this sounds like
       | someone criticizing some kid's side project.
       | 
       | I'm picking up some context clues that V is widely used / famous
       | / notable / significant somehow, but the only time I have ever
       | heard of it before this is Xe Iaso's similarly negative posts.
       | Did V receive some huge funding grant that made it the target of
       | ire? Is the author otherwise well-known? What am I missing?
        
         | AndyKelley wrote:
         | There is a summary at the top of this post from 2019:
         | 
         | https://andrewkelley.me/post/why-donating-to-musl-libc-proje...
        
         | smcl wrote:
         | When the V project started out the creator of V made some big
         | claims that raised a few eyeballs, they've gained a reasonable
         | following over the years, have a pretty serious looking website
         | (https://vlang.io), a beer-money level Patreon following and
         | some corporate partnerships/sponsors. However they have
         | experienced some pretty brutal takedowns over the years, with
         | some of the bolder claims about the language/compiler often
         | being exposed as untrue and some functionality being broken.
         | 
         | A word I keep seeing in relation to V is "aspirational" - the
         | project aspires to be a serious language and it aspires to have
         | some serious features, so I think it's fair to approach it with
         | a more critical eye than one would a kid's side-project. I
         | think HN would have been pretty understanding if they were open
         | about the state of the various features and were a little less
         | defensive when they encounter articles that review it like a
         | Real Language.
         | 
         | If the authors don't want this kind of feedback they can just
         | say front-and-centre (or on their FAQ @
         | https://github.com/vlang/v/wiki/FAQ) "this is a toy" or "this
         | is pre-alpha" or "this is for research purposes". There are
         | plenty of projects like this which are open about their intent
         | and which don't have posts like this written about them. But I
         | don't think that'll happen, so as it stands the pattern will
         | continue - someone revisits the language every year or so,
         | finds some things that doesn't meet expectations, writes about
         | it and we discuss it on HN again.
        
       ___________________________________________________________________
       (page generated 2024-02-24 23:01 UTC)