The V devs have promised a lot, have missed a lot but have also achieved a lot. I have written a few short programs in V. IMHO, the V syntax is concise and intuitive and the performance is good. It is lightweight and easy to install and to use. The blog post is probably right that V has many rough edges but I would say the core features in V are well planned. I actually prefer it over some other more popular languages. That said, because V hasn't reached 1.0, it is probably too early to use it in production.
Yeah, when the article skipped over the first two memory management strategies to point out issues with manual memory management and an "automatic" strategy that is unfinished or broken, it really struck me that it's quite impressive for a single author to have a functional, fast language with a working garbage collector and arena allocator (with some issues) in only a few years.
The criticisms in the article, which I just read beginning to end, are largely about features it claims to provide (or claims are in development) that either no other language has, are an improvement on other languages, or are state of the art features in world class languages with hundreds to thousands of times more developer hours.
On the one hand, it's not wrong to criticize the overly ambitious nature of V's plans nor criticize the poor attitude and self-advertising strategies of its lead author. On the other hand, I'm not sure that the article is doing that, it seems much more interested in taking one of these features, showing that it doesn't work, and saying "so there!". But the fact that these are the features being complained about, not the core of the language, says something in itself.
Likewise, the fact that a hobbyist language with a single primary developer has terrible documentation is at the very least par for the course. Heck, I've found the Zig documentation horrific (in the past), and that has way more developer time and mindshare. Compare it to, say, the Oil shell (at least, where it was a few years ago), if you want to be fair.
I'm not convinced that the blog author isn't a troll, in some sense of the word. Clearly, many of their criticisms are well founded. Clearly, Alex does not react well to criticism. Clearly, V kinda sucks for practical use right now in a lot of ways that do matter. But the post (especially the end) feels like an excuse to stir the pot, not well-intentioned criticism. The author seems to want to use this post to counteract people they feel have mistreated them (with some justification).
Note: I say all this as a complete outsider. I've never written a line of V code and probably never will. My only prior experience is that I'm familiar with the controversy around V, especially on this site.
> quite impressive for a single author to have a functional, fast language with a working garbage collector
From what I gather from the article, they didn't implement a garbage collector, but rather integrated the Boehm GC. This is a conservative collector, so it doesn't collect all garbage.
> But the fact that these are the features being complained about, not the core of the language, says something in itself.
Memory management is a core part of a language. According to the article this core part doesn't work, which is a pretty big flaw.
The problems with V has always been that its marketing is full of lies and its main selling points don't work as advertised. The same source code, but without the deception, might very well be an alright language.
Just like how healing crystals are perfectly fine if what you want is decoration and you think they look pretty. It doesn't make the deceptive marketing okay.
> it's quite impressive for a single author to have a functional, fast language with a working garbage collector and arena allocator (with some issues) in only a few years.
As the included code shows, the gc is boehm gc, and checking their repo shows they just include libgc/bdwgc. This is absolutely not a knock against anyone here, it's just about the standard library for this need, and I think it is a far smarter move to use it than for most to attempt to make their own general-purpose gc (though boehm can't catch all leaks).
I feel it would be wrong, however, to characterise this as being a single author having made a language with a gc and arenas, as if those were significant parts of the author's own developments, rather than using a well-picked import and a half-baked implementation of "arenas", which here are really just a global linked list of buffers, freed only at exit, and so everything leaks [0]. They're not really arenas, you can't use them locally in a region of code or as scratchpads, let alone multi-thread it. By their code's own admission, it's just a little pre-allocation to batch mallocs for all the little heap allocations of a GC-assuming codebase, so they're not really arenas like you'd use in C or elsewhere.
Not unimpressive, it's a valid approach for some uses (though not general purpose), it's just different from a language with their own gc and actual arenas. Indeed, just implementing an arena barely even registers in the complexity, I feel, as arenas really should be very simple in most use cases [1]. It would be far more impressive to have them actually integrated and be available as a true alternative to a GC for memory management, particularly integrating common patterns (e.g. [2]) in a way that could serve as a drop-in replacement, such that we can actually provide bounded lifetimes and memory safety without a full GC, let alone support multiple concurrencies with it from multi-threading to coroutines -- this would likely still be unsafe without a GC compared to, say, Rust or Vale, let alone Pony or SPARK, and would likely require a cultural shift in manual management akin to Zig or Odin, as it may be largely moot if dependencies end up enforcing the gc themselves. Still, again, making anything substantial is never unimpressive, we just need to retain the perspective of what was achieved and how.
As to the rest, well, I think it's fair to say that there should be a clear delineation between statements of "we can do this and here's how" and roadmaps with "we're aiming to do these things and here's our current progress". In my experience, people are quick to get these mixed up when they're excited about making something, and none of us are fully immune to this. It's not some moral failing or anything in and of itself, it can very easily be an honest mistake, but humans see patterns everywhere, so we often need to be receptive when others are trying to help us be level-headed and clear things up; otherwise a reputation begins to form. Especially in this industry, reproducibility matters, as we're all too familiar with the smoke-and-mirrors of demos (not to personally claim there is any here, just that it obviously helps dispel such concerns).
And, of course, second chances are always offered if someone is willing to amend mistakes.
How do you feel about the basic stuff not working as demonstrated in the article? What's so special about V that you prefer using a literally broken language? (The perma memory leaks are basically enough already to qualify it as broken)
The V devs have promised a lot, have missed a lot but have also achieved a lot. I have written a few short programs in V. IMHO, the V syntax is concise and intuitive and the performance is good. It is lightweight and easy to install and to use. The blog post is probably right that V has many rough edges but I would say the core features in V are well planned. I actually prefer it over some other more popular languages. That said, because V hasn't reached 1.0, it is probably too early to use it in production.
Yeah, when the article skipped over the first two memory management strategies to point out issues with manual memory management and an "automatic" strategy that is unfinished or broken, it really struck me that it's quite impressive for a single author to have a functional, fast language with a working garbage collector and arena allocator (with some issues) in only a few years.
The criticisms in the article, which I just read beginning to end, are largely about features it claims to provide (or claims are in development) that either no other language has, are an improvement on other languages, or are state of the art features in world class languages with hundreds to thousands of times more developer hours.
On the one hand, it's not wrong to criticize the overly ambitious nature of V's plans nor criticize the poor attitude and self-advertising strategies of its lead author. On the other hand, I'm not sure that the article is doing that, it seems much more interested in taking one of these features, showing that it doesn't work, and saying "so there!". But the fact that these are the features being complained about, not the core of the language, says something in itself.
Likewise, the fact that a hobbyist language with a single primary developer has terrible documentation is at the very least par for the course. Heck, I've found the Zig documentation horrific (in the past), and that has way more developer time and mindshare. Compare it to, say, the Oil shell (at least, where it was a few years ago), if you want to be fair.
I'm not convinced that the blog author isn't a troll, in some sense of the word. Clearly, many of their criticisms are well founded. Clearly, Alex does not react well to criticism. Clearly, V kinda sucks for practical use right now in a lot of ways that do matter. But the post (especially the end) feels like an excuse to stir the pot, not well-intentioned criticism. The author seems to want to use this post to counteract people they feel have mistreated them (with some justification).
Note: I say all this as a complete outsider. I've never written a line of V code and probably never will. My only prior experience is that I'm familiar with the controversy around V, especially on this site.
> quite impressive for a single author to have a functional, fast language with a working garbage collector
From what I gather from the article, they didn't implement a garbage collector, but rather integrated the Boehm GC. This is a conservative collector, so it doesn't collect all garbage.
> But the fact that these are the features being complained about, not the core of the language, says something in itself.
Memory management is a core part of a language. According to the article this core part doesn't work, which is a pretty big flaw.
The problems with V has always been that its marketing is full of lies and its main selling points don't work as advertised. The same source code, but without the deception, might very well be an alright language.
Just like how healing crystals are perfectly fine if what you want is decoration and you think they look pretty. It doesn't make the deceptive marketing okay.
I wouldn't say it's impressive.
I've seen tons of computer science graduates hooking up gc to their languages in uni when they learn about compilers and programming languages
1 reply →
> it's quite impressive for a single author to have a functional, fast language with a working garbage collector and arena allocator (with some issues) in only a few years.
As the included code shows, the gc is boehm gc, and checking their repo shows they just include libgc/bdwgc. This is absolutely not a knock against anyone here, it's just about the standard library for this need, and I think it is a far smarter move to use it than for most to attempt to make their own general-purpose gc (though boehm can't catch all leaks).
I feel it would be wrong, however, to characterise this as being a single author having made a language with a gc and arenas, as if those were significant parts of the author's own developments, rather than using a well-picked import and a half-baked implementation of "arenas", which here are really just a global linked list of buffers, freed only at exit, and so everything leaks [0]. They're not really arenas, you can't use them locally in a region of code or as scratchpads, let alone multi-thread it. By their code's own admission, it's just a little pre-allocation to batch mallocs for all the little heap allocations of a GC-assuming codebase, so they're not really arenas like you'd use in C or elsewhere.
Not unimpressive, it's a valid approach for some uses (though not general purpose), it's just different from a language with their own gc and actual arenas. Indeed, just implementing an arena barely even registers in the complexity, I feel, as arenas really should be very simple in most use cases [1]. It would be far more impressive to have them actually integrated and be available as a true alternative to a GC for memory management, particularly integrating common patterns (e.g. [2]) in a way that could serve as a drop-in replacement, such that we can actually provide bounded lifetimes and memory safety without a full GC, let alone support multiple concurrencies with it from multi-threading to coroutines -- this would likely still be unsafe without a GC compared to, say, Rust or Vale, let alone Pony or SPARK, and would likely require a cultural shift in manual management akin to Zig or Odin, as it may be largely moot if dependencies end up enforcing the gc themselves. Still, again, making anything substantial is never unimpressive, we just need to retain the perspective of what was achieved and how.
As to the rest, well, I think it's fair to say that there should be a clear delineation between statements of "we can do this and here's how" and roadmaps with "we're aiming to do these things and here's our current progress". In my experience, people are quick to get these mixed up when they're excited about making something, and none of us are fully immune to this. It's not some moral failing or anything in and of itself, it can very easily be an honest mistake, but humans see patterns everywhere, so we often need to be receptive when others are trying to help us be level-headed and clear things up; otherwise a reputation begins to form. Especially in this industry, reproducibility matters, as we're all too familiar with the smoke-and-mirrors of demos (not to personally claim there is any here, just that it obviously helps dispel such concerns).
And, of course, second chances are always offered if someone is willing to amend mistakes.
[0]: prealloc.c.v is barely over 100 lines long and quite manageable, https://github.com/vlang/v/blob/master/vlib/builtin/prealloc...
[1]: Chris Wellons, "Arena allocator tips and tricks", https://nullprogram.com/blog/2023/09/27/
[2]: Ryan Fleury, "Untangling Lifetimes: The Arena Allocator", https://www.rfleury.com/p/untangling-lifetimes-the-arena-all...
The V lang author implicitly claims to understand CS theory better than quite a lot of people including Go and Rust lang devs.
[flagged]
How do you feel about the basic stuff not working as demonstrated in the article? What's so special about V that you prefer using a literally broken language? (The perma memory leaks are basically enough already to qualify it as broken)
Genuinely curious, I don't understand the point
[flagged]