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.
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.
I've seen tons of computer science graduates hooking up gc to their languages in uni when they learn about compilers and programming languages
exec ["ld"; "-o"; out_file; obj_file]
exec ["ld"; "-o"; out_file; obj_file; "-lgc"]
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.
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...
Genuinely curious, I don't understand the point
I have no skin in the game. Got into V very recently, because it appeals to me at face value.
And in some ways better than other "better C" languages of today.
For me it's just good enough. The syntax is sane, the compiler doesn't want to maniacally ruin my day, the standard library is already quite rich, and finally wrapping C code is a breeze.
For instance, not understanding why try so hard to push a 2023 review for an old version of the language, when we are in 2024. But ok, here this is. It comes across as not being neutral because of the very personal dispute against V's creator, as revealed at the bottom of the blog. The super strange ranting displayed by the reviewer at the bottom, destroys all sense of neutrality, and disputably its credibility.
The review itself has various errors or problems that people gloss over or haven't caught some of: 1) It's weird to be complaining about autofree, when the documentation says its WIP and go use the GC for now. They clearly are giving user options for managing memory. 2) He was using the wrong or ignoring other compiler options. 3) The reviewer seems to be intentionally distorting or misrepresenting the coroutine situation; it's WIP and will be used on the Windows OS. 4) It's open source. Report to them or go help fix whatever is the issue, as other people have (hundreds of contributors).
For example, with the coroutines part, research (site and documentation) shows the V project will be using both OS threads and green threads for concurrency. Right now, they use OS threads, with the `spawn` and `go` keywords. In the future, the `go` keyword will only be for green threads, which the critic is referring to (corounties). At V's site, they are working on coroutines (green threads) for the Windows OS and are steadily working on implementing that into the language.
I would think most reasonable people would cut a volunteer open source project some slack and allow them time to improve upon what they are doing, but there appears to be some weird rush and other intent going on. Don't see V's community attacking anybody, just them happily focusing on their language, but it seems a lot of people are going after them, really hard.
The author clearly wants a reckoning, but he's unlikely to receive satisfaction. The people that still use or evangelize V are locked in, the contradictions will only make their belief stronger. Alex is a bullshitter, and arguing with someone like that is pointless.