5 ms·

There were no close to impossible/missing features.

richbell 3y ago
You're saying that when Volt and V were first announced, there were no advertised features that were missing?
bheadmaster 3y ago
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 :)
- amedvednikov 3y ago
  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.
  - bheadmaster 3y ago
    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.com/vlang/v/blob/master/doc/docs.md https://web.archive.org/web/20210315092012/https://github.co...
    - deleted 3y ago
      [deleted]
    - amedvednikov 3y ago
      What's written is correct, what's the issue again? RC was later replaced with a tracing GC. RC is a type of GC btw, so...
      - bheadmaster 3y ago
        > What's written is correct, what's the issue again? The fact that the feature promised is impossible. I'm quoting some comments from which this whole discussion has started, since you don't seem to be able to follow: > dgellow: They got lot of push back because what the core devs were describing Vlang to be was technically close to impossible > amedvedikov: There were no close to impossible/missing features. Static analysis (autofree) with reference counting, by itself, cannot theoretically free all of the objects during the runtime of the program. And I know that you know that since you've made the decision to switch to a tracing garbage collector. The choice of tracing garbage collection makes the initial claim much less impressive and innovative - Go already has escape analysis, which is basically an implementation of autofree. But Go used a garbage collection from the start, so escape analysis is just an optimization - exactly what autofree is for the current V with GC. V promised something impossible, it's not a big deal, we all make technical mistakes and learn from them. What makes it a big deal is your stubborn attempts to rewrite history and gaslight people.
        amedvednikov 3y ago
        > Static analysis (autofree) with reference counting, by itself, cannot theoretically free all of the objects during the runtime of the program. It can't, that's what it says on the home page. Stuff that can't be freed during compile time is handled via GC. What's the issue again? What's the impossible claim?
        bheadmaster 3y ago
        > It can't, that's what it says on the home page. Stuff that can't be freed during compile time is handled via GC. The documentation I've quoted and posted a source to specifically says that all objects are freed either by 1) autofree or 2) reference counting. > What's the impossible claim? The impossible claim is that all objects are freed either by 1) autofree or 2) reference counting. As I've mentioned, neither static analysis (which is what autofree is) nor reference counting is capable of completely freeing all unreachable objects at runtime - reference counting is in particular unable to handle cyclic references. > What's the issue again? The issue is you vehemently claiming that V has never, ever promised a feature that was impossible - which is false, as I've demonstrated and cited with reference to archive.org of V lang documentation. So can you stop doing that, please?
  - lvl5hm 3y ago
    > 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
    - amedvednikov 3y ago
      Nowhere in your quotes does it say GC-less autofree. "The right approach to solve this will be figured out in the near future." And it was figured out, and we now have what we have. It's described on the home page in detail. 4 ways to handle memory. Why another new account?
dgellow 3y ago
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.
- amedvednikov 3y ago
  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 :)

amedvednikov 3y ago
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.
- bheadmaster 3y ago
  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.com/vlang/v/blob/master/doc/docs.md https://web.archive.org/web/20210315092012/https://github.co...
  - deleted 3y ago
    [deleted]
  - amedvednikov 3y ago
    What's written is correct, what's the issue again? RC was later replaced with a tracing GC. RC is a type of GC btw, so...
    - bheadmaster 3y ago
      > What's written is correct, what's the issue again? The fact that the feature promised is impossible. I'm quoting some comments from which this whole discussion has started, since you don't seem to be able to follow: > dgellow: They got lot of push back because what the core devs were describing Vlang to be was technically close to impossible > amedvedikov: There were no close to impossible/missing features. Static analysis (autofree) with reference counting, by itself, cannot theoretically free all of the objects during the runtime of the program. And I know that you know that since you've made the decision to switch to a tracing garbage collector. The choice of tracing garbage collection makes the initial claim much less impressive and innovative - Go already has escape analysis, which is basically an implementation of autofree. But Go used a garbage collection from the start, so escape analysis is just an optimization - exactly what autofree is for the current V with GC. V promised something impossible, it's not a big deal, we all make technical mistakes and learn from them. What makes it a big deal is your stubborn attempts to rewrite history and gaslight people.
      - amedvednikov 3y ago
        > Static analysis (autofree) with reference counting, by itself, cannot theoretically free all of the objects during the runtime of the program. It can't, that's what it says on the home page. Stuff that can't be freed during compile time is handled via GC. What's the issue again? What's the impossible claim?
        bheadmaster 3y ago
        > It can't, that's what it says on the home page. Stuff that can't be freed during compile time is handled via GC. The documentation I've quoted and posted a source to specifically says that all objects are freed either by 1) autofree or 2) reference counting. > What's the impossible claim? The impossible claim is that all objects are freed either by 1) autofree or 2) reference counting. As I've mentioned, neither static analysis (which is what autofree is) nor reference counting is capable of completely freeing all unreachable objects at runtime - reference counting is in particular unable to handle cyclic references. > What's the issue again? The issue is you vehemently claiming that V has never, ever promised a feature that was impossible - which is false, as I've demonstrated and cited with reference to archive.org of V lang documentation. So can you stop doing that, please?
- lvl5hm 3y ago
  > 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
  - amedvednikov 3y ago
    Nowhere in your quotes does it say GC-less autofree. "The right approach to solve this will be figured out in the near future." And it was figured out, and we now have what we have. It's described on the home page in detail. 4 ways to handle memory. Why another new account?

dgellow 3y ago

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.

amedvednikov 3y ago
autofree is not reference counting, and it's marked as "not production ready yet" on the website.