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

141–150 of 336 posts

Re: V Language Review

#141

Post by tene »

sergiotapia wrote: post #48
smcl wrote: post #3

Christine Dodrill's early assessment of the language might be of interest here: https://xeiaso.net/blog/v-vaporware-2019-06-23 She doesn't pull any punches, but I think she was quite prescient in capturing the vibe of the project.

Nah that article is old as hell - time for new information. Things change. I also despise how many people want to shit on this new language before it even takes off. Why are so many people frothing at the chance to disparage this language and it's author? Never seen something like this.

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

Re: V Language Review

#142

Post by ptx »

Tozen wrote: post #79
mawfig wrote: post #74

Earlier quoted context omitted.

"A pure function is one without any side-effects." https://ocaml.org/docs/functional-programming "V functions are pure by default, meaning that their return values are a function of their arguments only, and their evaluation has no side effects (besides I/O)." https://github.com/vlang/v/blob/master/doc/docs.md#pure-func... It sure sounds to me like V is trying to claim that functions can be pure while still performin…

V's documentation is making it clear that it's not a purely functional language, so there should not be any such expectations. It also gives it's interpretation of what a pure function is, which other languages do as well, and there are various opinions about this. You appear to be unbothered by OCaml describing itself as "mostly pure", whatever such "marketing" truly means, but seem to take strong offense to V. Seem…

This thread appears to be conflating two different things: whether a language is a "purely functional language" and whether the language's functions are "pure functions".

Presumably a purely functional language would, it seems to me, be exclusively (i.e. purely) functional, i.e. the functions in the language would always be pure. A language that has pure functions and impure functions, on the other hand, would not be "purely functional" as it contains impure parts, but it could still contain pure parts as well.

The issue with V seems to be that, although everyone agrees that it contains impure parts and thus is not a "purely functional language", the supposedly "pure functions" are also not actually pure, according to some reasonable definitions of purity.

Re: V Language Review

#143

Post by ptx »

delian66 wrote: post #127
mawfig wrote: post #42

Earlier quoted context omitted.

Every evaluation in my blog is fully reproducible from the version of V I linked to and I've included all the source code used as well. My post stands on it's own. Instead of insinuating I'm some kind of competitor or have a personal agenda, I would encourage you to respond to the actual points raised in my post.

> I would encourage you to respond to the actual points raised in my post. ok, here is the first thing that I noticed, reading your blog post/review. > No undefined values ... > C allows you to use an uninitialized variable which can result in Undefined Behavior. I’ll assume that’s what this means. ... > Typically, uninitialized values come from a memory allocation that hasn’t been written to. ... > Let’s see if we c…

Hmm. So the claim article was examining here was "no undefined values", and you point out that the value is actually initialized to 0 and is thus not undefined.

However, the vlang.io page also makes the separate claim (as mentioned in the article) of "no null". But you seem to be saying that the bug in this case was actually a null pointer?

Re: V Language Review

#144

Post by the_duke »

lifthrasiir wrote: post #117
longrod wrote: post #95

I never understood the motivations behind V. 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. All that would be perfectly okay if V did what it claims to do but the author fanatically makes exciting claims but implements only fluff to hide the underlyi…

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.

Ductaped languages usually exist because they served some specific need, become popular and then evolved from there. PHP is the perfect example.

They were not "clean sheet, let's make a great new language" implementations.

Re: V Language Review

#145

Post by lifthrasiir »

the_duke wrote: post #144
lifthrasiir wrote: post #117

Earlier 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.

Ductaped languages usually exist because they served some specific need, become popular and then evolved from there. PHP is the perfect example. They were not "clean sheet, let's make a great new language" implementations.

PHP was already ductaped at the point of PHP/FI 2 [1], when it became more or less a proper programming language. PHP survived despite its ductape nature.

[1] https://www.php.net/manual/phpfi2.php

Re: V Language Review

#146

Post by dsego »

iamsahebgiri wrote: post #17
jitl wrote: post #12

My recommendation is that if you like the look of V, you should consider Zig or Odin as well. Personally, Zig seems like the most promising C-but-modern language due to the interesting compile-time programming features and impressive investment in toolchain infrastructure.

Where does language like Vala stand? Is it worth checking out?

Vala hasn't really caught on outside of the GTK world, since it's based on the glib object system.

Re: V Language Review

#147

Post by rurban »

creata wrote: post #132
rurban wrote: post #123

Earlier quoted context omitted.

Unfortunately that's needed nowadays to succeed. Java, Rust and many other would not be successful without standing on the shoulders of its big lies

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.

Re: V Language Review

#148

Post by agluszak »

rurban wrote: post #147
creata wrote: post #132

Earlier 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.

> The three securities they guarantee and cannot hold. Could you elaborate?

> null pointer segfaults They are not segfaults and are not related to memory safety. Segfault stands for "segmentation fault", not "runtime exception". https://en.m.wikipedia.org/wiki/Segmentation_fault

Re: V Language Review

#149

Post by slimygrapes »

creata wrote: post #88
mawfig wrote: post #74

Earlier quoted context omitted.

"A pure function is one without any side-effects." https://ocaml.org/docs/functional-programming "V functions are pure by default, meaning that their return values are a function of their arguments only, and their evaluation has no side effects (besides I/O)." https://github.com/vlang/v/blob/master/doc/docs.md#pure-func... It sure sounds to me like V is trying to claim that functions can be pure while still performin…

Yeah, "no side effects (besides I/O)" is so absurd it's funny.

Which means you are conceiving a strawman to mock.

The point is “no side effects other than IO” is a useful observation to make about how a language feels to use and the kinds of programs it encourages one to write.

Whether V is a good example of such a language I’ve no idea.

Re: V Language Review

#150

Post by pxeger1 »

crazywulf wrote: post #131
pxeger1 wrote: post #129

Earlier quoted context omitted.

I don't think this article contains any hatred. There is absolutely nothing wrong with an unfinished language - take a look at https://news.ycombinator.com/item?id=31775216 (2 days ago) for an example. This article criticises V for presenting itself as a usable language , when it definitely isn't, with all these features which don't work.

I don't think it is fair to criticize the language like that without having "0.2 ALPHA" in the title of the ycombinator title and the article. In fact the hole article does not contain the word "alpha" or explaining the state once. It reads like that the language is expected to be ready and that all features need to work now, but they don't. "At this time, I would not recommend spending time on V. I would also be ver…

I don't really care that they don't write "unfinished alpha" in big letters (although it would be nice if they did).

I care that they claim it has "no undefined behaviour", "as fast as C", "has generics", when these things are simply not true.

To use Ante as an example again, they literally have a checklist in the README, listing what is and isn't implemented yet.

Post reply on HN