Comment by arp242
1 year ago
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).
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.
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.
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.
Do not say that your software does something that in fact, it does not do.
That should be one of the n commandments of software development.
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.
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...
> 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.
1 reply →
I would argue that at least some of the grief GNOME gets is deserved. Especially given their attitude towards their users.
2 replies →
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.
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.
>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.
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).
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 :)
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.
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.
3 replies →