Only use the option of Autofree to manage memory

[Avey777]

I read a lot of the author's documents about V, and many of them said that GC brought him surprise, which made me think that V language is still a language that mainly develops GC.

To be honest, I came here for the Autofree function, and I think many people came here for this function.

There are too many languages that use GC. If the V language is dominated by GC, I don't think there will be much development, even if it is a combination of autofree and gc (this combination is uncontrollable).

I think the V language should spend more time on autofree, and provide a complete autofree option when compiling, so that I can know that my program is controllable.

[medvednikov]

autofree will be a first class citizen in 0.5.

Like the blog post on autofree explains, and like you mentioned, GC indeed showed a better performance than expected (and better than autofree), but it's clear that autofree is wanted/needed by many.

[Avey777]

Very good, looking forward to autofree becoming a regular official

[Avey777]

I would like to know about when V0.5 will be released?

[Avey777]

v -gc none -autofree
Only using AutoFree is essential for ensuring the correct and stable management of memory, rather than the uncertainty brought by GC. Moreover, the Go language performs better in GC.

[Avey777]

v -gc none -autofree main.v

avey@avey river-x86_64-unknown-linux-gnu % v -gc none -autofree main.v
main.v:13:9: warning: unused variable: `i`
   11 |
   12 |     // Continuously create a large number of temporary objects
   13 |     for i in 0 .. 1_000_000_000_000 {
      |         ^
   14 |         mut obj := MyStruct{data: ['Hello, World!']}
   15 |         // Here we don't actually use obj, it will quickly become garbage
main.v:14:13: warning: unused variable: `obj`
   12 |     // Continuously create a large number of temporary objects
   13 |     for i in 0 .. 1_000_000_000_000 {
   14 |         mut obj := MyStruct{data: ['Hello, World!']}
      |             ~~~
   15 |         // Here we don't actually use obj, it will quickly become garbage
   16 |     }
avey@avey river-x86_64-unknown-linux-gnu %

v -gc none -autofree
In my opinion, it has always been in an unavailable state, and I don't know if there will be separate support for AutoFree in the future. If we don't choose to use the GC language, V is not a better choice

[Avey777]

If Autofree executes slowly, it is because the current compilation and optimizer are not good enough! Continuous optimization can be carried out in the future

[medvednikov]

I want to confirm if there will be an option to only use AutoFree?

Of course, why wouldn't there be. In fact there already is. v -autofree

[medvednikov]

Autofree is not finished and not a priority until V 0.6, but it will be finished.

[Avey777]

v -gc none -autofree run .
v -gc none -autofree .

v -gc none -autofree -d veb_livereload watch run .

avey@avey vprod % v -gc none -autofree -d veb_livereload watch run .
2024-10-06 07:49:00.141: "/Applications/v/v" -gc none -autofree -d veb_livereload run . | pid:   11906 | reload cycle:     0
================== C compilation error (from cc): ==============
cc:                       ^
cc: /tmp/v_501/vprod.01J9FHC9KRR2NYPKC2WNJMDFV9.tmp.c:49647:39: error: call to undeclared function 'tp'; ISO C99 and later do not support implicit function declarations [-Wimplicit-function-declaration]
cc: string _arg_expr_split_parse_1_9393 = tp(2, _MOV((StrIntpData[]){{_SLIT0, 0xfe10, {.d_s = line}}, {_SLIT("\n"), 0, { .d_c = 0 }}}));
cc:                                       ^
cc: /tmp/v_501/vprod.01J9FHC9KRR2NYPKC2WNJMDFV9.tmp.c:49647:8: error: initializing 'string' (aka 'struct string') with an expression of incompatible type 'int'
cc: string _arg_expr_split_parse_1_9393 = tp(2, _MOV((StrIntpData[]){{_SLIT0, 0xfe10, {.d_s = line}}, {_SLIT("\n"), 0, { .d_c = 0 }}}));
cc:        ^                              ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
cc: /tmp/v_501/vprod.01J9FHC9KRR2NYPKC2WNJMDFV9.tmp.c:49648:5: error: expected expression
cc:                 } else {
cc:                   ^
cc: /tmp/v_501/vprod.01J9FHC9KRR2NYPKC2WNJMDFV9.tmp.c:49653:13: warning: ordered comparison between pointer and integer ('char *(*)(const char *, int)' and 'int')
cc:                 if (index < (int)(lines.len - 1)) {
... (the original output was 755 lines long, and was truncated to 12 lines)
================================================================
(You can pass `-cg`, or `-show-c-output` as well, to print all the C error messages).
builder error:
==================
C error found. It should never happen, when compiling pure V code.
This is a V compiler bug, please report it using `v bug file.v`,
or goto https://github.com/vlang/v/issues/new/choose .
You can also use #help on Discord: https://discord.gg/vlang .

[JalonSolov]

The problem is that -autofree support isn't complete, yet. It is still WIP. It is planned for the near future, but isn't complete yet.

[Wajinn]

"To be honest, I came here for the Autofree function, and I think many people came here for this function."

"There are too many languages that use GC. If the V language is dominated by GC, I don't think there will be much development, even if it is a combination of autofree and gc (this combination is uncontrollable)."

There is a number of issues, in regards to the statements above:

1. Many languages using a GC are slower interpreted ones (Python, Lua, Ruby...), where V is a compiled language, thus still fast.
2. Many people have no pressing reason nor a program that must use something other than a GC because of performance.
3. The majority of users and tasks are going to be just fine with using a GC, and where differences are within seconds or milliseconds.
4. The advantages of using V are beyond just autofree.
5. Have never seen it indicated that autofree is the ultimate purpose of V.

"In my opinion, it has always been in an unavailable state, and I don't know if there will be separate support for AutoFree in the future. If we don't choose to use the GC language, V is not a better choice"

I'm not understanding the insistence to make autofree the highest priority, when it's not listed as being that on the website. Don't get me wrong, another and faster form of automatic memory management is a nice feature (add arena allocation in there too), but it's not the only feature. Team V keeps making it clear it's one of many things being or to be worked on. V performs about as well as Go (but you can turn the GC off or choose something else), which are both compiled languages, and where they may have an advantage or disadvantage (to each other) depends on the test used and how the particular code was written.

The V language and other libraries (like VUI or C2V for instance), looks to be of at least equal importance to any particular memory management option. From what I've read around here and the website, looks like various options for manage memory will always be provided. Autofree looks to always be one of various options, versus the only option or the only reason V exists.

[qpwo]

I also came for the autofree. I don't mind the developers focusing on GC or taking V somewhere else. It is their project and they set the priorities. But autofree is what got me excited about this.

[medvednikov]

There are many people who think like you, so we'll definitely finish autofree and make it on par with GC. Maybe even an optional ownership model as well.

[medvednikov]

But yeah like Wajinn eloquently said, GC is fine for 95% of users, and it performs really well with a compiled static and simple language like V. That's why autofree is not a priority atm.

[Avey777]

There are many people who think like you, so we'll definitely finish autofree and make it on par with GC. Maybe even an optional ownership model as well.

Looking forward to autofree and optional ownership