Does the standard library use GC?

[Jengro777]

The V standard library shouldn't use GC, as that would impose significant limitations on developers using the V language.

Of course, you can use it temporarily for now and gradually transition to using unsafe and autofree once autofree is mature enough to completely remove GC from the standard library

[medvednikov]

No. You can use it in any app with -gc none.

[JalonSolov]

GC is the default, since most people will never need anything else, but for those who know what they are doing, there is -gc none which can be combined with -autofree, -prealloc, etc.

[Jengro777]

V's standard library doesn't use GC, so V itself has a very high ceiling. If the standard library starts using GC, V's future ceiling will be much lower

[JalonSolov]

That is not what was meant. If you do not use -gc none, then ALL THE CODE uses gc, including the standard library. If you do use -gc none, then NONE OF THE CODE uses gc, including the standard library.

[LukyGuyLucky]

It was told that at current stage -gc none will possibly lead to memory leak,is this still true as of today?

[medvednikov]

If you don't free the memory, of course. -gc none means 100% manual memory management.

[LukyGuyLucky]

Sorry,no,what I understood is,if -gc none turns on,there could possibly be memory leak in std.Is this true,or just a misunderstanding of the whole context?

Thanks.

[JalonSolov]

If you use -gc none, and do not free memory yourself, then yes, there will be memory leaks. Many of the standard library routines allocate memory then return it to the caller. It is the caller's responsibility to free that memory if they compile with -gc none.

[Jengro777]

To be precise, it should be

v -autofree -gc none .

The most important memory security concern should be this

---

In fact, too many people expect v to have the same Rust-like compiler memory safety capabilities.
The current syntax of v also has the potential to implement similar features.

[Wajinn]

Autofree, as it is now, is suppose to work with the GC. Autofree may take care of upwards to 90%, but there can still be a percentage that needs to be taken care of by the GC, depending on the program. -gc none, at this time, is arguably for advanced to expert users that truly need it, totally understand what they are doing, and are comfortable with manual memory management.

For autofree to work in the way that you are suggesting, that of which is not taken care of by it, needs to be identified in some way or reported on by the compiler.

That is where vlang's new optional ownership could come in, being a set of rules that the compiler checks, and then alerts the user of any issues.

[Jengro777]

No. You can use it in any app with -gc none.

  v -autofree -gc none  .

This is the real expectation.
What you really want is memory security for the compiler.
There are too many gc languages, but the threshold for rust is too high. What we need is a choice that is as safe as rust but with a slightly less complex syntax

[Wajinn]

v -autofree -gc none
This is the real expectation

Disagree. Arguably, the majority doesn't want to fight with the compiler or rather focus on the application they are making instead of memory management. As a compiled language, vlang with GC, is still quite fast. Great for beginners, intermediate, students, casuals, IT personnel, office workers, etc...

However, I'm in agreement that there is a place for optional ownership, autofree, and manual memory management. Vlang should cover those expert use cases too, to become an even stronger offering.

[quaesitor-scientiam]

After finding a significant performance penalty with default gc and json.encode flexibility is critical to get much faster performance

[Wajinn]

The statement is a bit nebulous, because what is the use case and situation? We can always ask for faster and even faster. But, many users are not consumed by "it must be the fastest ever". Which is often relative to bragging rights, like guys claiming they have the best muscle car times in a drag race. Instead, there is a very significant percentage of users looking at other things, such as: features, libraries available (e.g. UI toolkits, VLS, C2V/Go2V/Py2V), ease of use, overall usability, reliability, etc...

If "flexibility" is about offering clear and different memory management options, where the user can pick the one that best fits their situation (vgc, autofree, optional ownership, arena), then totally agree. As for GC, I'm all for the new vgc being improved too. Now that V has its own GC, it's intriguing as to what can be done with it.

[quaesitor-scientiam]

https://discord.com/channels/592103645835821068/592106336838352923/1531371054709215385