Rust lang vs V lang

can any one compare Rust language vs V language which is a new programming language which is too similar to rust lang

A lot of V's features are still aspirational -- I think it's way too early to make a serious comparison.

On a meta note, we don't really encourage language wars here. Try to keep any discussion objective please.


i have only good Intentions.i hope comparison help for improvements and better understanding.


What I know:


  • clean and concise (a little like Go or Kotlin) syntax which seems easy to learn


  • Big community and backed by Mozilla -> safe future

I actually think that it's sad that V got so little attention because it really makes promises on its website that, well, sound promising. If they are true, V should get more attention. If not, it would be nice if someone (or some website I trust) said this and I could stop thinking about V. But neither of this happened, which confuses me.

I tried out V a little (very little) and, well, the very basic things worked. It took about 15 seconds to compile 100000 println statements, while on GitHub - vlang/v: Simple, fast, safe, compiled language for developing maintainable software. Compiles itself in <1s with zero library dependencies. Supports automatic C => V translation. they say ≈100k — 1.2 million loc/s. This might be my fault, though, because I used a virtual machine on a rather cheap laptop.

Don't take my word for anything here, though, please. I spent about 30 minutes with V, most of this installing it.


AFAICT this language isn't really ready to get widely advertized in the first place, so I'm not sure "got so little attention" is the right assessment. Several of the features described on their website, including some of the ones highlighted in their FAQ and "sales pitch" have a bright purple (wip) badge next to them.

It's also not at all clear to me from the site how V is supposed to achieve its simplicity and compile-time improvements over Rust, without also dropping features that are critical in some of the domains that C and Rust target.

A simple example is "no global variables." While Rust strongly discourages them, it does allow them, as there are very real cases where you simply must use a global (e.g. when it represents part of the hardware your software is running on). Without further explanation, that bullet points seems to me like it's ruling out any chance of V being a viable language for at least embedded development. And that might be the right trade-off, because I get the impression V is aiming to be great at game dev and web services, but not at embedded or bare metal. Unfortunately for now, all of that is guesswork, since the site doesn't explicitly state any target domains or non-goals.

A more complex example is that "memory management" in general is marked WIP. The docs claim that it can provide compile-time memory safety guarantees like Rust without any built-in GC or reference counting, but of course in Rust that's only possible with our famously unfamiliar ownership and lifetime systems, so for now it seems to be simply unknown how V hopes to achieve that without adding similar complexity.

On the other hand, some nifty features do make sense as currently described. Hot code reloading, for example, requires a [live] opt-in marker on functions, and simply doesn't support changing types. So I can easily see how that would work in detail without compromising any of the other goals (we can debate how useful it is with those restrictions, but still).

Honestly, the more I look at this, the more I feel like I'm being unfair to it by even looking at it right now. It's clearly not ready to be judged or analyzed yet, much less compared to other languages.


Never heard of V before. Seems like a cool language though and a direct competitor for Rust (something which they also don't seem to hide on their site).

I'm still sticking to Rust though.

I don't know how much of this is still relevant, but I remembered this topic:


i fell that compile of v lang is so fast because it may not have any safety check like in rust language

The prize to pay for having safey in compiler time is the ownership and borrowing which are a pain in some situations, and having an excess of unrwaps and another ilogic sentences.
Speaking about safety, how many unsafe{} blocks does the rust runtime have?

V is more logic and fun and fast to program, is very well designed.
The binary file generated by V is more clear than the rust where the runtime is bigger than golang's

V is 100% compiatible with c, it has totally the power and good things of c in a productive language.

Have you just made this account to promote V?
No problem, but if you do so, please provide numbers and statistics and no meaningless subjective stuff like 'more fun'.

Which is something I doubt by the way, Rust is ranked #1 four years in row as most popular language in Stackoverflow's yearly developer survey.


Moderator note: These types of threads can easily get derailed or turn into flame wars. Please post only if you have concrete information to add about specific comparisons between Rust and V as languages.


I'm not sure the Rust community should shout about that so much.

Firstly because it seems like a totally bogus statistic. To be taken as seriously as the TIOBE index and such like.

Secondly because, what happens next year or the next year when the next "shiny thing" gets all the votes?

My questions re: V are:

Does it really offer the memory and thread safety guarantees that Rust does, at compile time?

Do the resulting executables have the performance of C/Rust?

Can it generate code for all the platforms I use, Intel, ARM, RISC V, MIPS?


It sounds wonderful. But I kind of wonder if the only reason it's fast to compile is because many features such as memory safety have not been implemented yet. Speaking of which.. I'm very skeptical he can efficiently do memory safety checks without needing something like ownership. Maybe it's specifically because he forbids global variables, so he can track them through functions.

And might just be fast to compile because it's compiling toy programs.

So, I'm skeptical but I certainly hope he proves me wrong. What he's trying to build would be incredible to have.

Yup.. too good to be true, to quote an article about V:

V isn’t garbage collected, a significant difference from Go, or even reference-counted. Instead, it’s more similar to Rust, managing memory at compile time. Unfortunately, this only currently works for basic situations; manual management is required for more complex cases, which are another WIP.

V’s creator [medvednikov] is quick to concede that memory management isn’t secure enough yet, but that it’s under constant improvement. It’s certainly something that needs to be worked on to lend credibility to the “safety” features of the language. And if there’s anything we’ve learned from the last thirty years of computer security, it’s that memory management bugs abound.

Which I read as: he figures that he can figure out a solution later.. or that he'll add in Rust like memory management later. To be fair a simplified restricted version of Rust would be kinda nice. But he's not going to magically fix memory management and fast compile times.

Source for those quotes:


Just from scanning the single page documentation (have never used it), V lang is very simple, yet promises C-like performance. We could use some of its ideas.

When I first started learning, I found Rusts Result and Option types to be an alien nightmare to get my head around. Luckily, Rusts lifetimes and borrowing seemed straightforward, however all code still needed to reflect Result and Option types as well as their means of being unwrapped.

With V, use of Option and Result types is really simplified - with both merged into a single type which can be invoked by adding a ? to a functions return type (not at expression level); after which you can then return a value, an error or a none. Here's an extract from sample code on;

fn (r Repo) find_user_by_id(id int) ?User {
	for user in r.users {
		if == id {
			// V automatically wraps this into an option type 
			return user
	return error('User $id not found')

I'm not sure how difficult it would be to get that into Rust, but it would be a real usability benefit for new users.

1 Like

This discussion made me think of this blog post about V, written shortly after it was publicly announced. It would be fair to say the post's author was unimpressed with V at that time. Given that it has now been very nearly 10 months since publication, it might be the case that the criticisms made have already been addressed - I simply don't know. I note though, that the last I saw a couple of weeks ago, a lot of the claimed great parts were indeed still (somewhat subtly) marked as WIP.

My overall feeling is that currently V is still too much in early development for any reasonable comparisons to be drawn. If the V team can indeed deliver on what they claim, then it would definitely be a language worth looking at. Currently that remains quite a big if. So far, it seems there has been quite a lot of promise, but not a whole lot of deliver (ala over-promise, under-deliver). I personally hope that they can come through, but I would be sticking with Rust for anything serious, for the time being at least.


There is a follow-up evaluation after half a year in this blog post. I found it an overall thorough enough evaluation even though parts of it are definitely intended to be humorous/satire. These two blog posts give insight into the progress/speed of the language and compiler over time as well. (edit: there's another final follow up now).


Thanks! :slight_smile: I somehow never saw that follow-up... :confounded:

I read through the documentation, and converted one of my smaller Rust projects into V as an experiment. Here are my conclusions.

V has some cool ideas, which could be applied to Rust. For example, it treats references and values the same apart from creation, so they can be mixed and used the same way. This means there is no &this or *that. Given that the Rust compiler generally knows that I missed out an ampersand or a star, why can't it quietly not require them?

However, V is not a general purpose language in the sense that Rust is (and Haskell, Lisp, ...). For example, Rust allows lambda expressions such as |x| foo(x). V allows very limited lambda-like syntax, foo(it) where it is a keyword. You cannot have lambdas with more than one parameter, and currying is not possible, because shadowing of variables is not permitted.

Similarly, in terms of memory management, it is not possible in V to pass ownership of one object to another. I don't think it is possible for a language to simply not have reference counting or garbage collection. It prevents fundamental patterns such as Factory.

Operator overloading and traits are supported in V but only in a very restricted way, to allow the arithmetic operators to be applied to data structures.

Interfaces in V are handled by duck-typing, same as Python. I'd be interested to see how this is implemented in an efficient way. I can't see how it could use v-tables for efficient dispatch, like Rust or C++.

JSON serialisation/deserialisation, printing to streams, and unicode string bashing are built into V, which is cool, but also indicates that it would be impossible to add features like them without modifying V itself. It would not be possible to write serde in V.

In my opinion, these issues are not simply that V is a young language where the features have not yet been added, but that the syntax of the language as presently conceived prevents them from being added in the future. Unless there is a radical compatibility-breaking redesign of V, I think it will remain one of those languages which is very good at what it does, but is not capable of becoming a general purpose language like Rust.


It could, but because Rust allows you to manipulate references as values with normal language features, it would be confusing to have some values that act like data, and others that act like completely different data from what they are. That kind of implicit behavior is one of the things that makes it harder to reason about performance in other languages.


Point taken. I do like the explicit nature of Rust. It's just that whenever I compile a Rust program I get loads of errors which require me to add ampersands or stars, or refs or ref muts. It all feels a bit like that episode on Hitchhiker's Guide to the Galaxy where they are trying to invent the wheel, but cannot agree what colour it should be. I am writing a Python to Rust compiler, and one of the big problems I have is with references versus values. (OK, Python just passes everything by reference, as one of the goals of Python is to make the performance as bad as possible.)

1 Like