I haven’t had the pleasure to try out V yet but I hope this discussion can rise above. Endless bickering leaves a sour taste in my mouth.
How can you assert that they're misleading or highly interpretive wrongs if you haven't dug into them yourself and actually used V? All the negative press I've seen on V has been highly detailed and reproducible.
Whenever this topic comes up I’m at a loss to understand why anyone would waste so much energy mud slinging over some personal language project. It only makes sense if it’s become a hate meme. My pocket word for an event that’s a sort of social singularity. It occurs when enough popular voices have directed the entirety of a community to shame a target based on some perceived wrong, real or otherwise.
Wherever it comes up I’m pretty taken aback by how tribal and ego focused we can be, even among the smartest of us. And that thought isn’t meant be taken as condescending. After all, we’re only human. And for a larger span of human history, that word has meant “hairless ape” more than anything else.
Does the fact that he earns money off of Patreon by overpromising all the impossible features change your perspective on the matter?
Unless things changed drastically V lang, as described by their documentation, is a vapor ware.
I'm still waiting for that CS breakthrough to happen - Rust guys will be so mad they spent their time writing lifetime annotations for the borrow checker :)
March 2019
> No. V's memory management is similar to Rust but much easier to use. More information about it will be posted in the near future.
May 2019
> No. V manages memory at compilation time (like Rust). Right now only basic cases are handled. For others, manual memory management is required for now. The right approach to solve this will be figured out in the near future.
April 2020
> No. V manages memory at compilation, like Rust: vlang.io/docs#memory
August 2023
> You can look up vlang.io on web archive and see that it never said GC-less autofree
"The right approach to solve this will be figured out in the near future."
And it was figured out, and we now have what we have. It's described on the home page in detail. 4 ways to handle memory.
Why another new account?
> Most objects (~90-100%) are freed by V's autofree engine: the compiler inserts necessary free calls automatically during compilation. Remaining small percentage of objects is freed via reference counting.
So most objects are freed by the autofree engine, and the rest are freed via reference counting. This implies that no objects are freed by the GC, which is exactly what I've said.
Please stop gaslighting people.
[0] https://web.archive.org/web/20210315092012/https://github.co...
RC was later replaced with a tracing GC.
RC is a type of GC btw, so...
The fact that the feature promised is impossible. I'm quoting some comments from which this whole discussion has started, since you don't seem to be able to follow:
> dgellow: They got lot of push back because what the core devs were describing Vlang to be was technically close to impossible
> amedvedikov: There were no close to impossible/missing features.
Static analysis (autofree) with reference counting, by itself, cannot theoretically free all of the objects during the runtime of the program. And I know that you know that since you've made the decision to switch to a tracing garbage collector.
The choice of tracing garbage collection makes the initial claim much less impressive and innovative - Go already has escape analysis, which is basically an implementation of autofree. But Go used a garbage collection from the start, so escape analysis is just an optimization - exactly what autofree is for the current V with GC.
V promised something impossible, it's not a big deal, we all make technical mistakes and learn from them. What makes it a big deal is your stubborn attempts to rewrite history and gaslight people.
It can't, that's what it says on the home page. Stuff that can't be freed during compile time is handled via GC.
What's the issue again? What's the impossible claim?
The documentation I've quoted and posted a source to specifically says that all objects are freed either by 1) autofree or 2) reference counting.
> What's the impossible claim?
The impossible claim is that all objects are freed either by 1) autofree or 2) reference counting. As I've mentioned, neither static analysis (which is what autofree is) nor reference counting is capable of completely freeing all unreachable objects at runtime - reference counting is in particular unable to handle cyclic references.
> What's the issue again?
The issue is you vehemently claiming that V has never, ever promised a feature that was impossible - which is false, as I've demonstrated and cited with reference to archive.org of V lang documentation. So can you stop doing that, please?
V never promised autofree without GC or RC.
Yes, because that version of documentation specified a feature that was impossible, which is exactly what we're discussing.
> V never promised autofree without GC or RC
First of all, I never mentioned "autofree without RC". I am strictly speaking about "autofree without GC".
Second of all, V documentation has had the "autofree frees 90% of objects, RC frees everything else" segment, which clearly implies no GC. So the documentation has clearly specified that feature, which was an impossible feature.
Even the next paragraph says:
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.
No heavy GC tracing everything or expensive RC for each object.
What's your issue with the wording?
1) The first sentence clearly stated that:
Most objects (~90-100%) are freed by V's autofree engine: the compiler inserts necessary free calls automatically during compilation. Remaining small percentage of objects is freed via reference counting.
2) Your emphasis of "everything" seems to imply a contrast to Python or Go method of memory deallocation:
"It just works", like in Python, Go, or Java, except there's no heavy GC tracing everything
Yes, and what's wrong with that? That's how it works now too, except RC has been replaced by a tracing GC.
But gaslighting people and pretending that overly grandiose claims/promises haven't been made in the past leaves a bitter taste, and doesn't inspire trust in core developers. Instead, it makes me think that the core devs are incapable of admitting a mistake - which would make their language a hazard.
For example, what if V gets huge and a serious security bug gets discovered - how can I trust that the developers will properly communicate the existence of such a bug and not just keep quiet about it, consider how they aren't even willing to admit that V has made some impossible claims/promises in the past? If I discover a bug, will they also pretend that the bug doesn't exist, even when confronted with indisputable evidence, because it threatens to damage their reputation?
As long as that attitude doesn't change, I'm not touching V with a 10 foot pole.
See my numerous replies to you in this thread, where I have quoted the documentation, provided the archive.org link and explained why the claim is impossible.
Do you have any other argument except "nuh-uh, didn't happen, lol"?
> I haven’t had the pleasure to try out V yet
How can you know that the wrongs are misleading if you've never even tried the language?
What, in your opinion, are legitimate reasons for someone to be upset with V?
Fair enough. But then, you should know false advertising by the language maintainer leaves an even bitterer one.