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…
V Language Review (2023)
31–40 of 115 posts
Re: V Language Review (2023)
#32A 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…
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.
Re: V Language Review (2023)
#33Earlier quoted context omitted.
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.
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.
Re: V Language Review (2023)
#34Re: V Language Review (2023)
#35A 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)
#36A 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…
Re: V Language Review (2023)
#37A 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…
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.
Re: V Language Review (2023)
#38A 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…
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.
Re: V Language Review (2023)
#39I 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.
Re: V Language Review (2023)
#40A 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 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.