The homepage still makes the claim that "[autofree] takes care of most objects (~90-100%): the compiler inserts necessary free calls automatically during compilation."
There is no citation for where this 90-100% number comes from, it seems to be pulled completely out of thin air.
Autofree, as it currently exists, cannot handle structs at all, so any program whose memory allocations consist of more than 10% structs unfortunately proves this claim false.
For a specific example, a while ago I wrote a minimax tictactoe program[1] in V, which specifically used a struct to store the board state rather than an array.
In this case, with the minimax running for 4 total moves, valgrind tells me:
==8518== HEAP SUMMARY:
==8518== in use at exit: 2,250,360 bytes in 68,544 blocks
==8518== total heap usage: 161,756 allocs, 93,212 frees, 4,762,235 bytes allocated
So only 93212/161756 allocations were freed, which is 57%.
... Now, I don't actually care that much that autofree doesn't work on structs. I think that's quite reasonable, as it's a very difficult thing to implement!
But, in my opinion, your website should really cite where this 90-100% number comes from, i.e. which benchmarks were used to generate it, so that it is clear that it isn't just completely made up.
(As it currently stands, I would argue this is false advertising specifically because there's no citation for this number!)
Why isn't there a citation for this 90-100% number? I really am extremely curious where it comes from.
As for why I am posting a similar message (not nearly the same post, though) to you here as I did a year ago:
It is because I am very, very curious about where this number comes from and why there is no citation for it! It is fascinating to me.
(And, more generally, I have empirical experience with autofree that many users don't seem to have... so it seems useful to post about that experience to provide extra context for everyone else on this website).
Sure (although I can't find anything like that on vlang.io myself), but your post was that "[n]one of the claims in this article are relevant now."
It is still relevant that autofree does not work on heap-allocated structs. In particular, this is relevant to the day-to-day usage of the V programming language.
Whether this is well-documented by V itself does not change that it is relevant, in my opinion.
In both the review itself and in V's documentation, from which the example came, it states that autofree is still WIP. It's arguably disingenuous to pretend otherwise or present unintended usage.
The normal "day-to-day" situation would be to have the GC on or as fallback, and to do otherwise (like -gc none or -prealloc), one should know what they are doing or be prepared to deal with such issues.
Those parts of the review, considered relevant in normal usage were resolved:
But even beyond that, the intent of the so-called review was arguably malevolent. It was not done in good faith, to be helpful to the developers or community, but done to spur on drama (thus adding the vaporware link and spamming it) and knowingly looking for ways to bash an alpha version of the language.
But I'm not pretending that autofree isn't documented as WIP, nor am I suggesting that anybody should use anything unintended.
I am simply pointing out that a single claim from the article is still relevant to how V functions today. To be more specific, the still-relevant claim is: "So forcing the value to be allocated on the heap reveals that autofree leaks the values."
The post I am replying to did not say "almost none of the claims in this article are relevant now," it specifically said "none" without qualification.
Maybe I am just unusual in how I use the English language, but I would unquestionably consider this to be a case where you should really qualify the word none, because otherwise it's just not true.
Whether autofree is completely in alpha and intended not to be used or not, the claim from the article that it doesn't work for everything is relevant. I don't see how it couldn't be.
Surely if autofree is WIP, it's no big deal to simply agree that the fact it doesn't work on heap-allocated structs is relevant to its current state?
Now, to be clear, I am aware that arguing over a single extremely small point is, to some degree, missing the point of the comment I was originally replying to. But this is also just how I talk about things on the internet. If part of your claim is untrue, even to an extremely minor degree, I will point that out. This is why when I personally claim things, I almost always qualify what I am saying. (See? Even here I said "almost always," because I just naturally add qualifications so as not to overstate my case).
So, research into the impact of biological sex on medication, and similar, doesn't really seem alienating to me. Despite the existence of trans people, there are obviously two main categories that people fall into in a medical sense.
That said, I do think it would be a mistake to assume that the conclusions of any research into biological sex can be directly extrapolated to trans people. If we know that the relevant mechanism is hormones or chromosomes we may be able to predict effects on trans people--but we also might not be able to, if the mechanism isn't known, or for whatever other reason.
One well known example is that trans women's risk of breast cancer is more comparable to cis women than cis men. If I recall correctly, this is because the relevant factors are basically whether a person has breasts or not, and of course, trans women grow breasts when on estrogen.
In my opinion, the current documentation on the autofree engine [0] constitutes a false claim about language capabilities:
> 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.
> 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, I am not entirely sure the best way to quantify whether this is true. However, I thought a fun test would be recreating "my first memory leak" -- the first memory leak I can remember fixing in code that I wrote. Specifically, I was essentially leaking some bespoke heap-allocated iterators I had created (inside of an infinite game loop).
So here is my little test:
struct Iter {
mut:
pointer int
}
fn main() {
my_array := [ 1, 2, 3, 4, 5, 6, 7, 8, 9, 10 ]
for true { // simulated game loop
mut iter := &Iter { 0 }
// heap allocated iterator
for iter.pointer < my_array.len {
print(my_array[iter.pointer])
print(" ")
iter.pointer += 1
}
println("")
}
}
I compiled this with -autofree -gc none, with V 0.3. Checking it with valgrind, it continuously leaks memory.
So, from what I can tell, this description of the autofree engine in the documentation does not accurately describe the existing functionality available in V.
I am curious where the 90%-100% figure comes from. It is such a specific number that it implies to me, as a reader, that it comes from an empirical measurement of an existing system. But, there is no link to where this measurement was taken. In my opinion, the documentation should include some details about how these figures were generated.
So, to be clear, is the intended reading of the documentation as follows?
> 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.
> 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.
> These points are both currently untrue, and should not be relied on in code.
I'm hoping I don't come off as flippant here. I just don't see any way to interpret these claims as an accurate description without adding that third bullet point.
Okay, I really don't understand what you're saying here.
The claims are objectively false. The autofree engine objectively does not free 90%-100% of objects, it is objectively not true that "It just works."
If I understand you, you're saying that autofree doesn't work because of bugs in the compiler. But, the fact that the claims are false as a result of bugs in the compiler does not somehow make those claims true.
Autofree exists and does work (https://youtu.be/gmB8ea8uLsM), however, it doesn't work where a user can have a complete lack of understanding about memory management like various GCs do or have never used it before. Autofree, as it is, also requires looking at examples of usage in various programs.
The website and documentation does explain the situation, for those that cared to actually read them. "Right now allocations are handled by a minimal and well performing GC until V's autofree engine is production ready." This should be enough to understand that autofree is WIP and not enabled by default (which is referred to in the documentation).
The other issue, is that people who have never used V or autofree (not even talking outright detractors), might interject or repeat uninformed opinions about the situation. Where those that have more thoroughly experimented with autofree and have used V or are in the V community, would likely understand the situation and history of it (have read other things about it on V's GitHub or asked about it on discord).
I understand that autofree is WIP. I read that part of the docs, and I have watched the demo.
But I don't really understand what the intended reading of the documentation is.
If I were to completely take these two paragraphs out of context, they are factually untrue:
> 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.
> 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, what does this mean? Well, nothing, necessarily. If the context clarifies that these points are all untrue, then, the documentation could be considered perfectly accurate as far as I'm concerned.
However, when I asked if the intended reading of the documentation was that these points are untrue, the answer was--no, these points are all actually true.
I don't understand that position. These claims are straightforwardly untrue.
To me, your response is reinforcing my original proposed reading. That is--to me, your response indicates that I should read these claims as being false, and that the documentation is acknowledging them as false.
Now to me, that is a perfectly good response to my original comment. If this part of the documentation is not intended to be read as a statement of fact, that makes perfect sense to me, even though I do think it could be communicated better.
As it stands, though, I'm not really sure what I'm meant to get from this[0] comment.
When a person new to V reads the documentation (which they should be doing), they would also see the following.
"Note 2: Autofree is still WIP. Until it stabilises and becomes the default, please avoid using it. Right now allocations are handled by a minimal and well performing GC until V's autofree engine is production ready."
So, autofree (as a WIP) is not at this point working as intended, which is described by, "The developer doesn't need to change anything in their code. "It just works"..." I don't take this as any attempt to mislead or deceive, like you seem to be doing. The documentation is even telling people to avoid using autofree, as it's WIP.
Yes, there is a difference between how autofree is suppose to work versus how it is presently working. Yes of course, I can totally see how people get very excited about autofree, and want it 100% working or want its development accelerated. But, it should be obvious that at this point, when a person is using it, they are experimenting. When a person takes it upon themselves to enable autofree, in an alpha status language, they shouldn't be surprised there are issues.
Then bringing it back to what I had typed about earlier, using autofree at this point, requires that the person understands something about memory management and looks at examples of its usage. Particularly when a person is going to enable it, against the recommendation of the documentation.
It seems we are essentially in agreement on how the documentation is meant to be read, which is that the points it makes about autofree are not meant to be statements of fact.
Not exactly, because what I'm saying is that the V website and documentation is explaining what autofree does, describing what autofree is, and how it works.
It appears you are implying that if autofree doesn't work perfectly as it is described, then that indicates a false claim or deception.
The counter to that (and what I'm saying) is that the website and documentation states that autofree is WIP and even recommends not to use it, and tells users that at this time GC is used instead. There is no deception, they are being clear. So if the user goes against the recommendation of the documentation, they should not be surprised that WIP autofree in alpha status V, is not working perfectly.
Furthermore, autofree does exist. We are not talking about a lie or false claim, where something is not in existence. Autofree does function, so here too, we are not talking about something that does not work at all. We are now talking about to the degree it is working or how well it works. Which on that point, the website and documentation both indicate WIP, so a user should not yet expect it to fully function.
I further elaborated that if you experiment with it, you may get autofree to work well. But, that can depend on: the program, can require experience using V, some memory management knowledge, and/or going through examples of V programs that use it. The expectation (and what those in the V community are aware of) is that as V goes to higher versions on its way to beta status, we will see better performing versions of autofree that requires less to no needed user knowledge about details.
There is no citation for where this 90-100% number comes from, it seems to be pulled completely out of thin air.
Autofree, as it currently exists, cannot handle structs at all, so any program whose memory allocations consist of more than 10% structs unfortunately proves this claim false.
For a specific example, a while ago I wrote a minimax tictactoe program[1] in V, which specifically used a struct to store the board state rather than an array.
In this case, with the minimax running for 4 total moves, valgrind tells me:
So only 93212/161756 allocations were freed, which is 57%.... Now, I don't actually care that much that autofree doesn't work on structs. I think that's quite reasonable, as it's a very difficult thing to implement!
But, in my opinion, your website should really cite where this 90-100% number comes from, i.e. which benchmarks were used to generate it, so that it is clear that it isn't just completely made up.
(As it currently stands, I would argue this is false advertising specifically because there's no citation for this number!)
[1]: https://pastebin.com/6ZDKKRQR