The V Programming Language: Vain Or Virtuous?

If you stay up to date with niche software news, your ears may recently have twitched at the release of a new programming language: V. New hobby-project programming languages are released all the time, you would correctly argue; what makes this one special? The answer is a number of design choices which promote speed and safety: V is tiny and very fast. It’s also in a self-proclaimed alpha state, and though it’s already been used to build some interesting projects, is still at an early stage.

Tell me more

V’s website, vlang.io, states that it is a

Simple, fast, safe, compiled language for developing maintainable software.

Each of these keywords is a cornerstone of V’s philosophy, which will crop up throughout this article.

“Maintainable software” hints at V’s very deliberate design choices, which force developers into certain ways of thinking. In many ways, V is similar to Go, which makes similar design choices that some would consider bold. (For example no exceptions and no traditional classes/inheritance.)

V claims to be inspired by Go and influenced by Oberon, Rust, and Swift.

So just how fast is it?

V’s headline fact is that it can compile around 1.2 million lines of code per second per CPU core (of an i5-7500).

Since the V compiler itself is tiny, at 400 kB, this author got V to compile itself in well under a second. Is that fact more than a gimmick to anyone trying to write anything with V? No – but it proves a point about simplicity.

Git cloning V and then running make first compiles V using a C compiler, then uses the resulting V executable to compile itself. I had no issues running it on Linux, but had to work a little harder to get an error-free build on Windows. Actual direct machine code generation is currently only available for x64/Mach-O. However, by the end of 2019, V 1.0 should be released with support for all x64, which I can believe given the current pace of development.

Features and design choices

V is very keen on forcing you to write good code; so keen that some could argue that it can be pushy at times – I’ll leave that up to you to decide. For instance, unused variables result in a compilation error rather than a warning.

Due to the simplicity of V, the docs are very short. In fact, it is claimed that it’s possible to read them in half an hour and absorb the whole language. I’m not entirely sure this is something to boast about, given the clear immaturity of the docs due to the project being in the very early stages. But nonetheless, reading them still highlights some interesting features:

Safety

Strict policies are put in place to attempt to make V as safe as possible, especially with respect to threading. These policies include:

• No global variables or global state (including at module level)
• Variables must always be declared with an initial value
• Variables are defined as immutable by default. You have to use mut to explicitly specify otherwise.
• No variables with a name already in use in the parent scope

Memory

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.

Error handling

V does not have exceptions, much like Go. We think [Dave Cheney] does a good job of explaining why.

Instead, there’s a combined Option/Result type, which is as simple to use as adding ? to the return type and optionally returning an error. Here’s an example of how it might work:

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

The function returns the type ?User, which could be a user, or an error. When calling the function, this could be propagated to the next level up by calling find_user_by_id(id, repo)? (in this case the parent function must have an Optional as its return type). This means that propagating errors is still easy, and doesn’t require using the try-catch exception model.

Features coming soon

• Inline assembly code support
• Hot reloading – code changes without re-compiling (edit: now implemented!)
• A package manager

These all seem like non-trivial features to implement and release quickly, but the speed of development on the project is impressively rapid.

Projects built using V

V’s creator, [medvednikov], has used it to build a number of projects.

V was actually created in order to develop Volt, a 300KB desktop messaging client capable of handling/scrolling through thousands of messages without lag. It’s interesting to note that V makes a big deal of its existing cross-compilation capabilities, and claims to be largely cross-platform, but that Volt is currently only available for Mac.

Vid is a 200KB cross-platform code editor, another project designed to be lightweight and snappy. This is due to be open sourced in July, any day now.

Vtalk is forum/blogging software used to power the V blog, also due to be open sourced soon.

Future

Here’s the graph of GitHub stars against time for V.

GitHub stars aren’t an indicator of merit, but they’re certainly an indicator of interest, which can lead to quality input from the open-source community. There are a large number of features marked Work In Progress scattered throughout the website and docs, and I’ve got to say that some of them look really awesome; most are expected to be released by December.

It’s very easy to claim that your language is lightweight when it lacks features and has large numbers of bug fixes awaiting it; on average, every pull request and bug fix that goes into an open source project adds code rather than removes it. But if V can retain its zero dependencies and small size whilst enduring ongoing development, it may have a place in the future.

Conclusion

It’s easy to forget that all of V’s development up until very recently has been the result of one person: [medvednikov]. After playing with the language for a while, this author wouldn’t feel comfortable writing a new project in V in its current state. But if [medvednikov] can keep up the current breakneck pace of progress on the project, there may well be something to get excited about very soon. I’m not quite ready to jump on the bandwagon, but will certainly follow it from a respectable distance.