Live data from Hacker News

V Language Review

mawfig.github.io

291–300 of 336 posts

Re: V Language Review

#291
post #273
post #269

Earlier quoted context omitted.

TFA has plenty. Don't let yourself get mired in fights on the orange site. Instead, spend the energy fixing bugs and you'll meet less criticism in the future.

I think that V developers and contributors are well within their rights to address criticisms of their work by detractors. Additionally, the OP has ran away from engaging in debate about various errors and opinions from their review, in an apparent attempt to leave an arguably underhanded one-sided negative impression (which includes suggesting not to use). So we have a situation where the OP created a hit piece with…

I believe I know who the OP is and it's a very sad situation of simple hurt feelings from largely misunderstanding. It's a sad situation actually, but such is life and differences of cultures and human interaction. I feel bad for the OP to have had to have felt so badly that they felt the necessity to post this hit piece vs trying to really address the issues that other community members have gathered from it as actual issues to resolve. So sad.

Re: V Language Review

#292

Earlier quoted context omitted.

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…

Understandable to misread - I, funnily, did as well as I was quickly going down through the original comment + replies.

Re: V Language Review

#293
post #282

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

Seriously? Talk to me privately if you have any actual demonstrable problems with me. It's not like I don't know who you are, but I'm not directly calling you out here for your desire to remain anonymous.

Re: V Language Review

#294
post #283
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…

No post body was provided.

Re: V Language Review

#295
post #249

Earlier quoted context omitted.

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…

Says a competitor from the Zig software foundation, as if you wouldn't have any ulterior motives, to include a clearly divergent reality.

If anything, I suppose the urge was too great, to not expose yourself.

Re: V Language Review

#296
post #278

Earlier quoted context omitted.

If the bugs are fixed, put 'em in your CI and blog about it. Taking my own advice here, I've got better things to do than argue with you.

So you're going to slander me, make a very strong accusation, call V (the work of hundreds of contributors) a "vapor", and when asked for a single proof you just say "I don't have time for this"? What a nice character you are.

I've been arguing on the internet longer than you've been alive. I don't claim to be nice, but here is a gift: in time, either you'll learn not to waste your time in this manner and let your results speak for themselves, or you'll fade away to insignificance. (here I am, insignificant, and breaking my own rule)

Re: V Language Review

#297
post #288

Earlier quoted context omitted.

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…

You've misunderstood my intent. In "I checked several notable claims, and most of them are false", I was trying to say that most of the notable claims that the author decided to check were false.

This is very different from saying most of the statements on the website are false, which would be a completely absurd accusation, as you correctly point out.

The summary section is literally a list of specific claims and the author's evaluation of these specific claims: https://mawfig.github.io/2022/06/18/v-lang-in-2022.html#summ...

My comment was refuting that these posts are not "frothing at the chance to disparage this language and it's author". I stand by my refutation that these posts are appropriate, specific, relevant criticism, and that they cite specific evidence for their specific disagreements with the stated claims.

You are certainly welcome to disagree with this author's claims! That sounds like appropriate, specific, relevant criticism of this author's claim. Would you say that you are "frothing at the chance to disparage this author"? I don't.

I'll admit to some satire in my top comment on this subthread. By saying "It's because of all the lying", I was partly satirically reacting to what I saw as inappropriate hyperbole in "frothing at the mouth to disparage". I broadly agree that the V website is fine, just a little distasteful by my aesthetic.

If you think it's fine for V documentation and advocacy to overstate their case and not mention significant gaps in what they claim the language has, I can't see how you'd call it inappropriate for other people who care about the production-suitability of a language to explicitly document what they believe to be major gaps in the production-readiness of a language claiming to have important safety features people want to rely on.

For some context on my interpretation of these posts, I think about how many times over my career I've had to deal with software that claims to have "just a few bugs" on something important, but somehow the bugs never actually get fixed, and the fully general solution just never appears. These things really are genuinely difficult to design and build a fully general solution for. It takes time and engineering work, as we can see by these people finding a lot of holes as soon as they looked.

As an engineer, I've had a lot of frustration from dealing with bugs and outages and maintenance issues that can be significantly improved by a good language. That's why I care so much about really wanting these things that V claims to have, and also why I care so much about the details of how exactly the claims currently fall short. It's so easy to overpromise, so I'm skeptical of any marketing for a new still-in-development tool that just claims to have solutions, with no big disclaimers about how they're still incomplete.

Regarding your specific example, the problem that's being implied by the "setting array length on creation is a terrible idea" is that every time you're setting an array length in V, any mistake will not be caught by the compiler, and can be an exploitable memory safety violation. Memory safety vulnerabilities really truly have been and continue to be a serious ongoing source of serious computer security problems. V making various memory safety claims like no null and no reading from uninitialized memory, and then that being trivially broken on literally the most obvious possible violation, without even any safety marker to make sure it's obvious that this is a place where you can violate memory safety, means that it's just not a language I want to use.

I agree that these posts are very passionate. I assert that these posts come from a passionate interest in what V aspires to be, and they hold V to a high standard, and find it believable that V can actually hit that high standard, and so they've checked it, and here are the places where you'll need to be extremely careful if you want to really rely on this in a high-reliability setting. It is not frothing at the mouth, and it is not disparagement; it is accurate and precise and specific and appropriate feedback, along with some emotional expression that I find relatable and appropriate.

Re: V Language Review

#298
post #297

Earlier quoted context omitted.

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…

You've misunderstood my intent. In "I checked several notable claims, and most of them are false", I was trying to say that most of the notable claims that the author decided to check were false. This is very different from saying most of the statements on the website are false, which would be a completely absurd accusation, as you correctly point out. The summary section is literally a list of specific claims and th…

> every time you're setting an array length in V, any mistake will not be caught by the compiler

What mistake? Does this apply to literally every other language, like Go with its `make([]int, len)`.

> If you think it's fine for V documentation and advocacy to overstate their case and not mention significant gaps in what they claim the language has

Can you link to such examples in V documentation?

Re: V Language Review

#299

Earlier quoted context omitted.

V has global consts, they are immutable, but can be initialized with complex expressions, for example `const x = foo()` There's a bug that allows to trick the compiler and modify the const via another variable, it's a one line fix, and will be fixed today. Global mutable variables are only allowed with `-enable-globals` and are supposed to be used only in low level code, like drivers and kernels.

How's that "one line" fix in the type checker coming? Looks like it wasn't fixed yesterday.

It was fixed, but you keep fighting your fight. I'm sure there's another bug you can find to spread the "V is scam" message.

Re: V Language Review

#300
post #296

Earlier quoted context omitted.

So you're going to slander me, make a very strong accusation, call V (the work of hundreds of contributors) a "vapor", and when asked for a single proof you just say "I don't have time for this"? What a nice character you are.

I've been arguing on the internet longer than you've been alive. I don't claim to be nice, but here is a gift: in time, either you'll learn not to waste your time in this manner and let your results speak for themselves, or you'll fade away to insignificance. (here I am, insignificant, and breaking my own rule)

Again, you slander me and hundreds of contributors, make strong accusations without any proofs, and now you're saying some crap about being old and that's who you are.

Like I said, it's already pretty clear what kind of character you are.

Post reply on HN