Live data from Hacker News

V Language Review (2023)

n-skvortsov-1997.github.io

11–20 of 115 posts

Re: V Language Review (2023)

#11
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

Re: V Language Review (2023)

#14

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.

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

Re: V Language Review (2023)

#15
post #9

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 some…

What's amazing is how large the community became and how strong their love and belief was.

Re: V Language Review (2023)

#16
post #11

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…

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 :)

Re: V Language Review (2023)

#17
post #11

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…

Do not say that your software does something that in fact, it does not do.

Re: V Language Review (2023)

#18
post #11

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…

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.

Re: V Language Review (2023)

#19
post #11

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…

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.

Re: V Language Review (2023)

#20

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.

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.

Post reply on HN