vlang.io
| Docs
| Changelog
| Speed
| Contributing & compiler design
Key Features of V
- Simplicity: the language can be learned over the course of a weekend
- Fast compilation: ≈110k loc/s with a Clang backend,
≈500k loc/s with native and tcc backends (Intel i5-7500, SSD, no
optimization) (demo video)
- Easy to develop: V compiles itself in less than a second
- Performance: as fast as C (V's main backend compiles to human-readable C)
- Safety: no null, no globals, no undefined behavior (wip), immutability by default
- C to V translation (Translating DOOM demo video)
- Hot code reloading
- Flexible memory management. GC by default, manual via
v -gc none,
arena allocation via v -prealloc, autofree via v -autofree
(autofree demo video).
- Cross-platform UI library
- Built-in graphics library
- Easy cross-compilation
- REPL
- Built-in ORM
- Built-in web framework
- C and JavaScript backends
- Great for writing low-level software (Vinix OS)
Stability, future changes, post 1.0 freeze
Despite being at an early development stage, the V language is relatively stable, and doesn't
change often. But there will be changes before 1.0.
Most changes in the syntax are handled via vfmt automatically.
The V core APIs (primarily the os module) will also have minor changes until
they are stabilized in V 1.0. Of course, the APIs will grow after that, but without breaking
existing code.
After the 1.0 release V is going to be in the "feature freeze" mode. That means no breaking changes
in the language, only bug fixes and performance improvements. Similar to Go.
Will there be V 2.0? Not within a decade after 1.0, perhaps not ever.
To sum it up, unlike many other languages, V is not going to be always changing, with new features
introduced and old features modified. It is always going to be a small and simple
language, very similar to the way it is right now.
Installing V from source
This is the preferred method.
Linux, macOS, Windows, *BSD, Solaris, WSL, etc.
Usually, installing V is quite simple if you have an environment that already has a
functional git installation.
Note: On Windows, run makev.bat instead of make in CMD, or ./makev.bat in
PowerShell.
To build with Visual Studio, run makev.bat -msvc. If the bundled TCC bootstrap cannot be
compiled or fails while building the next compiler stage, the script retries with MSVC,
then Clang and GCC.
Windows ARM64 releases are available as v_windows_arm64.zip. Install Visual Studio's
C++ ARM64 build tools and a Windows SDK, then use v -cc msvc file.v to build native
applications with the C backend. To build the compiler and release tools from source,
run ./cmd/tools/builders/windows_arm64_release.ps1 in native ARM64 PowerShell 7 on Windows 11.
Source bootstrapping also needs Visual Studio's x64 C++ tools and Windows 11's x64 emulation
to run the downloaded Windows snapshot. The script then explicitly targets ARM64 for the
compiler stages, release tools, and application smoke test, checking their PE architecture.
It builds and runs an application before packaging and does not require an x64 TCC bundle.
On native Windows ARM64, v up -skip_v_self uses this same bootstrap script and requires
native ARM64 PowerShell 7 and both Visual Studio toolchains; it keeps the compiler native.
makev.bat -clang keeps Clang's installed target: LLVM-MinGW uses its GNU runtime,
while Visual Studio's Clang uses the adjacent clang-cl.exe and the MSVC SDK.
Note: On FreeBSD, OpenBSD, NetBSD, DragonFly, and Solaris, install GNU make and run it as
gmake.
Note: On Ubuntu/Debian, you may need to run sudo apt install git build-essential make first.
To get started, execute the following in your terminal/shell:
git clone --depth=1 https://github.com/vlang/v
cd v
make
That should be it, and you should find your V executable at [path to V repo]/v.
[path to V repo] can be anywhere.
On Unix-like systems, make and the v self bootstrap fallback stream compatibility fixes
for older vc/v.c snapshots to the C compiler. These match the peak RSS helper's return type
to i64, guard Linux-only prctl code, and teach pre-uint compilers the new integer
spelling and allocator signatures. The snapshot stays unchanged on disk.
On FreeBSD, the filter preserves the snapshot's time types in headerless mode and uses
the system definitions when building with native headers.
The compatibility filter uses the system sh; Bash is not required.
On Windows, builds use PowerShell to prepare a temporary snapshot with the same integer
compatibility fixes. makev.bat generates the first compiler stage as C and links it directly.
This also works with older bootstrap snapshots whose process-spawn code is broken.
Direct TCC links add the installed bundle's thirdparty\tcc\lib\openlibm.o, when present,
for C99 math functions such as remainder. Each bundle ships this object for its own compiler,
so an existing amd64 or i386 checkout links a matching object even when it differs from the
branch selected by the host, -tcc32, or TCC_BRANCH.
For paths longer than 260 characters, see Long paths on Windows.
(Like the note above says, on Windows, use makev.bat, instead of make.)
This is the beginning of the README. Read the rest at the original. Read the full README ↗
