Last time I looked was beginning of 2022, and I read their stdlib implementation and tried the compiler. They advertised their non-GC solution, “auto free”, but it literally didn’t work, your program would just leak. And if you actually look at what they meant by “autofree”, it is a reference counting GC. They advertised Rust memory management ergonomics but without relying on linear types? Their way to do system calls was by running commands in shells.
Unless things changed drastically V lang, as described by their documentation, is a vapor ware.
I'm still waiting for that CS breakthrough to happen - Rust guys will be so mad they spent their time writing lifetime annotations for the borrow checker :)
You can look up vlang.io on web archive and see that it never said GC-less autofree. It actually explicitly said that RC/GC are used for stuff that can't be freed during compile time.
> No. V's memory management is similar to Rust but much easier to use. More information about it will be posted in the near future.
May 2019
> No. V manages memory at compilation time (like Rust). Right now only basic cases are handled. For others, manual memory management is required for now. The right approach to solve this will be figured out in the near future.
April 2020
> No. V manages memory at compilation, like Rust:
vlang.io/docs#memory
August 2023
> You can look up vlang.io on web archive and see that it never said GC-less autofree
Here's a direct quote from the documentation [0] from 2021:
> 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.
So most objects are freed by the autofree engine, and the rest are freed via reference counting. This implies that no objects are freed by the GC, which is exactly what I've said.
Last time I looked was beginning of 2022, and I read their stdlib implementation and tried the compiler. They advertised their non-GC solution, “auto free”, but it literally didn’t work, your program would just leak. And if you actually look at what they meant by “autofree”, it is a reference counting GC. They advertised Rust memory management ergonomics but without relying on linear types? Their way to do system calls was by running commands in shells.
Unless things changed drastically V lang, as described by their documentation, is a vapor ware.
autofree is not reference counting, and it's marked as "not production ready yet" on the website.
You're saying that when Volt and V were first announced, there were no advertised features that were missing?
What about GC-less autofree?
I'm still waiting for that CS breakthrough to happen - Rust guys will be so mad they spent their time writing lifetime annotations for the borrow checker :)
You can look up vlang.io on web archive and see that it never said GC-less autofree. It actually explicitly said that RC/GC are used for stuff that can't be freed during compile time.
> Is there garbage collection?
March 2019
> No. V's memory management is similar to Rust but much easier to use. More information about it will be posted in the near future.
May 2019
> No. V manages memory at compilation time (like Rust). Right now only basic cases are handled. For others, manual memory management is required for now. The right approach to solve this will be figured out in the near future.
April 2020
> No. V manages memory at compilation, like Rust: vlang.io/docs#memory
August 2023
> You can look up vlang.io on web archive and see that it never said GC-less autofree
1 reply →
Here's a direct quote from the documentation [0] from 2021:
> 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.
So most objects are freed by the autofree engine, and the rest are freed via reference counting. This implies that no objects are freed by the GC, which is exactly what I've said.
Please stop gaslighting people.
[0] https://web.archive.org/web/20210315092012/https://github.co...
15 replies →