Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

V Language Review

mawfig.github.io

Post reply on HN
Print view View original

281–290 of 336 posts

Re: V Language Review

#281

Post by amedvednikov »

somethingor wrote: post #93
klyrs wrote: post #87

Earlier quoted context omitted.

Your keep calling people "competitors." I don't think you're using the word right. Perhaps "detractors" is what you mean, but "reviewers" is more neutral. Xe and mawfig don't appear to be offering their own languages to compete with V. At one point, Andy Kelly (a "competitor") criticized the author's behavior, but he's also gone silent on the topic of V because of the vitriol he encountered. One reason that people hi…

> Andy Kelly (a "competitor") criticized the author's behavior, but he's also gone silent on the topic of V because of the vitriol he encountered AFAIK your stated reason for the silence is not accurate. Andy’s criticisms were always based on V making claims that no one could evaluate because it was closed source/unreleased (and then used those claims to solicit money from people). Once V was made open source, those…

No, he also had criticisms like "the V compiler depends on an OpenGL context creation library, so the claim that it has zero dependencies is false, the author is a scammer".

Re: V Language Review

#282

Post by mawfig »

amedvednikov wrote: post #276
klyrs wrote: post #274

Earlier quoted context omitted.

OP made a good faith effort hoping to find a sweet and working language, and the current implementation fell short of its long-advertised promises and accomplishments. That you're calling it a "hit piece" is telling. Y'all are well within your rights to waste your time arguing. I'm just saying that it's a waste of time.

Mostly all this post has is some type checker bugs that have already been fixed (of course the article will never be updated now that they're fixed) and using -prod for measuring compiler speed, when it's explicitly mentioned on the website it's for non optimized builds only. And nonsense like setting array length on creation is a terrible idea. Go with its `make([]int, 5)` must be a terrible scam language as well. I…

> Mostly all this post has is some type checker bugs that have already been fixed (of course the article will never be updated now that they're fixed)

Alex, all of these are still open right not and are not fixed:

- "No mut m := x mutability check" https://github.com/vlang/v/issues/14803

- "closure capture names are not checked for uniqueness with the closure parameter names" https://github.com/vlang/v/issues/14787

- "segfault in auto string method generated for []&int{len:1} (does not check for 0 pointers)" https://github.com/vlang/v/issues/14786

> using -prod for measuring compiler speed

My article does not do that. I included all the steps used and the 1,000,000 line tests use tcc and not -prod.

> And nonsense like setting array length on creation is a terrible idea. Go with its `make([]int, 5)` must be a terrible scam language as well.

V allows the user to override length field which is used in bounds-checking with no validation. That's the problem.

Please stop lying and just be honest about the state of V.

Given the behavior of you, Tozen and ylluminate on this thread, I have zero interest in interacting with the V "community" again.

Re: V Language Review

#283

Post by mawfig »

Tozen wrote: post #277
klyrs wrote: post #274

Earlier quoted context omitted.

OP made a good faith effort hoping to find a sweet and working language, and the current implementation fell short of its long-advertised promises and accomplishments. That you're calling it a "hit piece" is telling. Y'all are well within your rights to waste your time arguing. I'm just saying that it's a waste of time.

Nowhere did the OP state he came upon V in good faith to be helpful or seeking improvements, but rather starts with the position of whether or not it is worth it (setting up a position to dissuade). Then blasts the language in his summary and opinion (and who is he?), with a non recommendation. Never consults with the V community or opens any bug reports. He uses a throwaway name and account, then runs away from any…

Tozen, since no one has spelled it out for you: I am not obligated to sit at my keyboard refreshing the page constantly, waiting for your latest comment. I was here for 6 hours after posting and responded to many comments including multiple of yours where you continuously insinuated ill intent from me because I didn't give your pet programming language a recommendation.

The V project should feel free to pull any bug reports they want out of my blog post (I see they've already done so multiple times). From the votes on the comment section here, I can it's obvious to everyone how dysfunctional the V community is which explains a lot about the state of the project. I will not be interacting with you again.

Re: V Language Review

#284

Post by lifthrasiir »

ylluminate wrote: post #280
vlang1dot0 wrote: post #271

Earlier quoted context omitted.

Did you even bother to read what he pasted? Tcc is used in the first set of commands that do not terminate.

He is in fact reading it, please look again at what he pasted. It really seems somehow you're getting your wires crossed.

No he didn't understand at all. Both the OP and I'm saying that while `make` claims that tcc was not used, the compiler does seem to use tcc even in that case. I have demonstrated that this is a plausible explanation by moving the tcc binary and showing the stark performance difference.

(This is my final response on this matter. I have already given enough information and an inability to interpret it is not my business.)

Re: V Language Review

#285

Post by kristoff_it »

Tozen wrote: post #249
yjftsjthsd-h wrote: post #103

Earlier quoted context omitted.

> It's clearly not a hobby project started out by a developer who is genuinely experimenting with PLs and want to put out something unique. It feels more like a stunt or a flair to either extort money or become famous. Is that obvious? Yes, if I put on my cynical hat it pattern matches a money-grab or some other sort of fraud, but if I put on my charitable-interpretation hat V also perfectly pattern matches my idea o…

The V language pattern matches with new programming language initiatives such as Odin or Zig. It is in the category of both C and Go alternatives. Note- just by being a strong Go alternative by itself, one can see possible "behind the scenes" conflicts and motives. Though both V and Odin really should be fully embraced, because they continue the direction and changes in thinking started by Go, while providing feature…

You must come from an alternative reality because all that V achieved in terms of popularity is a big initial uptick of GitHub stars and donations obtained thanks to straight-up, no-discussion, clear-as-sky false advertising.

When it comes to sponsors and donations, V is far (really far) from the best in the category. Not to mention that Zig has a proper non-profit foundation, which is a far greater achievement than GitHub stars or even sponsors.

All your comments in this thread are in disagreement with reality to the same absurdist degree of conspiracy theories. And of course you yourself can't help but point out that everything is a conspiracy against V, which is laughable.

Re: V Language Review

#286

Post by amedvednikov »

mawfig wrote: post #282
amedvednikov wrote: post #276

Earlier quoted context omitted.

Mostly all this post has is some type checker bugs that have already been fixed (of course the article will never be updated now that they're fixed) and using -prod for measuring compiler speed, when it's explicitly mentioned on the website it's for non optimized builds only. And nonsense like setting array length on creation is a terrible idea. Go with its `make([]int, 5)` must be a terrible scam language as well. I…

> Mostly all this post has is some type checker bugs that have already been fixed (of course the article will never be updated now that they're fixed) Alex, all of these are still open right not and are not fixed: - "No mut m := x mutability check" https://github.com/vlang/v/issues/14803 - "closure capture names are not checked for uniqueness with the closure parameter names" https://github.com/vlang/v/issues/14787 -…

> V allows the user to override length field which is used in bounds-checking with no validation. That's the problem.

No it doesn't, it can only be set on init.

Please stop lying and just be honest about the state of V.

You never interacted with the community, never reported the bugs, never discussed these issues on Discord. Gotta create a new account and spread disinfo.

Re: V Language Review

#287

Post by amedvednikov »

mawfig wrote: post #283
Tozen wrote: post #277

Earlier quoted context omitted.

Nowhere did the OP state he came upon V in good faith to be helpful or seeking improvements, but rather starts with the position of whether or not it is worth it (setting up a position to dissuade). Then blasts the language in his summary and opinion (and who is he?), with a non recommendation. Never consults with the V community or opens any bug reports. He uses a throwaway name and account, then runs away from any…

Tozen, since no one has spelled it out for you: I am not obligated to sit at my keyboard refreshing the page constantly, waiting for your latest comment. I was here for 6 hours after posting and responded to many comments including multiple of yours where you continuously insinuated ill intent from me because I didn't give your pet programming language a recommendation. The V project should feel free to pull any bug…

You create a new account here to post your newly created "blog" with this attack on V 0.2 (a pre 1.0 language which you forget to mention) which is mostly based on some type checker bugs (that could've been reported in fixed within a week) and nonsense like "setting array length on creation is a terrible idea". (Go with its `make([]int, 5)` must be a terrible scam language as well.)

And you have the audacity to call the V community dysfunctional.

Re: V Language Review

#288

Post by tene »

amedvednikov wrote: post #267
tene wrote: post #141

Earlier quoted context omitted.

> Why are so many people frothing at the chance to disparage this language and it's author? It's because of all the lying. The author keeps claiming that their language has features that it definitely does not have. Why do so many people consider "I checked several notable claims, and most of them are false" to be some kind of hateful disparaging attack?

Can you list the false claims here? 1. 2. 3. Shouldn't be hard, if "most claims" are false according to you.

I was referring to both the original post, and Xe's older post that this comment thread is about. They both list claims made by V and describe details how they tested those claims and what their results were.

https://mawfig.github.io/2022/06/18/v-lang-in-2022.html https://xeiaso.net/blog/v-vaporware-2019-06-23

Re: V Language Review

#289

Post by amedvednikov »

lifthrasiir wrote: post #284
ylluminate wrote: post #280

Earlier quoted context omitted.

He is in fact reading it, please look again at what he pasted. It really seems somehow you're getting your wires crossed.

No he didn't understand at all. Both the OP and I'm saying that while `make` claims that tcc was not used, the compiler does seem to use tcc even in that case. I have demonstrated that this is a plausible explanation by moving the tcc binary and showing the stark performance difference. (This is my final response on this matter. I have already given enough information and an inability to interpret it is not my busine…

I admit I misread, and you do indeed use TCC.

I've just tested it, and turns out all C compilers are terrible at hundreds of thousands of print calls (for me Clang was stuck for minutes with 100% cpu usage).

The claim was made about actual code, like the V compiler itself, which is about 220k loc and compiles in 0.3 seconds, not some unrealistic test with a million of prints.

I'll make it clear on the home page with a link to the benchmark.

Re: V Language Review

#290

Post by amedvednikov »

tene wrote: post #288
amedvednikov wrote: post #267

Earlier quoted context omitted.

Can you list the false claims here? 1. 2. 3. Shouldn't be hard, if "most claims" are false according to you.

I was referring to both the original post, and Xe's older post that this comment thread is about. They both list claims made by V and describe details how they tested those claims and what their results were. https://mawfig.github.io/2022/06/18/v-lang-in-2022.html https://xeiaso.net/blog/v-vaporware-2019-06-23

Do you have anything more legit because these posts have nonsense like "setting array length on creation is a terrible idea" (Go with its `make([]int, 5)` must be a terrible scam language as well) and measuring the performance of a debug build, with slow backend, without vlib cached, and with vfmt on.

You can see that V is actually as fast as is claimed on the website:

https://www.youtube.com/watch?v=pvP6wmcl_Sc

Same with other points from the author that publicly claimed that "V has to die".

Like I said, if "most claims are false" on vlang.io, as you claim, it shouldn't be hard to list 3 of them here.

Post reply on HN