Can someone familiar with recent V developments comment on this? It makes bold promises that would be awesome to see realized, but I got the feeling there was just a lot of smoke and mirrors going on in the early days.
The big ticket item is the autofree memory management system which promises near C/Rust performance and minimal overhead without the complexity of borrowing and ownership. To date, this system does not work and is "wip" as the vlang community likes to say. There are also no clear explanations of how it works beyond just "it inserts calls to free() when you are no longer using a variable" which is ... extremely obvious. The more interesting question of how the compiler determines something is no longer being used in the face of aliasing and no borrowing system is completely unanswered. No one working on the project understands how complex that problem is. Initially the goal was that this system would manage all memory for the programmer automatically, this goal has since moved to "manage 90% of objects in memory and use GC for the rest". I suspect we will see that number continue to drop as the author realizes this is intractable without whole program analysis (which they can't do and still hit their compilation time targets).
Other items are very much in an alpha state if they work at all. Only in the last month have you been able to create a generic function with more than one type parameter, although V has been claiming support for generics since at least last year. There's still no ability to constrain the type parameter to something that implements an interface/trait/protocol.
C2V, another wildly ambitious project that could literally be a PhD project in automatic language translation, was supposed to be released "this week" 5 weeks ago. It's currently in a very private alpha and no source has been released.
Which is basically the state of most of the author's projects: huge promises in terms of features and performance with most of them little more than demos. I've come to believe this is an intentional strategy by the author to maximize his Patreon revenue. He makes big promises on social media and then delivers the easy 20% of the project to his followers before switching to another project. It would make far more sense to release a finished project before starting another massive one and yet he can't sit down and finish a project because he knows he can't actually deliver what's been promised.
> I wish people stopped approaching language design from the point of view that the people who have been working on garbage collection for the last 60 years are all idiots who don't see how simple it all is.
The classic example would be MongoDB and other NoSQL solutions etc. in the early days. We can be lightning fast compared to these RDBs! Clearly they're idiots, as is anyone that uses them!
Oh wait, what? You mean it's hard to actually work with data durably, and that not doing so is the main reason we're faster... crap.
Edit: I was wrong about the location but that does not change my opinion.
A demo of autofree with zero GC/RC:
https://www.youtube.com/watch?v=gmB8ea8uLsM
> Other items are very much in an alpha state if they work at all.
Can you list items that don't work at all or are in alpha state?
Generics missing some advanced features like protocols doesn't mean they don't work.
And no I don't live in Sweden. You seem to get a lot of things about V wrong.
Nothing, as I expected.
Since you want it so much, here you go:
- "No undefined behavior" -> How does V prevent this? V currently can't even generate well formed C code for all valid V so how do you prevent UB in the generated C? As of now, for any reference x in V, *x and ******x are both accepted by the checker. int32.MAX + 1 is instant UB yet V does nothing to prevent this. What is your plan to prevent UB in the generated C?
- Generics -> The example shown in your own docs expresses how "wip" this is (https://github.com/vlang/v/blob/master/doc/docs.md#generics). Why is `T.name` allowed? `T` can be literally anything since there is no constraint on it. You're obviously deferring type checking the function until it's monomorphized which is far more like C++ templates than "generics". How do you plan to deal with template bloat slowing down compilations?
- -usecache -> Another one of the 20% implemented features. This was done to give V a huge boost in compiling simple programs but the implementation is so busted, you yourself disabled it on the benchmarking site.
- "go" keyword -> From your docs: "V's model of concurrency is very similar to Go's. To run foo() concurrently in a different thread, just call it with go foo()". At least you've documented it but have completely buried the lede that unlike Go, `go` spawns an OS thread not a green thread. Speaking of green threads, how do you propose to keep the efficiency you claim ("within 3% of C") while still having transparent C interop? Are you going to use segmented stacks to allow 100,000s+ green threads and then run into the same issues Go has calling into C or are you going to larger stacks to make C interop feasible which limits how many green threads you can run before using enormous amounts of memory?
- "immutable" references -> As shown on Discord, "immutable" references can easily by laundered into mutable ones by assigning the reference to a mutable variable and then assigning into that.
- native backend -> Can handle hello world and programs that use string interpolation. Given that it can't handle the average 100 line V program, you should not be extrapolating the performance of 1,000,000 V programs.*
autofree was placed a bit lower on the prioritization list due to the focus on C2V and amazingly well integrated -gc boehm, which solves all leaks for now.
- "No undefined behavior" -> How does V prevent this?
By not having UB. You have any examples of UB in V?
`x and *x` type checker bug in the compiler means the compiler doesn't work? Then by this definition none of the compilers do, because all of them have bugs.
> How do you plan to deal with template bloat slowing down compilations?
Is that your example of an alpha or a broken feature?
> - -usecache -> Another one of the 20% implemented features. This was done to give V a huge boost in compiling simple programs but the implementation is so busted, you yourself disabled it on the benchmarking site.
No I didn't. V hello.v uses -usecache. And v self was removed for now because it's unfair: V modules are in vlib, all of them get cached, and the compilation is too fast. How is it 20% implemented?
> - "immutable" references -> As shown on Discord, "immutable" references can easily by laundered into mutable ones by assigning the reference to a mutable variable and then assigning into that.
Not anymore, a large amount of these bugs have been recently fixed.
Native backend is being worked on by a very experienced developer, author of radare2, so we will definitely see v self -native work this year.*
It’s rather sad to see people get roped in by these claims. This project is a true example of how far pushing false promises and lies can get you and it makes me a bit sad about the world.
This can be verified via web archive.
This has been the only mention of Nim.
What claims are false?
You make very big accusations ("a lot of false claims about itself but also other existing programming languages", "a true example of how far pushing false promises and lies can get you and it makes me a bit sad about the world"), and yet you can't provide examples of such claims and lies.
Sorry, but you can't flip a critic into a productive community member by calling them angry. If you want help building community, you need to inspire trust with a kickass product that meets or exceeds your promises
Critics fall away when they can't find valid criticism; browbeating and blocking them will only amplify the criticism. I see crap like this on almost all vlang-related posts. Y'all won't beat the drama with your current approach.