HackerReposA FIELD GUIDE TO OPEN SOURCE
ProSponsor the shelf♧ 0
← Back to top all-time
vlang
v
V2019–2026
vlang / v

v

Simple, fast, safe, compiled language for developing maintainable software. Compiles itself in <1s with zero library dependencies. Supports automatic C => V translation. https://vlang.io

Languages & CompilersLibraries & SDKs
Explore on GitHubRead Hacker News discussions
102Distinct people
234Mentions
1Explicit recommenders
38.1KGitHub stars
REPOSITORY AT A GLANCE

What to know before exploring

What it is

Simple, fast, safe, compiled language for developing maintainable software. Compiles itself in <1s with zero library dependencies. Supports automatic C => V translation. https://vlang.io

GitHub

Where it is used

No documented product use was verified in the last source check.

What people are saying

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…

delian66 used a recommendation phrase. One indexed comment matches. This is a phrase match, not a verdict.

No classified warning is attached to this page. Read the discussions before treating silence as approval.

Also in these discussions

  • vlang/vc · linked in 2 of the same discussions
  • vlang/vinix · linked in 2 of the same discussions

Mentioned in the same Hacker News threads. That is not proof they are substitutes.

This week on Hacker News

Nov 8–Nov 15 UTC · Direct repository links and separately labeled related project stories. Indexed through 11/15/2026, 5:05:26 PM UTC.

No direct repository links were found in the indexed HN discussions over the past seven days. Older discussions are available below.

Mentions over time

HN mentions by year234 dated mentions

Observed mentions: 2019-02-09 02:02:36 UTC to 2026-10-07 10:26:09 UTC.

0204060802019-01-01 00:00:00 UTC to 2020-01-01 00:00:00 UTC (exclusive): 37 mentions; 12 submissions, 25 comments20192020-01-01 00:00:00 UTC to 2021-01-01 00:00:00 UTC (exclusive): 18 mentions; 3 submissions, 15 comments2021-01-01 00:00:00 UTC to 2022-01-01 00:00:00 UTC (exclusive): 23 mentions; 4 submissions, 19 comments2022-01-01 00:00:00 UTC to 2023-01-01 00:00:00 UTC (exclusive): 84 mentions; 5 submissions, 79 comments20222023-01-01 00:00:00 UTC to 2024-01-01 00:00:00 UTC (exclusive): 21 mentions; 6 submissions, 15 comments2024-01-01 00:00:00 UTC to 2025-01-01 00:00:00 UTC (exclusive): 15 mentions; 4 submissions, 11 comments2025-01-01 00:00:00 UTC to 2026-01-01 00:00:00 UTC (exclusive): 24 mentions; 3 submissions, 21 comments2026-01-01 00:00:00 UTC to 2027-01-01 00:00:00 UTC (exclusive): 12 mentions; 4 submissions, 8 comments. Incomplete calendar period.2026*

* An incomplete calendar period is marked with an outlined bar. Its count is not directly comparable with a full period.

Counts come from the repository’s dated source evidence. Index cutoff: 2026-11-02 08:16:59 UTC.

View mention counts and date ranges
UTC ranges include their start and exclude their end. Select a period to filter the source evidence.
PeriodStart (UTC)End (exclusive, UTC)MentionsSubmissionsComments
20192019-01-01 00:00:00 UTC2020-01-01 00:00:00 UTC371225
20202020-01-01 00:00:00 UTC2021-01-01 00:00:00 UTC18315
20212021-01-01 00:00:00 UTC2022-01-01 00:00:00 UTC23419
20222022-01-01 00:00:00 UTC2023-01-01 00:00:00 UTC84579
20232023-01-01 00:00:00 UTC2024-01-01 00:00:00 UTC21615
20242024-01-01 00:00:00 UTC2025-01-01 00:00:00 UTC15411
20252025-01-01 00:00:00 UTC2026-01-01 00:00:00 UTC24321
2026 (partial)2026-01-01 00:00:00 UTC2027-01-01 00:00:00 UTC1248

What Hacker News says

24 sources
aw1621107·Dec 22, 2025
> Im more interested to know the points in relation to autofree. As sibling said, autofree is still stated to use a GC, which obviously disqualifies it from "memory safety without GC". > Regarding the details, here is a pretty informative github discussion thread on same topic: https://github.com/vlang/v/discussions/17419 I did see that! Unfortunately it doesn't really move the needle on anything I said earlier. It describes manual memory management as an alternative to the GC when using autofree (which obviously isn't conducive to reliable memory safety barring additional guardrails not described in the post) and arenas are only mentioned, not discussed in any real detail. > It is also accompanied with a demo video (pretty convincing in case you would like to watch). Keep in mind the context of this conversation: whether V offers memory
Read the rest
safety without GC or manual memory management. Strictly speaking, a demonstration that autofree works in one case is not sufficient to show V is memory safe without GC/manual memory management, as said capability is a property over all programs that can be written in a language. As a result, thoroughly describing how V supposedly achieves memory safety without a GC/manual memory management would be far more convincing than showing/claiming it works in specific cases. As an example of what I'm trying to say, consider a similar video but with a leak/crash-free editor written in C. I doubt anyone would consider that video convincing proof that C is a memory-safe language; at most, it shows that memory-safe programs can be written in C, which is a very different claim.
In Rue: Higher level than Rust, lower level than Go
freakynit·Dec 22, 2025
"none of those stand out as "memory safety without GC" to me" ... can you explain why you believe they are not memory safe without GC? Im more interested to know the points in relation to autofree. Regarding the details, here is a pretty informative github discussion thread on same topic: https://github.com/vlang/v/discussions/17419 It is also accompanied with a demo video (pretty convincing in case you would like to watch). V-lang is not shiny as other languages are, but, it does have a lot to learn from.
In Rue: Higher level than Rust, lower level than Go
aw1621107·Dec 22, 2025
> Check out V-lang ... it has the details. Does it? From its docs [0]: > There are 4 ways to manage memory in V. > The default is a minimal and a well performing tracing GC. > The second way is autofree, it can be enabled with -autofree. It takes care of most objects (~90-100%): the compiler inserts necessary free calls automatically during compilation. Remaining small percentage of objects is freed via GC. 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, memory can be managed manually with -gc none. > Arena allocation is available via a -prealloc flag. Note: currently this mode is only suitable to speed up short lived, single-threaded, batch-like
Read the rest
programs (like compilers). So you have 1) a GC, 2) a GC with escape analysis (WIP), 3) manual memory management, or 4) ...Not sure? Wasn't able to easily find examples of how to use it. There's what appears to be its implementation [1], but since I'm not particularly familiar with V I don't feel particularly comfortable drawing conclusions from a brief glance through it. In any case, none of those stand out as "memory safety without GC" to me. [0]: https://docs.vlang.io/memory-management.html [1]: https://github.com/vlang/v/blob/master/vlib/builtin/prealloc...
In Rue: Higher level than Rust, lower level than Go
baranul·Dec 2, 2025
A lot of things that people wanted in Golang (or in a C alternative), are in the newer language, Vlang[1][2]. Sum types, option/result types, enums, no variable shadowing, flexible memory management (GC can be turned off and stdlib does not rely on), generics (way before Golang's handlers relented to the masses), more safety features, goodies like filter, map, etc... As Vlang is 75% similar, it's also easy to learn and retains the high readability. [1]: vlang.io [2]: github.com/vlang/v/blob/master/doc/docs.md
In Several core problems with Rust
torginus·Aug 31, 2025
I don't think it's fine the way V does it. What V's compiler is essentially doing is that it parses the V code into an AST, then it walks the AST and tries to generate an equivalent C code on the fly: https://github.com/vlang/v/blob/master/vlib/v/gen/c/match.v How a proper compiler should work (and how they actually do from what I've seen), is that they first take the AST, try to remove all fancy syntatic sugar by converting it to simpler constructs, and then they generate an intermediate representation that's either stack, or SSA based. It might skip the lowering of syntatic sugar, and generate IR directly. At some point either on the AST, or the IR, you might want to do control or data flow analysis to support some of your features. From that point on, the backend generates either LLVM IR, C or might even attempt to generate machine cod
Read the rest
e itself. The problem with targeting C is that you lose access to stuff not accessible in C, like precise variable tracking on the heap/stack (needed for a good GC), or unwinding support needed for exceptions.
In My Foray into Vlang
torginus·Aug 31, 2025
I am of two minds on V On one hand, I think there needs to be an applications programming language that's both fast, statically typed, and minimalistic (like C). C# and Java are unwieldy and carry too much baggage. I hoped Go would be that language. Unfortunately Go's weird choice to use green threads and channels made it very difficult and slow to interop with native code, especially desktop frameworks, which usually rely on a pumped message loop. V was supposed to be that language, that keeps the excellent syntax, but replaces much of the weirdness with much more convenient stuff, while adding a few extra features. I first learned of V after reading the hit piece someone wrote on it, which has formed the majority of people's opinion's on the language. Back then I though most of the criticisms were unnecessarily harsh and belligerent, m
Read the rest
ost of it boiling down to the compiler/stdlib having bugs, and one asserting that it's 'autofree' implementation leaked memory, based on an incorrect understanding of how valgrind and C memory management works. I decided to get the truth for myself, and delve into the V language source code (after all, it's up on github). Oh boy. - The 'compiler' itself doesn't seem to have a a codegen backend, it just produces C code, with every code generation call essentially becoming a stringbuilder concat pushing C code into a buffer. So it's more of a transpiler than a compiler. - The compiler's code is very worrying - commented out snippets of code, TODOs like 'TODO: this isn't supposed to be null here' over a stray if statement - The vaunted 'autofree' which (to be fair never claimed to be 100% effective, relying on GC for cases it can't figure out) is just checking objects allocated in the function scope, and frees them at the end of scope. (to be fair, autofree seems to have been deprioritised) https://github.com/vlang/v/blob/master/vlib/v/gen/c/autofree... While it works in some cases (including the original critical post where it claimed to fail), and I don't pretend to understand all the nuances of the compiler, I feel like the engineering behind this project is somewhat unsound. It's super impressive just how much stuff they managed to do over the past few years, and I think a simple and pragmatic desktop language (that produces small binaries, has few dependencies and is easy to write and read) is still needed, I'm kinda reluctant to give V that role until the engineering behind it becomes more solid.
In My Foray into Vlang
baranul·Jun 16, 2025
Vlang has a Go to V translation project (Go2V)[1]. Usually vlang compiles to C (possibly aiming for a smaller and safer subset). This was a project focus[2] years before particular competitors, thus another hidden point, from which some of the drama springs from. Additionally, vlang has other backends (ability to compile to other languages), such as JavaScript, WASM, native (in development), etc... There were contributors proposing having Pascal (Free Pascal variant) and Go as backend options too. There have already been discussions and experiments around creating V2Go libraries. Various developers appear to be waiting for the language to become a bit mature. [1] https://github.com/vlang/go2v [2] https://github.com/vlang/v/discussions/7849
In Google Cloud Incident Report – 2025-06-13
hualaka·Jun 1, 2025
vlang is a Golang-like programming language. I will use vlang as an example, v has the same syntax as golang and is derived from it. But otherwise, v is moving closer to rust, with immutability, bounds checking, and so on. Here's a discussion of vlang's implementation of coroutine https://github.com/vlang/v/discussions/11582 Until recently, vlang has not supported coroutines very well The syntax of nature is different from golang. But everything else is the same as golang, including goroutine, GC, channel, cross-compilation and deployment, and even free programming ideas, less is more, and so on. I think these features are the best thing about golang, even in front of all programming languages. That's why I'm trying to see if I can create a better golang. In the early stages of availability, I would not advise others to switch to nature,
Read the rest
as this would be irresponsible. When nature is sufficiently advanced, the situation will be different.
In Show HN: A new programming language inspired by Go, no LLVM
baranul·Mar 26, 2025
It would be fair to say that many would disagree or have different opinions about the language and the creator. V's creator has an open discussion for criticism[1], which many other languages don't have. After reading various related threads, the strange abrasiveness and negativity often seems to be from others, not the other way around. Clearly, many people are paying attention to V. It is quite popular at GitHub with over 36.2k stars, 2.2k forks, and 775 contributors. [1] https://github.com/vlang/v/discussions/7610
In TUI editor and Vim/Neovim alternative
imiric·Mar 25, 2025
Like I said, I didn't want to get into a discussion. This is not the appropriate forum to discuss bug reports. I was simply sharing my experience with the project, which admittedly could be outdated by now, but those were my impressions from a few months ago. What I don't appreciate is the implication that I'm fabricating this, or that I'm biased, as OP accused me of upthread. I think that the defensive stance that you and some of the people in the V community[1] have historically taken when faced with any sort of criticism continues to be detrimental to your project. Whether the criticism is a misconception or a flaw in the project, if a user is confused it's still on you to address that with documentation, a bugfix, or a friendly response, if nothing else. Most people are not actively making up issues for some Machiavellian reason. This
Read the rest
"us vs them" mentality is barbaric. As for users telling you what is wrong, it's delusional to think that it's somehow their responsibility and that it shouldn't be hard. Creating a bug report that clearly explains the issue requires time and effort. And what is to be gained from that if it's only going to be met with defensive arguments and hostility? Like I said, most people will not bother with this, and you should expect that most issues will not be reported. Most users will simply move on, but they will remember they had a bad experience. Yes, projects in early stages have many bugs. All projects do. But maybe it would be wise to focus on stabilizing the core features the project claims to have, before moving on to building editors and operating systems with it? After 5 years there shouldn't be any confusion and unexpected behavior of core functionality. The work done on V is truly impressive, and I do wish the language was successful. But I think that realigning some priorities, being honest about what works now and how well it works, and a major shift in tone from maintainers to users, would go a long way towards earning back the trust the project lacks. Good luck! [1]: https://github.com/vlang/v/discussions/17122#discussioncomme...
In TUI editor and Vim/Neovim alternative

Showing the 15 most recent of 24 sources. Enable JavaScript to search and browse every indexed mention.

MAKE YOURSELF AT HOME

A few shortcuts

/
Search the collection
?
Open this guide
Esc
Close dialogs and navigation

Your saved repositories and interests stay in this browser.