V Language Review (2023)
n-skvortsov-1997.github.io
n-skvortsov-1997.github.io
- autofree doesn't work
- memory arenas (prealloc) isn't thread safe
- compiler produces large binaries
- coroutines invoke blocking calls
- community behavior is, uh, "unwelcoming"Their community, in comparison to others, even has their discussions open and open threads for criticism. Example.
I think part of the reason is that a lot of us want to believe something like V is possible, powerful safety features in a small conceptual and complexity footprint. So the first time we heard about V, we got excited, thinking maybe it could really be the cool thing it claims to be...
No one likes false hope. It really stings, actually. Then you find out they're not correcting their mistakes, which means they're doing it on purpose, which means they did it to you on purpose... that's the kind of thing that gets people pissed.
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?
https://andrewkelley.me/post/why-donating-to-musl-libc-proje...
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.
As someone uninitiated, you may not appreciate what a devastating burn that is.
That's a really big "kid's side project". Looking at V's GitHub stats:
35.2k Stars
722 Contributors
2.1k Forks
Possibly some are:
[1] Is V Lang Better Than Go And Rust? Let's Find Out
https://www.youtube.com/watch?v=puy77WfM1Tg
[2] V - Best Programming Language to Learn in 2023?
https://www.youtube.com/watch?v=jr1EBaLkjfc
[3] First Impression - V programming language
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]
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.
That, and a lot of the more advanced features were just broken.
I believe the war is already over, the other side forked the language and seems to move in their own direction to create something new - https://github.com/nim-works/nimskull . That's probably for the better.
I've been around Nim communtiy around a year and I haven't seen any major conflicts break out since these people left. Nim is still actively developed and a joy to use. And even the creator of the language, deemed as dictator or asshole by some, comes off only as grumpy old man (show me an old man who isn't grumpy, duh). Who also realizes his flaws and is willing to compromise.
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.
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.
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.
I've seen tons of computer science graduates hooking up gc to their languages in uni when they learn about compilers and programming languages
exec ["ld"; "-o"; out_file; obj_file]
exec ["ld"; "-o"; out_file; obj_file; "-lgc"]
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.
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/builtin/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...
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.
For instance, not understanding why try so hard to push a 2023 review for an old version of the language, when we are in 2024. But ok, here this is. It comes across as not being neutral because of the very personal dispute against V's creator, as revealed at the bottom of the blog. The super strange ranting displayed by the reviewer at the bottom, destroys all sense of neutrality, and disputably its credibility.
The review itself has various errors or problems that people gloss over or haven't caught some of: 1) It's weird to be complaining about autofree, when the documentation says its WIP and go use the GC for now. They clearly are giving user options for managing memory. 2) He was using the wrong or ignoring other compiler options. 3) The reviewer seems to be intentionally distorting or misrepresenting the coroutine situation; it's WIP and will be used on the Windows OS. 4) It's open source. Report to them or go help fix whatever is the issue, as other people have (hundreds of contributors).
For example, with the coroutines part, research (site and documentation) shows the V project will be using both OS threads and green threads for concurrency. Right now, they use OS threads, with the `spawn` and `go` keywords. In the future, the `go` keyword will only be for green threads, which the critic is referring to (corounties). At V's site, they are working on coroutines (green threads) for the Windows OS and are steadily working on implementing that into the language.
I would think most reasonable people would cut a volunteer open source project some slack and allow them time to improve upon what they are doing, but there appears to be some weird rush and other intent going on. Don't see V's community attacking anybody, just them happily focusing on their language, but it seems a lot of people are going after them, really hard.
I forgot what it was about but I haven’t heard about V since then. This article was interesting to read!
And lots of funding for then vaporware
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).
Ironic now when the compiler is written in Zig considering how Zig is advertising itself as being better at stability and reliability than C/C++ (the C3 compiler is written in C and Odin’s compiler is a C-like C++)
873 open, 7275 closed.
The ratio is important. What is it for the ones you listed?
Your post would be fine without the last sentence.
If you don't want to be banned, you're welcome to email hn@ycombinator.com and give us reason to believe that you'll follow the rules in the future. They're here: https://news.ycombinator.com/newsguidelines.html.
If you'd please review https://news.ycombinator.com/newsguidelines.html and stick to the rules when posting here, we'd appreciate it.
- 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.
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.
But Go is a working programming language.
I loved the idea of simplicity, autofree, the UI framework, the browser, Volt app, GitHub alternative, operating system and so much more. But it just didn't seem to go anywhere. The syntax however was simple, I really admired it and by 0.3 they would have a syntax freeze, but I do see that some major syntax has changed after 0.3 multiple times. I left the same day another developer did, and having talked with multiple V developers shortly after, four of them said they agreed to my criticism about moderation and broken promises. Alex (the creator) wrote to me personally, but denied all the criticism which was mentioned in the "V for Vaporware" articles.
In the moderator channel Alex mentioned that autofree wouldn't be delivered in 0.3 and this became my main criticism in the DMs. He could not see why I found it important to notify the community about this, while also telling me to "grow up" for not supporting offensive language, referencing some of the ways Linus Torvalds has written responses.
Shortly thereafter he blocked me privately. It wasn't clear to me if I was blocked though, as Discord just told me I couldn't reach him. So I contacted one of the moderators, who told me that it's due to culture differences.
At one point I even searched in the Discord for messages by Alex that contained "this week", "this month" and "this year", also using "next" instead of "this". It came out to 50+ times that deadlines had been missed (closer to 80+ probably). Even with some major projects such as Gitly from 2019 if I remember correctly, which still isn't done.
Shameless plug:
Please take a kind look at https://yakshalang.github.io/. I'd like to receive some criticism.
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).
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 :)
> 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.
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.
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.
That's an extraordinary claim, to say the least. And, as we all know, extraordinary claims require extraordinary proofs.
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.
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...
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.
And a lot the incidents I can think of, of people being unreasonable there, came AFTER attempts at reasonable requests were ignored.
But sure go off.
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.
What he is saying rings true. There is a level to all of this "that's beyond the pale".
> Is V production-ready?—no. Is Go? Yes, for a long time.
Go is a 10 years older (from 2009) corporate creation. It's not an apples to apples comparison, which can easily set the stage for tension in an interaction. It does not make sense to compare how production-ready a much older language is to a younger volunteer open source language in beta (and whose site and version number indicate that's so).
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.
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.
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.
> "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.
> 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).
Most people don’t have the energy for that and just move on. Which doesn’t help others.