As a Go programmer I think I already know V
C++ smart pointers (unique_ptr and shared_prt) exist and have existed in the standard for over a decade now (2011) and have existed in the boost library for almost 2 decades (2004). They handle the freeing for when the variable goes out of scope. Yes you can also use manual new/delete and manual malloc/free but you only rarely actually have to do that and usually shouldn't do that.
Been following it for a few years now, and it doesn't ever seems to be moving along as quickly as its claims do. Pretty uninteresting when the field is filled with so many great languages currently.
Very interesting! I'm also wondering how the autofree works. I'm a little concerned that it conceals potential leaks by circular references without the user knowing from just looking at the code. Or just very late freeing of objects.
It's like Go and Rust had a baby – very slick language, I really dig its design! Very smart and pragmatic choices all over the place! Thanks so much for the intro, I learned a lot and might give it another shot! I had a look a couple of years ago, it was already very promising back then but it still was very immature.
Now that you mention Nim, I really feel it deserves a lot more attention, hopefully you can dive into it with some practical examples.
Thanks for trying V, and for the unbiased review about it.
Hmmm, I did not know, it appears to have some curious problems with this approach of using ref-counting automatically, it makes the code very less explicit than it proably should be, and I wonder if the switch from autofree to manual memory management wouldn't hurt a lot when people actually need to change. It is surely an interesting language, but I think it is not, at least for now when it is not stable yet, worth learning more than other already working languages, maybe in the future it could be great.
Nim also has ARC memory management that's becoming default in 2.0 (current devel).
Swift / Obj-C are great examples of ARC that really, really work. It's totally possible, although I'm sure it's tricky to get right
Doesn't look that interesting to me tbh. I didn't really see something that really sets it apart in a useful way and the syntax seems worse. Explicitly capturing and using fn keywords for closures & lambdas are annoying to me.
I'd stick and improve my skills with Rust than learning another language.
That's a really good video, keep it up!
Apple platforms with Objective C and Swift have had ARC (automatic reference counting) for a decade. before that, Objective C had manual reference counting with semi-automatic reference counting using autorelease pools. the LLVM front-end, Clang, inserts allocs and deallocs into the code on your behalf with each trip through the compiler, not as part of your source code. No performance hit above what manual memory management would cost you otherwise, and autorelease pools would in many circumstances improve performance by allowing you to use/reuse local memory pools (say, within tighter loops) that you could free up upon exiting scope or keep around but clear out if you know you're going to reuse it. But like I said, a decade or more.
I'd really like to see a Nim video. For some intangible reason, I feel like Nim is more solid than V. I think maybe it's because the tutorials just didn't compile or behave as advertised when I went through them. I wasn't able to get Doom to work, etc.
A lot of people saying it's like Go++ but if it doesn't have the Go standard library, it's more like Go--
It is just straight up incredible how fast V developes, literally a year ago and there was like nothing, almost no docs and such.
A huge problem I see with V is target audience. If I'm okay with slight performance compromises (garbage collection/autofree) I can use Go or target WASM. If I need C-like performance I want full control over memory management, which makes Zig or Rust preferrable. How is V supposed to compete? Also, autofree is a huge challenge and will likely influence the language's design, delaying it in favor of GUI features etc seems like a questionable order of priorities.
V doesn't really have anything that makes it better than other langs in particular, and the community just keeps, for years, saying "X feature will be there" to the actual useful ones that the people wanted to begin with. And then when the devs instead add features that should be external libraries, just totally neglecting the things they said they'd implement, the community just keeps coping, calling people trolls for questioning, and acting like they put their life savings down on V because they thought it would be the next big employable language. It has no use case. It might if it could do what it says it wants to, but it does not.
@codetothemoon