Ouch. All I can do is reference this Gabe Newell quote.

Don’t ever, ever try to lie to the Internet, because they will catch you. They will deconstruct your spin. They will remember everything you ever say for eternity.

Able to translate arbitrary C/C++ code to V

I’m sorry, writing a C++ compiler is essentially impossible unless you have the GDP of a small country, or you’re just building a wrapper around gcc or llvm. Translating C++ into anything other than C++ is even more ludicrous.

That promise combined with the 400k promise should be enough to tell how much of a lie this is.

I wish this were true, because D does try to be somewhat C++ compatible, but it’s very difficult to catch up. If anything could interop with C++ the way they do with C, that would be a huge, big deal. I really wish there was some easy upgrade path away from C++, but this is a fantastical creature that doesn’t exist.

One nit: the section about memory safety uses an example of a memory leak as a counter, but leaking memory is not generally an unsafe thing to do. Those examples still look bad, but it’s not quite correct to put that under a section about memory safety.

More generally, I don’t understand how things like this get attention. V is not the only programming language that has received a lot of attention and made some claims without providing the tools for others to verify it. Once I see that I can’t test it for myself, absent any other compelling evidence, I just close the browser window and forget about it until something changes.

What I’m trying to say is that while the author of V has clearly made some missteps here, this is also a lesson for the rest of us: demand evidence before hyping stuff. This article was likely only written because V received so much attention from us in the first place.

I think I’m just going soft–this writeup is something that years ago I would’ve been jealous to have written!

That said…I kind of hope the author of V doesn’t get too discouraged and they address this stuff and keep working on their language.

Well done, one comment on this quote:

Yes it is somewhat crazy to have 1.2 million statements in a single function, but as a compiler author it’s generally not your position to make these kinds of judgments. If the user wants to have 1.2 million statements in a function, let them.

Even the C standard has some fairly arbitrary limits conforming compilers may enforce (though most allow you to break the limits), so technically a C compiler can make these judgements.

Perhaps next you can generate 200k 3-6 line functions spread across many files and see what happens.

Another nit:

V claims to be memory-safe: Memory management There’s no garbage collection or reference counting. V cleans up what it can during compilation.

Memory safety and not leaking memory are slightly different. I guess it should read “V claims to manage memory” but your point overall is accurate. Tbh, he probably also claimed it is memory safe, and given the state of affairs, it obviously isn’t.

Having done some digging through the V source code, I’m not sure what to think. There are tons of TODOs scattered across the code, a lot of modules/functions are just stubs, and some types are just weird. A lot of features are not implemented, and variety of the author’s repositories are just placeholders. When asked about this, the answer is basically “soon”.

Given V in its current state appears practically useless, I wonder if Volt is actually written in V, or if it’s just written in another language. Volt also seems to be doing some shady things.

Given the current state of things, I’d say V is still a year or two away from being usable; if it ever becomes usable.

(Disclaimer: I have never looked at V, only see topics of some news lately, that’s all, so I have zero knowledge about the language and compiler itself)

Entertaining to read, but I had some thoughts that are left unaddressed by the article:

• A speed of 1.2 million instructions per second doesn’t mean that the compiler should support compiling a million instructions. I mean, if you drive your car with the speed of 100km/h, it doesn’t mean you need to travel 100km to make the measurement.

• Dependencies of the compiler executable on libpthread and libc are I think too common to use them as an argument. Since libpthread and libc are distributed with every GNU/Linux distro, I don’t think they should be treated as ‘dependencies’.

• About the nature of memory leaks: technically Valgrind reports non-freed memory, not memory leaks, and not every non-freed memory is a memory leak. There is a nice optimization ‘trick’ that is popular: don’t manually free the memory if the program is about to exit. If the program’s process is about to end, the OS itself is perfectly capable of freeing all memory pretty quickly in few operations, by freeing whole pages of memory. Manually iterating over lots of small objects can take more time, and it may delay the time needed by the application to finish its quit process. So, not freeing the memory on exit often enables fast shutdown of the application.

• Using shell commands to implement some functionality is also used by larger projects, like GNU libc itself. I.e. here (warning, it’s a link to the orange site), and other libc implementations (FreeBSD’s libc, macOS libc, musl). It uses an external process to implement the wordexp() function.

With the rest of the points in the article I agree, and thanks to it I won’t be spending my time on V anytime soon :)

Excellent work. Thanks!

The style of writing and the types of claims reminds of the GWAN web server.

My response to this copied from https://news.ycombinator.com/item?id=20258485

Thanks :) It’s 0.0.12, the first public release. What’s with all this “vaporware”?

The compiler can already compile itself in 0.3 seconds and is written 100% in V: https://github.com/vlang/v#installing-v-from-source

It allows building easy cross platform graphical apps: https://github.com/vlang/v/tree/master/examples/tetris

It has easy cross compilation and can even compile itself for another platform: https://twitter.com/v_language/status/1137537130887077890

It allows to build small performant GUI apps like Volt: https://volt-app.com/ (Volt 1.0 RC 1 for macOS has been used by thousands of happy users for several months.)

It powers a simple forum: https://blog.vlang.io/forum And the entire forum is one 65 KB binary.

It can translate and build DOOM: https://github.com/vlang/doom

It has very extensive and simple to read documentation that covers pretty much the entire language: https://vlang.io/docs

I think it’s pretty good for 0.0.12.

Come back when it’s v1.0 by the end of this year.

Would it be better to point to a permalink on the download_file mac implementation instead?

It got fixed on master approximately one hour ago (which is some timing, considering this was also submitted an hour ago).

I’ll post the same thing here that I posted to HN.

It would be nice if people were supportive of this effort instead of just ******* on it.

Of course it is incomplete at 0.0.12. Was it over hyped? Sure. Good for him to have time for some marketing of his work next to actually writing a working compiler with a good start for a standard library

This thing is real and here to stay.

How about this: instead of writing about frauds and vapourware, contribute to the project. File an issue, fix a bug, work with the author.

We should applaud and encourage these efforts instead of using every opportunity to be negative about them

This post is bullshit and I’m sad to see it here with 82 upvotes.

I hate the smug pedant writing style throughout, the massive effort spent explaining that WIP features are indeed a work in progress, the pages of copy pasted console output to demonstrate that there are trivially fixable bugs, and so many errors. (using trivially replaceable libc functions fits the standard definition of “zero dependencies” for C code, try making a release build, nobody cares if a compiler leaks memory, you would fix it by deleting the malloc, nobody cares that compiling a 1.2m line function fails, your benchmark is invalid because it doesn’t actually work, macbooks are 10x slower than any modern desktop, …)

I especially hate the condescending suggestions at the end and loosely sprinkled flowery statements that allow you to pretend you’re being constructive and not just making fun of someone in public for upvotes.

Five days ago you submitted a post about how you hope you can help new programmers get into the industry, now you’re writing multiple posts and comments dumping on someone because version 0.0.12 of the one man project they’re giving away for free isn’t as good as you hoped. Don’t you find that hypocritical?

BTW yes I am aware his patreon raises $800/month, remarkably average programmers fresh out of school make that much in one day at Google/FB/etc, all of whom will happily take his work and give nothing back should it benefit them.

My benchmark:

#! /usr/bin/env python3

def write_fn(f, fn_name):
    f.write("fn %s() {\n" % fn_name)
    for i in range(49999):
        f.write("  print('test\\n')\n")
    f.write("}\n\n")


with open("million_lines.v", "w") as f:
    names = []
    for i in range(1200000 // 50000):
        name = chr(ord("a") + i)  # a-x
        write_fn(f, name)
        names.append(name)

    f.write("\nfn main() {\n")
    for name in names:
        f.write("  %s()\n" % name)

    f.write("}\n")

Lets generate the file:

$ ./gen_million_lines.py
$ wc -l million_lines.v 
1200075 million_lines.v

And measure how long it takes:

$ time ../compiler/v million_lines.v

real	2m55,227s
user	0m14,998s
sys	0m0,468s

$ ./million_lines | wc -l
1199976

@ Intel(R) Core(TM) i5-7200U CPU @ 2.50GHz

Well. Here you have it. It is quite synthetic benchmark and it is possible that it works better on “real” source.

PS: I like V as a language. The presentation, not so much.

Don’t know how v is supposed to be hyped and when, I just never heard of it, maybe using mainly lobste.rs to get tech info I’m protected of this vaporware.

@cadey please dig up a copy of Jai and repeat the scalding for max lulz :)

I don’t think it was necessary to trash the project so much. I appreciate that the inaccuracies were pointed out though.

[Comment removed by author]

Great breakdown!

More general note: it always bothers me how much black magic you need to build software. Linking against libexecinfo? Never heard of it.