v

a little less defensive when they encounter articles that review it like a Real Language. If the authors don't want this kind of feedback they can just say front-and-centre (or on their FAQ @ https://github.com/vlang/v/wiki/FAQ) "this is a toy" or "this is pre-alpha" or "this is for research purposes". There are plenty of projects like this which are open about their intent and which don't have posts like this written about them. But I don't think that'll happen, so as it stands the pattern will continue - someone revisits the language every year or so, finds some things that doesn't meet expectations, writes about it and we discuss it on HN again.

nked 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...