4 ms·

So, the review was my only contact with V until today, and I have to say your response seems unnecessarily hostile. I understand there night have been a lot of

by ketzu 4y ago

So, the review was my only contact with V until today, and I have to say your response seems unnecessarily hostile. I understand there night have been a lot of negativity around your project and it seems to be successful despite these, so nice for you. The post seems to spend quite a lot of time on the V language and discussing it, so I got curious and put in some of the examples into V for windows. The results seem to be different, but my knowledge on V is too low to understand the implications fully. The "No null" experiment does not give a segmentation faul, instead it prints &nil. That seems to be effectively a null value to me though. Adding another layer of null dereferencing creates an access violation/sefault. The undefined behaviour for integer overflow is the exact same as in the post. (edit: and in the github issues it is marked as "won't fix" it seems V does not care about creating undefined behavior in the generated C code, just that the behavior is defined within V.) The overwriting of len for the array seems to be fixed as the capacity is increased to the value of len seems to return nil references now. The immutable->mutable trick seems to be caputred by the type checker. The remarks on included libraries seems to hold, as well as the "simple webserver" being 2MB when compiling (although openssl seems to be included now). I have no motivation to redo all the other experiments in the blog post. And your response as well as the small checks leave me not-very-impressed with V, as I can't take any of the claims on the website seriously like that. If you claim it is a v0.1 or v0.3 language, sure, make a list of features that actually exist or a roadmap when they are reached. This is especially true for the "novel memory management" which seems optimistically to assume it worked before when a changenote is included that the compiler doesn't leak memory anymore by default. That is not particularly instilling confidence, although it's the right direction.

amedvednikov 4y ago
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.
super_flanker 4y ago
> The immutable->mutable trick seems to be caputred by the type checker. Just add the immutable variable's reference to a mutable array, now mutate the immutable variable using array[0], magic!! The compiler is so basic and naive, it's laughable how their authors have guts to fight everyone about it's stability.

by ketzu 4y ago

amedvednikov 4y ago

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.

super_flanker 4y ago

> The immutable->mutable trick seems to be caputred by the type checker. Just add the immutable variable's reference to a mutable array, now mutate the immutable variable using array[0], magic!! The compiler is so basic and naive, it's laughable how their authors have guts to fight everyone about it's stability.