Emerging Rust GUI libraries in a WASM world
221–230 of 272 posts
Re: Emerging Rust GUI libraries in a WASM world
#222Re: Emerging Rust GUI libraries in a WASM world
#223Re: Emerging Rust GUI libraries in a WASM world
#224Re: Emerging Rust GUI libraries in a WASM world
#225Re: Emerging Rust GUI libraries in a WASM world
#226Earlier quoted context omitted.
I remember looking into V last year, it seems most of the discussion surrounding it was that it was vaporware. Is that not the case? It certainly looks nice, but is it ready for use?
The main issue was that V promised automatic memory management like Rust, but without the "trouble" caused by the borrow checker, which is something anyone who knows about the problem more deeply would laugh at.... last I checked, they were still at the same stage as a few years ago with that: "it will be working soon". It will almost certainly always stay there.
The situation (as I understand it) is unlike using a GC, autofree requires the user to have knowledge of memory management and how to use it properly. One of the objectives of Vlang is to be easy (easier) to use. Using a GC as the default, proved to perform very well with the language, and presented less complications for users.
It appears the strategy of the Vlang developers (as stated on their website and documentation) is to go with flexible memory management. That is the GC can be turned off whenever the user wants (-gc none), and other memory management options can be used such as autofree (-autofree) or their arena allocator (-prealloc).
This flexible memory management strategy would be somewhat similar to what Nim did, and interestingly, I don't see people crying as much about it. Furthermore, there is more to Vlang as a programming language than just autofree, as if its the only thing that counts. People use it for many other reasons.
1. https://www.youtube.com/watch?v=gmB8ea8uLsM (Autofree demo) 2. https://www.youtube.com/watch?v=mJG4Zg6Ekfw (Vinix OS)