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.
The developer doesn’t need to change anything in their code. “It just works”, like in Python, Go, or Java, except there’s no heavy GC tracing everything or expensive RC for each object.
How are cycles handled, especially if the code does not require any special handling? The documentations only says that this is still work in progress and currently a garbage collector is used by default.
For developers willing to have more low level control, autofree can be disabled with -manualfree, or by adding a [manualfree] on each function that wants manage its memory manually. (See attributes).
Note Autofree is still WIP. Until it stabilises and becomes the default, please avoid using it. Right now allocations are handled by a minimal and well performing GC until V's autofree engine is production ready.
Even if it’s compiling the entire compiler in 0.7 seconds it’s certainly not generating good code. Even then it’s dubious and likely skipping semantic checks, etc.
It's also worth noting that way back when, V could compile itself in almost 0.1s[0]. Now it's 7x slower. Of course, 0.1s -> 0.7s is very different than 10s -> 70s, but I think it is just another example of how programs start lightweight, but end up weighed down very, very quickly. What will V look like when all the promised features actually work?
The Rust compiler only takes 45 minutes to build if you're also including the time to build LLVM from scratch. Given that the page mentions V's "Clang backend" and later asserts that Clang takes one hour to build, that means that it's fair to say that the V compiler builds itself in one hour and one second.
Somehow V conveniently left out its closet competitor D language where DMD, D's reference compiler can compile itself and the entire standard library in less than 5 seconds with parallelism turned off [1].
[1] Ask HN: Why do you use Rust, when D is available?
I'm not understanding this post. "V" didn't make that post on devtalk, it was DevotionGeo. So "V" didn't leave out anything nor are they obligated to post and explain about competing languages.
Not understanding how some detractors are so desperate to attack a competing programming language, that they would take a post from April 2021 (more than 2 years ago), and use it as a pretext to bash it on HN.
If a person is that offended or disturbed that others like a different language, just leave it be, and go play with what you do like. Different people, like different languages, time to accept that.
My post might get downvoted into oblivion for daring to speak out about such bullying and odd behavior, but somebody has to speak out when such wrongs are being perpetrated.
I install mob branch changes automatically via cronjob, and use it as my dev compiler. It's about 10x faster than gcc/Clang with -O0, and thus finds errors much faster. Not many warnigs, but good enough
The developer doesn’t need to change anything in their code. “It just works”, like in Python, Go, or Java, except there’s no heavy GC tracing everything or expensive RC for each object.
How are cycles handled, especially if the code does not require any special handling? The documentations only says that this is still work in progress and currently a garbage collector is used by default.
For developers willing to have more low level control, autofree can be disabled with -manualfree, or by adding a [manualfree] on each function that wants manage its memory manually. (See attributes).
Note Autofree is still WIP. Until it stabilises and becomes the default, please avoid using it. Right now allocations are handled by a minimal and well performing GC until V's autofree engine is production ready.