3 ms·

The post is unnecessarily hostile. Created by a new anonymous account, with the goal of attacking V and "not recommending to use it". Also with referencing the

The post is unnecessarily hostile. Created by a new anonymous account, with the goal of attacking V and "not recommending to use it". Also with referencing the notorious ridiculous "V is vaporware" articles, it's pretty clear what the goal of the author was. It'd take 10 minutes to submit github issues, instead they spent a month on this. Null is only allowed in unsafe code. Overwriting of len was never fixed, because it was never an issue in the first place. The author made it up. It's always worked like in Go. Included libraries, you mean the json library that's part of vlib. So each Go program that uses net.http also has library dependencies by this logic.

dmux 4y ago
>It'd take 10 minutes to submit github issues, instead they spent a month on this. If the author put in the work, I don't see the problem with it being a blog post. Also, given the history of github comments / issues being removed from the vlang github project, I don't blame them for wanting to keep their post for posterity.
- amedvednikov 4y ago
  Lol, no issues/comments are removed. One and only time a github comment was removed was before the open source release and I just started this new job of an open source maintainer. Actually, sorry, I did remove one issue recently. It said "Delete this project, it's a joke".
Calavar 4y ago
This is all around a terrible and nonconstructive attitude. > The post is unnecessarily hostile. Created by a new anonymous account, with the goal of attacking V and "not recommending to use it". What about it was hostile? It was written in a very neutral tone and was almost exclusively fact based, with just a couple of summative comments about the author's overall impressions at the end. How could you possibly know the motives of an anonymous author? Seems like the author was smart to remain anonymous too, given the amount of vitriol the V community has directed his/her way for writing the review. > Also with referencing the notorious ridiculous "V is vaporware" articles, it's pretty clear what the goal of the author was. Of course a review will mention a widely circulated previous review. As much as you might like to pretend that it never existed, this isn't the CCP where we can expunge things that we don't particularly like from the historical record. > It'd take 10 minutes to submit github issues, instead they spent a month on this. I see, reviews are only okay if they are positive. Otherwise they must be github issues. What a convenient way to make sure that no negative review is ever "by the rules" and to question the motivations of anyone who dare write one.
- Tozen 4y ago
  > What about it was hostile? It was written in a very neutral tone and was almost exclusively fact based, with just a couple of summative comments... The review started out hostile by links to blogs and posts that smear V and the author from outright competitors and detractors! Completely unnecessary, if the purpose of the review was to stand on its own merits. It also sets the tone, of not being neutral, from the very start. And, links itself with other attack blogs and threads from the past. It made itself the newest link in the chain of attacks. The review is highly opinionated. It's an evaluation of claims, where the author gives his opinions on their validity. The author never gives readers his qualifications for even being able to properly evaluate the language, and uses a throwaway account, where he can easily run away. The V developers are held accountable for their opinions, but not the reviewer. You can never hold the author of the review accountable for anything he got wrong, was mistaken about, or is missing. It's also not a fair or objective evaluation, where he sought to get any input from V developers to clarify their positions about claims made. So it's his own one-sided perspective. He is going to be one-man judge, jury, and executioner. And that one-man judge's sentence is, "...I would not recommend spending time on V". Which is clearly very negative. It is also very presumptuous, that readers should come to his same negative conclusions, versus do their own evaluation, check out what the V community has to say, or check out the latest version of V. > I see, reviews are only okay if they are positive. Otherwise they must be github issues. Nobody said that reviews must only be positive. What is being conveyed is that if the reviewer really had a problem with using V, wanted it to become production-ready, or wanted something fixed then the way to do it is to submit issues or discussions to V's GitHub. Otherwise, it shows the intention that one's purpose is not to fix anything, but to spread drama and smear. The reviewer has a throwaway GitHub account, where it would have been easy for them to verify various conclusions with developers, submit issues, or create a discussion at V's GitHub site.
anderskaseorg 4y ago
> Null is only allowed in unsafe code. That’s clearly not the case, as the exact code in the post prints ‘&nil’ in current V master, and if you add a dereference you get a segfault (which someone else just filed as https://github.com/vlang/v/issues/14911 https://github.com/vlang/v/issues/14911). > Overwriting of len was never fixed, because it was never an issue in the first place. The author made it up. The home page claims the language has “no null (allowed in unsafe code)”. println(*[]&int{len: 1}[0]) is not marked unsafe, yet it still segfaults by dereferencing a null pointer. Can you explain why you say this was never an issue? (I’ve filed this as https://github.com/vlang/v/issues/14914 https://github.com/vlang/v/issues/14914. A related issue in maps was filed a year ago: https://github.com/vlang/v/issues/10837 https://github.com/vlang/v/issues/10837.) > It's always worked like in Go. Go is not a language that claims to have no null.

dmux 4y ago

>It'd take 10 minutes to submit github issues, instead they spent a month on this. If the author put in the work, I don't see the problem with it being a blog post. Also, given the history of github comments / issues being removed from the vlang github project, I don't blame them for wanting to keep their post for posterity.

amedvednikov 4y ago
Lol, no issues/comments are removed. One and only time a github comment was removed was before the open source release and I just started this new job of an open source maintainer. Actually, sorry, I did remove one issue recently. It said "Delete this project, it's a joke".

Calavar 4y ago

This is all around a terrible and nonconstructive attitude. > The post is unnecessarily hostile. Created by a new anonymous account, with the goal of attacking V and "not recommending to use it". What about it was hostile? It was written in a very neutral tone and was almost exclusively fact based, with just a couple of summative comments about the author's overall impressions at the end. How could you possibly know the motives of an anonymous author? Seems like the author was smart to remain anonymous too, given the amount of vitriol the V community has directed his/her way for writing the review. > Also with referencing the notorious ridiculous "V is vaporware" articles, it's pretty clear what the goal of the author was. Of course a review will mention a widely circulated previous review. As much as you might like to pretend that it never existed, this isn't the CCP where we can expunge things that we don't particularly like from the historical record. > It'd take 10 minutes to submit github issues, instead they spent a month on this. I see, reviews are only okay if they are positive. Otherwise they must be github issues. What a convenient way to make sure that no negative review is ever "by the rules" and to question the motivations of anyone who dare write one.

Tozen 4y ago
> What about it was hostile? It was written in a very neutral tone and was almost exclusively fact based, with just a couple of summative comments... The review started out hostile by links to blogs and posts that smear V and the author from outright competitors and detractors! Completely unnecessary, if the purpose of the review was to stand on its own merits. It also sets the tone, of not being neutral, from the very start. And, links itself with other attack blogs and threads from the past. It made itself the newest link in the chain of attacks. The review is highly opinionated. It's an evaluation of claims, where the author gives his opinions on their validity. The author never gives readers his qualifications for even being able to properly evaluate the language, and uses a throwaway account, where he can easily run away. The V developers are held accountable for their opinions, but not the reviewer. You can never hold the author of the review accountable for anything he got wrong, was mistaken about, or is missing. It's also not a fair or objective evaluation, where he sought to get any input from V developers to clarify their positions about claims made. So it's his own one-sided perspective. He is going to be one-man judge, jury, and executioner. And that one-man judge's sentence is, "...I would not recommend spending time on V". Which is clearly very negative. It is also very presumptuous, that readers should come to his same negative conclusions, versus do their own evaluation, check out what the V community has to say, or check out the latest version of V. > I see, reviews are only okay if they are positive. Otherwise they must be github issues. Nobody said that reviews must only be positive. What is being conveyed is that if the reviewer really had a problem with using V, wanted it to become production-ready, or wanted something fixed then the way to do it is to submit issues or discussions to V's GitHub. Otherwise, it shows the intention that one's purpose is not to fix anything, but to spread drama and smear. The reviewer has a throwaway GitHub account, where it would have been easy for them to verify various conclusions with developers, submit issues, or create a discussion at V's GitHub site.

anderskaseorg 4y ago

> Null is only allowed in unsafe code. That’s clearly not the case, as the exact code in the post prints ‘&nil’ in current V master, and if you add a dereference you get a segfault (which someone else just filed as https://github.com/vlang/v/issues/14911 https://github.com/vlang/v/issues/14911). > Overwriting of len was never fixed, because it was never an issue in the first place. The author made it up. The home page claims the language has “no null (allowed in unsafe code)”. println(*[]&int{len: 1}[0]) is not marked unsafe, yet it still segfaults by dereferencing a null pointer. Can you explain why you say this was never an issue? (I’ve filed this as https://github.com/vlang/v/issues/14914 https://github.com/vlang/v/issues/14914. A related issue in maps was filed a year ago: https://github.com/vlang/v/issues/10837 https://github.com/vlang/v/issues/10837.) > It's always worked like in Go. Go is not a language that claims to have no null.