Why is the performance of V's autofree worse than gc?

[Avey777]

1、The performance of V's autofree is worse than gc, so what is the original intention of developing the V language?
2、The highlight of V language is autofree. If the performance of this function is poor, it is better to use rust directly.
3、Should the V language consider a rust-like memory management approach in the future?
4、Many of the V languages are similar to the Go language. Can you consider replacing Java?
5、The best thing that V language does currently is that its syntax is much more comfortable than go language and is more in line with human writing habits; but if the performance is not as good as go language, or even better, I can't find any reason to use v language.

[medvednikov]

autofree is not the highlight

this is:

The home page and the compare page go over what V offers:

https://vlang.io/compare#go

[Avey777]

Autofree is not the highlight, so many optional memory management methods are the real highlight of V?

[Wajinn]

...so what is the original intention of developing the V language?

There are also 2 YouTube videos that discussed the reasons behind why V was developed:
1) A small presentation of V's features at IBM
2) How To Maintain And Iterate With V - SYNCS 2023

The highlight of V language is autofree. ...If the performance of this function is poor, it is better to use rust directly.

If we really wanted to bash our heads against the wall, we could just use assembly directly. Many use higher level programming languages for their conveniences, not only because of speed. When it comes to speed, V as a young compiled programming language, is plenty fast and comparable to C. Slight differences in speed, are often insignificant, relative to the tasks most are doing. Even if focusing on this, as different languages come out with new or improved compilers and versions, the results can be different. The difference in results can also be how the code is written or the algorithms used.

Should the V language consider a rust-like memory management approach in the future?

Such points are way too skewed, where they are looking at everything through rust's perspective. V's use of a GC allows for both memory safety and convenience for users (and "simple" was a primary design goal). Even with GC usage, V has proven to be fast enough (new programming language benchmark).

V is designed for flexible/optional memory management. So you can turn off the GC and then use autofree, arena allocation (-prealloc), or maybe something else new in the future.

...(V language) syntax is much more comfortable than go language and is more in line with human writing habits; but if the performance is not as good as go language, or even better, I can't find any reason to use v language.

V's performance is already comparable to Go and C. Various tasks on benchmarks will show V ahead of Go, then show Go ahead of V for some tasks. That situation is very common for many compiled programming languages. They will keep leapfrogging each other depending on task, optimization for task, how code is written, algorithms used, and compiler or version of language used.

Therefore if your preference for V is based on it being more convenient and comfortable to use, a person should relax. V is only going to get better on performance, as it matures.