Hacker News new | ask | show | jobs
by amedvednikov 1032 days ago
What's written is correct, what's the issue again?

RC was later replaced with a tracing GC.

RC is a type of GC btw, so...

1 comments

> What's written is correct, what's the issue again?

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.

> Static analysis (autofree) with reference counting, by itself, cannot theoretically free all of the objects during the runtime of the program.

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?

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

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?

You pointed to an old version of the documentation. RC was changed to tracing GC. Things can change in the design.

V never promised autofree without GC or RC.

> You pointed to an old version of the documentation

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.
So yeah, V promised autofree without GC.
And again, everything written is correct.

No heavy GC tracing everything or expensive RC for each object.

What's your issue with the wording?

V is not a finished product nor 1.0 yet. It's unproductive to act like things were carved in stone, from day 1. Programming languages go through development phases, where things do change and lead developers are allowed to make changes.