The V Programming Language

The V Programming Language

Simple language for building maintainable programs

V is already mentioned couple of times in the forum, but I think it needs an introduction thread of its own.

V is very similar to Go. If you know Go, you already know ≈80% of V. Things V improves on Go:

You can learn the entire language by going through the documentation in an hour, and in most cases there’s only one way to do something.

This results in simple, readable, and maintainable code.

Despite being simple, V gives a lot of power to the developer and can be used in pretty much every field, including systems programming, webdev, gamedev, GUI, mobile (wip), science, embedded, tooling, etc.


  • As fast as C (V’s main backend compiles to human readable C)
  • C interop without any costs
  • Minimal amount of allocations
  • Built-in serialization without runtime reflection
  • Compiles to native binaries without any dependencies: a simple web server is only 65 KB

Fast compilation

V compiles ≈110k (Clang backend) and ≈1 million (x64 and tcc backends) lines of code per second per CPU core.
(Intel i5-7500, SM0256L SSD, no optimization)

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

Innovative memory management

V avoids doing unnecessary allocations in the first place by using value types, string buffers, promoting a simple abstraction-free code style.

Most objects (~90-100%) are freed by V’s autofree engine: the compiler inserts necessary free calls automatically during compilation. Remaining small percentage of objects is freed via reference counting.

The developer doesn’t need to change anything in their code. “It just works”, like in Python, Go, or Java, except there’s no heavy GC tracing everything or expensive RC for each object.

For developers willing to have more low level control, autofree can be disabled with -noautofree.

V’s compile-time memory management demo. All objects are freed during compilation. Running the Ved editor on an 8 MB file with 0 leaks:

Small and easy to build compiler

V can be bootstrapped in under a second by compiling its code translated to C with a simple

cc v.c

No libraries or dependencies needed.

For comparison, space and time required to build each compiler:

Space Build time
Go 525 MB 1m 33s
Rust 30 GB 45m
GCC 8 GB 50m
Clang 90 GB [0] 60m
Swift 70 GB [1] 90m
V < 10 MB [2] <1s

Building V in 0.3 seconds and then using the resulting binary to build itself again:

C translation (wip)

V can translate your entire C project (wip) and offer you the safety, simplicity, and 10-25x compilation speed-up.

std::vector s;               mut s := []
s.push_back("V is ");        s << 'V is '
s.push_back("awesome");      s << 'awesome'
std::cout << s.size();       println(s.len)

C++ to V translation is at an early stage.

Translating DOOM from C to V and building it takes 0.7 seconds.

You can follow the progress and read translated code here:

Hot code reloading

Get your changes instantly without recompiling.

Since you also don’t have to get to the state you are working on after every compilation, this can save a lot of precious minutes of your development time.…/examples/hot_reload

Powerful graphics libraries

Cross-platform drawing library built on top of GDI+/Cocoa Drawing, and an OpenGL based graphics library for more complex 2D/3D applications, that will also have the following features:

  • Loading complex 3D objects with textures
  • Camera (moving, looking around)
  • Skeletal animation

DirectX, Vulkan, and Metal support is planned.

A simple example of the graphics library in action is tetris.v.

Native cross-platform GUI library

Build native apps with native controls. You no longer need to embed a browser to develop cross-platform apps quickly.

V has a ui module that uses native GUI toolkits: WinAPI/GDI+ on Windows, Cocoa on macOS. On Linux custom drawing is used.

Coming soon:

  • a Delphi-like visual editor for building native GUI apps
  • iOS/Android support with native controls
  • a declarative API similar to SwiftUI and React Native

Easy cross compilation

To cross compile your software simply run v -os windows. or v -os linux. No extra steps required, even for GUI and graphical apps!

Painless deployments and dependency management

To build your project, no matter how big, all you need to do is run

v .

No build environments, makefiles, headers, virtual environments, etc.
You get a single statically linked binary that is guaranteed to work on all operating systems (provided you cross compile) without any dependencies.

Installing new libraries via vpm, a centralized package manager written in V, is as simple as

v install ui

Run everywhere

V can emit (human readable) C, so you get the great platform support and optimization of GCC and Clang. (Use v -prod . to make optimized builds.)

Emitting C will always be an option, even after direct machine code generation matures.

V can call C code, and calling V code is possible in any language that has C interop.


>>> import net.http 
>>> data := http.get('')? 
>>> data.text 

V Script

for file in ls('build/') {
mv('v.exe', 'build/')
v run deploy.vsh

Read more about V script

Code formatting with vfmt for consistent style

No more arguments about coding styles. There’s one official coding style enforced by the vfmt formatter.

All V code bases are guaranteed to use the same style, making it easier to read and change code written by other developers.

v fmt -w hello.v

A built-in code profiler

Build and run your program with

v -profile profile.txt x.v && ./x

and you’ll get a detailed list for all function calls: number of calls, average time per call, total time per call.

JavaScript and WASM backends

V programs can be translated to JavaScript:

v -o hello.js hello.v

They can also be compiled to WASM (for now with Emscripten). V compiler compiled to WASM and running V programs by translating them to JavaScript:

A game written using V’s graphical backend and compiled to WASM:


Automatic documentation

Use vdoc to get instant documentation generated directly from the module’s source code. No need to keep and update separate documentation.

v doc os

Built-in testing framework
Writing tests is very easy: just start your test function with test_

fn get_string() string { return 'hello' }

fn test_get_string() {
  assert get_string() == 'hello'

Friendly error messages
Helpful error messages make learning the language and fixing errors simpler:

user.v:8:14: error: update_user parameter user is mutable, you need to provide mut: update_user(mut user)

    7 |     mut user := User{}
    8 |     update_user(user)
      |                 ~~~~
    9 | }

Powerful built-in web framework

fn (b Blog) show_post(id int) vweb.Result {
  post := b.posts_repo.retrieve(id) or {
    return vweb.not_found()
  return vweb.view(post)

Gitly, a light and fast alternative to GitHub/GitLab is built in V and vweb.

Built-in ORM

import sqlite

struct Customer {
  id int
  name string
  nr_orders int
  country string

fn main() {
  db := sqlite.connect('example.sqlite') or {
    panic('could not create/find example.sqlite')

  nr_customers := sql db {
    select count from Customer
  println('number of all customers: $nr_customers')

  // V syntax can be used to build queries
  uk_customers := sql db {
    select from Customer where country == 'uk' && nr_orders > 0

  for customer in uk_customers {
    println('$ - $')

  // by adding `limit 1` we tell V that there will be
  // only one object
  customer := sql db {
    select from Customer where id == 1 limit 1

  // insert a new customer
  new_customer := Customer{name: 'Bob', nr_orders: 10}
  sql db {
    insert new_customer into Customer

(copied from the homepage)


Corresponding tweet for this thread:

Share link for this tweet.

Very interesting, how does it do ‘autofree’ without a GC or runtime tracking of some sort, or is it using compile-time ownership modelling, and if so then how pervasive is that through the language?


the compiler inserts necessary free calls automatically during compilation.

Do you think the autofree can be trusted all the times?


That’s what I’m curious about as well. Like it seems impossible at times to ‘know’, such as in pseudoish-code what if you have this:

something *blah = null;
if(someConditional()) {
  blah = (*blah)malloc(sizeof(something));
/* other stuff that uses blah if not null */

How does it insert a free at the end of this? How can you force a free earlier? Will it automatically free it if not null if something like this is run later in that function:

if(anotherConditional()) {
    blah = mallocDefaultedSomething();

Or will the previous value be leaked, or will it try to free a null, etc…? There’s lots of cases, so how it handles this is very interesting…

1 Like

Ah wait, I found it:

Most objects (~90-100%) are freed by V’s autofree engine: the compiler inserts necessary free calls automatically during compilation. Remaining small percentage of objects is freed via reference counting.

So yeah, reference counting then.


Before (if I ever?) comment on V in general, the comparison is not complete without OCaml. It has a lightning-fast compiler.


Looks like the ~90-100% autofree and then reference counting, is a good memory management, and is very practical too, as proved by translating DOOM from C to V and building it in 0.7 seconds, and the demo showing Ved editor compiled with --autofree, running with 0 memory leaks.

And the good thing about autofree is that "The developer doesn’t need to change anything in their code. “It just works” ".


Yeah, making compilers fast isn’t ‘too’ hard, it’s just hard when you use a framework like LLVM that’s designed to be extensible and extremely optimizing, not fast, lol.

OCaml still has one of the fastest optimizing compilers I’ve ever seen, and as stated ‘optimizing’, it makes really good code.