Adding a mention that V is still far from 1.0 in the title or at the beginning would have been honest.
V Language Review
211–220 of 336 posts
Re: V Language Review
#212Earlier quoted context omitted.
They call names to anybody who dares to ask a genuine question they don't like. It's a meme by now, how easy it is to get banned on V's discord server. I've a feeling that author tried to bring these issues on their discord server, got himself banned and then decided to write a blog.
Quoted post unavailable.
Well I started talking with Nim chat, and that was very good advice, thanks!
Re: V Language Review
#213Quoted post unavailable.
Really? I didn't catch that vibe at all. You're saying if you do this without involving the community it is trolling? I guess it is fair to run the article by the community somehow, but I'm not sure the best approach to that. I'm doing a similar thing for Nim so I would like to not be seen as trolling.
Not sure what you want to test, though I'd bet that if you post questions on forum.nim-lang.org then you will get good help.
Anyway, to maybe get you started, Nim compile speed is usually best with a tcc backend (nim c --cc:tcc or set that in config.nims/nim.cfg). Meanwhile, run-time speed is usually best with gcc PGO.
Re: V Language Review
#214Earlier quoted context omitted.
100% right. It's sick. As a donor and supporter of this VALIANT AND VALID effort, I applaud the V community. It's full of sincere passion, love and is putting forth a great effort to realize something useful and needed in this sector.
So you think it's okay to lie and mislead people? You're going round the comments and telling everybody how wrong they are. Do you have any thing to say about concerns raised in the blog post? Or would you say that it's a lie and all the points raised are based on falsehood?
No post body was provided.
Re: V Language Review
#215Re: V Language Review
#216Earlier quoted context omitted.
Ductaped languages can be extremely useful though (cf. PHP). But extraordinary claims were what failed V and---sadly and contrary to my remaining hope---continue to do so.
Can you list here the extraordinary claims that failed please.
Read correctly; I said extraordinary claims failed V. But the other reading doesn't seem to paint a pretty picture anyway. Every point made in the original article is a reasonable expectation by outsiders, and many of them are still unsatisfactory ("failed claims" if you like).
What you should do now is to decide what to do with those points instead of arguing. If the decision is WONTFIX (okay to do, not everything can be made into the language) then the advertisement should be updated (ProTip: you should really have done this years ago). If the decision is to do something with that then the advertisement should be still updated, hopefully with a link to the tracking issue. If you are already doing something about that then you still should have a link to the tracking issue. If the point is "misleading", then you should write out clearly why it's misleading, how the author could have concluded in that way (i.e. assume no malice and debug instead), and how to verify your updated claim. With no strings attached.
Honestly though these points have been iterated and reiterated years ago. I had a hope that you have learned (hard) from that past experience; my hope seems not justified.
Re: V Language Review
#217Earlier quoted context omitted.
They call names to anybody who dares to ask a genuine question they don't like. It's a meme by now, how easy it is to get banned on V's discord server. I've a feeling that author tried to bring these issues on their discord server, got himself banned and then decided to write a blog.
Quoted post unavailable.
And what gives you authority to decide what a person should or shouldn't do?
If you really think that the blog doesn't represent the facts right, go ahead write your own blog with the justifications, we'll be eager to read.
Re: V Language Review
#218> Variables aren’t immutable in any significant way because you can trivially turn an immutable reference into a mutable one. To be fair, they didn't claim that the values were immutable, only the variables. Isn't the example in the article basically the same as Java's final variables, i.e. immutable references to mutable values? > No global variables [...] Evaluation: V does not prevent you from creating and mutatin…
Quoted post unavailable.
This is absurd. It is now a V team's job to continue with, not the other way around. In fact, this kind of outsider perspective is very valuable to growing language communities because it's plain impossible to attain by themselves. As long as the article is not written in a derogatory tone (and I believe not) the OP's job is done by now.
Re: V Language Review
#219Earlier quoted context omitted.
What lies did the Rust developers make? (Also, "nowadays" must stretch out to many decades if you're including Java!)
The three securities they guarantee and cannot hold. Fearless concurrency. Java also promised memory safety. I still get Null pointer segfaults in Java code.
If you know of a case where rust code violates memory safety without the use of an unsafe block, file a bug and it will probably be fixed within a release or two.
"Fearless concurrency" is more subjective, but rust code (again with the caveat that there isn't unsafe code, or unsafe cose upholds all unvariants) dows eliminate certain classes of concurrency bugs. Although, dreadlocks are definitely possible, and certain kinds of race conditions could potentially exist. But I don't know of any claims that concurrency bugs are impossible in rust.
Re: V Language Review
#220Earlier quoted context omitted.
The three securities they guarantee and cannot hold. Fearless concurrency. Java also promised memory safety. I still get Null pointer segfaults in Java code.
If you know of a case where rust code violates memory safety without the use of an unsafe block, file a bug and it will probably be fixed within a release or two. "Fearless concurrency" is more subjective, but rust code (again with the caveat that there isn't unsafe code, or unsafe cose upholds all unvariants) dows eliminate certain classes of concurrency bugs. Although, dreadlocks are definitely possible, and certai…
Someone pointed out an obvious one: You can open the file "/dev/mem" or equivalent on many Unix systems and break things horribly, and rust can't tell that you're doing it or stop you. Someone used this to write an unsafe-free transmute, which is probably at least two different war crimes.
I doubt the rust team will try to "fix" that.