Comment by amedvednikov | Hacker News Reader

Comment by amedvednikov | Hacker News Reader

Parent Full thread

I have some guesses.

I'll publish a big blog post about this. It will debunk all these "V is a scam" articles.

Basically V appeared out of nowhere and got popular very fast. It took a lot of shortcuts: it was self hosted on release, GitHub started supporting it 1 month after the release, it had hot code reloading, fast compilation (v self is <1s [0]) and so on.

People developing other languages and their communities didn't like it, and decided to attack it.

There were 2 strategies: making completely false statements (like claiming that the V compiler has a dependency on glfw, so the no dependency claim is false, and claiming that V programs use libc, system's only official API, therefore again the no dependency claim is false) and nitpicking over bugs that are inevitable in a 0.1 language, and sometimes complaining that features explicitly marked as [wip] are not ready yet. One of the common questions I saw is "why release it if it's not ready". While that's the whole point of open source. I got lots of help from 500+ contributors and got to this point a lot faster.

Then there was also a misunderstanding with the "preview" release one week before the source code was released, and many thought V was going to be closed source. Over this week unfinished features were not marked as [wip]. They were marked so after the open source release, and now there're no [wip] features on the website. Everything listed there is working in latest V.

[0]: https://www.youtube.com/watch?v=pvP6wmcl_Sc

> People developing other languages and their communities didn't like it, and decided to attack it.

I honestly doubt this is the case. Aside from some cargo-culters (which are far from being a majority), most programming language enthusiasts are very welcoming to new languages and ideas they bring with them. I have never seen a "language war" happening this way.

Personally, I admire the V's ambitions (if the autofree() ever reaches production-quality it would be a total triumph over Golang's garbage collection approach), but I dislike the unprofessional approach to the community (explained in many other comments - particularly false claims about language capabilities, deleting criticisms, unwillingness to admit shortcomings and making up excuses for each of them, etc.).

There are 0 false claims about language capabilities on the website or in the docs.

If you can link one, that'd be great, and it'll be fixed. I've spent a lot of time verifying all claims are valid.

For example there was the "functions are pure by default except IO" which caused lots of criticism and memes. I simply changed the wording to a more verbose but correct phrase. So we do admit shortcomings and not make up excuses "for each of them"

We do not delete criticisms, we actually welcome them and any kind of feedback:

https://github.com/vlang/v/discussions/7610

So you're sticking with "people are evil and hate me"?

So can you list the "false claims about language capabilities" here?

Saying "no undefined behavior" when what you really mean is "We define our language's behavior to be the same as C's" (in other words, you just punt undefined behavior to the C compiler) is deceptive at best. I'm specifically thinking of signed integer overflow here, but that makes me think there may be other cases as well.

You're reading my words, but you're not trying to understand what I'm saying.

Unless you demonstrate an honest effort to understand, I will not continue this pointless argument.

You said there are false claims about language capabilities, I asked you to list them. It's a reasonable request. I don't want to have false claims on the website.

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.

[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("")
        }
    }

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.

No, it describes it absolutely accurately:

> until V's autofree engine is production ready.

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.

They are both true, and it clearly says it's not production ready yet, so there are bugs.

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.

[0] https://news.ycombinator.com/item?id=31955809

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.

Reply on news.ycombinator.com