ERRATA: At around 7:00, I explain what the vision for autofree is. I say that it aims to automatically distinguish between cases where something needs to be deallocated at the end of the scope it was defined in, and cases where runtime reference counting is needed. But I skirted over one of its core value props - and that is that it aims to determine at compile time when memory is no longer needed and deallocate that memory, even when that place is not in the same scope where the memory was allocated. The claim is that it can do this *without* a runtime reference count in the vast majority of scenarios, but will fall back to runtime reference counting in the cases where it can't.
Objective C has been around for nearly 40 years and for most -- if not all -- of its lifetime it's had the autorelease that the dev invokes manually. The boundary conditions are pretty clear: values declared in local scope / stack that are not assigned to references that exist beyond that scope. In ref-counted systems, it's a +1 ref count followed immediately by a -1 so that it's at 0. then when scope ends, it gets freed.
@@godofbiscuitssf Right - I think the novel thing here that memory is freed when it is no longer needed, even if that is prior to or after the end of the scope where the memory was allocated and even if there are multiple references to it - in many cases without even needing an RC.
@@codetothemoon does this differ to ARC in Swift and Objective C? Because I was describing the situation before ARC came along. ARC has been around quite some time now.
Thanks! I actually took a brief look at Crystal in the video "Rust vs 7 other languages you probably haven't tried". I was extremely impressed with it during the brief time I used it, i'm hoping to get more time with it at some point.
3:40 that looks a lot like captures in c++ lambdas. Looking at the doc's they are similar just that they don't support wildcards and are always capture by copy. The docs for function captures also showcase that references in V are in themselves also basically just pointers that if you copy you get another reference instead of a copy of the underlying object which I don't really like.
I'm confused as to why you said that it converts C to V while you showed C++, and what's more is the output didn't actually match the input functionally. The V code built up a string and then printed in one go while the C++ printed as it went. As for V itself, it just looks like a less awful syntax version of Rust. One of the things I hate about Rust is the inconsistency in syntax, but the manual interventions you have to take as the programmer that C++ doesn't make you take really irks me. I've always hated C++, despite loving certain features, but the more of Rust I learn and the more of the source code for its implementation I read, the more I despise Rust. In fact, the more I learn of other languages, the more I appreciate the cold, calculating consistency of C++. It's butt ugly, but it does a lot right that other languages really screw up. That said, I still prefer C over everything else and use it for nearly every personal project.
I also call bullshit on the autofree feature. This would require some kind of global lifetime analysis which is exceedingly difficult and would drive up compile times significantly. And most likely it's not even superior to a modern GC.
I was so excited about language but totally lost interest after realizing that it doesn't have a good memory management and it's not clear what they are really doing about it. I switched to Rust and it's good.
I am very interested to see how the V project goes. I like Go and Rust, and V seems like awesome meeting of the two. We'll see if the project leaders can persevere to bring V into the full vision they lay out. But I am watching this project very eagerly. Thanks for this video. Was interesting
V tries to hide some memory things to make it easy for the programmer, but in fact, hiding things is worse, it complicates even more knowing who owns data, and no hidden control flow, is awesome
Funny, semicolons are one of the things I dislike most about Rust. I've been curious about why some languages have them and others don't. Why do you like them?
@@codetothemoon I like semicolons because it lets me split up a statement into multiple lines. So it's less about the actual semicolon and more what it lets me do. It doesn't have to be a semicolon, or even work the same way, as long as I can split up a statement with multiple methods for example, into multiple lines, then I am happy!
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.
From what I found on the reddit discussion and other places in the internet, that's the current situation, at the moment it cannot guarantee that no leaks will happen for a 100% of the cases (although that's the goal), that's why the --autofree flag ships with the GC anyway for that 10% of the cases when autofree missed some borrowing at compile time. There's also a discussion (not for v specific) about optimized, multi-core GCs that could outperform by miles the current implementations, which could mean that this current mix of autofree and a gc might not even be a bad choice, as that could work best for cases where memory deallocation occurs frequently. Ultimately, the goal would be to find a balance between performance, predictability, and ease of use.
wouldn't fault you for doing so! there's definitely a cost associated with always diving into the bleeding edge stuff that has an uncertain future. There's something to be said for keeping your focus on one thing and not getting distracted!
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.
@@SkyyySi shared_ptr is ref-counted, but unique_ptr isn't, and only uses language features (destructor, deleted copy ctor, custom move ctor) to implement it's functionality
@@chiragsingla. relatively new to the standard but atomic shared pointers also exist. They were added as a TS in 2016 introduced into the main draft in 2017 and are in the standard as of C++20. Also if you can't use C++20 for a project boost has also had them since at least 2017
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.
I had exactly the same thoughts. It looks syntactically similar to go and got some variables from Rust. Since it is transpiling to C code, it could be potentially used for bare metal programming in a go-style.
Am I the only one who thinks this video is going a bit too fast? Great content but it would be nice to see the code at the end for a few seconds before it cutting away to the next part. Had to watch it in .75 speed and pause constantly
I don't think you're the only one. It's very tricky getting the pacing right so that folks stay engaged but the video doesn't become confusing. Probably one of the most difficult aspects of doing YT 😕
@@codetothemoon you should leave a 0.5-1 sec part before transitioning/sliding to the next part of the video.I can t even read the code on the screen and listen to the talk without pausing the video.
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.
@@leeroyjenkins0 I don't think people would add it to rust. The solution that's described in the video would have a serious runtime impact, and making it a default in rust would go against the language's philosophy. That being said, a Rust version of Rc that automatically optimizes away the Rc would be nice, and would lead to an easier experience using the language for newcomers. Or maybe a clippy warning that an Rc can be optimized away manually.
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.
This is interesting - I'm guessing they only add reference counting where needed. Given that, I'm curious whether they handle some of the tricky scenarios where reference counting actually isn't needed, but maybe a naive compiler would think it is needed.
There is a published book by Manning on Nim: “Nim in Action”! I Think this is a sign of its maturity. I liked V at first sight, but I also had an impression it’s memory management was not fully implemented yet! I got quite suspicious after that (3 years ago). On the other hand I reckon that Nim is already used in commercial projects. But as a Java developer switching tech stack, I’m focusing all my energies on Go: a much safer bet than Nim or V.
Thought I'd heard of all the new bleeding edge languages at this point, but this is the first I've heard of Koka. Thanks for the mentioning it, I've added it to my "to check out" list!
@@codetothemoon To me Koka seems like a purely functional Rust. If I'm being honest some of what I've seen goes straight over my head but it has some amazing ideas.
The BFDL is a total ass. He's rude ti anyone who criticizes its design and can't even accept healthy criticism. This cannot lead to a healthy community. Shame, but I've followed Vlang since its announcement but refuse to use it. It doesn't even provide anything unique.
Unfortunately you're not the first one I've heard this from :( regarding uniqueness though - I think it may depending on how it winds up implementing autofree
Yeah, V is a great language but unfortunately has the most bizarrely toxic community I've ever seen for a programming language. It's odd and very discouraging. A lot of V coders have this up-on-their-high-horse mentality, which you see in most language's userbase, mostly jokingly, but with a lot of V users it feels like it like it's coming from a genuine place of perceived superiority. And again, V itself is a fantastic language... but man, they got more toxic members in their community then any other language I've seen to date. It's all so weird and off-putting. I'd encourage everybody reading this to give V a genuine try, it's worth your time... Just mind yourself around the online communities that have sprout out around it. Some of them can be pretty unhinged. It's why I stay a lurker.
@@codetothemoon I see the GC as a problem, but I don't see the borrow checker as a problem. I think we should be aware of our usage of heap and the stack. It gives me hope of how languages are iterating over concepts to get ride of the GC which are not manual requests of memory. But being completely unaware of it seems like a step in the wrong direction for me.
This is interesting - I wonder if there is a gap between what they do and what autofree aims to do. Because I think they have acceptable performance but definitely aren't known for top tier performance.
wait is that the language that promises a ridiculous amount of stuff that is literally impossible and delivers on nearly none of it? The one that feels like a cult?
It definitely seems to have that reputation with some folks. I won't defend the alleged false claims they've made (I actually haven't even looked into them). All I can say is that my experience in my brief time experimenting with it was positive overall. Though I do have concerns with respect to the feasibility and completion of autofree.
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.
@@holthuizenoemoet591 You can. But then what's the point of a language that doesn't provide actual value? Not that autofree does this anyway. But the syntax is nothing to run home for. So what is?
V is compiled to C so every lib written in C can be used in V and (almost) be converted to V. Development time is very fast and you can learn everything of the language in an hour
I work in cyber security and the language helps me write code fast like python, but with the performance and control of C.Also inline assembly code is a plus for me.
it could be usefull in science where you want quick prototyping but also dont necessarily want to deal with the slowness of some interpreted languages (I am looking at you Python)
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.
haha! yeah i think the next logical step would be to do a deep dive comparison of V and Go, and take a look at language features, performance, ecosystem, etc. When I made this video I didn't realize the full extent of V's similarity to Go
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.
V borrows so many concepts and syntax from Go ... the author should have learned Go before discussing it. One could say V is an evolution of Go, adding some missing concepts, and fixing (?arguably?) some stuff.
yeah I had heard it was similar to Go, but I didn't fully realize how much it borrows from Go until I watched the Primeagen's reaction to this video. So many places where he said 'ok so it's just like Go', where the similarity was unbeknownst to me
Personally I think zig has more promise because the creators behind v seem to be somewhat hostile towards their own community. As you highlighted at the end of the video, there have been quite a few controversial decisions with this language. The thing is, autofree doesn't actually seem that farfetched if the compiler can assign lifetimes to variables under the hood. In this way you'd effectively have ownership but you wouldn't have to worry about the borrow checker because the compiler would determine if the object can be dropped by scope or if it needs reference counting. That being said, I'm not confident in the v contributors to be able to properly implement this feature. Zig on the other hand has multiple memory management schemes and it has already delivered on a lot of the promises that the language originally promoted. Another language that is really exciting in 2023 is ocaml. There have been so many cool editions to that language recently which make it very appealing for anybody who uses rust or go.
As a go programmer I already feel entitled to try it, thanks for such a detailed video. Also, what colorscheme are you using in your editor? Monokai? Looks so calm and classy.
haha i think there will always be new bleeding edge languages to check out, sometimes it's hard not to get distracted. I'd stick with Rust for the time being :)
Autofree will likely have problems just like garbage collection. The performance of a program will depend on V compiler version, where some values are stack allocated, heap allocated etc. Golang does the exact same thing with its analysis, golang and V are on the same playing field.
I think the goal of autofree is to not have the same performance issues as garbage collection, remains to be seen whether that will be achieved. Re: Golang, regardless of the static analysis done at compile time, you'll still have the overhead of the garbage collector right?
@@codetothemoon If you don't create pointers in Golang there's no garbage to collect, and if compiler detects with escape analysis that variables can be freed in the same scope it essentially becomes stack allocated, essentially what happens in autofree. I don't think there's any real solution to Rust's ownership model today.
hah! the problem exists in the other direction too - work without semicolons for awhile and try to go back to Rust or Java and... yeah. I highly recommend checking out Kotlin if you live in the JVM world (no semicolons there either though!)
Last time I used it, year ago or so, it compiled not working code, even if syntactilly it was correct. Telling from various readmes that list projects in V it is ORM, GUI and freakin Linux replacement and others. Without fully working and documented compiler. What the hell went wrong
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.
At 7:00 I left out a key piece about what's I think is novel about autofree, as compared to the languages you mention. Check out the pinned comment - basically I think (again, the documentation on this is harder to come by than it should be) it aims to also do something like Rust's borrow checking and ownership changes, but without requiring the developer to be involved in them. Long story short, I believe the aim is to take some of the cases that would require RC in the languages you refer to, and eliminate the need for that RC. Without this, I'm not sure if there would be much to see here.
With Arduino it shouldn't be a huge issue. However with ESP-IDF it might be a bit difficult adding bindings for all the IDF functions especially considering that the available functions change depending on the IDF config. It should be possible as we also see with Rust bindings. But some features might be unavailable without falling back to C and the IDE support might not be great depending on how the tool chain will handle that case.
Controversy is mostly egotistical and rarely informative. Solutions and Actionable responses are the only respected forms of controversy, but usually you have to dig deep into reddit replies to find those helpful comments.. V syntax looks very welcoming. Can anyone actually tell me from experience if V fails to deliver on it's claims? I want to know!
C with colsures. All the other features look great but that's all I need. All it needs now is a repl like Holy-C has. Then it would be good enough to take over an operating system.
0:38 "Looks like Go..." Hmm, yeah, looks like Go except kinda oxidized, converting the semireadable fragment "func" to an unpronounceable utterance "fn" and requiring every variable to be prefixed with "mut" to vary.
I hate having to explicitly declare a field as required, as opposed to explicitly declaring a default value. It's so much cleaner if you know exactly what a field's default value would be if you don't specify it otherwise on initialization. The required keyword feels exactly like the bolted on solution they are currently adding to C#.
@@petrmakhnev4037 That's great but I still feel like the default behavior of having an initialized struct while some fields or all its fields can remain uninitialzied, is bad default behavior.
I'd have to agree with you for the time being. But if autofree makes good on its vision, I can see a scenario where I'd prefer switching from those (and I'm a huge fan of Kotlin and Scala) in places where it'd be a good fit.
ERRATA: At around 7:00, I explain what the vision for autofree is. I say that it aims to automatically distinguish between cases where something needs to be deallocated at the end of the scope it was defined in, and cases where runtime reference counting is needed. But I skirted over one of its core value props - and that is that it aims to determine at compile time when memory is no longer needed and deallocate that memory, even when that place is not in the same scope where the memory was allocated. The claim is that it can do this *without* a runtime reference count in the vast majority of scenarios, but will fall back to runtime reference counting in the cases where it can't.
Don't forget to pin this comment.
@@fionawashere1086 ahh thanks for pointing this out! Pinned.
Objective C has been around for nearly 40 years and for most -- if not all -- of its lifetime it's had the autorelease that the dev invokes manually. The boundary conditions are pretty clear: values declared in local scope / stack that are not assigned to references that exist beyond that scope. In ref-counted systems, it's a +1 ref count followed immediately by a -1 so that it's at 0. then when scope ends, it gets freed.
@@godofbiscuitssf Right - I think the novel thing here that memory is freed when it is no longer needed, even if that is prior to or after the end of the scope where the memory was allocated and even if there are multiple references to it - in many cases without even needing an RC.
@@codetothemoon does this differ to ARC in Swift and Objective C? Because I was describing the situation before ARC came along. ARC has been around quite some time now.
As a Go programmer I think I already know V
exactly, so similar
selective variable capturing by closures is dope, though
The docs say you should
Go++
that was my very same thought when he started coding V.
That clojure syntax is criminal
Yes
Partly looks like Clojure.
Isn't the same as in C++?
Interesting video, although it reminds me a lot of Go, thank you anyways! Could you review Crystal lang next?
Thanks! I actually took a brief look at Crystal in the video "Rust vs 7 other languages you probably haven't tried". I was extremely impressed with it during the brief time I used it, i'm hoping to get more time with it at some point.
3:40 that looks a lot like captures in c++ lambdas. Looking at the doc's they are similar just that they don't support wildcards and are always capture by copy.
The docs for function captures also showcase that references in V are in themselves also basically just pointers that if you copy you get another reference instead of a copy of the underlying object which I don't really like.
as a Go developer this seems pretty promising!
there definitely seems to be a strong Go influence on the language!
I'm confused as to why you said that it converts C to V while you showed C++, and what's more is the output didn't actually match the input functionally. The V code built up a string and then printed in one go while the C++ printed as it went. As for V itself, it just looks like a less awful syntax version of Rust. One of the things I hate about Rust is the inconsistency in syntax, but the manual interventions you have to take as the programmer that C++ doesn't make you take really irks me. I've always hated C++, despite loving certain features, but the more of Rust I learn and the more of the source code for its implementation I read, the more I despise Rust. In fact, the more I learn of other languages, the more I appreciate the cold, calculating consistency of C++. It's butt ugly, but it does a lot right that other languages really screw up. That said, I still prefer C over everything else and use it for nearly every personal project.
Autofree will take decades and decades to be perfect
That appears to be a concern shared by many folks!
I also call bullshit on the autofree feature. This would require some kind of global lifetime analysis which is exceedingly difficult and would drive up compile times significantly. And most likely it's not even superior to a modern GC.
Rust and typeScript are all i need for now
Who does have the better mascot between Go and V?
V
I was so excited about language but totally lost interest after realizing that it doesn't have a good memory management and it's not clear what they are really doing about it. I switched to Rust and it's good.
can't go wrong with Rust. I agree that it doesn't seem ultra clear how they are going to get to where they intend to go in terms of memory management.
I am very interested to see how the V project goes. I like Go and Rust, and V seems like awesome meeting of the two. We'll see if the project leaders can persevere to bring V into the full vision they lay out. But I am watching this project very eagerly. Thanks for this video. Was interesting
me too! My gut instinct is that they have enough momentum to shake off the negative aspects of their reputation if they persevere, as you say!
miss me with that :=
I don’t feel like it has any advantage over Rust and so for that reason I am going to stick with Rust. It already has a massive ecosystem.
V tries to hide some memory things to make it easy for the programmer, but in fact, hiding things is worse, it complicates even more
knowing who owns data, and no hidden control flow, is awesome
golang:
😎
good video
thanks!
No semicolons? Thanks, I'm going to stick with rust.
I like the semicolon freedom from Kotlin and Swift
Funny, semicolons are one of the things I dislike most about Rust. I've been curious about why some languages have them and others don't. Why do you like them?
@@codetothemoon I like semicolons because it lets me split up a statement into multiple lines. So it's less about the actual semicolon and more what it lets me do. It doesn't have to be a semicolon, or even work the same way, as long as I can split up a statement with multiple methods for example, into multiple lines, then I am happy!
@@codetothemoon The semicolons are a way to explicit the end of a statement, it's all but I like the explicit.
Slick video
I like the syntax, but the rest... not really.
understandable - unclear whether "the rest" will fulfill its vision
cpp syntax like, no no no.. i prefer zig
Are the sounds made by your real keyboard? If so, what is it?
i wonder why that matters lol
@@reinhold1616 Cause they are really nice and I want to buy it!
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.
The author of it lied about a lot of it's features iirc
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.
From what I found on the reddit discussion and other places in the internet, that's the current situation, at the moment it cannot guarantee that no leaks will happen for a 100% of the cases (although that's the goal), that's why the --autofree flag ships with the GC anyway for that 10% of the cases when autofree missed some borrowing at compile time.
There's also a discussion (not for v specific) about optimized, multi-core GCs that could outperform by miles the current implementations, which could mean that this current mix of autofree and a gc might not even be a bad choice, as that could work best for cases where memory deallocation occurs frequently. Ultimately, the goal would be to find a balance between performance, predictability, and ease of use.
It leaks in a hello world. This project is vaporware.
@@gagagero Are you talking about a blog post from 2019 or from a recent, 2023 test with autofree+gc?
(currently, it doesn’t)
@@fdimb A friend of mine tested it a few days ago, it leaks.
I'd stick and improve my skills with Rust than learning another language.
wouldn't fault you for doing so! there's definitely a cost associated with always diving into the bleeding edge stuff that has an uncertain future. There's something to be said for keeping your focus on one thing and not getting distracted!
@@codetothemoon Exactly! Thank you.
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.
imo c++ isn’t so bad language as it described by rustaceans , I think it’s easy to avoid memory issues now.
Aren't those using reference counting, though?
@@mister-ace thread safety tho
@@SkyyySi shared_ptr is ref-counted, but unique_ptr isn't, and only uses language features (destructor, deleted copy ctor, custom move ctor) to implement it's functionality
@@chiragsingla. relatively new to the standard but atomic shared pointers also exist. They were added as a TS in 2016 introduced into the main draft in 2017 and are in the standard as of C++20. Also if you can't use C++20 for a project boost has also had them since at least 2017
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.
I had exactly the same thoughts. It looks syntactically similar to go and got some variables from Rust. Since it is transpiling to C code, it could be potentially used for bare metal programming in a go-style.
Am I the only one who thinks this video is going a bit too fast? Great content but it would be nice to see the code at the end for a few seconds before it cutting away to the next part. Had to watch it in .75 speed and pause constantly
I don't think you're the only one. It's very tricky getting the pacing right so that folks stay engaged but the video doesn't become confusing. Probably one of the most difficult aspects of doing YT 😕
@@codetothemoon you should leave a 0.5-1 sec part before transitioning/sliding to the next part of the video.I can t even read the code on the screen and listen to the talk without pausing the video.
@@kivimangoproductions9655 💯 Take your time! I think your core audience is not teens with an attention span for tiktok shorts.
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.
Haskell's function/closure definitions = sublime because everything is a function :)
@@leeroyjenkins0 I don't think people would add it to rust. The solution that's described in the video would have a serious runtime impact, and making it a default in rust would go against the language's philosophy.
That being said, a Rust version of Rc that automatically optimizes away the Rc would be nice, and would lead to an easier experience using the language for newcomers. Or maybe a clippy warning that an Rc can be optimized away manually.
Haha, the mascot is indeed better :D
💯
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).
This is interesting - I'm guessing they only add reference counting where needed. Given that, I'm curious whether they handle some of the tricky scenarios where reference counting actually isn't needed, but maybe a naive compiler would think it is needed.
Now that you mention Nim, I really feel it deserves a lot more attention, hopefully you can dive into it with some practical examples.
absolutely, I'm hoping to dive further into nim. I've only worked with it very briefly but I found it to be very enjoyable
I agree. Nim is a good language. V is promising, but Nim is already good. I think V has the advantage that it’s syntax is very go-like.
There is a published book by Manning on Nim: “Nim in Action”! I Think this is a sign of its maturity.
I liked V at first sight, but I also had an impression it’s memory management was not fully implemented yet! I got quite suspicious after that (3 years ago).
On the other hand I reckon that Nim is already used in commercial projects.
But as a Java developer switching tech stack, I’m focusing all my energies on Go: a much safer bet than Nim or V.
@@a0um There is also Mastering Nim book by the language creator Andreas Rumpf, physical version only. I have yet to get that one.
The koka programming language claims to have achieved something similar to the autofree feature mentioned in this video
Thought I'd heard of all the new bleeding edge languages at this point, but this is the first I've heard of Koka. Thanks for the mentioning it, I've added it to my "to check out" list!
@@codetothemoon the effects system feature that was talked about a couple of blog posts ago in Rust is possible that it originates from Koka
@@codetothemoon To me Koka seems like a purely functional Rust. If I'm being honest some of what I've seen goes straight over my head but it has some amazing ideas.
Thanks for trying V, and for the unbiased review about it.
Thanks for watching! Glad it came off as unbiased, that's exactly what I was going for.
The BFDL is a total ass. He's rude ti anyone who criticizes its design and can't even accept healthy criticism. This cannot lead to a healthy community. Shame, but I've followed Vlang since its announcement but refuse to use it. It doesn't even provide anything unique.
Unfortunately you're not the first one I've heard this from :( regarding uniqueness though - I think it may depending on how it winds up implementing autofree
@@codetothemoon Agreed with autofree! I am curious as to where it goes. Great video btw!
Yeah, V is a great language but unfortunately has the most bizarrely toxic community I've ever seen for a programming language. It's odd and very discouraging. A lot of V coders have this up-on-their-high-horse mentality, which you see in most language's userbase, mostly jokingly, but with a lot of V users it feels like it like it's coming from a genuine place of perceived superiority. And again, V itself is a fantastic language... but man, they got more toxic members in their community then any other language I've seen to date. It's all so weird and off-putting. I'd encourage everybody reading this to give V a genuine try, it's worth your time... Just mind yourself around the online communities that have sprout out around it. Some of them can be pretty unhinged. It's why I stay a lurker.
I still prefer switching each transistor manually, or if it HAS to be super high level like V, ill just use asm
lol that's next level 😎
5 minutes thinking: This is just go.
End: not worth my time.
Did you find the prospect of no GC and no borrow checker but still getting memory safety compelling?
@@codetothemoon I see the GC as a problem, but I don't see the borrow checker as a problem.
I think we should be aware of our usage of heap and the stack.
It gives me hope of how languages are iterating over concepts to get ride of the GC which are not manual requests of memory. But being completely unaware of it seems like a step in the wrong direction for me.
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
This is interesting - I wonder if there is a gap between what they do and what autofree aims to do. Because I think they have acceptable performance but definitely aren't known for top tier performance.
Personally if this sits somewhere between Rust and Go then I have zero interest because that just makes it worse than Rust for my purposes
It’s just a weirder go with a really fast compiler
wait is that the language that promises a ridiculous amount of stuff that is literally impossible and delivers on nearly none of it? The one that feels like a cult?
It definitely seems to have that reputation with some folks. I won't defend the alleged false claims they've made (I actually haven't even looked into them). All I can say is that my experience in my brief time experimenting with it was positive overall. Though I do have concerns with respect to the feasibility and completion of autofree.
Can you list the impossible stuff please? All claims on the website are true.
I loved explicit closure params. All the other, idk, it’s confusing to be able doing similar things in many different ways, reminds me ruby
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.
they should introduce an option to disable it
@@holthuizenoemoet591 You can. But then what's the point of a language that doesn't provide actual value? Not that autofree does this anyway. But the syntax is nothing to run home for. So what is?
V is compiled to C so every lib written in C can be used in V and (almost) be converted to V. Development time is very fast and you can learn everything of the language in an hour
I work in cyber security and the language helps me write code fast like python, but with the performance and control of C.Also inline assembly code is a plus for me.
it could be usefull in science where you want quick prototyping but also dont necessarily want to deal with the slowness of some interpreted languages (I am looking at you Python)
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--
haha! yeah i think the next logical step would be to do a deep dive comparison of V and Go, and take a look at language features, performance, ecosystem, etc. When I made this video I didn't realize the full extent of V's similarity to Go
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.
Can you give an example?
@@aberges Autofree, automatic C translation, and a working stdlib, for starters
Sounds like "D" 15 years ago. The next big thing, the c++ killer. It wasn't
Yeah i see no advantage over e.g. Rust, why learn a new language
@@andrewrobinson2985 what do you mean by automatic C translation? C2V? There's a DOOM translation demo on our channel. What's not working in stdlib?
I will stay with golang and rust.
I wouldn't try to talk you out of it!
We're in the age of too many similar programming languages. - Do we even need more at this point?
V borrows so many concepts and syntax from Go ... the author should have learned Go before discussing it. One could say V is an evolution of Go, adding some missing concepts, and fixing (?arguably?) some stuff.
yeah I had heard it was similar to Go, but I didn't fully realize how much it borrows from Go until I watched the Primeagen's reaction to this video. So many places where he said 'ok so it's just like Go', where the similarity was unbeknownst to me
That's a really good video, keep it up!
thank you!
Personally I think zig has more promise because the creators behind v seem to be somewhat hostile towards their own community. As you highlighted at the end of the video, there have been quite a few controversial decisions with this language. The thing is, autofree doesn't actually seem that farfetched if the compiler can assign lifetimes to variables under the hood. In this way you'd effectively have ownership but you wouldn't have to worry about the borrow checker because the compiler would determine if the object can be dropped by scope or if it needs reference counting. That being said, I'm not confident in the v contributors to be able to properly implement this feature. Zig on the other hand has multiple memory management schemes and it has already delivered on a lot of the promises that the language originally promoted. Another language that is really exciting in 2023 is ocaml. There have been so many cool editions to that language recently which make it very appealing for anybody who uses rust or go.
It's a scam. The author claims a bunch of features which are all pretty much bullshit or just shallow promises
it seems like autofree is often thought of as one of these - are there others too?
VIdeo maker is all wowed over V features like GUI built-in that have been around in REBOL since 1999, but whatever.
V looks good.
fwiw i don't think it turned out to be the best language to learn in 2023 🙃
@@codetothemoon Thanks for the update!
LOL, its like GO with safety of RUST
I'd add that it also aims to do so without garbage collection
As a go programmer I already feel entitled to try it, thanks for such a detailed video.
Also, what colorscheme are you using in your editor? Monokai? Looks so calm and classy.
Yeah I think the Go crowd will feel right at home with V. Good guess, I'm using doom-monokai-pro 😎
Goddamn it, I've barely had a good look into rust, can language devs please slow down just a bit lol
haha i think there will always be new bleeding edge languages to check out, sometimes it's hard not to get distracted. I'd stick with Rust for the time being :)
Autofree will likely have problems just like garbage collection. The performance of a program will depend on V compiler version, where some values are stack allocated, heap allocated etc.
Golang does the exact same thing with its analysis, golang and V are on the same playing field.
I think the goal of autofree is to not have the same performance issues as garbage collection, remains to be seen whether that will be achieved.
Re: Golang, regardless of the static analysis done at compile time, you'll still have the overhead of the garbage collector right?
@@codetothemoon If you don't create pointers in Golang there's no garbage to collect, and if compiler detects with escape analysis that variables can be freed in the same scope it essentially becomes stack allocated, essentially what happens in autofree. I don't think there's any real solution to Rust's ownership model today.
4:47 there's 2 assert statements, the last one says "should fail". Then you run the tests but the tests all pass? How? :D
yeah, I think I used the wrong clip there. The Primeagen pointed this out in hilarious fashion here ruclips.net/video/j47Hk5qE9As/видео.html
It's not the language and the countless of fruitless claims around it I can't stand. It's the author and his attitude I can't stand.
Yeah, I've heard this sentiment elsewhere as well. Sad considering the potential of this thing.
Ukrainians, start hating
wat?
Coming from Java seeing all that code without semicolon is causing my eyes bleed.
hah! the problem exists in the other direction too - work without semicolons for awhile and try to go back to Rust or Java and... yeah. I highly recommend checking out Kotlin if you live in the JVM world (no semicolons there either though!)
uh it's really a bad reason to dislike a language
Last time I used it, year ago or so, it compiled not working code, even if syntactilly it was correct. Telling from various readmes that list projects in V it is ORM, GUI and freakin Linux replacement and others. Without fully working and documented compiler. What the hell went wrong
virst
nice!
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.
At 7:00 I left out a key piece about what's I think is novel about autofree, as compared to the languages you mention. Check out the pinned comment - basically I think (again, the documentation on this is harder to come by than it should be) it aims to also do something like Rust's borrow checking and ownership changes, but without requiring the developer to be involved in them. Long story short, I believe the aim is to take some of the cases that would require RC in the languages you refer to, and eliminate the need for that RC. Without this, I'm not sure if there would be much to see here.
A question: Can V to programming for Esp8266 or esp32 boards?
seems possible if it compiles initially to C anyway.
With Arduino it shouldn't be a huge issue.
However with ESP-IDF it might be a bit difficult adding bindings for all the IDF functions especially considering that the available functions change depending on the IDF config. It should be possible as we also see with Rust bindings. But some features might be unavailable without falling back to C and the IDE support might not be great depending on how the tool chain will handle that case.
I think I will wait a bit longer before jumping on the bandwagon...
probably the right call! especially given how straightforward it is to learn
the best programming language to learn in 2023 is brainfuck
hah! to each their own...
Funny you posted this video I bought the book last weekend, very promising but there are some bits I'm still not sold on.
Which book?
@@bexplosion "Getting Started with V Programming."
Syntax is like Rust and Go made a baby
Intrigued by the language, horrified by the "Programmer.loc_per_day = 100000" line.
the most copium video i have seen regarding programming languages
Thanks for the feedback - how so?
I'm really rooting for V to get to 1.0, until then I really hope the LSP support gets better, so I can have a better time playing with it
Controversy is mostly egotistical and rarely informative. Solutions and Actionable responses are the only respected forms of controversy, but usually you have to dig deep into reddit replies to find those helpful comments.. V syntax looks very welcoming. Can anyone actually tell me from experience if V fails to deliver on it's claims? I want to know!
It seems to be the best on paper, but in reality it's bloated.
how is it bloated? In terms of performance?
C with colsures. All the other features look great but that's all I need. All it needs now is a repl like Holy-C has. Then it would be good enough to take over an operating system.
Vlang has Garbage Collector. Rust is better.
it does, but my understanding is that it's just a stopgap until they get autofree working for 100% of cases
As a go developer i mean a V developer this is so familiar
yeah, not having known Go prior to making this video, it was a bit over my head the magnitude of the similarity to Go
it's just like a dollar store version of golang 😂
I think it aims to have less of a performance overhead than Golang, though I'm not sure that's the case currently
Cool might actually learn it. what's the font name and theme you have!
font is Monaco and theme is doom-monokai-pro
This language tells a story where Go married Rust but some months later Go made a threesome with C and C++ and Rust did not wanted to take part.
I hope we have V for microcontrollers
interesting, yeah not sure if that's one of their target use cases
>like rust
nah, i'm good
to each their own!
0:38 "Looks like Go..." Hmm, yeah, looks like Go except kinda oxidized, converting the semireadable fragment "func" to an unpronounceable utterance "fn" and requiring every variable to be prefixed with "mut" to vary.
hah yeah I think some aspects of it will make Rust devs feel more at home than they will for Go devs
my parameter is theprimeagen, if he doesn't like vlang then I won't either.
I hate having to explicitly declare a field as required, as opposed to explicitly declaring a default value. It's so much cleaner if you know exactly what a field's default value would be if you don't specify it otherwise on initialization. The required keyword feels exactly like the bolted on solution they are currently adding to C#.
In V you can also declare default values for fields
@@petrmakhnev4037 That's great but I still feel like the default behavior of having an initialized struct while some fields or all its fields can remain uninitialzied, is bad default behavior.
@@PaulSebastianM All fields are initialized to zero-value by default, 0 for numbers, empty string for strings, and so on.
Check out the Hylo language :)
This looks super interesting, thanks for putting it on my radar!
C++ has smart pointers now. No need for new and delete by the programmer.
3:04 "Dont try to pass in a Programmer, they arent people!" This is true.
i will wait until it gets into 1.0 to test it
wouldn't talk you out of that!
The sound of your switches makes my brain vibrate
Edit: its a good thing
If you're referring to the keyboard switches, watch out for the next video this week, you might like it 😎
Elixir is really nice, too.
i was very impressed with it in the brief time that I tried it
Oh yeah...Reddit. The cesspool of armchair warriors.
Should we start using V?
I wouldn't use it for anything business critical quite yet. But for experiments I'd say go for it
As a C#, C++, Kotlin and Scala developer, I do not see a reason to use V over well established programming languages and their ecosystems.
I'd have to agree with you for the time being. But if autofree makes good on its vision, I can see a scenario where I'd prefer switching from those (and I'm a huge fan of Kotlin and Scala) in places where it'd be a good fit.
what the heck is goin on with the line numbers??????????
The active line is the line number relative to the program, the others show distance from active line.
yeah these are relative line numbers to facilitate vertical movement of the cursor
What coding font and theme is that?
Monaco and doom-monokai-pro
Not too impressive tbh, which is exactly the same impression I've always had of golang so I guess it's fitting, but let's see what comes of it
yeah it'll be interesting to see how the project plays out! seems to have improved dramatically in the past year from what I understand
It has ORM ... I'm listening ...
nice, ORMs seem to be critical for many folks!