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.
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
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.
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.
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!
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.
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.
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.
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.
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.
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)
it doesn't develop that fast. I've been following it for 4 years. I quit looking at it because in those four years, it feels like it's made no progress toward becoming what it promises, and they keep adding language-nonessential library features instead of actually working on the features that they initially used to draw in devs. Using it feels too broken to even consider doing a hobby project in it.
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.
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.
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.
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
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.
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.
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.
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.
Thanks for the review. As a young language, V has many problems, some of them are being solved, some of them are not yet. Such reviews will help the language to become more known and attract more people interested in the development and improvement of languages. Calling people for questions about memory management and speed like C as trolls is a known problem, but as far as I can see it is already much less, although there are people like the author of that comment who spoil the impression of the language, which is very sad. I think in 3-4 years we will get a good language with its own advantages and disadvantages. Let's see how it goes.
To be fair a baby with a crayon and a piece of paper could come up with a better mascot than the gopher. It was clearly a decision based on inclusivity instead of merit.
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.
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.
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.
Would love to make one, feels like that's one of the main centers of innovation in the elusive goal of terse syntax + memory safety + optimal performance
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.
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.
6:17 - 7:00 - rust objects just copied (arc/rc are reference counted objects, that contains heap-allocated memory-blocks with objects inside), - there is no heap allocations for stack-allocated objects, - it's not the same as in C/C++ giving a pointer to heap-allocated memory block.
out of curiosity - why do you choose Zig over something like Rust? I feel like I'm missing some pieces of the Zig puzzle and am eager to learn from those who are immersed in it.
@@codetothemoon Aw, my bad. I actually love both Rust and Zig. It just so happens that Zig is a lot easier and simpler for me to work with, compared to Rust. As a worn out C++ dev with horrendous nightmares of failed projects 😅, Rust and Zig gave me a chance to redeem myself. I'm in my 40s now, so I highly gravitate towards simplicity and ease of use.
1:48, ouch! I don't want to specify the returning type! 3:03, ouch! I want this to be automatic! 6:31, std::unique_ptr frees that memory automatically. 6:42, C++'s std::shared_prt is meant for this RC. 6:55, are you saying 'deallocate' meaning 'free from stack' too? Because in C++ things are build on stack by default. For instance: auto a = Thing. It's recommended freeing the stack as soon as possible, because it's precious memory, as small as faster.
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.
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 have been watching V for a while. So far I treat it like Star Citizen ;-) V has the most beautiful and intuitive syntax of any programming language I have seen (personal preference) and I really want this to be my language. But while constant progress is being made, the main developer seems very sidetracked with non-language features even while a core feature such as autofree does not completely work yet.
As a relatively-new-to-rust person, I probably wouldn't stick around if the community wasn't so supportive. . . Even if V is intuitive, considering how I would Stack Overflow questions endlessly, and considering how the early V community responds to the "troll" questions of individuals, I think I would rather stick to Rust 🤷
@@yuartv of course. I said it is how I treat it, I am not saying it is the same. I treat it like that because it has lofty goals that I support but seems far away and distracted from them. Clearly a free open source project is not the same as a commercial one. That's where my wink in the comment did some heavy lifting.
The syntax reminds me a lot of go. I wonder if it also copies the bits of go that are absolute genius? (channels, goroutines, duck typing for interfaces etc)
There are channels, and OS threads for now, goroutines/green threads are planned, but not implemented yet. Starting a new OS thread is done similar to Go, with `spawn fn() { println('hello') }`, launching a new green thread will use `go fn() { println('hello') }` . Duck typing for interfaces is also already supported.
I usually dislike "new" languages because I am too old for changing my development habits. but this thing sounds really good actually. memory management wihout annoying ownership of rust. built in orm and gui. smart decisions
The thing is, their memory management doesn't actually work properly as advertised. This is a common problem with many of V's features and well known in the PL community (there's a well-known article and saying "V stands for vaporware"). The reason all their stuff sounds way too good to be true for such a new and unknown language is because it is. Most of the interesting language features are either not really working as advertised, don't work at all, or are a buggy mess. It was even worse when the language was first made public and for a fair while, most people just considered it a scam since they initially asked for donations before having open-sourced their code and before people had a chance to try the compiler while advertising basically the same features as today which ofc were even less implemented back then. If you search for "v language review 2022" you'll find that it hasn't really improved significantly since then.
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.
V is pretty interesting, from the design itself and how "easy" it can be, I like Rust and Go they are super good. If you look at the moment for a language in a professional environment and for work, I'd suggest to go for Rust or Go, let's remember, V is still 0.3.3 and there is still a lot of work to be done until it can get to the v1.0.0 , some languages required decades to become really good, and people love those for what they have become. Great video, much appreciated, I like V for small projects and just personal fun, while using other languages in my day to day work.
I agree, I'm using it to develop some small projects, and it's been really fun learning it, the "batteries included" really help, and I'd think it could be really useful for writing cross-platform scripts, although python could also be used, I developed a hate for python. I'm still learning the ins and outs of coding so after I finish my current project, I would like to interop it with C to make a nintendo 3ds homebrew but also make it crossplatform, any idea of how that could be done?
1. Not sure about C++, it was my first language but it is also one of my least favorite. It'll be around for a very long time but it doesn't really seem to be a nucleus of innovation at the moment 2. Thanks, it's Monaco!
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
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 love how the solution for people forgetting to do memory management is to make another programming language that has a garbage collector and runs like C instead of making a program that scans and alerts any memory not being freed in a C program. (And it's not that hard to make. I believe I saw a video where someone just made a couple of macros that stores how many times malloc and free functions were called. And you could also store the line that they were called at and the file name. Best of yet, the only thing needed to deactivate or activate it was by a single #define and a rebuild)
the issue is that it's not possible to create a static analyzer (that's what we're talking about here) that guarantees memory safety. Being able to do so would be equivalent to solving the halting problem. It'll catch some things, but can't possibly catch everything. The approach V takes is basically just incorporating said static analysis into the compiler, and using reference counting or GC to handle the cases where safety can't be proven. This seems to be an approach being explored by several languages atm
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.
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.
ok I like the idea but already hate the syntax after just the first minute - don't know exactly why - maybe it is just hard to read what exactly is going on because I am not used to it especially the := vs = just feels wrong - what's wrong with a declaration keyword? and damn the closures look ugly / hard to read Also for some reason I have a lot of difficulty with programming languages that leave the brackets around conditions (but that is a me-issue I guess)
you're right! This was an example pulled directly from the V website where it talks about C to V conversion, and I hadn't even realized that the code was C++. Upon taking another look, it actually says that C++ to V is currently under development as well
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.
You need to change the way you write code to accommodate it when you do so right? And you can't really use anything that depends on garbage collection when you do so?
@@codetothemoon I heard this story on some meetup. They had huge benefit (like 2 or 3 times faster) from fully turning off garbage collection and just relanching application by some condition (maybe when it gets near to some memory limit or by some other reasons - don't remember now). I'm not a java programmer, but found openjdk JEP 318 "Epsilon: A No-Op Garbage Collector (Experimental)" saying "Java implementations are well known for a broad choice of highly configurable GC implementations. The variety of available collectors caters for different needs in the end, even if their configurability make their functionality intersect."
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
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.
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
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
@@phagesuffersatgaming.3797 what tghe fat is iirc
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.
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.
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.
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.
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.
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.
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.
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.
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)
It is just straight up incredible how fast V developes, literally a year ago and there was like nothing, almost no docs and such.
How fast it develops is a little misleading, since it's still nowhere near it's initial promises.
it doesn't develop that fast. I've been following it for 4 years. I quit looking at it because in those four years, it feels like it's made no progress toward becoming what it promises, and they keep adding language-nonessential library features instead of actually working on the features that they initially used to draw in devs.
Using it feels too broken to even consider doing a hobby project in it.
Actually in 2020 the main docs were there.
@@nicktreleaven4119 main docs are pointless when the features themselves are incomplete
@@andrewrobinson2985 far from pointless. They documented what was implemented so far and what was planned at the time
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.
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.
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 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
That's a really good video, keep it up!
thank you!
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 😎
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.
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."
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.
It’s just a weirder go with a really fast compiler
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.
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.
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
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
Thanks for the review. As a young language, V has many problems, some of them are being solved, some of them are not yet. Such reviews will help the language to become more known and attract more people interested in the development and improvement of languages.
Calling people for questions about memory management and speed like C as trolls is a known problem, but as far as I can see it is already much less, although there are people like the author of that comment who spoil the impression of the language, which is very sad.
I think in 3-4 years we will get a good language with its own advantages and disadvantages. Let's see how it goes.
Haha, the mascot is indeed better :D
💯
To be fair a baby with a crayon and a piece of paper could come up with a better mascot than the gopher. It was clearly a decision based on inclusivity instead of merit.
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?
That clojure syntax is criminal
Yes
Partly looks like Clojure.
Isn't the same as in C++?
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 😎
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
the idea seems cool, will wait to see how it evolves. a bit strange to incorporate gui right into when it is on version 0.4
agree, wouldn't fault anyone for holding off until it gets a bit more mature
Would love to see a video on Nim as well
Would love to make one, feels like that's one of the main centers of innovation in the elusive goal of terse syntax + memory safety + optimal performance
@@codetothemoon True that
as a Go developer this seems pretty promising!
there definitely seems to be a strong Go influence on the language!
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.
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.
Cool might actually learn it. what's the font name and theme you have!
font is Monaco and theme is doom-monokai-pro
I love Rust, but Vs ? operator representing either an option or an error is really nice.
6:17 - 7:00 - rust objects just copied (arc/rc are reference counted objects, that contains heap-allocated memory-blocks with objects inside), - there is no heap allocations for stack-allocated objects, - it's not the same as in C/C++ giving a pointer to heap-allocated memory block.
Tried V, still defaulted back to Zig. There's just something about Zig that makes it a joy to work with.
out of curiosity - why do you choose Zig over something like Rust? I feel like I'm missing some pieces of the Zig puzzle and am eager to learn from those who are immersed in it.
@@codetothemoon Aw, my bad. I actually love both Rust and Zig. It just so happens that Zig is a lot easier and simpler for me to work with, compared to Rust.
As a worn out C++ dev with horrendous nightmares of failed projects 😅, Rust and Zig gave me a chance to redeem myself. I'm in my 40s now, so I highly gravitate towards simplicity and ease of use.
1:48, ouch! I don't want to specify the returning type! 3:03, ouch! I want this to be automatic!
6:31, std::unique_ptr frees that memory automatically. 6:42, C++'s std::shared_prt is meant for this RC.
6:55, are you saying 'deallocate' meaning 'free from stack' too? Because in C++ things are build on stack by default. For instance: auto a = Thing. It's recommended freeing the stack as soon as possible, because it's precious memory, as small as faster.
Thanks, never heard of this language before!
Happy I was able to get it on your radar! It wasn't on mine either until very recently
What is the font used? The parentheses are gorgeous!
Thanks, it's Monaco!
@@codetothemoon Thanks!
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.
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.
I have been watching V for a while. So far I treat it like Star Citizen ;-) V has the most beautiful and intuitive syntax of any programming language I have seen (personal preference) and I really want this to be my language. But while constant progress is being made, the main developer seems very sidetracked with non-language features even while a core feature such as autofree does not completely work yet.
As a relatively-new-to-rust person, I probably wouldn't stick around if the community wasn't so supportive.
.
.
Even if V is intuitive, considering how I would Stack Overflow questions endlessly, and considering how the early V community responds to the "troll" questions of individuals, I think I would rather stick to Rust 🤷
@@mysterry2000 good point. maybe as the language matures, some people will too.. or ChatGTP will make Stackoverflow unnecessary 🙂
@@yuartv of course. I said it is how I treat it, I am not saying it is the same. I treat it like that because it has lofty goals that I support but seems far away and distracted from them. Clearly a free open source project is not the same as a commercial one. That's where my wink in the comment did some heavy lifting.
Cool video. What font are you using ?
Monaco 😎
The syntax reminds me a lot of go. I wonder if it also copies the bits of go that are absolute genius? (channels, goroutines, duck typing for interfaces etc)
that's a great question - I didn't encounter any of the features you mention, though I could have overlooked them.
There are channels, and OS threads for now, goroutines/green threads are planned, but not implemented yet. Starting a new OS thread is done similar to Go, with `spawn fn() { println('hello') }`, launching a new green thread will use `go fn() { println('hello') }` .
Duck typing for interfaces is also already supported.
I usually dislike "new" languages because I am too old for changing my development habits. but this thing sounds really good actually. memory management wihout annoying ownership of rust. built in orm and gui. smart decisions
yeah it seems worth keeping tabs on 😎
The thing is, their memory management doesn't actually work properly as advertised. This is a common problem with many of V's features and well known in the PL community (there's a well-known article and saying "V stands for vaporware"). The reason all their stuff sounds way too good to be true for such a new and unknown language is because it is. Most of the interesting language features are either not really working as advertised, don't work at all, or are a buggy mess. It was even worse when the language was first made public and for a fair while, most people just considered it a scam since they initially asked for donations before having open-sourced their code and before people had a chance to try the compiler while advertising basically the same features as today which ofc were even less implemented back then. If you search for "v language review 2022" you'll find that it hasn't really improved significantly since then.
really loving the videos, btw what editor do you use
thank you, glad you're getting something out of them! I'm using DOOM Emacs
@@codetothemoon thanks
@@codetothemoon thanks, i forgot to ask the font and theme also
think that V is a more easier version of Rust. It's also very flexible, you can easily make a GUI/Web Server.
Yeah it seems like they are aiming to get most of the benefits of Rust without requiring so much development overhead
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.
V is pretty interesting, from the design itself and how "easy" it can be, I like Rust and Go they are super good. If you look at the moment for a language in a professional environment and for work, I'd suggest to go for Rust or Go, let's remember, V is still 0.3.3 and there is still a lot of work to be done until it can get to the v1.0.0 , some languages required decades to become really good, and people love those for what they have become. Great video, much appreciated, I like V for small projects and just personal fun, while using other languages in my day to day work.
I agree, I'm using it to develop some small projects, and it's been really fun learning it, the "batteries included" really help, and I'd think it could be really useful for writing cross-platform scripts, although python could also be used, I developed a hate for python.
I'm still learning the ins and outs of coding so after I finish my current project, I would like to interop it with C to make a nintendo 3ds homebrew but also make it crossplatform, any idea of how that could be done?
It's fine if it isn't complete, but that doesn't excuse the author for making complete bullshit statements about it.
@@gagagero what do you mean ?
@@kamkoamoh Things like "compiles 2.5 million lines of code a second".
@@gagagero such claims were never made
Great video learned a lot, bro can you please tell me what extension your using to add that sound effect when your typing the code. It sounds too good
Nice glad you got something out of it! I actually just mic up the keyboard when I'm recording myself typing.
@@codetothemoon what keyboard you use?? It really sounds good
LOVE YOUR VIDEOS. + 2 questions:
1. will you make a video about c++?
2. the code's font is insanely beautiful, what it's name?
1. Not sure about C++, it was my first language but it is also one of my least favorite. It'll be around for a very long time but it doesn't really seem to be a nucleus of innovation at the moment
2. Thanks, it's Monaco!
In C++ you would use `std::unique_ptr` not `new`
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
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.
This is really cool! Would love to see more examples of the V language in the future
There are tons of examples in the examples folred in V. Clone it and take a look on them.
I hope to cover it more as the language grows in maturity!
I love how the solution for people forgetting to do memory management is to make another programming language that has a garbage collector and runs like C instead of making a program that scans and alerts any memory not being freed in a C program. (And it's not that hard to make. I believe I saw a video where someone just made a couple of macros that stores how many times malloc and free functions were called. And you could also store the line that they were called at and the file name. Best of yet, the only thing needed to deactivate or activate it was by a single #define and a rebuild)
the issue is that it's not possible to create a static analyzer (that's what we're talking about here) that guarantees memory safety. Being able to do so would be equivalent to solving the halting problem. It'll catch some things, but can't possibly catch everything.
The approach V takes is basically just incorporating said static analysis into the compiler, and using reference counting or GC to handle the cases where safety can't be proven. This seems to be an approach being explored by several languages atm
Hey, can you tell us what theme and font you're using?
doom-monokai-pro and Monaco
@@codetothemoon amazing, thank you a lot. Loved the video by the way!
Autofree will take decades and decades to be perfect
That appears to be a concern shared by many folks!
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.
May I ask what font you are using in the editor?
Monaco
which font are you using in this video?
I believe it was Monaco!
Who does have the better mascot between Go and V?
V
What font and theme are you use?
Monaco and doom-monokai-pro
Intrigued by the language, horrified by the "Programmer.loc_per_day = 100000" line.
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 th-cam.com/video/j47Hk5qE9As/w-d-xo.html
Could you do a video on sql and v, please?
maybe!
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 😎
What is the name of the font you are using?
Monaco
Yo man. I just wanted to start learning Rust as I am switching from js node . I hope in future it won't be as popular as rust. Time will tell
nah don't worry it's just a scam language they wouldn't make it real until you die
js node?
Go ahead, there is a steep learning curve but once you get past it you'll be good.
I think you're on a good course with Rust, stick with it!
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.
ok I like the idea but already hate the syntax after just the first minute - don't know exactly why - maybe it is just hard to read what exactly is going on because I am not used to it
especially the := vs = just feels wrong - what's wrong with a declaration keyword?
and damn the closures look ugly / hard to read
Also for some reason I have a lot of difficulty with programming languages that leave the brackets around conditions (but that is a me-issue I guess)
Autofree is just like the Objective-C and i guess Swift compiler tries to do it's release/retain optimizations.
What font are you using for doom emacs?
3:27 this is so good
You say C program to V but the code is C++, is it possible too to pass from C++ to V automatically?
you're right! This was an example pulled directly from the V website where it talks about C to V conversion, and I hadn't even realized that the code was C++. Upon taking another look, it actually says that C++ to V is currently under development as well
Does that font exist in vscode? I guess you are using vim.
It should (it's Monaco) you should be able to get a similar theme as well (Monokai)
jai is better.
though it is currently in private beta
heard the name but haven't checked it out yet. Maybe I'll look into it, thanks for the suggestion!
didnt tell me anything new i didnt already know...the answer to the question posed in the title is still: maybe?
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
What coding font and theme is that?
Monaco and doom-monokai-pro
I hope we have V for microcontrollers
interesting, yeah not sure if that's one of their target use cases
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.
What is the name of the theme in doom emacs?
doom-monokai-pro
@@codetothemoon tnx
You can disable garbage collection in java too.
You need to change the way you write code to accommodate it when you do so right? And you can't really use anything that depends on garbage collection when you do so?
@@codetothemoon I heard this story on some meetup. They had huge benefit (like 2 or 3 times faster) from fully turning off garbage collection and just relanching application by some condition (maybe when it gets near to some memory limit or by some other reasons - don't remember now). I'm not a java programmer, but found openjdk JEP 318 "Epsilon: A No-Op Garbage Collector (Experimental)" saying "Java implementations are well known for a broad choice of highly configurable GC implementations. The variety of available collectors caters for different needs in the end, even if their configurability make their functionality intersect."
What is that font tho? it's so nice
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!
What font are you using?
Monaco
@@codetothemoon Thank you. Great video btw. V sounds promising but the "promising more than delivering" part grounded me 😅.
C++ has smart pointers now. No need for new and delete by the programmer.
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
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!
what font do you use for emacs?
I believe it is Monaco
Concurrency support? Does it have channels and v-routines like golang?
Yes it does. It uses the go keyword for them haha
Does V support macros like lisp?
I'm pretty sure it does not
don't think so, but not 100% sure