V Language Review | Hacker News Reader

V Language Review

mawfig.github.io

297 pointsmawfig298 comments

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 underlying broken machinery.

I tried V when it first got popular (about 3 years ago). I am no expert on languages but the way it was ductaped (AST-less compiler for "performance", a "graphic library" when even basic things don't work etc etc) made me eventually lose interest.

3 years later V is still mostly where I left it. If the V author focused on the stabilizing the compiler instead of starting off shoot projects like vui, vdb etc. it might actually work.

> 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 of "solo developer wants to create the perfect language and goes after it with fresh eyes and a lot of enthusiasm (and yes, does get slowed down when it comes to fleshing out every little detail correctly and fully)". How do you distinguish?

Yeah, a lot of projects that fall through aren't actually made by scam artists or people trying to make a quick buck. I'd wager most of these are just by overly ambitious people that massively underestimate the challenge of getting there.

It's especially prevalent in indie gaming and large Kickstarters. Some are actually scams, but a lot are just entirely out of their depth and realize this too late/only when their deadlines come due. And yet there are content creators which just make video after video just shitting on these people. Quiet sad all around.

(Though that link from the sister comment does make it look quiet bad in this case. Projects that just make great sounding claims about the current state of the project, even though none of it is true can't be taken seriously in my opinion.)

> when it comes to fleshing out every little detail correctly and fully

In the case of V it's not only about details. Memory management, for example, is a fundamental part of a programming language and not something you can do as an afterthought. It is still not clear at all how memory management works in V.

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 features that such users might crave or have wanted.

V has been more successful than other newer programming languages at getting sponsors and supporters (check V's GitHub or vlang.io), to include publicity, both very good and at times negative (which appears to include angry detractors). It also has been developing at a more rapid pace than other languages in its category.

From looking at the history, some of the controversy appears to come from years ago and whether or not the language was real or was going to be released, because it was already "advertising" itself and had sponsors. Keep in mind that other languages have a very hard time at getting sponsors, supporters, or users. So, that another language getting what they are not able to or feel they deserve, can become a source of conflict as well.

My opinion is that the V creator did nothing wrong, because it was a very smart decision to attract sponsors and users, and the creator did release the language. This alone already separated V from the many languages we never know or hear about, the ability to get enough sponsors and supporters to sustain growth and momentum.

Yeah, it's might seem great to be a solo developer making what he/she feels is the perfect language as a hobby, but at some point the enthusiasm stops or the person realizes what's the point if nobody cares and nobody uses it.

Another aspect of this situation is it appears detractors were running with the narrative that V was "fake" or "vaporware", and then when it was actually released, they had to reset their narratives. You can't claim that something that exists and is used by many, is "fake" or non-existent. So then the attacks appear to then go for whatever might stick. Anything about the language, which is "not perfect" or as they feel is claimed, is then targeted. This is why we have these odd and controversial takedown attempts of a language which is still in alpha and evolving. I'm very much not saying that people shouldn't be criticizing or pointing out flaws, but rather it doesn't need the viciousness or underhandedness of trying to persuade people to stop using or attempts to kill it off.

Ultimately, just don't think that such tactics are going to work, because V has such strong community support and is continually improving. V is well on the path of becoming a very viable and highly useful language.

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.

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.

I'm not in the ZSF, although I do throw $50 a month to them, even though I don't use Zig. I use Rust a lot personally. I just like what Zig is doing. They haven't achieved all of their goals yet---just like V hasn't---but I look forward to when they do. And they've already produced some awesome stuff. While there are many differences between Zig and V, one of the most important ones is that Zig doesn't falsely advertise. If they did, I wouldn't contribute a single cent to them.

I totally agree with kristoff here and also munificent[1]. Y'all have a massive victim complex on grand display in this thread and exhibit the classical signs of projecting your own issues on to everyone else.

[1] - https://news.ycombinator.com/item?id=31795322

The V community does not create these continuous attack threads or blogs (which is very obvious when reading them), nor told competitors or detractors to come join in on these underhanded attacks.

The "projection", is coming from yourself. That you are a supporter of Zig and Rust, is your own business, that's not the focus of this thread or what my comments are about. But clearly you couldn't help yourself to come do some bashing of a rival language, then gaslight about why there might be a reaction to it.

The OP isn't an attack. That's the victim complex I'm talking about. It's a standard experience report.

Your attempts at gaslighting won't work. The OP appears to have created a throwaway account for the purposes of recommending to not use V and then to be used as a linked reference document for further attacks by competitors and detractors, as has already happened on various other internet sites, including here. This is also a pattern of attack on the language, used previously by other detractors, including here and on the OP's "evaluation".

And there is more:

1) The OP does not mention he is evaluating an alpha version of the language.

2) OP starts the "evaluation" with a link to a very contentious and controversial post from 2019, which smears the author and describes the language as vaporware (despite it being 2022 now and over 100 releases later).

3) At no time during the creation of his supposedly month long "evaluation" did the OP reach out to the V developers or community to verify anything in his report.

4) At no time did the OP demonstrate any good will by filing any bug reports or creating a discussion at V's GitHub. He had a unknown throwaway GitHub account, to easily do such.

5) The OP's "evaluation" summary (that can not be responded to) is full of opinions that are subject to interpretation.

6) Exactly how qualified is this mystery evaluator doing this negative review? Unknown.

7) Multiple times in the review, the OP mentions "we", as if he is part of a team. Who is "we"? Unknown.

8) The OP avoids attempts to be engaged in debate with V developers on various points about his review or make it known that he will modify it for correctness, fairness, or language version.

The OP doesn't need to file bug reports. The experience report is its own thing of value. I've had people write experience reports about software I've written many times. You know what doesn't happen though? I don't accuse them of bad faith. And I don't cry about them not filing issues as if that's some moral necessity.

The irony of you picking apart the OP's wording as not being exactly correct is just too much. There's the projection I was talking about. :-)

> Multiple times in the review, the OP mentions "we", as if he is part of a team. Who is "we"? Unknown.

On the off chance that you just aren't aware of the idiom, it's common to say "we" as in "me and you, the reader."

Search for "we" in one of my pieces of writing, for example: https://blog.burntsushi.net/csv/

There's nothing nefarious about it. See also: https://academia.stackexchange.com/questions/5500/use-of-fir...

At this point the V community is verging on self parody. I can’t think of a more illustrative example of a victim complex.

Unfortunately it’s very hard to convince self-proclaimed victims that they are not in fact victims, because then you become one of the “detractors” or “competitors” looking to “gaslight” and “slander”.

I’ve never seen a language with so much self-inflicted drama around it.

Indeed. Pointing it out to them is difficult. I have experience doing it in other contexts. The jury is still out on whether it's successful or not. :-/

A conspiracy theory is claiming that a competitor's compiler has a dependency on an OpenGL context creation library.

And it's laughable to claim that its popularity on launch was due to false advertising. Even your leader admitted that self hosting on launch is impressive:

> Wow, that's incredibly fast. Self-hosted in 2 weeks? Hot code reloading? This is everything I plan to do with Zig, but apparently done already. How did you do it so quickly?

(I hope you won't argue that V wasn't written in V on release.)

Funny how the agenda changed.

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

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.

Can you elaborate how language features failed V? And what claims were extraordinary?

Like the language compiling itself in <1s? It's true and you can verify it yourself:

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

Look, you are doing what I've just said not to do. I have nothing to say because the OP did most of claims already, you should directly respond to the OP.

And you are slightly altering the very claim you've already said; the OP specificially tests the claim that "V compiles [...] ~1 million (x86 and tcc backends) lines of code per second per CPU core", which I can easily verify on my machine (1m_helloworld.v took 25.5 and 15.5 seconds to compile under the same settings). To be fair these test files are edge cases you can easily dismiss (ProTip: you can make your advertisements more accurate), but edge cases show the weakness of your design and you should not confront them.

You made a claim:

> extraordinary claims failed V.

I asked you to list such claims. You fail to do so.

There's no way it takes 15s to compile 1m_helloworld.v. You're probably using a debug build of V.

What's your hardware? CPU/SSD.

> There's no way it takes 15s to compile 1m_helloworld.v. You're probably using a debug build of V.

You don't have to guess because I can give you my log. I have exactly followed what the OP did, except for more recent revision because I couldn't get it compiled in my environment.

    $ git clone https://github.com/vlang/v/
    $ cd v
    $ git checkout 0e4198f23b2b9a52d72f61dd40d019412b809791

    $ VFLAGS="-prod" make
    make fresh_vc
    make[1]: Entering directory '/tmp/v'
    rm -rf ./vc
    git clone --depth 1 --quiet --single-branch https://github.com/vlang/vc ./vc
    make[1]: Leaving directory '/tmp/v'
    cd ./vc && git clean -xf && git pull --quiet
    make fresh_tcc
    make[1]: Entering directory '/tmp/v'
    rm -rf ./thirdparty/tcc
    git clone --depth 1 --quiet --single-branch --branch thirdparty-linux-amd64 https://github.com/vlang/tccbin ./thirdparty/tcc
    make[2]: Entering directory '/tmp/v'
    make[2]: Leaving directory '/tmp/v'
    make[1]: Leaving directory '/tmp/v'
    cd ./thirdparty/tcc && git clean -xf && git pull --quiet
    cc  -std=gnu99 -w -o v1.exe ./vc/v.c -lm -lpthread
    ./v1.exe -no-parallel -o v2.exe -prod cmd/v
    ./v2.exe -o ./v -prod cmd/v
    rm -rf v1.exe v2.exe
    Note: building an optimized binary takes much longer. It shouldn't be used with `v run`.
    Use `v run` without optimization, or build an optimized binary with -prod first, then run it separately.

    Note: `tcc` was not used, so unless you install it yourself, your backend
    C compiler will be `cc`, which is usually either `clang`, `gcc` or `msvc`.

    These C compilers, are several times slower at compiling C source code,
    compared to `tcc`. They do produce more optimised executables, but that
    is done at the cost of compilation speed.

    V has been successfully built
    V 0.2.4 0e4198f

    $ cat > t.sh && chmod a+x t.sh && ./t.sh > 1m_helloworld.v
    #!/bin/bash
    echo 'fn main() {'
    for i in {3..1000000}
    do
        echo '    println("hello world")'
    done
    echo '}'

    $ time ./v 1m_helloworld.v
    parsed 100000 statements so far from fn main.main ...
    parsed 200000 statements so far from fn main.main ...
    parsed 300000 statements so far from fn main.main ...
    parsed 400000 statements so far from fn main.main ...
    parsed 500000 statements so far from fn main.main ...
    parsed 600000 statements so far from fn main.main ...
    parsed 700000 statements so far from fn main.main ...
    parsed 800000 statements so far from fn main.main ...
    parsed 900000 statements so far from fn main.main ...

    real    0m14.929s
    user    0m6.516s
    sys     0m8.031s

I have also verified that TCC was indeed in use:

    $ mv thirdparty/tcc/tcc.exe thirdparty/tcc/tcc.exe.orig

    $ time ./v 1m_helloworld.v
    parsed 100000 statements so far from fn main.main ...
    parsed 200000 statements so far from fn main.main ...
    parsed 300000 statements so far from fn main.main ...
    parsed 400000 statements so far from fn main.main ...
    parsed 500000 statements so far from fn main.main ...
    parsed 600000 statements so far from fn main.main ...
    parsed 700000 statements so far from fn main.main ...
    parsed 800000 statements so far from fn main.main ...
    parsed 900000 statements so far from fn main.main ...
    ==================
    cc: internal compiler error: Killed (program cc1)
    Please submit a full bug report,
    with preprocessed source if appropriate.
    See <file:///usr/share/doc/gcc-7/README.Bugs> for instructions.
    ...
    ==================
    (Use `v -cg` to print the entire error message)

    builder error:
    ==================
    C error. This should never happen.

    This is a compiler bug, please report it using `v bug file.v`.

    https://github.com/vlang/v/issues/new/choose

    You can also use #help on Discord: https://discord.gg/vlang


    real    6m50.090s
    user    6m8.375s
    sys     0m31.094s

(I gave up when the gcc memory usage ballooned up to 20 GB.)

> What's your hardware? CPU/SSD.

i7-7700 3.60 GHz, 48 GB of RAM, SSD in use, Windows 10 WSL (that's probably why kernel time is higher than average, otherwise my userland time agrees with the OP).

You're not using the tcc backend.

It says

Note: `tcc` was not used, so unless you install it yourself, your backend C compiler will be `cc`, which is usually either `clang`, `gcc` or `msvc`.

Also you have "gcc" in your error:

See <file:///usr/share/doc/gcc-7/README.Bugs>

And on the website the claim is made for tcc and x64 backends.

Like I said, no way it'd take 15 seconds :)

If I was not using the tcc backend for the first execution, then why would the second execution without tcc.exe be timed out? (I have also checked strace just like the OP.) It seems unlikely that the first execution and the second execution use the same gcc and still behave in such diverging ways. And if my reasoning is incorrect, please do not instinctively reply to me (I had enough) and put a proper diagnostic to tell whether TCC is being used, since it looks like a genuine confusion.

You're not using tcc, because the language literally tells you so, you get a GCC error, and you get 10x slower compilation time.

I think it's pretty clear.

Anyway, now that we are clear on the compilation speed claim, can you please list a couple of those extraordinary claims?

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

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.

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

Let's not discount the hundreds of contributors, sponsors, and other developers that continually make contributions to and improve V.

The impression should not be given that V is just a one-man show. Many of the offshoot projects are in collaboration with others, not just the author, who have invested heavily in them and also wanted or helped create them.

Even when they are known to be scammers and frauds?

V's author is paying others to write things in V (even when basic functionalities don't work as advertised). They don't want to improve the language, they want to create a showcase to attract more funding, that's about it.

This is a complete lie.

Like what is lie? I was offered money to develop something in WASM using V, so that they could add it to their "awesome-v" list.

Aren't you the part of the core team who bans anyone on discord who asks questions about V's memory management?

From what I've seen, V's author (along with other contributors and sponsors) have been constantly improving the language. Of which, these efforts are applauded by V's users and supporters.

As far as I'm concerned, V works as described in their documentation. As with any language, there are some specifics that are subject to interpretation or debate, but that is to be expected.

And, V is not doing anything that other languages also try to do in terms of sponsors and investors to sustain progress, increase popularity, or make improvements.

> As far as I'm concerned, V works as described in their documentation.

Really? Can you explain to me how memory management works in V?

V (which is at 0.2.4) is using -gc boehm, which is presently the default. On present versions, you don't have to do anything to enable it. On older versions, you needed to enable -gc boehm. You can choose to use and enable Autofree (-autofree), which works, but you have to know what you are doing. Thus it's best to refer to examples of its usage. Then you can also manage memory manually, where of course you clearly must know what you are doing.

Autofree will not be the default until version 0.3 of the language. Autofree inserts free calls during compilation, and the rest is managed by RC. V will be giving users 3 choices: GC, Autofree, or manual. Those people that actually use the language, would already know this.

This is mentioned on both the website and in the documentation, and any confused users can simply ask on discord (https://discord.com/invite/vlang) or the GitHub discussion (https://github.com/vlang/v/discussions).

Can you point me to a source that explains how "autofree" is supposed to work?

EDIT:

> which works, but you have to know what you are doing

This does not feel very convincing...

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.

Xe is phasing out that name in favor of "Xe". Xer domain name change was a part of that shift.

Ah I'm sorry, I hadn't checked the website in a little while. I now see there's a redirect and that there is a different name in use.

Is 'Xe' the name or the preferred pronoun of the person in question? Is this like Latinx but race neutral? Gender identity accommodations seem to get more complex and confusing by the month...

Name, at least that's my interpretation from looking at her Contact Me page:

https://xeiaso.net/contact

[correction] on their GitHub page I see: Please call me (order of preference): Xe/xer, They/them or She/her please.

[edit] obscure to have your pronoun also be your name (or maybe your title?). Or maybe it is all just satire, given: "I am an ordained minister with the Church of the Latter-day Dude. This allows me to officiate religious ceremonies in at least the United States." - https://dudeism.com

To be honest having a person's name be the same as their nominative case pronoun is kind of cool from a whole different perspective than you normally get to see. By doing this experiment I get to see how bad of an idea it is to do that. So far the xe/xer pronouns don't seem to stick as well, but it looks cool so I'm gonna keep up the experiment.

I'm also quite seriously an ordained minister.

:-)

> To be honest having a person's name be the same as their nominative case pronoun is kind of cool

The whole point of a person's name is to sufficiently differentiate them from the other persons. Using pronoun as name (or vice versa) just totally negates this goal.

To be fair, the name came first. Then I found out it conflicted with people's pronouns and I sat on the idea for a while. Now I'm throwing science at the wall to see what sticks, and this is a fairly amusing experiment. So I'm gonna keep it going.

I like it!

Who gives. Just use 'they' or 'them', or whatever. It is a universal catch all, gender neutral, i18n inclusivity conformant, ISO 69420 compliant, race neutral, etc.

At this point, all of it is basically designed to further confuse and only create a very monthly chaotic outcome for everyone.

Xe has been in use as a gender neutral pronoun for nearly thirty years. I, a startlingly ordinary person, was familiar with it as early as the late 90s.

Why not both?

Thanks for linking Xe's blog here! It's a few years old and I've seen a lot of comments on HN that suggest V has improved significantly since 2019 so I thought it might be worth looking into for myself and writing down a review of what I found.

I'm always interested in new languages and loved your write-up & evaluation of V.

I really don't get the purpose of someone exaggerating the capabilities of their language, to the point of outright lies.

I think people think that's "marketing".

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 marketing sentence "A language empowering everyone to build reliable and efficient software." is not true.

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

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.

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.

But you can get away with that in most languages that are generally considered memory safe, so a sane interpretation of the term "memory safety" wouldn't care about that.

How would anyone go about preventing you from doing that?

Keep in mind /dev/mem is just a convention, I can just mknod it at any place in the filesystem I want. I can even put a FUSE overlay on it that would turn it into a regular file instead of a device node, so you wouldn't have any possible way of telling what you're about to do.

There is no "defense" against /dev/mem, that's just something you don't do as a sane programmer.

do you your self a favor and search their ticket system for stack overflow. the list gets longer, not smaller.

and looking at their compiler it's clear why. stack-allocation of vars is fine and dandy, but comparable to vlang's famous unbounded autofree system. alloca() is dangerous for a reason.

unsafe vec, really?? mutexes in threads, really?? concurrent blocking IO in this decade??

also read their docs about their unsafeties, and concurrency deficiencies. compare that to the docs of real safe languages. you won't find such chapters, because safe languages are safe, not just almost-safe.

3 issues mentioning stack overflow:

https://github.com/vlang/v/issues?q=is%3Aissue+is%3Aopen+sta...

I've never had one in 3 years.

edit: ah, you meant Rust

> do you your self a favor and search their ticket system for stack overflow

First of all, most of those erorors are about stack overflows in the compiler not the compiled program. And secondly, stack overflow isn't a memory safety issue like, say use-after-free, uninitialized variables, data races, etc. If you allow recursive function calls, you can't really prevent stack overflows.

> alloca() is dangerous for a reason

Rust doesn't have an equivalent of alloca.

> unsafe vec, really??

I'm not sure what you are referring to here.

> mutexes in threads, really??

What does this have to do with memory safety? The only language with threads I know of that doesn't have mutexes is Erlang. And rust Mutexes are better than mutexes in most other languages because you can't access the data protected by the mutex at all, unless you have a lock. And the lock is automatically freed when it goes out of scope.

> concurrent blocking IO in this decade??

Again, what does this have to do with memory safety? And for many applications blocking IO is fine. You don't always need the performance of async I/O which adds complexity. And if you do need async i/o, rust has options there too (just not in the standard library).

> also read their docs about their unsafeties, and concurrency deficiencies.

The Rust Programming Language book has one section of one chapter on "unsafety", and that is specifically on using the `unsafe` escape hatch. Yes, there is a separate book about how to write a `unsafe` code that maintains rust's safety garantees. but that is limited to `unsafe` blocks, which in many cases you can just avoid using. As compared to c or c++, where the entire language is full of potential safety problems.

> compare that to the docs of real safe languages. you won't find such chapters, because safe languages are safe, not just almost-safe.

What "real safe languages" would those be? Can they be used in all the same domains as rust?

You most likely get NPEs, not segfaults. I have never seen a segfault in Java and the first Java version I used was 1.5.

Why in the world do competitors of this programming language insist on dragging out evaluations from 3 years ago, which state that V is vaporware and before the language was even released? This is 2022, not 2019, and we are talking a hundred releases later (https://github.com/vlang/v/releases).

At least stick to the current evaluation (or attack), which is more relevant, and make points from there. But, keep in mind that these attacks are on a young language that isn't 1.0 yet, so even with this we are talking about a moving target. The language is still evolving.

I don't have a horse in this race, but when a language makes present-tense claims about its features I assume that they're already functioning features.

People are poking holes in V because its claims are unfounded, not because they've decided they're in competition with the language. A simple "work in progress" sign on the features in question would draw a lot of fire away from the language and its creator.

Indeed! I even mentioned this in my "Rules of engagement" section:

> Features indicated to be incomplete/work in progress/unimplemented will be mentioned as such.

Indicating on the vlang.io homepage how much of the language has yet to be realized would go a long way in my opinion.

After I criticized the project for collecting donations on deceitful information, the author put purple "WIP" labels next to a bunch of stuff [1] which led me to make this statement [2]. However, it looks like medvednikov has since removed the "WIP" labels.

[1]: https://web.archive.org/web/20190624052507/https://vlang.io/

[2]: https://twitter.com/andy_kelley/status/1142503808901308418

From his perspective, he's been Working on them ;)

Credit to both you and him for the passion and effort put in. I just think his excitement bubbles over into an unfortunate way of communicating (lets call it cute)

Communication is something you're excellent at, in a large part due to your truthfulness

I just think vlang is living in and expressing dreams and visions. Which I agree has problems, but creating a language is an aspirational endeavour

You know something, some of us are HAPPY donators for 3 years now and we're fine and feel that our investment is worthy. I really think you are terribly misrepresenting the situation.

Yeah you can't buy trust. Once it's done is done.

I'm not touching a language developed by folks who don't see a problem in scamming users, sorry.

No scamming coming here whatsoever. And this is coming from a LONG TERM patron/donor.

Financial supporter of V here. I don't feel scammed or misled at all. So keep speaking for yourself with the imaginary money you did not donate nor lose.

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 highlight older criticism is because it's useful to examine past behavior, past promises, and contrast them to current behavior and current promises. If V is going to improve its reputation, it's going to do it by (a) making good on the promises it can, (b) coming clean on the promises it can't, and (c) offer a clear win for some distinguishing featureset. Badgering people to shut up about the past isn't on that list.

> 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 criticisms no longer applied, as things like TFA could be written.

Ah, fair enough, my memory is imperfect and I'm not inclined to paw through old HN comments.

Edit: ack, and I misspelled his name and the edit window closed

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

> Why in the world do competitors of this programming language insist on dragging out evaluations from 3 years ago...

This question is answered in the comment you just replied to:

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

It's been around for a few years now.

Mostly because the author completely scammed the shit out of people by promising a ton of things to garner patreon support before open sourcing what was essentially a hobby project at the time. I haven't followed it very closely, but last I heard about it was not delivering on the "autofree" feature.

I dont really care about the language. I've tried it a couple times and it's nothing special (to me) so I moved on, but I definitely understand where the hate comes from. The author essentially lied for at least months about his project to get financial support.

Quick edit: to actually add to the discussion, I think the weirdest thing about V is the odd support it does get. Most projects, especially compilers, with as much controversy as V would never get any support. I'm very curious what its proponents are using it for and why they choose V over pretty much any other language.

you heard wrong, it's been delivering quite well

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

no one has been scammed, whatever that means in opensource development

Oh, that's really cool to hear! I'm glad that they've turned around.

So, where can I download the version of V with non-nullable references, no uninitialized memory, no mutation without call-site mutability annotations, that can compile 1M loc/sec, and a functional autofree?

All the features you listed are there, maybe with bugs, which is expected for a 0.2/0.3 version, but they are there.

If someone advertises their language as having no Null, no reading from uninitialized memory, and no mutation of immutable values, then I really do expect to be able to rely on those being completely absent. It is dishonest and shameful to say "No null" on the front page of the website when the developers are well aware of ways that their system fails to actually prevent null references.

If I'm buying a sandwich advertised as "no cockroaches", then I think it's appropriate to be pissed off about there being bugs in my sandwich, especially when it's clear that the sandwich shop knows all about the bugs in the sandwich and they just prefer to falsely claim their absence.

I would have no complaints if the developers would just describe these things as ambitious goals they haven't actually accomplished yet, instead of declaring that they've completed work they know they have not completed.

No, you would look at the version of the language, realize it's 0.2 and not production ready yet.

No, I really wouldn't, and don't. This is the kind of thing that reads to me as honest for a new in-development language: https://github.com/cruxlang/crux#status

Features are explicitly listed as working, partially done, and not yet implemented. You're really truly allowed to say "This doesn't work yet, but we're working on...", and it is legitimate to criticize people for choosing to lie instead.

Well that's what it literally says on the website:

> V avoids doing unnecessary allocations in the first place by using value types, string buffers, promoting a simple abstraction-free code style.

> Right now allocations are handled by a minimal and well performing GC until V's autofree engine is production ready.

Because no other new languages lied that much?

>Things change.

Based on submitted link, they don't.

> 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

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.

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.

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

Tene’s post is the most reasonable and valuable feedback you’ve gotten in this entire thread. Your reply should have been one of thanks and appreciation, not confrontational and argumentative.

Honestly, from the outside reading this thread you probably shouldn’t have come here in the first place. I get you want to defend your language, but there’s a fine line between defending your creation and being argumentative with people who don’t actually mean you harm, and who aren’t trying to take you down.

Your posts here are very defensive, and your tone is argumentative to the point when someone gave you accurate info about using tcc, you refused to believe it and argued about it for several posts. Just listen instead of arguing.

Look, I get you want to defend your creation. But my advice from one lang dev to another is stop posting on hn, and do what you’re good at by working on making your claims about your language bulletproof instead. People have been giving you this advice since you started V years ago but you haven’t taken it. Let V speak for itself. Stop arguing with people on the internet.

The developers of V should feel free to defend or talk about their creation, as they wish, and as other language developers have done on HN.

The situation is also not as simplistic as making claims bulletproof, but also dealing with a continuous concerted effort to smear the language.

If you accidentally make a mistake when setting an array length in V, your program can read from uninitialized memory, as discussed in this article. This program, quoted from the article we're discussing, is accepted by the V compiler, and attempts to read from uninitialized memory:

  fn main() {
      x := []&int { len: 10, cap: 0 }
      println(x[4])
  }

In this case, the program crashes with a segfault, because the program is simple enough that the memory after the heap allocation was not mapped. The point of these examples is to be minimal tests cases clearly demonstrating that the language does the wrong thing. This is a general category of bug that permits memory unsafety, and in more-complex real-world programs, this could be exploitable. In general, any time you see a segfault, it's a strong signal that there could be an exploitable memory safety vulnerability.

This does not apply to every other language. The specific problem is that V lets you directly adjust the array length without doing anything to ensure that the array capacity is at least as large as the newly-specified length. Go's `make([]int, len)` ensures that the produced array's capacity is at least len. Go does have some memory safety issues (data races), but this specific issue is not a problem that Go has.

> Can you link to such examples in V documentation?

I agree with the article we're discussing that the "Safety" section prominently displayed on https://vlang.io/ immediately after the header is significantly overstating its case. Here is the list, each item of which is discussed specifically in this blog post, with minimal source code you can run to check their work:

  - No null
  - No undefined values
  - No undefined behavior
  - No variable shadowing
  - Bounds checking
  - Immutable variables by default
  - Immutable structs by default
  - Pure functions by default  --  This has since been removed from the list, but was present when the author started this review: https://web.archive.org/web/20220305171852/https://vlang.io/
  - Option/Result and mandatory error checks
  - Sum types
  - Generics
  - Immutable function args by default, mutable args have to be marked on call
  - No global variables

"No Null" is misleading because the compiler does not actually prevent null references.

"No Undefined Values" is misleading because the compiler does not actually prevent reading uninitialized memory.

"No Undefined Behaviour" is misleading because the C code generated by the V compiler does include behaviour that is undefined according to the C language standard.

"No Variable Shadowing" is correct; the V compiler rejects programs that would shadow variables. I don't actually see this as a benefit, as I use shadowing all the time, but it's an accurate statement about the current V compiler.

"Bounds Checking" is mostly correct, but slightly misleading because the bounds are exposed to your code, and it's up to you to make sure you manipulate them correctly.

"Immutable variables by default" and the other immutability points are misleading because functions that accept immutable arguments can still mutate those arguments.

Compared to languages with real mutability tracking, this is far less helpful in designing misuse-resistant APIs, and avoiding hard-to-diagnose bugs caused by unexpected mutation.

"Pure functions by default" is misleading because the V developer has chosen to use their own special nonstandard meaning for "Pure" that includes IO, and because of the mutability tracking not actually being effective.

"Option/Result and mandatory error checks" is correct and fine; I have no problems with this.

"Sum Types" is kind of okay, but they look kinda janky and limited. This article's example of sum types not being able to hold references is pretty concerning.

"Generics" is kind of okay, but it similarly is a very early very limited implementation.

"No global variables" is just false. V has "constants", which are just "immutable" global variables, and as we've already seen, V's "immutability" is very mutable.

This blog post also addresses the "Performance", "Fast Compilation", and "Innovative memory management" sections of https://vlang.io/.

Broadly speaking, https://vlang.io/ seems to very clearly present the language as one that is suitable for use today. I don't see anything on the main page of https://vlang.io/ that says anything even vaguely similar to "This is a very early language, these features are aspirational but still very much under serious development, and there are many known gaps we have not built solutions to yet".

By my personal standards of epistemic integrity, the front page of https://vlang.io/ is misleading and dishonest. I recognize that many people consider this kind of "marketing" to be acceptable, and I'm fine with letting people do that as long as they're not complaining about people actually checking their claims.

I really love the ambition of V, and I would be very happy to use it if it were actually production-ready. I have sometimes used early-development tools in production when I've had a good understanding of what the actual gaps and deficiencies and defects in the under-development software are. V's aggressive marketing that goes out of its way to avoid discussing its weaknesses means that I can't actually rely on what I read from them about the language's suitability for high-reliability use. When someone shows me that they're happy and willing and eager to mislead people about the flaws in something, then I believe them!

To me, these posts seem to be written from a perspective of eagerly wanting to use the language that seems to be advertised, and being disappointed at the big gap between the marketing and reality. The two big messages I see in these blog posts are "Here are problems I found that make me concerned about using V" and also, separately, "V appears to be marketed as if it were a polished product suitable for production use, and that's concerning, given the problems found."

Notice the end of this post: "At this time, I would not recommend spending time on V. I would also be very cautious when taking claims made by the authors at face value."

This author explicitly says "At this time" they don't think V is suitable to rely on or will be soon, and they encourage skepticism when interpreting claims made by the author. This does not read at all like someone hateful to me. This very much reads like someone who really wants a production-quality V language to use, and hopes that the project someday succeeds.

I strongly disagree with you about the intent of the OP. I'm not saying you don't have other valid points, but want to focus on this particular aspect of your post. I think it's important to not assign benevolence, to what is possible malevolence. Why?

1) It is the author of the blog, that also created this thread on HN.

It shows the intent to disseminate his negative review as far and as wide as possible. And to do so outside of the V community.

2) If the OP was as eager to use the language as you believe, and was disappointed, he could have brought those issues to the V GitHub.

Who is going to the fix those issues that the OP (or anyone else) believes is a problem? It is going to be the V developers. So if the OP wanted those things that he believes are a problem fixed, that's who he has to bring them to.

Just outright mounting a smear campaign or crapping on the V language wherever possible, will never get any of the issues fixed on its own. Instead, as has been shown (by other places linking to the OP's blog), it will only invite more smearing and attacks.

3) The OP starts the review by linking to a number of very contentious posts from competitors and detractors of V, to include those that smear the author and language.

To do such will clearly set off drama, and makes the negative review part of the past drama. It now links them all together. This is not the intent of a person that wishes to "come in peace" or be helpful, this comes across as one having the purpose to set off a blazing fire of more drama.

4) The OP has shown no interest in working with V developers, and that's prior to publishing the review and spreading links to it.

The OP has demonstrated no intent to modify his review for correctness, fairness, or language version. This then puts "at this time", in the context that the review can stay as it is, indefinitely, regardless.

Add to that, the OP is purposely using a throwaway account on GitHub. He simply can disappear, without ever making changes to the review. We all know who the creator of V is and a number of its developers, they are all held accountable, as you are trying to do now. The OP on the other hand, has no accountability nor any "skin in the game".

5) The OP's review is without the necessary context and highly opinionated.

Without feedback or the opinions of the V developers, this is a one-sided negative review full of many debatable points about the claims made. The many gray areas can only gain context, when compared with what the V developers are showing their intentions are and in their responses to what are believed to be issues.

For more clarity at what I'm getting at, I'm not saying there are no issues with various claims or marketing, but rather what is claimed can be a matter of opinion. Because a person or reviewer disagrees with a claim, does not make them or their review 100% right either. Readers are left with a situation as to what percentage of either side is correct.

And no matter at what percentage either side is correct, who is going to fix any discovered issues? Right, it will be the V developers. So if the point was not to do any harm and help create production-quality V, then that's who needed/needs to be informed and worked with. If the OP is not interested in working with V developers, and rather produce and disseminate drama or facilitate smearing, then that's a reflection of their real intent.

Okay so do something about it. It’s been over 3 days since the blog post was written and all you’ve done since then is mount the same complaints here about how unfair the blog was.

Go write your own blog post. Submit it to hn. Refute all the points in the blog with evidence and code. Then we can have a follow up discussion with more substance.

At this point, you’ve made your position clear and you’re talking in circles. The way you combat a negative story is with a positive story. Whining about how unfair everyone is being to your favorite new language is a perfect way to limit its growth.

As such a small community, your personal behavior on public forums defines the tone of the entire V community for outsiders. You should critically analyze your posts here and ask yourself if they leave the impression of a community people would want to join.

I'm not here to speak for all members of the V community, as it appears your are trying to pigeonhole me as doing, for your narrative. My personal opinions are in no way reflective of their entire community.

It also appears you prefer to see negative opinions or commentary about V, and are getting overly upset or obsessed with those you believe are defending the language in any way. I'm simply responding to a thread on HN (as you are), that was not made by me, and calling out things that I see or believe to be unfair.

The V community has open discussions that anybody can join and make comments on. You can also freely create an appropriate discussion at the V GitHub. This is something that it appears you don't know about (and what the OP purposely avoided), as you're "talking in circles" with me and giving your opinions about "whining". The link to it is below.

What don't you like about V / what would you like to be changed? (https://github.com/vlang/v/discussions/7610)

You can also interact with the V community on discord as well. (https://discord.com/invite/vlang)

You are free to go there and submit your many opinions about what the members of the V community should or should not be doing. Even better, as you seem to describe yourself as very technical and knowledgeable. You would be commenting directly to them. In general, they are very receptive, open, and friendly.

> My personal opinions are in no way reflective of their entire community.

Unfortunately for you, the V community is small and you tend to come here on HN, so you are who we see as an ambassador for V. You are a defacto representative of the community even if you do t see yourself as such. The way you comport yourself here reflects on the entire community. Fair? No. But if you read the comments here and in other threads, you’re definitely leaving an impression as to the entire V community.

> You are free to go there and submit your many opinions about what the members of the V community should or should not be doing.

I don’t have many opinions, I have one opinion and I have given it to you. Stop arguing on the internet and just make your claims bulletproof.

> ...you are who we see as an ambassador for V...

There is no "we", everybody on here does not think as you do. Better to clearly speak for yourself.

> ...defacto representative of the community...

If you bothered to read and pay attention, the creator of V posted on this thread. This includes other V contributors (that debated some technical points), and long time proud paying supporters of V (who have identified themselves as such).

I have also clearly (and now repeatedly) told you that I'm not the V community nor do my personal opinions represent them. I'm expressing my opinions on HN, as you are, which refer to the actions of the OP and the topic of this thread. Anybody with common sense should understand that. Stop being so upset that there are people with different opinions about V and are supportive, not everybody gets off on smearing others or clings to negativity.

> ...make your claims bulletproof

It is not my position nor place to make any claims bulletproof, in reference to V, to your personal satisfaction. If anybody wants to actually address the V community, and tell them their opinions about what they could be doing or share their technical knowledgeable on the subject, then instead of just trying to argue me down specifically, they can go over to where they are at (V Github or discord).

> The specific problem is that V lets you directly adjust the array length without doing anything to ensure that the array capacity is at least as large as the newly-specified length.

This is false.

I tried to find the source of the "V has to die" comment, and I see that you linked this in a previous claim that Xe said "V should die": https://news.ycombinator.com/item?id=27442724

Actual quote from this comment:

  Personally I think it is something that should be ignored until it dies into obscurity
  There are good ideas there, but if you sell someone the moon and give them a block of cheese that's kind of a scam

This is definitely not "has to die". This is "should be ignored" and a prediction that V will die, justified by disappointment at the large gap between their interpretation of V's marketing vs the reality of the current state of V.

Well this is sure to be a reasonable thread with reasonable arguments coming from both sides. Surely the usual patterns of any vlang criticism won't pop out again.

Unfortunately, Vlang isn't a project out of an overeager young dev (not anymore at least), but at the same time, it hurts no-one. Sure, the author is making 1k a month out of it, but it's not like it's the scam of the century making him rich. I see startups on HN lying harder than that every week. Just let the dude make his stuff on his side, have a good laugh when articles like this come out, and that's it. Look at legitimate alternatives like Zig or Odin, and keep V as a fun little distraction when you want to see what overpromising looks like

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?

Similar to a language like D. Technically quite good, but not quite compelling enough that it has picked up momentum that is likely to push it into the mainstream and generate a large library ecosystem.

I think of Vala as the “Swift of Gnome”. As in, a nice language primarily useful for programming in the World Of Gnome, like Swift is a nice language for programming in the World of Apple. I don’t use Gnome, so I’m not interested in their Swift. ¯\_(ツ)_/¯

Do you mean Vale? Vala (the gnome langage) is in an unrelated category.

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

Vala seemed interesting to me quite a while ago, but V ticks the right boxes.

An article like the V one on Zig checking the claims would be awesome, wouldnt it.?

I think it would be fun and educational!

You're welcome to write it yourself.

Something you'll see by reading the overview is the part where the Zig team themselves warn you that Zig is not a fully safe language and link to articles describing the safety boundaries. Scroll to the bottom of this section:

https://ziglang.org/learn/overview/#performance-and-safety-c...

Zig is arguably not something similar enough that it would be attractive. Odin and Vlang are kind of offshoots of Golang, so would be more similar and attractive to those users. If a person is a Golang user, they would be more likely to see the advantages and possible improvements of Odin and Vlang.

“Those users” are a mystery to me. Who are they? Instead of talking about hypothetical persons, I am sharing my perspective and recommendation, as someone who learned C before learning Go, and who programs Go from time to time. To me, Go feels like C set to “Very Easy Mode”. Memory: specify layout but don’t worry about freeing it! I see Zig as C set to “Easy Mode”. More control than Go, can do all the C things as good as C, but memory management is explicit (like in C, but less tricky to get right).

Nah, very much personally dislike those two languages for various and many (predominantly technical, but some aesthetics are involved as well) reasons. V hits a sweet spot coming from a Ruby background.

> 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 mutating globally shared state in any meaningful way.

Although I agree with the evaluation, the claim of "no global variables" might still hold, assuming it refers to mutable global variables. The global constant holds an immutable reference to a mutable value, just like how in Java a singleton object (or a class with mutable static fields) can be used to simulate global variables.

It's just a one line bug in the checker, which can be reported via github, but it wouldn't be as dramatic.

Maybe I misunderstood then. I was saying that it seems to behave basically like Java. Is that a bug?

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.

If I understand the example code correctly, it's modifying a heap-allocated struct that's pointed to by a global const. So the global const contains an address which is not modified, but the thing at that address is modified. Right?

What does the intended behaviour (after the fix) look like? Are mutable fields in structs disallowed if the struct is pointed to by a const?

After the fix it's not allowed to do

`mut x := immutable_var`

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.

You only merged it one hour ago.

https://github.com/vlang/v/pull/14805

Over promising (hardly a one line patch) and under delivering (well beyond your "it will be fixed today" statement) as usual.

The check to fix the issue is indeed 8 lines long, and not one, the bulk of the patch is updating the places where the compiler was relying on this behaving with unsafe blocks and the rest is adding tests.

The patch adds two consecutives if statements to forbid the behaviour and could surely be written as a 2 lines or one line patch.

Not checked the timeline. It it is a bit irrelevant, I am not here to score point for either author.

I have a test project of around 5k lines of V, taken from a prototype in Go. Using V has been much more pleasant than Go or Zig, but I like zig comptime features. V is a nice language syntactically. Go has better tooling and is mature. I also rewrote the same code in Zig which I would trust today for production. Finally, I really like zig (and Jai) build system, and Jai very logical design and meta-programming features (no, I am not in the beta).

Hopefully from that statement, everyone can see that I am rooting for the adversarial team and therefore you can all discard my commment as biased

While I would agree with many of the comments regarding how the V site is not clear enough on the level of maturity for each of the attempted goal, and very quick to celebrate work in progress, I feel that balanced comments on this thread are mixed with some which would probably trigger me should I have invested lots of energy in trying to make V successful. Thanksfully I only contributed one AST optimisation as curious bystander, so I can read this thread as most will do: noting how people are capable of listening without hearing.

All this discussion did was to radicalise even more both parties. I would hope V developers will take the time to review what was posted in this thread, when the minds have cooled down, and will try to understand the cultural differences which can exist between people when it comes to reviewing public claims made.

I attempted once to bring this exact topic in the discord channel but reading the room there was zero appetite for change, so I stopped as I felt I would be alienating people if I continued. I self censored to not damage my standing on discord ~ so why am I ruining it with this post: to say that asking people to meet you on your ground to discuss problems is not going to work (general statement) People with nuanced opinion will often shut up when the discussion hits up. When points are not understood, the tension rises and the quality of argumentation reduces very quickly.

My view, and feel free to disagree, is that the V community has been burned out and does not welcome criticism anymore, trust in other developers is broken, from here no constructive discussion can happen anymore and for some participants of this thread the same can be said the other way round.

Team Problem? If it is not communication, it is communication https://www.mtdtraining.com/blog/lencionis-five-dysfunctions...

It would be very nice if you could do the same thing for Nim.

Nim and Zig are both pretty interesting to me as up-and-coming languages so I do have them on a short list of things to try. This post took about a month of effort in my spare time to write so I don't think I will get to those anytime soon.

> Nim and Zig are both pretty interesting to me as up-and-coming languages so I do have them on a short list of things to try.

Then I take the liberty of doing some promotion for Oberon+ here too.

I had a look at the Oberon+ language definition and noted that one of the most annoying Oberon shortcomings (as compared to Modula-3) still remain: ...from the point of definition to the end of the scope... Oberon+ should have a look at Active Oberon 2019, not for its "active" aspect, but for its syntactical and semantic improvements, like the correction of the above problem.

> ...from the point of definition to the end of the scope..

Not sure what you mean. Is it about the fact that all variables are declared in the header of the procedure, i.e. not somewhere in the body as e.g. in C# or Java? This is actually the same with Active Oberon and Modula-3. In case you mean that the order of declarations is relevant, Oberon+ assumes at least a two pass parser by design; a declaration sequence can contain more than one CONST, TYPE and VAR section in arbitrary order, interleaved with procedures, and the order of declaration is not relevant; see e.g. https://github.com/oberon-lang/specification/blob/master/The... and https://oberon-lang.github.io/2021/07/16/comparing-oberon+-w...

Sorry, but I read in your documentation: The Programming Language Oberon+ .... 4. Declaration and Scope Rules .... The scope of an object x extends textually from the point of its declaration to the end of the block (module, procedure, or record) to which the declaration belongs and hence to which the object is local

The spec is a work based on the original Oberon-2 spec; I tried to not change too much; in the referenced section I just replaced point 3 (pointer forward declaration) by "The order of declaration is not significant" and thought it was clear enough; apparently not, so I will add some clarifications. At some point I will have to re-write the whole spec.

It's a great idea, I nominate myself unless anyone more qualified steps in. It should take about a month. I will do what the author did and evaluate the claims the language makes one by one.

Very well, be sure to ask in the IM channels when you need guidance and good luck.

I started here: https://github.com/svanderbleek/x-language-review/blob/main/...

What do you mean IM channels?

Nice, Matrix Discord, IRC and others.

People like to dunk on V because of its author and community, but I will say that the design of the language itself (leaving aside the implementation) is genuinely interesting. To me, it feels like what Go should have been. And I like Go. So obviously I have a bit of a soft spot for V.

Disclaimer: I’ve never actually used it.

I'm sorry if you feel this is a dunk on V. Having seen quite a bit of discussion both on hacker news and other places saying that V has improved significantly since Xe's articles a few years ago, I thought it would be worth while to attempt a modern evaluation of the language based on where it is today. Throughout, I tried to ground my review by basing it on the claims the developers themselves make.

Would you mind expanding on your later comment? While I'm not a Go programmer, it's pretty easy for me to see why it has the features it has based on their commitment to fast compile times and being easy to learn. V on the other hand feels like an incoherent list of the biggest buzzwords in the industry right now with no clear overall design.

Sorry, I didn’t mean to suggest that this article itself was a dunk. I was commenting on the discussion I see elsewhere on the language (including elsewhere in this comments section). The article itself is a good summary of the problems with V — mostly with its implementation which does appear shoddy.

V’s design address many things I feel are lacking whenever I use Go: nil safety, sum types, option/result types, mandatory error checking. I think V is best understood in the context of being Go++.

Having looked a bit deeper though, the immutability and generics stuff does feel a bit bolted on, so I do see your point.

> I thought it would be worth while to attempt a modern evaluation of the language based on where it is today

A good idea indeed, thanks for the effort.

Although I'm quite surprised why V has gained so much attention.

> the design of the language itself (leaving aside the implementation) is genuinely interesting […]

> Disclaimer: I’ve never actually used it.

I can make a hypotethical language as well (I do it all the time), but I wouldn’t make a website about it and give it a name.

New language proposal: W

Features: * All of the things you want * No things that you don't want

Please donate to my Patreon

I agree, the interface has always been great which is what attracts people. The core developer is just overselling and it’s coming back on him

Am I wrong/naïve in thinking that a number of things mentioned here (no null pointer references, better bounds checking, immutability, pure functions by default) would be relatively easy to implement at least simple versions of in a language that compiles to C?

For example, the null pointer reference the author demonstrates would not be at all difficult to identify at compile time, it's literally just checking whether any structs are created with pointer properties initialized to 0. Checking for null pointers in all circumstances is much harder, but this particular example is easy. Why claim V supports this when it doesn't? Am I missing something about how hard it'd be to implement?

You're not wrong. For the most part, these would be relatively easy to implement.

Pure functions are the hardest of the ones you've identified -- they're nominally easy if you have perfect purity information, but pretty difficult (impossible, in the general case) if you don't or if your definition of "pure" is just plain incorrect (like V's is).

The criticism re: purity is silly. It can still be useful to design a language that is “mostly pure” because you’re mostly not trying to fuck your self over. For example OCaml is “mostly pure” and it’s tremendously beneficial in terms of writing correct software, regardless of the IO escape hatch or the ‘a ref explicit mutability etc.

(I don’t care for V one way or the other though, and most of the results in the post are clearly bad, I just find this particular point to be absurd).

To be clear, there's nothing wrong with impure programming languages. I use them every single day. My complaint is that V claims to be pure and is actually impure. To my knowledge, OCaml makes no claim to functional purity.

"ML-derived languages like OCaml are "mostly pure". They allow side-effects through things like references and arrays, but by and large most of the code you'll write will be pure functional because they encourage this thinking. Haskell, another functional language, is pure functional. OCaml is therefore more practical because writing impure functions is sometimes useful."

https://ocaml.org/docs/functional-programming

> My complaint is that V claims to be pure...

"V is not a purely functional language however." (from V documentation)

https://github.com/vlang/v/blob/master/doc/docs.md#pure-func...

"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 performing I/O.

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. Seems like "mostly pure", in either case, should be equally acceptable or generate equal outrage.

V's documentation says that V's functions are pure by default, but they aren't.

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.

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.

Exactly, that was the idea. The wording was already changed a couple of weeks ago to more clear on the home page. Will update the docs as well.

I don't have a horse in this race, but ive always enjoyed playing with new languages from all paradigms.

My goto "test" is doing a simple webscraper and put results in a db.

The above is important and where I(your milage may vary allllot) think many fail or fail to some degree:

Its 2022 your new lang should have above excellent support for:

1) Multicore:(async, csp, threads) I dont care which just that it should be excellent and not some added library

2) We live in a inter-connected work: Thus I require your language to have above excellent support for things like: Http, websockets, json, encryption, auth,dbs etc.

3) Really bring something new or make coding in an alternative a pain. (stupid example: going back to posix threads in c, after coding i. go with channels)

4) Ecosystem:Hit the ground running, dammit if i spend 20 minutes getting a hello world with an external library up its too much ! Looking at you Python having to weave magic spells to get the correct versions and environment just so" is a absolute pain.

5) Pattern matching, immutability, functional, typing: Yea this is where people get very passionate* :) You probably have to include atleast one the above.

That being said my hat and github stars go out to all pl designers ! You at least took a shot and shipped something ! Bloody well done to you all !

Also if you looking to tinker look at janet and joy(web framework based on janet)

PS: Ive tried v in the past and it really was too bad(no program in production yet)

PS2: My dream lang would be lisp-like(more clojure than lisp) that compiles to go ?

I do not understand the hatred, reminds me of the last article of this kind. This language is in alpha. I've been in the Discord community since 2020 and no one would think of recommending the language for production use because it's WIP. Sure the goals are high and a lot of things don't work yet or are shaky but that's the way it is ATM. The wording of the article is simply not appropriate for the fact that the language is not even published. The community is small, active and also very friendly. I had a very good experience with Vlang in 2020 when I used it for Advent of Code and actually always got help when I got stuck with some bug.

I'd be curious to see your AoC solutions in V, if you have them kicking around?

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 very cautious when taking claims made by the authors at face value."

Also this point. Why does he recommend people to avoid the language. These people need contributors which help them to improve their language. It is open source. Maybe it is because I'm not native, maybe you are right.

I'm also curious if the author even tried to interact with the community/developers to get his examples to work. I'm not that good of a developer to rate the things he is claiming, so I don't know.

Hopefully he created some bugs on github so the developers have at least the chance to fix the issues he is talking about.

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.

> Why does he recommend people to avoid the language. These people need contributors which help them to improve their language. It is open source.

This is why the "critic" can also be interpreted (or misinterpreted) as another attack. It's one thing if this was a blog evaluating the claims of multiple programming languages, but it being a very specific and dedicated critic of V, looks strange.

To include it uses the term "we" a lot in the summary, as if it was a collaboration effort by a group of programmers directed at V. It is unknown who are the "we" being referred to.

"We’re able to create a null pointer (V reference) with no compiler errors or warnings."

"We weren’t able to shadow local variables."

If the evaluation was in the spirit of improving the language (as it is still alpha) or pointing out things that need to be addressed, then one would expect it to be presented as various issues or bugs on V's GitHub. There would not be any blindsiding or surprise, but an exchange between the evaluator(s) and V's developers and contributors.

Parts of the evaluation and summary are debatably subjective. The categories of purity, sum types, generics, speed, and compiling are among them. So getting direct feedback from the developers and contributors of V would have been much more fair and helpful.

> I'm also curious if the author even tried to interact with the community > Hopefully he created some bugs on github

He didn't.

But I understand what you are saying. Back when I tried the language I expected an unfinshed state because of the version number, but I guess they should make more clear that the features are the goal and not the state what is working currently.

Funny, I've never had any misgivings or unfulfilled expectations so far. I suppose my "defaults" are a bit different than others. Very disheartening to see the world in such a state as people feel its necessary to waste times with negative activities vs trying to build and uplift.

This is strong point that is conveniently overlooked. That the language is alpha and 0.2.4, should be clue enough that it is a WIP by default (at this point), by those that have actually tried it.

Valid criticisms of the language should arguably be more directed towards its issues on GitHub (https://github.com/vlang/v/issues), in addition to any blog or article, where the contributors and developers can address them.

When approached correctly, and not in an adversarial and combative way, I've seen the V community be very friendly and helpful.

I speak English proficiently I speak Chinese with no mistakes I can bend pipes with my bare hands.

Then when you speak to me you hear me speak Chinese well, then you see I can’t bend pipes nor speak English proficiently.

I presented myself to you and two of my self introduction claims were lies or half lies.

If you then feel like I lied to you then my answer is that I’m studying (Alpha)

This is what V was like 3 years ago and doesn’t seem like it has changed.

By the way, the collection of snippets of V (Vlang) examples on Rosetta Code has become quite significant. People are demonstrating how to use it over there as well.

https://rosettacode.org/wiki/Category:Vlang

Adding a mention that V is still far from 1.0 in the title or at the beginning would have been honest.

V’s Github description from October 2019 would have disagreed

https://web.archive.org/web/20191020121218/https://github.co...

Hopefully what is not being suggested is that creators of open-source programming languages are not allowed to revise their release schedules, underestimate, or change the number of features it will have.

Languages such as Nim have took 11 years before reaching 1.0, so V is still doing comparatively well. V's pace of development has been quite fast and substantial. More comparable languages such as Zig and Odin have yet to hit 1.0 as well, and are many years older.

Yes, the pace of development is getting faster and user patience less, but V should still be afforded some leeway in this regard.

TLDR

> At this time, I would not recommend spending time on V. I would also be very cautious when taking claims made by the authors at face value.

Quick glance says: This is like the perfect blend of Go and C.

I love it.

Except that unlike C and Go it doesn't work.

Yes, that's the sad part.

What makes you think it doesn't work? An article that listed a couple of type checker bugs?

It is an awesome language. It's the first language I'm feeling will be able to pull me from Ruby once some things get ironed out.

At this point, why do people even spend time on debunking the marketing claims of this language at all? It's been done to death, whoever was going to be convinced the V developer is a charlatan has already been convinced. For better or for worse.

I think everyone wants a "Rust but better" language to exist, and that very well might be V in 5 years, but Rust wasn't advertising features as 'completed' years before they were implemented/stable and neither should V. Continuing to point out the design issues will either get the marketing claims removed (just throw up a roadmap!) or articles like this will be used to show V's progress in a distant future.

I wouldn't bet a single dollar on V improving to any qualitative level. It's been a surprisingly large transpiling hack. Graydon Hoare had some PLT knowledge before going on doing Rust, it's not just feature names and potential impl.

What are the qualitative levels in your opinion?

The V compiler is self hosting for example, there are useful examples done in the main repo, people are using it for writing web servers.

What it should do, to "qualify", and to qualify in what?

Formal semantics

Everyone wants that? Not even everyone wants something like Rust. But I doubt that everyone who programs in Rust (and like it somewhat) want Rust-but-better (when that entails learning a completely different language, at least).

A lot of people want it which is why V is so popular despite not really working well

A lot of people want to go to Heaven.

> wants a "Rust but better" language to exist, and that very well might be V in 5 years . . .

How can anyone possibly believe this?? What is the motivation?? V is a `README` full of desires, and a source tree full of incompetence. There is no concrete or technical evidence that can support this optimism. Zig is a serious project. Go is a serious project. Rust is a serious project. V is, obviously, an un-serious project.

I assure you, that V is a very serious project, and its README is not full of desires, whatever that means.

As for the source tree full of incompetence - that may be so, if you can help, you are welcome to make PRs to improve it.

As incompetently written as it is, it is capable of compiling itself, and quickly, unlike some others.

For what it's worth, there has been some progress on the language and the author has responded to past criticism. I've been following developments of the language for a few years now, and I'd love it if all the claims came to fruition. Since it's a work in progress, past criticism doesn't necessarily apply -- leaving me to wonder "is it not bullshit yet?" Since the author has a habit of overpromising and even declaring things finished before even starting on them, and newcomers might not know what to think, his claims warrant regular scrutiny. It appears that V is still for vapor.

> Since the author has a habit of overpromising and even declaring things finished before even starting on them

Do you have any examples?

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 no feedback from V developers or its community, and detractors are elaborating on it, that leaves few other public options to address it.

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.

If he had a good faith, he'd report these issues via GitHub, and they'd get fixed within a week.

So, regarding your claim that I have "a habit of overpromising and even declaring things finished before even starting on them".

Please, list them here. 1.2.3.

Must be easy if there's a habit.

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)

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.

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

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

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.

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 attempt to be engaged by the V developers over errors and opinions in his review. Looks like a hit piece to me.

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.

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.

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.

> I think that V developers and contributors are well within their rights to address criticisms of their work by detractors.

Indeed you are, but realize that you are also ambassadors for your language, and engaging in petty language war nonsense on public forums doesn’t leave anyone looking great. That’s a problem for V moreso than your detractors, because you are the ones building a reputation for yourselves, while your detractors are relatively anonymous and fungible. They can act anyway they want and it won’t follow them around.

On the other hand, everything said here by Vlangers will stick to V and will be brought up on the next thread. You don’t want the reputation of being fanboys who will descend on any thread about V and zealously argue about it for days. But that’s the reputation you’re building here, and it has nothing to do with the behavior or actions of anyone else. That’s something you are actively choosing to do, and it doesn’t make you or your community look good.

Again, no one looks great in threads like these, but most people here aren’t building a reputation. V is building a reputation. What do the posts by Vlangers here say about V? It’s not exactly a shining advertisement for your community.

Yeah, because V supporters should stay silent, and allow detractors free rein to say anything and continuously smear the language and its developers at will.

Funny, I notice the supporters of other languages don't seem to follow such advice. They make strong defenses and advocate for the languages they like, anywhere and everywhere, including on even this thread.

If anything, V supporters might want to be more vocal and show their support (which can be done in various ways), to counter what's going on. It doesn't work to stay quiet and let bullies keep slapping a person around. They incorrectly interpret it as a sign to continue.

Listen, you do you. I’m just letting you know how you come across to others. Maybe you think you’re defending V here but you’re doing the language and community a grave disservice, IMO. Others have given the V community the same advice, and have been for years, so it’s not just me.

But as long as you’re here on HN could you please at least follow this community’s guidelines? Several of your posts have been flagged for containing personal attacks, and accusations of bad faith and gaslighting are not well-received here. If you’re going to continue commenting, please just make your comments substantive. A strong defense of V would not include accusing others of bad faith because they didn’t file a bug report of GitHub.

Listen, you do you, as well.

Those people who are open-minded about programming languages, can make up their own minds about V. I'm quite sure their decisions will not be solely dependent on HN or me, if they even come by here.

And sure, I will heed the warning to watch my back on HN, to include the downvoting and flagging.

You made a very strong accusation.

Please list the things that were declared finished before even starting on them.

Have a look at the GitHub repo, it’s very active and there are clearly some passionate people putting a lot of work into it. So it’s worth looking at the language again every now and then.

Cryptocurrencies are also full of ‘passionate’ people. Doesn’t change that it’s all a bigger-fool scam.

There’s some value to people that don’t refresh the front page 10 times a day. I’ve only ever seen the language mentioned in passing and saw the shiny website, but not that it’s all utterly bs. Also as the author said apparently there’s been claims of improvement since the last debunking post, and it seems like it’s still vapourware.

I have no horse in the race, and having never seen the controversy, it does seem suspicious that the language author is making money off of claims that simply aren’t true. The amount of stars on GitHub compared to actual activity on comparable repos does indicate that the marketing is working though, the claims being made are taken at face value, not the WIPs that they actually are.

I too can dream of a perfect language, but it doesn’t mean I should put up a website claiming that I’ve actually made it and it’s real.

I'm personally holding out some hope that it'll eventually live up to its marketing claims - which means that I'm interested in seeing whether or not it has progressed in that direction in the last 3 years.

Reply on news.ycombinator.com