I am betting on Vlang instead. Rust is too complicated for an average person - like me. It's basically the Haskell of system programming. V is basically Go made right.
It's sorely lacking Haskell features, I have sometimes written functions to simplify my code to find out the function signature is several lines of code and MUST use references
fn apply<A, B, C, G>(mut f: impl FnMut(B) -> G, a: A) -> impl FnMut(&B) -> C
// must still be `for<'r> impl FnMut(&'r B) -> C`, because that’s what filter requires
where
G: FnMut(A) -> C,
B: Copy, // for dereferencing
A: Clone,
{
move |b| f(*b)(a.clone()) // this must do any bridging necessary to satisfy the requirements
}
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 problem is that although the creator is gifted, he seems to not have much theoretical PL design knowledge. That is an issue for something as complex as this; this automatic memory management without a GC is cutting edge research and we don't know if we can make it work without making sacrifices like Rust did. You have to sacrifice something and that means while you won't have to worry about memory management, the work for the programmer becomes harder. Or just use a GC.
Vlang is worked on by a large group of different developers, not just the creator. It seems this gets lost in a lot of narratives, as if it's a one man show. If you check V's GitHub, it's clear to see they have many contributors and developers who are professional programmers or have extensive backgrounds.
Autofree already works (to a significant extent) and has been demonstrated[1], for years now. Vlang's Vinix OS[2] uses autofree.
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.
Everybody is trying to make a more user-friendly Rust. The problem is that it is not clear yet whether that's possible, and if it is, how it may look. I know Vale and have tried it, though it's extremely early to judge anything so far. It does have a much stronger theoretical background than V, but even the theory is not completely clear at this point.
People should be allowed to have a difference of opinion and like other programming languages, without a swarm or mob of evangelists going on a downvoting party. If others like Rust or Go, that's their preference, but it's not necessary to bully other programmers.
Lots of people like Vlang, so better to accept that. Not everybody is going to prefer or think the same in regards to programming languages.
