Hacker News new | past | comments | ask | show | jobs | submit login
The V Programming Language (vlang.io)
144 points by dTal 12 days ago | hide | past | favorite | 191 comments

I know the launch was mired in controversy, but work has gone on since them. Christine Dodrill occassionally takes a look at it after writing about it at launch and I like her updates. Here's[0] her most recent look at the project, from June

[0]: https://christine.website/blog/vlang-update-2020-06-17

worth noting, at the end of christine's update mentioned above:

"I do not plan to make any future update posts about the V programming language in the future. The V community is something I would really rather not be associated with. This is an edited-down version of the post that was released last week (2020 M06 17).

"As of the time of writing this note to the end of this post and as far as I am aware, I am banned from being able to contribute to the V language in any form. I am therefore forced to consider that the V project will respond to criticism of their language with bans. This subjective view of reality may not be accurate to what others see."

for anyone considering getting involved, read christine's three articles on the topic first: https://christine.website/blog/series/v

Would be helpful is Christine gave some examples to threads and discussions. Without any details, either side can be blamed for the ban.

Also, would be good to know what are the contributions. I have looked at the github page of V contributers https://github.com/vlang/v/graphs/contributors and have not find Chrinstine there.

I don't know if I have any copies of it anymore, because it was deleted from the V Discord. Once they found out I was the author of that post everything was deleted and I was banned from the Discord, Telegram and GitHub.

> I was banned from the ... GitHub

Even if they banned you from GitHub, they did not rewrite git history, I hope? I have not found any commits authored by you in the V repository:

  git log | grep Author: | egrep -i '(christ|xe)' | sort | uniq
   116 Author: Alexey <alex.esprit@gmail.com>
     1 Author: Alexey Lustin <allustin@users.noreply.github.com>
     1 Author: Bryan Christopher Johnson <bryanchristopherjohnson@gmail.com>
     1 Author: Chris <chris@suletuxe.de>
     1 Author: XeGrox <52340924+XeGrox@users.noreply.github.com>

I was banned before I could contribute to the repo.


When given criticism, banning the critic from ever contributing is a ludicrously adolescent response.

I'm going to guess (at least I hope!) that you're inexperienced in the professional world. Well, in the adult world you will face criticism for what you produce constantly.

Some of that criticism will be fair and you'll be able to act on it - you can improve what you've done. Some will be fair but you can't act on it - you can't change it in time or on budget and that's not your fault. And some will be completely unfair - it's simply not accurate.

You need to develop a mature response to all these scenarios. But sticking your fingers in your ears and going, "lalala I can't hear you" is not one of them.

Looks like this is the reason why that person was banned.


This post pretends to be a security report, but it does not help anybody (there are no users who would be protected by disclosing this "vulnerability"), it is just disruption of people work, and nothing more.

People actively breaking things cannot be just ignored, they should be banned.

> When given criticism, banning the critic from ever contributing is a ludicrously adolescent response.

According to this: https://christine.website/blog/series/v it was a year between first post and the last. It was more than enough time to make at least some contributions.

This timeline convinces me that Christine did not intend to contribute at all.

> Well, in the adult world you will face criticism for what you produce constantly.

Criticism is natural. Banning people who don't help, but distract and demotivate, is also natural.

> You need to develop a mature response to all these scenarios.

It's not that simple. Too much criticism can kill will even in strongest people. Sometimes the best response to non-constructive criticism is to just ban, and focus on what's important.

No, the best response, if the devs truly felt the criticism was non constructive, was to ignore it.

Having read the posts, it seems perfectly reasonable criticism, with enactable improvement. The dev response seems immature (at best) to me.

To put it another way: if this was a commercial product and my team came whining to me about this, I'd tell them to grow up.

> No, the best response, if the devs truly felt the criticism was non constructive, was to ignore it.

We don't know how exactly Christine communicated with project devs. We see the posts, but we don't see Telegram or Discord messages or GitHub issues or comments or whatever.

For example, there are people who just derail/flood group communications by raising non-important issues (like discussing syntax), or discussing completely unrelevant topics (like starting a conversation about political situations, human rights etc).

Anyway, I agree that the project author could do better. But I cannot blame him either. At least until either party provide some evidence.

> Having read the posts, it seems perfectly reasonable criticism, with enactable improvement

Calling a product vaporware is not a good way to start a constructive communication.

If I did that, I'd either start with apologising for calling the project vaporware, or did not attempt to join the community.

> To put it another way: if this was a commercial product and my team came whining to me about this, I'd tell them to grow up.

Developers in commercial products are paid for listening that feedback (constructive or not). But V is open source.

And in commercial companies, internal tensions are usually fixed very quickly, because teams cannot work efficiently when communication is bad.

We don't know the full story because the V devs deleted it. Experience tells me that people tend not to delete stories that paint them in the better light.

It's vaporware until it we exists. Perhaps it would be kinder to call it "conceptware" but who really cares?

Oh, and the vast majority of commercial software firms have absolutely terrible communication. And, yes, they do not work effectively.

I feel like I am destroying an optimistic world view here, which is the last thing I wanted. There are many excellent and exciting places to work. Don't let an old man's cynicism put you off!

>Perhaps it would be kinder to call it "conceptware" but who really cares?

I do. It is not vaporware, because it exists, can be used, works for the most part, and is improving every day.

Please do refrain from calling stuff, that you do not use yourself names.

> And in commercial companies, internal tensions are usually fixed very quickly

I would love to know what companies have good systems to keep internal tensions in check because I've never even seen a single company that had that figured out.

> I would love to know what companies have good systems to keep internal tensions in check because I've never even seen a single company that had that figured out.

Probably most companies deal with tensions more or less successfully. They have good instruments to manage these things: yearly bonuses and option to fire employees who do not cooperate.

Obviously these instruments are not available in open-source projects.

What companies, and what are those instruments?

I'm sincerely curious, I have worked in tech for 20 years, and while some companies are active in trying to make sure teams work well together, I've never seen one that had specific systems for keeping tensions in check - maybe it's because I've worked for <1000 people companies?

All successful companies, and these instruments are: 1) bonuses for successful work, which includes ability to resolve conflicts peacefully; 2) option to fire employees who don't work well, in particular, those who don't get along with the team and hire a replacement.

> I've never seen one that had specific systems for keeping tensions in check

It does not work perfectly, for sure. But in free-time opensource project, if you don't like something, you can always express this loudly, or just stop caring about this project, because leaving the opensource project is not a big deal.

Unlike employment, when if you quit or fired, you get a lot of stress, you are seriously motiviated to get conflict resolved.

Long time ago I read an interesting article about how hard is to be a manager in a terrorist organisation. You don't pay people money, at least not a lot, there's no contract, employees goal are likely very different from yours. They quit randomly, they do whatever they want, and it's hard to achieve some discipline. I think this is kind of similar environment as in open-source project (except, open-source contributers don't blow themselves up).

Again you’ve failed to provide a single example from your experience so I’m left to assume you have none.

Sorry, it sounds like you have idealized views that don’t match with actually working at tech companies. Please don’t proselytize things that you have no experience with - it can be massively distracting and confusing for people who are in situations where your advice seems like pure gaslighting.

Bonuses are not a way to ease interpersonal tension, in fact, they make them worse.

If I’ve misread this in any way, please let me know, but don’t further waste my time with bullshit.


I'm failing to see how that post is a "childish attempt" at anything. Offering a language playground to the general public and not sufficiently preventing that playground from compromising the very server on which it runs is a pretty glaring problem. At worst, you might criticize her for publishing that post immediately after discovering the exploit (instead of the more "polite" approach of allowing someone to patch it first, within a reasonable deadline), but that's pretty minor in comparison to, you know, V's playground being vulnerable to major security issues.

In any case, banning people from contributing to a project entirely merely because they pointed out glaring security issues is considerably more childish than the actual pointing out of security issues, no matter how distastefully the latter might've been done (and again, aside from the lack of a responsible disclosure period, I ain't seeing anything particularly glaring in that post).

I considered it not an issue to post about it because the server was down and confirmed to not come back up (I think someone ace'd it and installed a rootkit then rebooted).

And that very important fact ("confirmed to not come back up") was not even mentioned in the "advisory" blog post.

> Offering a language playground to the general public and not sufficiently preventing that playground from compromising the very server on which it runs is a pretty glaring problem

How it is a problem for anyone except project owners?

Project owners were notified. There was no need to disclose it publicly. I say it's childish.

> banning people from contributing to a project entirely merely because they pointed out glaring security issues

Banning them because they:

* don't do any good (in particular, zero code contributions in a year)

* disrupt the work by telling the internet how to break their service

* call the project "vaporware"

I'd call it is enough reasons to ban them.

And some personal argument.

I have a service I'm running, for the random people in the internet. I implemented it long time ago, and I spend like 10 minutes a year supporting it. It is not protected seriously, because I don't have enough time to do so. I think any kid with basic knowledge of how internet works, can easily break it, or even can DOS it causing me to pay big bucks to the hoster for the consumed CPU.

And I have full-time job. So if some person would notify me about the vulnerability, and give me one (!) day to fix it, I would probably give up what ever I'm doing, my work, my personal plans, and fix the issue, but I would be very unhappy about it, and I will probably be angry at that person, and I'll try to avoid that person like fire.

> How it is a problem for anyone except project owners?

Because an infected machine can and often will participate in infecting other machines.

Not to mention that if an attacker managed to extract credentials that happened to be shared between that server's accounts and, say, contributors' GitHub accounts...

More relevantly for regular users of the playground, though, it ain't clear whether or not the playground server was separate from the web server. If not, then the playground having root access immediately exposes ordinary users to high risk of browser-based attacks (drive-by downloads, outright replacing the V downloads with compromised versions, etc.). And even if they were indeed separate servers, if the credentials to access those servers were shared between them, then compromising one exposes the other.

I agree with you that maybe the author of that article should've waited more than a day, but that's really a drop in the bucket compared to the possibilities of running arbitrary user-supplied server-side code without sufficient sandboxing.

> call the project "vaporware"

I mean, for quite a while it did seem to have a lot of hype without much to show for it (as did Volt, its "killer app", so to speak), and it had a pretty rough release. It's a bit of a harsh characterization, but at the time it wasn't all that inaccurate. Hopefully things have improved since then.

> Because an infected machine can and often will participate in infecting other machines.

OK, so how disclosing this vulnerability will help preventing that? It is the opposite, disclosing this vulnerability only speeds up this process.

> Not to mention that if

That big if.

> If not, then the playground having root access immediately exposes ordinary users to high risk of browser-based attacks (drive-by downloads, outright replacing the V downloads with compromised versions, etc.).

That's good example.

And that's one more reason to privately push the owners of the project owner to fix the issue instead of disclosing after one day.

> that's really a drop in the bucket compared to the possibilities of running arbitrary user-supplied server-side code without sufficient sandboxing

I agree, that's bad, and that's happen all the time in huge companies, not just single-person open source side projects.

The correct response to vulnerability would be creating a post to pressure project owner by explaining the dangers of it without disclosing how exactly it can be exploited.

> It's a bit of a harsh characterization, but at the time it wasn't all that inaccurate.

Analogy. Your coworker is dumb. You can say he is dumb. And then he refuses to work with you.

Saying he is dumb is not innaccurate. But it doesn't help constructive team work.

The blog author could start by apologizing (or at least by redacting the post), if they wanted to work with the project team.

> Project owners were notified. There was no need to disclose it publicly. I say it's childish.

I don't think you understand how disclosure works within security.

Well, I can only say you don't understand how disclosure works.

When vulnerability is disclosed, there are usually good reasons for doing so.

For example, when a vulnerability in operating system is found, it is disclosed, so users of that operating systems could upgrade operating system, or stop using it, or ask vendor to fix it or whatever. Disclosing this vulnerability makes the people (who are not project owners) safer from possible attacks from attackers who can independently find this vulnerability.

How would disclosing vulnerability of V playground be beneficial for anybody? I can hardly find any significant reason.

It's like you have accidentally found that your neighbour forgets to close the door when he leaves for a walk. You notified him, he did nothing. Disclosing this vulnerability would not make good to anyone except burglars. Good people don't do that.

What's wrong with that post? It seems like the playground in question had some security flaws and those where found.

Users of the service were not affected by this vulnerability, it had no personal data or something.

The only people who could be hurt by this vulnerability is the project owner.

Disclosing this vulnerability would only make it worse for the project owner, and would not do good to anyone (except cracker who might want to use the server to send spam or something).

This post did no good to anyone. It's lose-lose. That's why this post is wrong.

Author of that post here in case you have any questions, ask me anything!

Wow, it makes me sad to hear they had retaliated in this way.

You're one of the most knowledgeable people I've seen, with a consistently incredible blog I've learned so much from.

At the end of the day, it's an experimental language that (I thought) was fun to mess around with. Not a very kosher way to respond to factual criticism.

Thanks, I try.

The last article had to be edited down because as it was written initially (see the git history of https://github.com/Xe/site) it made the V cult come after me. This among other things is why I do not plan to write about V in the future.

> The last article had to be edited down...see the git history

For anyone interested:


> I do not plan to make any future update posts about the V programming language in the future.

As a V contributor, I regret that you decided that. Even though I do not like your attitude towards what is in the end an open source project with many contributors, I do think that your posts when they contained objective and reproducible examples, were actually contributing indirectly to make V better, by pointing out our weak sides at the time of writing.

I just got tired of the anger that the posts get me on Twitter, email and on forums. If there wasn't so much transphobic garbage spat at me when those articles were new I would probably be working on a planning document for part 4.

IDK, some of your criticisms seem a bit over the top.

For example, compiling 1000 files with 1200 printfs results in ~80mb (according to my poor math skills) worth of static strings and then you state they aren't doing a very good job of creating small binaries because, dunno? Sure, some fancy whole program optimizations should be able to figure out the 1.2 million functions are basically the same and just compile one version -- which, honestly, you'd think the C++ compiler could also be able to figure out but seems to not be doing either.

Not that I think they should be banning people for things like this.


Actually...thinking about this a bit it seems a particularly hard optimization problem since the functions only vary by the address of the string they print so the optimizer would need to know this detail while determining the function hash (or whatever is used for equality testing).


Yep, saw the downvotes coming...perfectly fine to bash on someone else's hard work on a new language though.

In all actuality, if I were working on an optimizer I don't even think I'd bother with something like this because if you program like this (duplicate functions) in The Real World™ then you get what you deserve.

What caused them to ban you?

Since you're here...

>Do not shell out to arbitrary commands in the standard library for any reason. If an attacker can somehow run code on a server with a V binary that uses the download_file function, they can replace curl with a malicious binary that is able to do anything the attacker wants.

I don't understand this threat model. If an attacker is in a position to replace /usr/bin/curl with a malicious binary, surely you're already pwned? And surely an attacker could just as easily switch out libcurl.so as the curl binary? I just can't make sense of any threat model which treats the OS as untrusted.

As written it's it won't just call /usr/bin/curl, but the first curl in $PATH. Not to mention just hardcoding /usr/bin/curl isn't portable (Android/NixOS don't have a /usr/bin like you expect). Also take a look at this: https://christine.website/blog/OVE-20190623-0001

Many computers are misconfigured to include "." (the current working directory at the time of execve) in PATH, which allows a trivial privilege escalation and/or native code execution for any attacker that can write a executable file named "curl" in any directory that the target process can be convinced to cd into.

Shelling out also means the process will unexpectedly stop working if /usr/bin/curl disappears (or wasn't installed in the first place), whereas that's a known and expected issue for libcurl.so and there are established tools (eg `ldd /bin/program`) for tracking such dependencies.

What is the problem with the "still reachable" memory report in Valgrind? That's not a leak, that is just skipping an unnecessary free() that will happen anyway when the process exits

Some embedded platforms don't have memory protection, but just a big blob of global heap memory. If you forget to call free(), that memory is gone for good until you clear the entire ram and start over. Admittedly this doesn't seem to be a target use case of V, which only supports x86_64, but any serious C competitor must have meticulous memory accounting and not rely on the OS to clean up after it.

I may be wrong, but my C teacher in college told me that was a leak.

I’m with shawnz. If it’s a global/static, and you’re the entire process, freeing it is altogether a waste.

Actually, if you have actual destructors, it’s even potentially hazardous. Rust deliberately eschews static constructors and destructors due to their problems, so I presume it would fall foul of this test of yours as well. It offers this explanation: https://doc.rust-lang.org/1.6.0/complement-design-faq.html#t... (link is to the Rust 1.6 docs; in theory by the next release the content was ported to the main site, but I can’t find it and suspect it got lost at some point).

Now if you’re a library, then having the ability to deinitialise your library might be useful. Probably not, but it might be.

> Rust deliberately eschews static constructors and destructors due to their problems, so I presume it would fall foul of this test of yours as well.

I would be surprised if embedding a string literal into a Rust program would cause a runtime dynamic memory allocation. There is no reason for that: it can be embedded into the binary as static constant-initialized data.

So I would presume the opposite: I would expect that the comparable Rust program would not fail this Valgrind test, because it would not perform any dynamic memory allocation at all.

I don't know anything about V, but I would similarly wonder why this program requires malloc().

This is true; I contemplated it but decided not to mention it. I haven’t looked into why this V program would be allocating, but I agree with you that the equivalent Rust program would not allocate for this.

I decided instead to focus just on the matter of what happens if you do allocate in such a global—which Rust doesn’t let you do directly, you deliberately have to use a trick like lazy_static which constructs on first use and then deliberately leaks so that it never has to destroy.

I admit I was wrong, I will use this information in the future to make my blogposts better.

Failing Valgrind is surely not a state in which neither a serious program should be nor the code produced by it. Most programs and their results that are in serious use are actually regulaly tested with Valgrind and therefore don't have such elementary failures, unless they aren't maintained.

It doesn't have to be "a library" -- as soon as you want to test it, you don't want it to fail the trivial tests. Nobody wins anything by keeping that in that state.

Who says having "still reachable" memory in your Valgrind output is a "fail" though?

Look at this excerpt from the Valgrind manual:

> Since the block is still pointed at, the programmer could, at least in principle, have freed it before program exit. "Still reachable" blocks are very common and arguably not a problem. So, by default, Memcheck won't report such blocks individually.


> Most programs and their results that are in serious use are actually regulaly tested with Valgrind

See https://github.com/vlang/v/tree/master/vlib/v/tests/valgrind . The automatic memory management is work in progress right now, but we do have a growing battery of tests for it.

I currently would not use V for a long running program for exactly that reason, unless it is a very simple service and I free everything manually. That said its -autofree mode is improving daily.

Isn't all memory falls into that category then? "We are not leaking X bytes per request, we're just avoiding unnecessary free"

No, in your example that's a necessary free because you'll exhaust the system memory eventually otherwise

> So the compiler with "zero dependencies" is a dynamically linked binary > with dependencies on libpthread and libc.

And requires an OS to run too. That's another dependency! This and memory leak, seems quite forced. Ad homminens doesn't help either.

Its been a while since I've read something that entertaining. Thank you.

No problem, I'm planning to write more like that, but I may end up dialing back the sarcasm a bit

Please do. I really enjoy your objective criticisms.

Hm, are you sure that attacking the V's playground at the time and publishing info, that others could use to attack it, did not have something to do with your ban?

So you know the context. Can you please tell us, why exactly the blog author was banned?

I do not know the full context, because at the time I was not involved with the V project.

I did notice then though that the playground was taken down, and there is this: https://web.archive.org/web/20191223200601/https://christine... (unfortunately I could not find an earlier snapshot, sorry)


It was posted after the project owner confirmed it was down and would stay down.


My chatlogs from then show that this was first discovered on an IRC channel and then I notified the V author as soon as I could.

This was not my finest hour, but the server was good and confirmed as not coming back online about a day before I posted that advisory.

You can believe what you want about this, you seem unconvinceable either way. Also see https://github.com/Xe/site for the git tree behind my site code and blogposts.

So if I recall correctly? when this language was first announced there was some strange controversy about it mostly being vaporware and serious claims being made about the language and its performance before they were implemented.

I assume this has mostly changed now? Has anyone tried using it recently?

I think when V was first announced (and to a lesser degree still today) it was really hard to tell the difference between the things the author had actually running and what was only “the vision.”

For example, V compiles to C super fast. Then you compile the C code at normal C compilation speed. Very logical design so no complaints there, but the original claims made it sound like it went straight from V to machine code in a blink, which isn’t exactly true.

However I will say that the project has been very active, the author has made his claims a lot more clear, and so far he’s delivering on his promises little by little.

If I were to summarize my experience testing out V, I would say the author looked around at the world of software engineering and said, “there are lots of good pieces out there, but what I want is one language + Stdlib that does absolutely everything, and what the hell, I’m just going to make it myself.”

It’s super ambitious, but it’s also pretty neat.

I wonder what are the tradeoffs between targeting C and targeting LLVM/LLIR? Is it mostly "I know C"? Given that LLVM is purpose-built for this kind of use case, I would expect that it would be the better target, but I'm not very knowledgeable on the subject.

I'm one of the maintainers of the Terra language, so I can shed some light here.

In addition to what the sibling comment said, LLVM is a moving target. The project moves slower now than it used to, but as a general principle, the project does not provide backwards compatibility. That means there is a certain amount of constant effort required just to keep up. Even projects featured on the LLVM homepage get behind, sometimes by a large number of releases.

You're right that LLVM is better for some things. E.g. if you want to generate "real" debug info. Or if you want to generate code for GPUs, without having to teach your compiler to generate what is essentially a different language. But if you're talking about the fastest (and in many ways most stable) path to generating code, you can't really beat source-to-source with C as output.

Well, emitting C is easier than emitting LLIR. Not just in the sense that you know C already and don't know LLIR yet, but if your source language is close enough to C semantics (basically, it's imperative language), you can most of the time generate the code in one straightforward walk over your whole AST. In fact, translating it to some home-made lowered IR and then to C would probably produce less effective binary.

Can use any compiler. (GCC sometimes optimizes better than LLVM, GCC has more platform support, TCC can be used for faster compilation).

LLVM interface is unstable.

That said there are things you can't properly implement by compiling to C.

> there are things you can't properly implement by compiling to C

Very interesting claim, any examples?

• You don't control your ABI. For example, you can't reserve a register for error object return like Swift does.

• You don't control your stack and stack frames. You can't implement a segmented stack, for example.

• You have very limited options for unwinding. setjmp doesn't really cut it. You could leverage C++ exceptions or platform-specific things like SEH, but you can't design anything radically different.

• You can't have debug information fancier than #line and maybe reusing C++ name mangling. You can't make debuggers see your higher-level constructs and data as anything other than their lowering.

• You have very limited options for specifying pointer aliasing.

• If you don't want to inherit UB from C, you'll have to be very clever about using alternative constructs that don't cause UB while still compile to efficient code you wanted.

• If you mean standard C, not C with compiler extensions, then look at the whole list of non-standard intrinsics and built-ins for things C can't do.

If your source language has some construct that you want to express as state machines (e.g. async, CPS, pattern match compilation), and you want to compile the state machine as direct threaded code[0] (which involves fewer branches than a while-switch), then if you're compiling to C, you need computed gotos[1], which are non-standard.

[0]: https://en.wikipedia.org/wiki/Threaded_code#Direct_threading [1]: https://gcc.gnu.org/onlinedocs/gcc/Labels-as-Values.html

GCC, Clang, ICC do support computed gotos and you can fallback to ``while true`` loop + switch dispatch for others.

This is what Nim does: https://nim-lang.org/docs/manual.html#pragmas-computedgoto-p...

It's not only interesting, it's blatantly false.

There are certainly some good reasons to use C as your backend, but there are some huge downsides as well. The main one in my mind is that you're limited by restrictions placed on you by the target language. V claims no UB but C has lots of UB so extreme care must be taken while doing code generation not to run afoul of C's rules. A quick glance at V's issue tracker shows that is not the case. Nor does there seem to be any plan for solving this.

Other points in that document are frankly baloney:

- Writing programs that pass -Wall -pedantic, Clang analyzer, PVS, and result in zero Valgrind warnings/errors is a dream of any C/C++ developer. With V it's going to be guaranteed for every V program. (We are not there yet, but very close.)

Clang analyzer is not integrated at all so this is not "very close".

Valgrind tests are mostly disabled (especially with -autofree), this is baloney.

Author has yet to set up PVS or Coverity although it was suggested a few days ago on Discord. Again, baloney.

`-Wall -pedantic` Given V can't even compile valid V programs consistently without generating C _errors_ I find this extremely difficult to believe.

> Stability. New languages using LLVM directly are going to crash often. That's inevitable, and can be seen across all new languages using LLVM. The V compiler hasn't crashed once for me, and I haven't received any crash reports from other users.

V issue tracker has lots of instances of the V compiler crashing. "I haven't received any crash reports from other users" is a verifiable fabrication. ([1](https://github.com/vlang/v/issues/6310), [2](https://github.com/vlang/v/issues/6263), [3](https://github.com/vlang/v/issues/4730))

> Simplicity. LLVM is a huge C++ dependency, meaning that both developers of the language and the users are forced to install it. Calling C++ is not easy from V/C, so C wrappers have to be used, increasing the number of dependencies and complexities.

But you need a C compiler. `v -o` requires either clang (and thus LLVM) or GCC both of which are massive dependencies. This logic rings hollow.

> But you need a C compiler. `v -o` requires either clang (and thus LLVM) or GCC both of which are massive dependencies. This logic rings hollow.

It requires a C compiler. You said it yourself. Clang and GCC are not the only existing C compilers. tcc for example is tiny compared to them - on linux, `thirdparty/tcc/` is ~4.1MB, excluding the `thirdparty/tcc/.git` folder, and ~5.8MB including it.

> Author has yet to set up PVS or Coverity although it was suggested a few days ago on Discord. Again, baloney.

I personally, find the following course of events very interesting:

On 2020/09/14, a Discord user named `Engineer` writes the following:

> We should consider using Coverity as this is an opensource github project - we can test the output v filename.v -o filename.c as input for Coverity - to help us understand issues with the generated C code.

Mind you, that is not a code contributor, and his earlier questions, are about a mysterious undisclosed C compiler, that produces much more stricter error messages than gcc's ones.

Then he makes a short lecture on the topic of `What is static analysis?` again on Discord...

It is a Scooby Doo mystery indeed.

I have nothing against Coverity personally - it may very well help the V code generator, but I hate being forced to use a product in such a way.

Yes, please continue unraveling this "Scooby Doo mystery", I'm sure it will be entertaining for everyone!

Do you think there's a coordinated campaign by(?) Coverity to get your open source project to use it? For what reason? It's surely not to make money considering Coverity gives open source projects a free license.

> I have nothing against Coverity personally - it may very well help the V code generator, but I hate being forced to use a product in such a way.

Yes, two random people telling you to consider using a static analysis tool is "forcing" you to use a product.


This is a great example why everyone should stay away from V. Industry standard best practices are treated as conspiracy theories by the developers.

It's fine for people to decide they want to make a new language; that's great! It's also totally fine for all of those people to have no idea what they're doing; that's how you learn. But at some point, you need to recognize that you don't know what you don't know. V is not anywhere close to the level of production ready-ness you yourself have repeatedly claimed.

I myself do not claim that V is production ready. It is not even 0.2 ... I think it is very disingenuous of you, to put words in my mouth in such a way. I would appreciate, if you stop doing that to me, or others in the future.

As for Coverity, we are considering it, and afaik Alex has a license for PVS-Studio.

Part of this authors' "vaporware" criticism aims squarely at his "Volt" app [2] (the reason for this language), which was supposed to be released sometime last year, but as far as I can see, after some buggy beta releases [1], has disappeared again. It may be coming back [3], but a lot of confusion here. [4]

[1]: https://twitter.com/volt_app

[2]: https://volt-app.com/

[3]: https://github.com/voltapp/volt/issues/164

[4]: https://github.com/voltapp/volt/issues/149

It got flamed hard on /r/programming several times.

My personal impression was that V was an extremely ambitious project by a single developer without much experience taking on such a project, and the feature list was more of a roadmap last I looked.

There were also some head scratchers in the implementation/libraries and I recall that the playground got pwned and there was a great blog post flaming it but I can't find it at the moment.

A serious number of CS-defying claims, most of the rest being intellectually dishonest.

To be fair I didn't see a ton of "CS-defying" claims as in they were impossible, however he made a ton of claims that would put his language on par with languages with huge teams of people, several with major companies backing them, with far more resources.

It was like, really? You're going to have all these features that teams of engineers have been working on for decades (in many cases)? And do them flawlessly? You're also going to beat Zig, Nim, and Go - in far less time?

I've got no problem with projects like this for fun, but it's being marketed as a full fledge project.

There was at least the CS defying claim of "no GC, no leaks, simpler than rust" (I'm paraphrasing, but it was along these lines). Sounds easy when you just write it as a checkbox on a list of exciting features.

There is no GC, and the language is indeed simpler than rust.

The "only" thing missing for now is "no leaks", but we are working on it.

You may be interested in https://aardappel.github.io/lobster/memory_management.html .

> regarding lobster memory management:

> the scope of anonymous functions cannot outlive variables' scope they reference, however V plans full closure support

> lobster compiles whole codebase at once (so it can properly track data flow across module boundaries), however V plans incremental compilation support

> both points are direct consequence of lobster's choice for memory management, ie solving them would mean moving away from lobster's strategy as far as I undersand


Lobster's approach at least has some theoretical rigorousness to it. What V is doing is quite different both in terms of the implementation and the requirements from the language itself and they have never been shown how their version is sound.

I still don't want to play with that because the author seems to insinuate that his language is the leanest fastest because it compiles to C as if he's not taking the C->native step.

TFA lists total time with clang and tcc backends. I believe it also has a beta quality x64 native backend now.

I believe part of it is that they were getting a lot of donations, probably based to some extent on those claims.

I remember this as well. My opinion is that both sides were in the wrong. I think it's a case where the creator is overambitious, and set unrealistic timelines that obviously weren't met. In response, many called him a scammer/vaporware because he's soliciting donations.

That said, the project kept progressing along and seems to get daily commits, which would be unusual for vaporware.

I never mind that creator was ambitious. The problem is he made the claims as if they were implemented, without even knowing about the feasibility of them.

The creator of V also seems to lack knowledge of CS fundamentals and apparently thinking he can make a great language by retrofitting "missing features" into Go.

The language is an unfunny joke.

Well, I can definitely see why someone would want to add generics and less verbose error handling to Go.

The word is retrofit.

I fail to get the distinction you're trying to make. "To retrofit", to my knowledge, means "to add a part to something that didn't have it originally". Is it supposed to be pejorative?

Slightly pejorative in that it suggests a result that's less effective/streamlined/economical/whatever than had the new part been included (or at least accounted for as a possible extension) in the original design.

Want to comment as someone who has written small amounts of code in V and followed it since near it's inception:

V is essentially a much cleaner version of Go, syntactically. Though it adds many features that turn it into one of the nicest (IMO) languages to write.

It adds:

    - Hot reloading, on a compiled language (WOW)
    - Pattern matching/match statements
    - Option/Sum types
    - A really clean approach to handling Maybe results that I haven't seen in other languages before -- EDIT: I take it back, apparently my own ignorance here
    - Generics
    - C interop and compile/build integration that's incredibly easy
Some of my favorite bits:

    // Error-catch + propagation on Maybe's with "?"
    fn f(url string) ?string {
        resp := http.get(url) ?
        return resp.text
    // Identical to this -- Option types must be handled with "or" if not "?"
    resp := http.get(url) or {
        return error(err)
    return resp.text

    number := 2
    s := match number {
        1    { 'one' }
        2    { 'two' }
        else { 'many'}
Additionally, the devs/community on Discord are really friendly, and they spent an hour helping me compile Facebook's reference C++ GraphQL parser library, and interop with the C API from V. I'd never touched low-level stuff before and the experience was a blast.

This was all it took (minus figuring out the C++ build process):

    // app.v
    #flag -I libgraphqlparser_compiled
    #flag -L /home/user/Projects/vlang-graphql/libgraphqlparser_compiled
    #flag -l graphqlparser
    #include <GraphQLParser.h>
    #include <GraphQLAstToJSON.h>

    struct C.GraphQLAstNode{}

    fn C.graphql_parse_string(text charptr, error &charptr)  &C.GraphQLAstNode
    fn C.graphql_ast_to_json(node &C.GraphQLAstNode) byteptr

    node := C.graphql_parse_string("query MyQuery { id email }", "Failed to decode")
    json_str := cstring_to_vstring(C.graphql_ast_to_json(node))
And because the primary compilation target atm is C, performance is generally screaming fast.


Edit: Want to clarify it's still experimental. As a concept/language, I found it fun.

See Christine Dodrill's negative experience and valid criticisms below for the other side of this coin.

> A really clean approach to handling Maybe results that

Rust has exactly the same question mark syntax, and obviously V copied it from Rust.

Copying good ideas from other languages is right.

> I haven't seen in other languages before

But you did not know that the syntax was derived from Rust. And the value of a review of some programming language from a person without basic knowledge of the space is not very helpful.

It's likely that you missed a lot of other important details. Like this one:

> V is essentially a much cleaner version of Go, syntactically

Syntactically only, yes. But it is very different from Go, because it does not do garbage collection.


V's Maybes are different than Rust's, only the ? syntax is similar

1. Option/Result are unified into a single type, ?T.

2. It is not parameterized over the error type.

3. The Ok() case does not need to be marked (ex. you write 1, not Ok(1)).

4. In addition to the x? sugar, there is also x or { ... } sugar, which is like Rust's x.unwrap_or(|err| ...) except without the closure so you can eg. break or return from the block. There is also if y := x { .. } else { ... }, which is like Rust's match x { Ok(y) => ..., Err(err) => ... }.

These are all reasons you could think V has cleaner Maybe handling than other languages.

> 1. Option/Result are unified into a single type, ?T.

This is not a positive. Option<T> and Result<T, E> have semantically different meanings. This is like saying integers and strings have been unified into a single type: string.

Ah, I meant the "or" operator, in Rust you have to match on the option result right?

  match maybe_error {
    Ok/Some(val) =>
    None/Err =>

You can do

result.or_else(|err| ... )


result.map(|value| ... )

Ah welp, fair enough that's on me for being clueless. Edited my answer.

You can do result or { break }. You can't do that from a closure.

Hot reloading in a compiled language is not that difficult - you just dlclose/dlopen/dlsym the shared library when it changes.

Hah! You have to deal somehow with objects created by the old code, and pointers to static data or functions that move.

Various systems solve that in various ways, but it's definitely complex and difficult.

But making sure program won't crash after reloading (e. g. because of memory layout or invariants change) is much harder, and I doubt V prevents these failures.

It does not. The reloaded program can crash.

It is very useful for tweaking code, but if you make more substantial changes to your state, currently hot code reload will not help you, and you may be better of just restarting your app.

I guess I'm just easy to impress then, because lower-level code might as well be magic to me haha.

The handling of the maybe result is similar to the do notation in Haskell for the Maybe monad.

What's this clean way of handling Maybe? The question mark operator or something else?

The problem with V is the habit of intellectual dishonesty surrounding it.

Take this chart, showing the selling point of "fast compilation times":

                Space required  Build time
    Go          525 MB          1m 33s
    Rust        30 GB           45m
    GCC         8 GB            50m
    Clang       90 GB           60m
    Swift       70 GB           90m
    V           < 2 MB          <1s
All of these programs native compilers of complex languages, supporting multiple architectures. V is a frontend for a C compiler, which is likely GCC or Clang. It doesn't even belong in the comparison.

The fact that building Clang/LLVM takes 90GB of disk space is of course a sign of the impending collapse of human civilization, but I digress.

V can use any C99 compiler as its backend, including tcc, clang, gcc or msvc. It really does recompiles itself very fast - on a i3-3225, using tcc it self compiles for ~0.6s .

You can clone the repo, type `make` in it, then do `time ./v -show-timings self` and see for yourself - it will take you less than a minute (including cloning and the initial make which also clones from another C repository v.c, then compiles it to bootstrap v).

I'm not sure where they got that number, but my LLVM 8.0.0 install (relatively complete, including Clang, etc) is 1.7GiB.

According to the website, V seems to have two backends: C and x86 - so it's not just a frontend to GCC. Unless I'm mistaken?

There is a native backend, that compiles directly to elf binaries on linux without using a C compiler, but it is still wip (and can not yet be used to selfcompile V itself for example).

For example:

    0[20:45:04] /v/nv LINUX $ ./v -x64 examples/hello_world.v
    use `v -x64 -v ...` to print resulting asembly/machine code
    code_start_pos = 78
    x64 elf binary has been successfully generated
    0[20:45:08] /v/nv LINUX $ ls -lart examples/hello_world
    -rwxrwxr-x 1 delian delian 188 сеп 15 20:45 examples/hello_world
    0[20:45:17] /v/nv LINUX $ examples/hello_world
    Hello, World!
    0[20:45:21] /v/nv LINUX $
... and yes - the generated executable is 188 bytes long...

If curious, see previous discussions:

https://news.ycombinator.com/item?id=19403271 (191 points / Mar 15, 2019 / 182 comments)

https://news.ycombinator.com/item?id=19526924 (61 points / Mar 30, 2019 / 101 comments)

https://news.ycombinator.com/item?id=20229632 (146 points/ June 20, 2019 / 137 comments)

It's still strange. What about Github stars? Either the HN crowd is very biased or we have been ignorant or V enthusiasts do not show up here often. Most of the latest system programming language discussions and post here revolve around Rust, C, Go with some sympathy for Nim, Zig, Crystal and others.

A quick lookup on star ranking gives surprising results for V: * Go 76.5k * Rust 48.2k * V 18.5k (??) * Crystal 15.2k * Nim 9.9k * Zig 6.6k

V got a lot of hype last year, and then a lot more criticism here on HN. I suspect that's a reason it's not been promoted much on this site. People who saw it coming out last year (like me) mostly ignore it, and the people interested in it found other places to discuss it without the criticism.

HN is a bubble. It does not see the whole web.

> Most of the latest system programming language discussions and post here revolve around Rust, C, Go with some sympathy for Nim, Zig, Crystal and others.

Well I've got to give it to V for rolling without LLVM and forking from Golang's compiler, unlike Rust, Crystal and Zig.

There is an indeed language bias and a ton of shillers going on here.

That a look at the comments on this post. Nothing but stones thrown at a free open source project.

Peak tribalism. Unfortunate coming from us developers, a segment that often prides of being detached from emotion.

I always have this feeling that the author of V just does not really know how to properly write a compiler. imho he just always hacks something up without properly learning the craft, which frequently results in some monstrosity that at first does not quite work and gets slowly patched to the real thing (e.g. the parser). This is very annoying because sometimes the real thing is quite easy (or a solved problem) but the V compiler just seems to fail at it.

Should every software engineer immediately be well-versed in everything they attempt? It's the passion project of a single engineer, not a company or team. Imagine if we directed this mindset towards every new open source project.

There are many people designing languages for hobby. See r/programminglanguages for examples. But they didn't claim they were creating next big thing with all those 'dreamed' features.

I don't see anywhere on the website that the author claims the language is 'the next big thing'. Perhaps the author takes some pride in what they've accomplished, but should we really police people feeling proud of their own work?

The context for most discussions of V is the over-promises about feature delivery the author has made. You could dig up all the old threads AGAIN (what, 5 times this year?), but that wouldn't really help anyone. Judging by the website, I don't think the general hype pattern (including the impossibly thin claims about compiler performance mainly measuring Clang) has changed all that much, though it appears to have slowed.

A lot of the actual Next-Big-Thing-ism seems to be coming from excited users rather than the author himself. There is a GitHub issue entitled "Very long term consideration: what it takes to get a language adopted by Google?"; there are others about getting "parallelism & concurrency for seamless local and distributed programming" and similarly extraordinarily lofty goals. People love being part of the winning project, and the overall hype history has drawn them like moths. That's OK, they can all go hang out writing V programs and wishing upon stars. It probably shouldn't bother people as much as it has.

When should we "police people feeling proud", then? Here I think there's not so much harm. Legally speaking, pretending he's in my jurisdiction (AU) for a moment, seeking donations can be trade or commerce, and then a bunch of consumer protection laws may apply, esp. ACL s 18. But you still need people who feel they've been wronged. Show me someone who tanked a heap of money into it on the pitch alone and I'll change my mind, but I don't think that's happening.

On the point of design vs actual quality, you can get an idea of OP's perspective by browsing through the GitHub issues. To be fair, the project is only a few years old, but some of the issues there are simply alien to me. It just doesn't seem like it was written in a language that has the features V has. Every new feature seems to have missed matching an enum variant somewhere. I don't understand how a compiler could exist that appears NOT to be made of building blocks that don't completely break when you add new features. I just can't relate many of the errors people get to a "Parse -> Valid Syntax -> Type Checker -> IR -> ... IRs ... -> Machine Code" progression. This is what makes me think it's not going to survive very long -- those kinds of bugs don't simply stop cropping up.

Unfortunately, V currently does not generate a classical stricter IR, but C code (as strings) directly, which explains some of the issues concerning C compilation errors.

I am optimistic about the future though, so I continue writing and changing V programs (the V compiler itself is a V program mind you)... I am not in the habit of wishing upon stars (or other people), for something that requires just thinking, engineering and time.

p.s. PRs are welcome.

Right. It's like sitting down in a café with your whole day of work ahead of you, a nice cup of coffee and some thinking, engineering and time. Except the day is perhaps 400,000 man-hours long, for all the things V wants to be. Every new project is nice when it's greenfield, but V is something else. V seems to be perpetually on the cusp of greater things. And it has done all the things that projects do when they are there, and will continue to do the things that projects do when they are there. (Like stability guarantees!) That does not make it a great thing, but it stays enjoyable to hack on because you get to be part of a thing that exists. And it's on the cusp! As long as V never gets good, and the author keeps claiming things are around the corner, it will always be on this cusp. And coding it will never be too complicated, because V doesn't do any of that fancy stuff. Well, it already does, but not yet. "It does but not yet" is exactly what makes you the happiest, because you simultaneously get to be part of the avant garde, and not have to know how to do it. I bet the author loves it. It's no fun when people point out that it doesn't yet, because it will, it will because all these people here are busily plugging away and adding all the things it already has, which is significantly easier than adding the things it hasn't. It's even worse when people say it won't, because if it won't, then it never did. Unfortunately, for the people you need to make it work, that kind of "It does but not yet" is not fun. It makes me bristle. This Sisyphus, reader, would rather throw himself down the mountain. You, too, can feel the nausea if you sit with it.

I am more motivated to have a language that compiles fast to small binaries, is easy to understand and use, and is cross platform, but thanks for you attempt for psychoanalysis of a stranger on the internet anyway.

If I were you though, I would stick to coding, your prose is hard to read - at least try to use proper punctuation and spacing.

Reads fine to me. The gratuitous negativity is unnecessary.

Given this is hacker news, hacking something up seems very appropriate. I don't know the author, but it is clear that he is prolific and talented.

This project is very much in the seeking ground phase, so having a bunch of hacks is very appropriate. If it turns out useful, then people will fix things. If it turns out not to be useful, then oh well.

The danger of course if there are show stopping bugs which prohibit the transition from interesting project to useful project.

Perhaps it will become the most popular web backend language then.

Just as we separate web design and development into different disciplines, we should consider splitting language design and development into different disciplines as well.

The V language looks beautiful (like an improved version of Go). There's always the chance someone will design something that's too complicated to develop, but that's the same with web design.

Except in web design you rarely create a design that is literally, provably impossible to make

Can you be more specific about what is impossible to make?

Any decent language designer should know the Halting Problem and how that translates to static analysis (Rice's Theorem). But more than that, it's quite easy to design typechecking algorithms that exhibit combinatorial explosion. A naive language designer could promise fast compilation speeds and robust typechecking with inference, assuming that typechecking could be sped up with caches and a fast implementation language. However if the typechecking algorithm is O(n^3), no matter what, compilation speed will be slow.

I lived through the early 90s, when Borland's Turbo Pascal and later Delphi, compiled programs in a fraction of a second.

It proved empirically, that compilation does not need to be slow, if the language is simple and carefully designed. Go is also a good example.

Computers are now several orders of magnitude more powerful.

We do NOT have to wait for compilation of simple programs in 2020. In my opinion, waiting is more of a symptom of the current obsession with optimization, and disregard for ergonomics, than a fundamental CS result that is set in stone. Compare for example compiling a program with gcc and tcc (without optimizations, so that they are on equal grounds, because tcc does not strive to do optimizations, but strives to be fast and tiny) .

tcc is usually 4-5 times faster.

I don't think a total split is reasonable (in both examples given). Technical implementation and design inform each other because there's always a point where limitations, performance, or some other aspect becomes relevant, and where having knowledge of both domains is very useful.

You can have a designer say, create a great UI but if they are not aware of the underlying limitations of the tech it can create a lot of headache. This may be even more relevant for language design and implementation. Ideally you have 'all-rounders' around for these issues.

Yes, ideally in both the designer has some mid-level understanding of development and the developer has some mid-level understanding of design. Without that overlap, things can go off the rails.

Maybe you are right. Heck, you probably are. But should it matter? If the claims are real – fast compilation times, hot reloading, and an overall nicer/safer language to work with.

I'd be interested in hearing the critique of language, features, claims. Not sure if the implementation details are relevant to end users of language.

It's been shown time and time again they aren't: https://christine.website/blog/v-vaporware-2019-06-23

The author has been doing periodic reviews of the development of the language: https://christine.website/blog/vlang-update-2020-06-17

V is mostly vaporware with a lot of bombastic marketing.

V is not vaporware - I use it daily, so do hundreds of other developers - see the commit log at https://github.com/vlang/v/commits/master .

Have you tried it yourself?

It takes just a minute to clone and build it, if you already have a working C99 compiler like gcc on your machine.

I get a similar impression. And it's a shame because their language design skills seem much better than their compiler development skills. Unfortunately I think compiler implementation is probably more important than language design as a component of a languages overall success.

PRs are welcome. Especially from skilled compiler developers.

Alas I'm not one either. I would love to make my own language. But I definitely don't have the skills to do so at the moment. For now I've decided I'm better of contributing change requests to existing languages.

Edit: I would like to add that I once had your optimism and enthusiasm for my projects. I didn't quite manage to achieve them, but I got an awful lot further than most would have predicted and I learnt a great deal in the process. So all power to you.

How would you properly learn this craft? What resources would you recommend or look into?

K. Cooper, L. Torczon "Engineering a Compiler", 2nd ed. (2011)

A. W. Appel, M. Ginsburg "Modern Compiler Implementation in Java" (2007)

S. Muchnick "Advanced Compiler Design and Implementation" (1997)

The last book focuses entirely on program analysis and optimization. It even has a chapter on optimization for the memory hierarchy! Of course, since it's a rather dated book, the specific details in that chapter are mostly useless today, but the rest is solid.

However, those books mostly cover imperative languages (although Appel & Ginsburg devote a chapter on functional languages, both of strict and lazy variety and discuss some optimization challenges), so if you want to learn about implementing functional languages...

S. L. Peyton Jones et al. "The Implementation of Functional Programming Languages" (1987)

A. W. Appel "Compiling with Continuations" (1992)

Holy fatcats, those are some old books! But sadly, I am not aware of more modern ones. Try searching for papers on the topics that interest you in particular, I guess (for example, there are several papers that discuss appropriateness of using CPS as IL: "Compiling with Continuations, Continued", "Compiling without Continuations", and "Compiling with Continuations, or without? Whatever". Yes, the puns seem to be the noble tradition in the PL implementation circles). The first book starts as a general introduction but starting at about the middle firmly steers into implementing a lazy languages. The second is pretty much a description of how SML/NJ compiler was made, based on its state in about 1991, of course, and has some interesting benchmarks on efficiency of different implementations of closures.

Plus, there are lot of random pages on the web with resources for various compiler implementation courses from different universities. For one arbitrary example, https://course.ccs.neu.edu/cs4410/

Probably LLVM. You just have to parse the syntax into LLVM IR

If your language is fairly low-level, you might be able to get away with "translating" it into LLVM.

If it's not low-level, you have to make a bunch of implementation decisions - how do your language's killer features work under the hood??

For just one example, for V, the author reuses Go's `go` keyword to launch a new coroutine/green thread. What algorithms do you use to share work between threads equally? What data structures do you use to represent those? What's the right balance between latency, throughput, memory usage, etc etc?

Many common language features are non-trivial to implement, even with the help of the LLVM IR (which I think is wonderful).

Dragon Book probably still valuable resource.

It should be noted though that Dragon is very detailed especially on parsing. Thus some consider it a bad introductory book and/or even outdated. But it's good resource if you want to become better and parsing is just a part of the book.

The Dragon Book used to be a good recommendation but not anymore. It is outdated.

Well I would hope then the V spec is well defined so that people can write competing compilers. The beauty of a language is the spec, not necessarily a specific implementation.

Language specs are a dime a dozen. Especially when type inference is involved, it's the compiler / interpreter that really does the heavy lifting.

I have an idea, let's create a new programming language! I'll be the "ideas" man and come up with syntax ideas. You work on the compiler backend ok? And we'll split the fame 80/20 since I'm the face of the project, you know?

How about I create a new language, grow it and make it really popular, and then you can create a lightning fast alternate compiler to replace my crappy proof of concept one. Everybody wins.

This is what I'm doing at the moment. I'm just translating to Java right now so I can have a robust platform to target; it's working well for me, but it would be nice if I could go directly to bytecode. However, that work doesn't add value until latency matters.

It seems you find the bugs in V-lang 'easy' to fix and you dislike the authors 'hacks' and believe he isn't properly learning the craft on how to write a compiler.

Perhaps you could show him the way by sending in a pull request or patchset to the project to verify your expertise in fixing these 'annoying' bugs and properly writing a compiler.

Patches are welcome.

I'm not sure I like how V seems to claim to be better across so many dimensions. Language development is all about tradeoffs. You can have good static analysis or fast compilation, not both. If you look at most successful languages, they don't claim to be a silver bullet. Rust doesn't claim that it compiles quickly. Go doesn't claim to have the best type system. Python isn't the fastest language.

I'm curious to see how V ends up. It's unlikely that it'll succeed at everything, so eventually it'll choose a niche. And backtrack/sweep under the rug the claims that don't fit in said niche.

V is not a silver bullet either. No language is. V values highly fast compilation times, and does not claim to have the best type system, similar to Go.

The problem is that V claims:

- As fast as C - No manual memory management - No GC - Memory safety - Not hard like Rust

You have fundamentally conflicting requirements. Saying "we'll do it like lobster" does not solve that. Lobster is essentially region based memory management with fallbacks to reference counting at runtime. That fundamentally contradicts "as fast as C". You cannot do more work than C at runtime and still be faster.

Lobster is also a different language which had to forgo a number of features V has already embraced. It's unclear how that can be rectified.

Very interesting, the list of improvements over Go address a lot of complaints I have about the language.

Taken from https://vlang.io/compare#go

- No global state

- No null

- No undefined values

- No err != nil checks (replaced by option types)

- Immutability by default


What's motivating your hostility in this thread?

There are people who are designing nice native compiled languages with a proper knowledge of PL design and implementation, for example:

And then there is V author, who claimed highly improbable and sometimes CS-defying features, and got popular and also got donations.

If you say rust crowd is overenthusiastic and cult-ish, you haven't seen those teenagers on vlang discord. All this while not having 1% of technically talented people in Rust community (which I often dislike for too much enthusiasm).

When Andrew Kelly (creator of zig, I know him only on this site and zig project, no affiliation) criticized V of hype, and he got downvoted / criticized here for being politically incorrect.

Yeah retrofit these missing features (GC, communicating concurrent processes, module system) into C and create the perfect language. Years of PL research and implementation wasted. No one got the idea except an old dude from the Bell Labs.

And yet Go, while still not the perfect language, is more pleasant than C, and is definitely not a failed experiment.

If I remember correctly, there was a lot of controversy, partially because of the amount of donations being elicited before releasing anything and overselling some benchmark results.

Looking at the repo, it looks like there is a ton of effort going on. 6458 commits and 687 open issues. Seems promising?


So how well it has ended up holding on its promises/claims? When was initially released (previous year?) there was a backlash, and checking the source there were some bad points but it seems it has now improved considerably.

It really reminds me of Jai programming language by Jonathan Blow. Just downloaded and started testing it, looks promising! Is its main use case for now the games development?

It is a general purpose language, but there are several games in the main V repo, for example:



You can try them with: `./v run examples/tetris/tetris.v` and

`./v run examples/2048/2048.v`

They work the same on Linux, Windows and MacOS.

It lost me from the main page example. How about...

fn main() { areas := ['game', 'web', 'tools', 'science', 'systems', 'embedded', 'drivers', 'GUI', 'mobile'] areas.each_with_index i { println('Hello, '+ ' areas[i] ' + developers!') } } for loops should not exist because they they are external to the an object reflection attributes.

Looks really neat! What's the catch here?

One catch is that it's not currently memory safe, and it's unclear (to me) what the future plan is for memory safety.

There is no catch, it is just a work in progress, and it is improving every day.

> No variable shadowing

too bad.


Please don't post like this and https://news.ycombinator.com/item?id=24482726 to Hacker News. You're breaking the site guidelines and making the thread worse. Maybe you don't owe "some teenager" better, but you owe this community better if you're posting to it.

Actually, if the author really is a teenager, you do owe him better. Teenagers should be encouraged and educated, not beaten with internet clubs. And whether he really is a teenager or not, using that word as an insult is not in the spirit of HN.

I understand how annoying it can be when someone makes inflated or false claims about their project, but if you're going to react to that, please don't do it in a way that damages the commons.

We detached this subthread from https://news.ycombinator.com/item?id=24483203.

To be fair dude, you're probably being downvoted because you're all over this post, and in every single post of yours, you're denigrating everything about V.

Now I don't know if you're right or wrong, but that whole attitude is a turn-off unless you're obviously right every single time, and from a cursory glance, V looks like it has some things that I like the look of.

I really don't care about the technical awesomeness or lack thereof of the parser, if it works. I really couldn't care less if the author is a CS major, if he's produced something good. I'm not making the judgement about whether it's good or not because V is new to me, but I'm prepared to give him the benefit of the doubt until I've tried it, and someone barfing all over every aspect of the project doesn't come across well.

I'm not downvoting you (I can't even if I wanted to :) but there's not much in this world that is utterly without any redeeming factor, and you seem to be trying to persuade everyone that V is one of those things. Maybe it is. I guess we'll see.

It's not about the author being a CS major or how the parser is implemented. It's about the author being completely wrong and unwilling to admit it ("parsers are why compilers are slow" -> v 0.2 gets a parser) and being completely ignorant of the basics of writing a compiler.

My generous side says this might just be a language or communication issue but my cynical side says $900 a month on Patreon has a lot to do with it.

However, my pet peeves with the project basically just boil down to the half-truths or outright lies on the home page:

> No null

From their own docs: https://github.com/vlang/v/blob/master/doc/docs.md#calling-c...

we see

    error_msg := charptr(0)
and a use 5 lines later with no "unsafe" or other escape hatches in sight. Looks to me like you have null, you just don't have a keyword for it.

> No undefined behavior

What's the behavior of

    error_msg := charptr(0)
How are they guaranteeing no UB? The compiler works by generating C via string concatenation. Where does the compiler validate the C generated is free of UB? If it's true via construction, then how do basic issues like [this](https://github.com/vlang/v/issues/6290) [keep](https://github.com/vlang/v/issues/5912) [happening](https://github.com/vlang/v/issues/6206)?

> Pure functions by default


You're telling me I can read a file off disk in a "pure" function? Wat?

> Generics

Generics only work if there's 0 or 1 type parameters. Support for generics in general is "alpha" quality at best. [Lots of correct code just segfaults the compiler](https://github.com/vlang/v/issues/6263). (If the language has no UB and has bounds checking, why does the compiler seg fault?)

Array.map and Array.filter are not regular library functions with a generic type, they're special cased in the compiler with special syntax.

> V is written in V and compiles itself in under a second.

That's not what fast.vlang.io says: 2080ms.

They could just say that it compiles very fast and link to their benchmark site.

I'm not even going to touch the "no dependencies" claim when you need a C compiler (and often two if you want optimizations).

> C translation (wip)

WIP is overly generous. A very broken version of c2v was released for v0.1 and never updated for v0.2.

> V can emit (human readable) C, so you get the great platform support and optimization of GCC and Clang.

Hopefully you consider C files over 100,000 lines to be readable.

> Powerful built-in web framework > Built-in ORM

Maybe focus should be spent instead on completing the memory management story which is still a TODO item?

[The author doesn't seem to even understand what he's trying to do.](https://github.com/vlang/v/issues/1247#issuecomment-51346731...)

When asked what the plan is there, all the community says is that it will be similar to Lobster's (searching "Lobster" on their Discord will show numerous results). However when the reasons why that can't work with V as is currently exists are pointed out, [there is silence](https://github.com/vlang/v/issues/1247#issuecomment-68018256...). Meanwhile, V has already [promised no breaking changes for at least 5 or 10 years](https://github.com/vlang/v#stability-guarantee-and-future-ch...). Perhaps that should have been done after deciding how memory management would work?

You'd think this would be pretty much the top priority at the moment but the handful of buggy commits say otherwise:

- https://github.com/vlang/v/commit/bffa100aa6fbf4842aa6b4f442...

- https://github.com/vlang/v/commit/db51ee08ea269b17bec97fb102...

- https://github.com/vlang/v/commit/b74c1805d72df8fd6e30cc236a...

- https://github.com/vlang/v/commit/e0d20eadff113b3f36fb96226b...

If look closely, you'll see lots of code under the "autofree" path is commented out. I guess you can't have use after free if you never free?

You'll also notice the author has a consistent pattern of committing commented out code, uncommenting it in a later commit and then recommenting it again because it never worked in the first place. This is probably why the author refuses to go use the PR process for themselves and instead pushes directly to master often breaking CI and the project for everyone else.

The problem with V in my opinion is not that it has high aspirations, it's that doesn't distinguish between aspirations and the mostly unimplemented barely functioning reality of the present. Only the happiest of happy paths currently work which is probably only 10% of the effort required to make a serious programming language. You'd think from their website and their fanatics that they're nearly there when they have yet to even realize how much work hasn't even been started yet.

I am not the language author, just a contributor. There are many contributors like me, that see the potential of V, instead of focusing on petty beefs about how someone had been wrong on the Internet once upon a time.

> What's the behavior of error_msg := charptr(0) error_msg

    1[23:04:49] /v/nv LINUX $ cat > hate_will_raise_your_cortisol_levels.v
    error_msg := charptr(0)
    0[23:05:12] /v/nv LINUX $ ./v run hate_will_raise_your_cortisol_levels.v
    hate_will_raise_your_cortisol_levels.v:2:2: error: undefined variable: `error_msg`
        1 | error_msg := charptr(0)
        2 | *error_msg
          |  ~~~~~~~~~
    1[23:05:14] /v/nv LINUX $ cat > hate_will_raise_your_cortisol_levels.v
    error_msg := charptr(0)
    *error_msg = 1
    0[23:05:32] /v/nv LINUX $ ./v run hate_will_raise_your_cortisol_levels.v
    hate_will_raise_your_cortisol_levels.v:2:2: error: `error_msg` is immutable, declare it with `mut` to make it mutable
        1 | error_msg := charptr(0)
        2 | *error_msg = 1
        |  ~~~~~~~~~
    1[23:05:35] /v/nv LINUX $
    0[23:05:36] /v/nv LINUX $ cat > hate_will_raise_your_cortisol_levels.v
    mut error_msg := charptr(0)
    *error_msg = 1
    0[23:06:13] /v/nv LINUX $ ./v run hate_will_raise_your_cortisol_levels.v
    hate_will_raise_your_cortisol_levels.v:2:12: error: modifying variables via dereferencing can only be done in `unsafe` blocks
        1 | mut error_msg := charptr(0)
        2 | *error_msg = 1
          |            ^
    1[23:06:13] /v/nv LINUX $

Note that charptr is intended to be used only for easier C interoperability, not in pure V code. Also note, that the V language implementation has not yet reached version 0.2 , and new checks about undefined and dangerous behavior are added on a regular basis.

>> V is written in V and compiles itself in under a second. > That's not what fast.vlang.io says: 2080ms.

Both are true. What you seem to lack in understanding, is that performance comparisons with absolute time need also another dimension - the hardware on which they are run, and also what backend C compiler is used. On my i3-3225 for example, I can recompile v with tcc in ~0.6s on average (and under 0.5s when v was compiled with clang before that):

    0[23:16:04] /v/nv LINUX $ time ./v -cc gcc -show-timings self
    V self compiling (-cc gcc -show-timings)...
    PARSE: 175 ms
    CHECK: 64 ms
    C GEN: 116 ms
    C gcc: 4422 ms
    real   0m4.792s
    user   0m4.604s
    sys    0m0.159s
    0[23:16:22] /v/nv LINUX $ time ./v -cc clang -show-timings self
    V self compiling (-cc clang -show-timings)...
    PARSE: 167 ms
    CHECK: 62 ms
    C GEN: 118 ms
    C clang: 2265 ms
    real   0m2.629s
    user   0m2.499s
    sys    0m0.108s
    0[23:16:31] /v/nv LINUX $ time ./v -cc tcc -show-timings  self
    V self compiling (-cc tcc -show-timings)...
    PARSE: 186 ms
    CHECK: 66 ms
    C GEN: 117 ms
    C tcc: 104 ms
    real   0m0.489s
    user   0m0.437s
    sys    0m0.050s
    0[23:16:36] /v/nv LINUX $
> They could just say that it compiles very fast and link to their benchmark site.

Yes, but for most people with average hardware produced in the last 10 years, the times will be < 1s much more likely than not, while recompiling from scratch say gcc, or clang, or go for that matter, will definitely not happen for < 1s even with very powerful hardware ...

> I'm not even going to touch the "no dependencies" claim when you need a C compiler (and often two if you want optimizations).

The V compiler itself do not have dependencies - it is a single C file (see https://github.com/vlang/vc/blob/master/v.c), that can be generated from its V source code (with `./v -o v.c cmd/v`). That v.c file, can then be used to bootstrap v, by needing just a working C99 compiler. In fact that is exactly what the make.bat and Makefile do. You can use just one working C99 compiler, for example gcc to bootstrap v. If you mean that you need 2 compilers, because tcc is so much faster but it does not optimize, well yeah, I do like to use tcc while developing, and then use gcc only when releasing. In my opinion, having the choice to do that is a big feature, not a disadvantage.

> Hopefully you consider C files over 100,000 lines to be readable.

You can use `-printfn module__func_name` to read single generated C functions that are of interest to you directly in your shell, there is no need to look at the whole generated .c file. Plus even with the full file, most editors have the amazing ability to search for text, so you do not have to read the whole file from start to finish.

> Maybe focus should be spent instead on completing the memory management story which is still a TODO item?

May be your focus should be on helping the projects that you like, instead of complaining about the ones you do not?

My point still stands: is this UB or not?

    foo := charptr(0)
    x := *foo 
The "wasm" playground generates no compiler errors or warnings. In fact, the compiler seems happy to accept any number of dereferences as this

    foo := charptr(0)
    x := **********foo
compiles without error.

Thats called marketing for you, something most developers aren't very good at.

Dishonest marketing. Even rust community gets called out for 'marketing'.

Also, engineers don't do dishonest marketing doesn't mean they can't be good at it.

Dishonest or honest, it is still marketing, whether you deliver or not is the main point.

In the case of V it's clearly worked hasn't it? Seems like there is a community growing in V and people are contributing to the language.

Can you share any programming languages you created?

So you have to be an author to criticise books?

Unless you're a chef you're not allowed to say some food tastes bad?

Unless you're a programmer you cannot write bug reports?

No one can write a product review unless they're able to create an instance of the product by themselves?

That's not how it works and [edit]not[/edit] a good reply to someone critiquing something.

I didn't say they couldn't criticize the project. From the comment, it sounded like they had some good knowledge on the subject. Was curious if they ever designed a language, or helped out on one.

> it sounded like they had some good knowledge on the subject. Was curious if they ever designed a language, or helped out on one.

Had you written exactly that, you would've gotten the reply you expected from them. Apologies for the misunderstanding.

Creating a language isn't a requirement to comment on the problems with this project.

I didn't say it was. From the comment, it sounded like they had some good knowledge on the subject. Was curious if they ever designed a language, or helped out on one.

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact