Hacker News Reader

Comment by Jenz | Hacker News Reader

The controversy around V is not without reason.

For some context here’s the last of a series of posts examining some of Vs claims https://christine.website/blog/vlang-update-2020-06-17

View on HN

The way I'd describe what I see from V's author from his two projects (V and Volt/eul) is a continual over-promising and underdelivering - as well as misleading statements (for example, a claim that V is the "fastest on Tech Empower's web framework", which is actually fastest in only plain text (it does not do enough to be qualified on the full leaderboards) on an unofficial run (it is currently 2nd I believe), where it is simply a wrapper around a C server [1][2][3] - which I believe is misleading, even if the C interop is neat). That is not to say he cannot eventually deliver on his promises, but they frequently take years beyond his initial predictions, and sometimes come watered down.

My personal conclusion from my reading was - if you wish to go use V, go ahead, but I'd exercise caution when relying on anything about it.

[1]: https://twitter.com/v_language/status/1234586123424456705

[2]: https://github.com/vlang/v/blob/bc288019932c35cc09dcf7b438bc...

[3]: https://github.com/vlang/v/tree/bc288019932c35cc09dcf7b438bc...

Just for reference in Techemppwer Benchmark, the same guy who utilizes H2O HTTP source code for benchmarking, wrote h2o.cr for Crystal language and pico.v for V language. It’s isn’t mean for general use in any projects.

This is a set of very biased articles, I mean just look at this for example:

> Git is a dependency, which means perl is a dependency, which means a shell is a dependency, which means glibc is a dependency, which means that a lot of other things (including posix threads) are also dependencies. Pedantically, you could even go as far as saying that you could count the Linux kernel, the processor being used and the like as dependencies, but that's a bit out of scope for this.

What's the point of such nitpicking? You don't need git to use V, and the point of the no dependency claim is that bootstrapping V is as simple as `cc v.c` and the V compiler produces single file binaries, that are easy to deploy, without any dependencies on an interpreter/environment/libs etc.

I'm actually going to write a post debunking all of the claims in these articles, since I see them mentioned quite often (including measuring the compilation speed by using an unoptimized debug build + running vfmt + rebuilding the standard library with each compilation + using a 2x slower backend).

How about refuting the memory leaks claim? Or the others in previous posts as well, that were calling out impossible features of the lang (that sounded like some ad)

Nitpicking nitpicks is still nitpicking.

A memory leak that even the author admits is one line of code fix away? (free() on a global const)

See the YouTube demo I posted which shows how V removes 100% of leaks in a complex graphical application (text editor).

Well, I will believe it when I see it, as well as the other hard to believe claims like I don’t know how many lines of code/second compilation speed, perfect C-to-V compiler, etc. I’m not sure how many of it is still up on the website, because some were called out and were taken down.

Why won't you see it? It's public:

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

You can also download it and try it yourself.

As for compilation speed, here's V compiling itself in 0.2 seconds:

https://pbs.twimg.com/media/EoAx9fsWMAE2M4U?format=jpg&name=...

The nearly 1 second compilation is impressive, but why claim it has 0.2 second compile time when using a cache? It doesn’t represent the real-world time it would take to compile v or another program from fresh in order to install it.

I often compile projects before the cache expires...

-usecache here means that vlib is cached. It will be the default in 0.2.1.

The entire V compiler is built from scratch.

All memory leaks in C are one line of code away as well (calling free() in some place).

Just FYI: on Hacker News, it's customary to add a little disclaimer to comments like these. Something like:

  (Disclaimer: I'm the creator and main developer of V.)

All right, makes sense. Added it to my top level most upvoted comment here.

Lol, unless this person was ridiculously well informed on V, that was basically the only option I saw :)

Diving straight in to attack the critic (again) rather than discussing things usefully made it pretty obvious it must be the original developer. You don't generally see two people who behave like that managing to co-exist in the same project.

> without any dependencies on an interpreter/environment/libs etc.

no stake on either side, but the post specifically mentions this (though that was on vlang 0.1)

> I claim that the V compiler has dependencies because it requires other libraries or programs in order to function. For an example, see the output of ldd (a program that lists the dynamically linked dependencies of other programs) on the V compiler and a hello world program:

  $ ldd ./v
          linux-vdso.so.1 (0x00007fff2d044000)
          libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f2fb3e4c000)
          libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f2fb3a5b000)
          /lib64/ld-linux-x86-64.so.2 (0x00007f2fb4345000)

  $ ldd ./hello
          linux-vdso.so.1 (0x00007ffdfdff2000)
          libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007fed25771000)
          /lib64/ld-linux-x86-64.so.2 (0x00007fed25d88000)

> If these binaries were really as dependency-free as the V website claims, the output of ldd would look something like this:

  $ ldd $HOME/bin/dhall
          not a dynamic executable

libc is the only stable system api, on non Linux system you don't have a choice to use anything else.

Go tried, and went back to linking to libc, because of constant syscall changes.

So I don't view having libc a dependency, it'd be like saying that macOS is a dependency.

You can also use musl on Linux with V for 100% static binaries.

libc is not stable, glibc breaks plenty of times (try running some real old software without relinking glibc).

The only stable system API is the linux kernel syscalls. Those basically don't break.

That’s true for Linux and why Go thought they could do this everywhere. It turns out that libc is the only stable interface for a lot of platforms (notably MacOS and many other BSDs if not all).

Correct, on Windows there is no stable syscall interface, same for BSD. Hence you're supposed to link things. But Linux syscall interface is stable and libc is definitely not stable.

What has glibc broken?

Here is a tracker for backwards-incompatible changes to glibc:

https://abi-laboratory.pro/?view=timeline&l=glibc

didn't mean to argue, just providing context for people scrolling through the comments :) i agree that it's a bit nitpicky. (but "depends only on libc" would probably be a better phrasing)

Sure is nitpicky. When I see some open source software I certainly never see libc mentioned as a dependency. It's just assumed that it is there as part of the OS which it basically is.

"I don't view this dependency as a dependency" is ... ok, you can redefine things if you're clear about that, but given you've also argued that "printing to stdout doesn't make a function impure" I think perhaps a glossary of terms that V uses differently would be helpful to understand your claims.

I'd also note that given you then banned her from the issue tracker after that post went up rather than discussing it, your claims of bias on her part seem a trifle strange.

But the example was run on Linux.

FreePascal works without libc

I liked the design of V and gave it a try. I quit paying attention when I realized almost nothing worked like it was supposed to. Even hello world was difficult due to needing to configure all sorts of stuff to get tcc and configure it to compile correctly.

That shouldn't be happening. We have lots of tests to make sure it works.

Are you on Windows? Can you create a GitHub issue with `v doctor` so that it can be resolved asap.

Sorry, I already went down the road of broken promises and moved on. Make something that works out of the box. Package tcc with it.

It already is...

> > Git is a dependency, which means perl is a dependency, which means a shell is a dependency, [...]

Indeed, this is a silly matter. In both sides.

Ok, V creator may have an huge ego. Evan Czaplicki (Elm creator) may have an even larger ego. The list goes on. Does it worth to do everything to castrate their ambition? They like to put the bar high. Higher than they can jump most likely but in the meanwhile they build something. Probably not exactly what they proposed to but way more than the ones that criticise them. Criticise with work not with nitpicking, from the outside it resembles envy. Time will certainly judge them and us also.

Disclaimer: I don't know V authors nor I'm part of V community.

Some other claims from the author:

> Good question. I haven't mentioned memory management because it's not done yet. I know for sure there won't be a GC or reference counting. [0]

> What I mean is `a = sort(a)` will be optimized to `sort(&a)` which can mutate internally. [1]

Do look at the entire threads - I don't think the claims are too out of context as quoted.

[0] - https://news.ycombinator.com/item?id=19102318

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

> The controversy around V is not without reason.

There is no controversy but the one you are trying to build up. This language is obvious quite young in development, isn't backed by mega corp Z with billions of $ at its disposal, yet it is trying to manage to find a solution to multiple issues Go couldn't even resolve in 10+ years. cut it some slacks.

It’s fair to try to solve issues. But these are hard issues, and it is at best overconfident to outright say they will do X, when they didn’t even started working on it, and at worse it may be a scam making money from donations, but I am hoping that it is the first case.

> at worse it may be a scam making money from donations

Before making such a rude conjecture, at least check the dev's github page [1] first. Most of his git commits are related to V and he has been actively working on it for a couple of years, even over weekends. V may fail like many new languages, but at least the dev has paid the efforts. He has my respect.

[1]: https://github.com/medvednikov

At the start of the project, the source code was not available and I deliberately wrote that I really hope and want to believe that the first option is the correct. Nonetheless, this project did start controversially with absolutely bold claims, other, similarly small languages like zig interestingly doesn’t have bad connotations associated with it. Hopefully V will be able to shed these and will grow successful.

Reply on news.ycombinator.com