Joined 4 years ago
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).
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.
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).
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
... 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!)
For example, the following code from the article still leaks with autofree:
[heap]
struct MyHeapValue {
value i64
}
fn draw_text(value MyHeapValue) {
}
fn main() {
// ...
arg1 := MyHeapValue { 42 }
arg2 := MyHeapValue { 100 }
draw_text(arg1)
draw_text(arg2)
// ...
}
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.
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.
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.
> 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.
> 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.
[0]: https://github.com/vlang/v/blob/master/doc/docs.md#memory-ma...
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("")
}
}
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.