Vinix – An effort to write a modern, fast, and interesting operating system in V(github.com)
github.com
Vinix – An effort to write a modern, fast, and interesting operating system in V
https://github.com/vlang/vinix
85 comments
The Linux source (!binary) compatibility target is exciting. Will be nice to carry over Linux modules/drivers + software. The initial PS/2 keyboard support just landed (https://twitter.com/v_language/status/1402193052941312002).
Oh also, mintsuki's (limine, lyre, echfs, qword, some things with managarm, etc) comments about V vs C/Rust/Odin/Zig are really interesting in #vinix-os: https://discordapp.com/channels/592103645835821068/645024404...
Can you copy those comments here by chance?
I basically said that V lends itself better to this kind of development; and the modular, headerless structure gets less messy than C codebases.
I also said that while I was skeptical of V (I have read all the criticism many times and I was also critical of the language for the longest time), it lends itself relatively well to kernel development and I am generally having a good time developing Vinix, only encountering minor compiler-related issues here and there, mostly with inline assembly.
I also said that the language, by virtue of it currently being a relatively thin wrapper over plain C, resonates with me more as a C developer than somewhat similar alternatives like Zig or Rust.
Matter of opinions, really.
I also said that while I was skeptical of V (I have read all the criticism many times and I was also critical of the language for the longest time), it lends itself relatively well to kernel development and I am generally having a good time developing Vinix, only encountering minor compiler-related issues here and there, mostly with inline assembly.
I also said that the language, by virtue of it currently being a relatively thin wrapper over plain C, resonates with me more as a C developer than somewhat similar alternatives like Zig or Rust.
Matter of opinions, really.
I remember shenanigans when V was first announced (release date for public preview, but for a little money you get early access), people being upset that it was half-baked, etc. and wrote it off, but I've heard that it has since changed a ton and is nothing like the early days.
Can someone familiar with recent V developments comment on this? It makes bold promises that would be awesome to see realized, but I got the feeling there was just a lot of smoke and mirrors going on in the early days.
Can someone familiar with recent V developments comment on this? It makes bold promises that would be awesome to see realized, but I got the feeling there was just a lot of smoke and mirrors going on in the early days.
Things have improved but it's not clear the author realizes the magnitude of what he's trying to do.
The big ticket item is the autofree memory management system which promises near C/Rust performance and minimal overhead without the complexity of borrowing and ownership. To date, this system does not work and is "wip" as the vlang community likes to say. There are also no clear explanations of how it works beyond just "it inserts calls to free() when you are no longer using a variable" which is ... extremely obvious. The more interesting question of how the compiler determines something is no longer being used in the face of aliasing and no borrowing system is completely unanswered. No one working on the project understands how complex that problem is. Initially the goal was that this system would manage all memory for the programmer automatically, this goal has since moved to "manage 90% of objects in memory and use GC for the rest". I suspect we will see that number continue to drop as the author realizes this is intractable without whole program analysis (which they can't do and still hit their compilation time targets).
Other items are very much in an alpha state if they work at all. Only in the last month have you been able to create a generic function with more than one type parameter, although V has been claiming support for generics since at least last year. There's still no ability to constrain the type parameter to something that implements an interface/trait/protocol.
C2V, another wildly ambitious project that could literally be a PhD project in automatic language translation, was supposed to be released "this week" 5 weeks ago. It's currently in a very private alpha and no source has been released.
Which is basically the state of most of the author's projects: huge promises in terms of features and performance with most of them little more than demos. I've come to believe this is an intentional strategy by the author to maximize his Patreon revenue. He makes big promises on social media and then delivers the easy 20% of the project to his followers before switching to another project. It would make far more sense to release a finished project before starting another massive one and yet he can't sit down and finish a project because he knows he can't actually deliver what's been promised.
The big ticket item is the autofree memory management system which promises near C/Rust performance and minimal overhead without the complexity of borrowing and ownership. To date, this system does not work and is "wip" as the vlang community likes to say. There are also no clear explanations of how it works beyond just "it inserts calls to free() when you are no longer using a variable" which is ... extremely obvious. The more interesting question of how the compiler determines something is no longer being used in the face of aliasing and no borrowing system is completely unanswered. No one working on the project understands how complex that problem is. Initially the goal was that this system would manage all memory for the programmer automatically, this goal has since moved to "manage 90% of objects in memory and use GC for the rest". I suspect we will see that number continue to drop as the author realizes this is intractable without whole program analysis (which they can't do and still hit their compilation time targets).
Other items are very much in an alpha state if they work at all. Only in the last month have you been able to create a generic function with more than one type parameter, although V has been claiming support for generics since at least last year. There's still no ability to constrain the type parameter to something that implements an interface/trait/protocol.
C2V, another wildly ambitious project that could literally be a PhD project in automatic language translation, was supposed to be released "this week" 5 weeks ago. It's currently in a very private alpha and no source has been released.
Which is basically the state of most of the author's projects: huge promises in terms of features and performance with most of them little more than demos. I've come to believe this is an intentional strategy by the author to maximize his Patreon revenue. He makes big promises on social media and then delivers the easy 20% of the project to his followers before switching to another project. It would make far more sense to release a finished project before starting another massive one and yet he can't sit down and finish a project because he knows he can't actually deliver what's been promised.
Reminds me of this line by tom_mellior[0]:
> I wish people stopped approaching language design from the point of view that the people who have been working on garbage collection for the last 60 years are all idiots who don't see how simple it all is.
[0]: https://news.ycombinator.com/item?id=26765369
> I wish people stopped approaching language design from the point of view that the people who have been working on garbage collection for the last 60 years are all idiots who don't see how simple it all is.
[0]: https://news.ycombinator.com/item?id=26765369
Honestly, that describes a lot of the tech hype cycle.
The classic example would be MongoDB and other NoSQL solutions etc. in the early days. We can be lightning fast compared to these RDBs! Clearly they're idiots, as is anyone that uses them!
Oh wait, what? You mean it's hard to actually work with data durably, and that not doing so is the main reason we're faster... crap.
The classic example would be MongoDB and other NoSQL solutions etc. in the early days. We can be lightning fast compared to these RDBs! Clearly they're idiots, as is anyone that uses them!
Oh wait, what? You mean it's hard to actually work with data durably, and that not doing so is the main reason we're faster... crap.
> Initially the goal was that this system would manage all memory for the programmer automatically, this goal has since moved to "manage 90% of objects in memory and use GC for the rest". I suspect we will see that number continue to drop as the author realizes this is intractable without whole program analysis (which they can't do and still hit their compilation time targets).
A demo of autofree with zero GC/RC:
https://www.youtube.com/watch?v=gmB8ea8uLsM
> Other items are very much in an alpha state if they work at all.
Can you list items that don't work at all or are in alpha state?
Generics missing some advanced features like protocols doesn't mean they don't work.
And no I don't live in Sweden. You seem to get a lot of things about V wrong.
A demo of autofree with zero GC/RC:
https://www.youtube.com/watch?v=gmB8ea8uLsM
> Other items are very much in an alpha state if they work at all.
Can you list items that don't work at all or are in alpha state?
Generics missing some advanced features like protocols doesn't mean they don't work.
And no I don't live in Sweden. You seem to get a lot of things about V wrong.
You solved the memory management for one particular program written in exactly the style necessary to avoid leaks for the demo. You'll find as you fix other programs, you'll introduce UAFs into this one which is, I suspect, one reason your commit activity around autofree has basically dropped to 0 recently.
> Can you list items that don't work at all or are in alpha state?
Nothing, as I expected.
Nothing, as I expected.
No reply to the autofree comment? Unsurprising.
Since you want it so much, here you go:
- "No undefined behavior" -> How does V prevent this? V currently can't even generate well formed C code for all valid V so how do you prevent UB in the generated C? As of now, for any reference x in V, *x and ******x are both accepted by the checker. int32.MAX + 1 is instant UB yet V does nothing to prevent this. What is your plan to prevent UB in the generated C?
- Generics -> The example shown in your own docs expresses how "wip" this is (https://github.com/vlang/v/blob/master/doc/docs.md#generics). Why is `T.name` allowed? `T` can be literally anything since there is no constraint on it. You're obviously deferring type checking the function until it's monomorphized which is far more like C++ templates than "generics". How do you plan to deal with template bloat slowing down compilations?
- -usecache -> Another one of the 20% implemented features. This was done to give V a huge boost in compiling simple programs but the implementation is so busted, you yourself disabled it on the benchmarking site.
- "go" keyword -> From your docs: "V's model of concurrency is very similar to Go's. To run foo() concurrently in a different thread, just call it with go foo()". At least you've documented it but have completely buried the lede that unlike Go, `go` spawns an OS thread not a green thread. Speaking of green threads, how do you propose to keep the efficiency you claim ("within 3% of C") while still having transparent C interop? Are you going to use segmented stacks to allow 100,000s+ green threads and then run into the same issues Go has calling into C or are you going to larger stacks to make C interop feasible which limits how many green threads you can run before using enormous amounts of memory?
- "immutable" references -> As shown on Discord, "immutable" references can easily by laundered into mutable ones by assigning the reference to a mutable variable and then assigning into that.
- native backend -> Can handle hello world and programs that use string interpolation. Given that it can't handle the average 100 line V program, you should not be extrapolating the performance of 1,000,000 V programs.*
Since you want it so much, here you go:
- "No undefined behavior" -> How does V prevent this? V currently can't even generate well formed C code for all valid V so how do you prevent UB in the generated C? As of now, for any reference x in V, *x and ******x are both accepted by the checker. int32.MAX + 1 is instant UB yet V does nothing to prevent this. What is your plan to prevent UB in the generated C?
- Generics -> The example shown in your own docs expresses how "wip" this is (https://github.com/vlang/v/blob/master/doc/docs.md#generics). Why is `T.name` allowed? `T` can be literally anything since there is no constraint on it. You're obviously deferring type checking the function until it's monomorphized which is far more like C++ templates than "generics". How do you plan to deal with template bloat slowing down compilations?
- -usecache -> Another one of the 20% implemented features. This was done to give V a huge boost in compiling simple programs but the implementation is so busted, you yourself disabled it on the benchmarking site.
- "go" keyword -> From your docs: "V's model of concurrency is very similar to Go's. To run foo() concurrently in a different thread, just call it with go foo()". At least you've documented it but have completely buried the lede that unlike Go, `go` spawns an OS thread not a green thread. Speaking of green threads, how do you propose to keep the efficiency you claim ("within 3% of C") while still having transparent C interop? Are you going to use segmented stacks to allow 100,000s+ green threads and then run into the same issues Go has calling into C or are you going to larger stacks to make C interop feasible which limits how many green threads you can run before using enormous amounts of memory?
- "immutable" references -> As shown on Discord, "immutable" references can easily by laundered into mutable ones by assigning the reference to a mutable variable and then assigning into that.
- native backend -> Can handle hello world and programs that use string interpolation. Given that it can't handle the average 100 line V program, you should not be extrapolating the performance of 1,000,000 V programs.*
> No reply to the autofree comment? Unsurprising.
autofree was placed a bit lower on the prioritization list due to the focus on C2V and amazingly well integrated -gc boehm, which solves all leaks for now.
- "No undefined behavior" -> How does V prevent this?
By not having UB. You have any examples of UB in V?
`x and *x` type checker bug in the compiler means the compiler doesn't work? Then by this definition none of the compilers do, because all of them have bugs.
> How do you plan to deal with template bloat slowing down compilations?
Is that your example of an alpha or a broken feature?
> - -usecache -> Another one of the 20% implemented features. This was done to give V a huge boost in compiling simple programs but the implementation is so busted, you yourself disabled it on the benchmarking site.
No I didn't. V hello.v uses -usecache. And v self was removed for now because it's unfair: V modules are in vlib, all of them get cached, and the compilation is too fast. How is it 20% implemented?
> - "immutable" references -> As shown on Discord, "immutable" references can easily by laundered into mutable ones by assigning the reference to a mutable variable and then assigning into that.
Not anymore, a large amount of these bugs have been recently fixed.
Native backend is being worked on by a very experienced developer, author of radare2, so we will definitely see v self -native work this year.*
autofree was placed a bit lower on the prioritization list due to the focus on C2V and amazingly well integrated -gc boehm, which solves all leaks for now.
- "No undefined behavior" -> How does V prevent this?
By not having UB. You have any examples of UB in V?
`x and *x` type checker bug in the compiler means the compiler doesn't work? Then by this definition none of the compilers do, because all of them have bugs.
> How do you plan to deal with template bloat slowing down compilations?
Is that your example of an alpha or a broken feature?
> - -usecache -> Another one of the 20% implemented features. This was done to give V a huge boost in compiling simple programs but the implementation is so busted, you yourself disabled it on the benchmarking site.
No I didn't. V hello.v uses -usecache. And v self was removed for now because it's unfair: V modules are in vlib, all of them get cached, and the compilation is too fast. How is it 20% implemented?
> - "immutable" references -> As shown on Discord, "immutable" references can easily by laundered into mutable ones by assigning the reference to a mutable variable and then assigning into that.
Not anymore, a large amount of these bugs have been recently fixed.
Native backend is being worked on by a very experienced developer, author of radare2, so we will definitely see v self -native work this year.*
Can you explain how a conservative garbage collector solves all leaks?
[deleted]
I remember the hubbub a year (or longer? another covid timewarp) ago when this first came out. It looks like now the dev of V is just pulling under 1K a month so it's not like he's making bank so if they're still just grifting it's not really working.
No grifting going on. We have a vibrant awesome community that feels very Ruby-like in many ways. Good people.
He lives in Sweden where the cost of living is quite a bit lower than most of the US and also has people contributing to him on GitHub. A quick Google search suggests it's quite possible to live on $1k a month in Sweden for one person but I admit I have no personal experience in that point.
Edit: I was wrong about the location but that does not change my opinion.
Edit: I was wrong about the location but that does not change my opinion.
No, he does not live in Sweden.
The cost of living in Sweden is not quite a bit lower than most of the US. It may be less than Manhattan or SF but it's certainly not cheap, especially compared to most of the US. I visited Sweden a few years back and found most things to be very expensive and I just did a quick Google search now to confirm before writing this comment.
These issues should / could all be addressed - if you're in Discord already, which it sounds like you probably are, feel free to talk about each point. The C2V source IS in fact, already available to many folks (v devs specifically, of which there are many).
The last time I asked about how the memory management would work, the conversation was quickly shut down by a vlang dev (not Alex) who grilled on me on why I wanted to know how the language worked. I've seen this same reaction to other newcomers who dare to ask reasonable questions instead of simply drinking the Kool aide.
Strange, I'll mention it. There have been a lot of crazy trolls so a few folks are a bit thin on the patience front - especially a few who are crazy hard at work all the time on the language. I do have sympathy for them and they're great folks if you just try to understand the history and their own context a bit.
I think it would be more productive to direct the attention to https://github.com/vlang/v/issues/1247 which catalogues a number of issues with the proposed approach and yet hasn't had any activity in 9 months.
Ditto same experience, I asked if somebody could explain me the memory model of V; and all of sudden hell broke loose. I was asked why do I need to know how memory model worked, are you a troll, if you don't contribute to the lang you're not welcome here.
Never asked a second question again.
Yep. Very telling when no one on the server can explain it and anyone who asks is silenced.
who inspired who here ? musk or v-author ?
Not only did this project make a lot of false claims about itself but also other existing programming languages. This included Nim (which I am one of the core devs on).
It’s rather sad to see people get roped in by these claims. This project is a true example of how far pushing false promises and lies can get you and it makes me a bit sad about the world.
It’s rather sad to see people get roped in by these claims. This project is a true example of how far pushing false promises and lies can get you and it makes me a bit sad about the world.
Do you have links to false claims about Nim?
I think they meant V-lang is making false claims about itself.
I meant both V-lang making false claims about itself and making false claims about Nim.
Please get specific - not sure what you're talking about. I've only ever seen other folks coming in and attacking V really quite baselessly.
The specifics were discussed in the Nim forum:
https://forum.nim-lang.org/t/4758
I don't and to be fair, from what I recall, these were dropped from the V website as soon as the Nim community challenged them.
Nothing was dropped: https://vlang.io/compare
This can be verified via web archive.
This has been the only mention of Nim.
What claims are false?
You make very big accusations ("a lot of false claims about itself but also other existing programming languages", "a true example of how far pushing false promises and lies can get you and it makes me a bit sad about the world"), and yet you can't provide examples of such claims and lies.
This can be verified via web archive.
This has been the only mention of Nim.
What claims are false?
You make very big accusations ("a lot of false claims about itself but also other existing programming languages", "a true example of how far pushing false promises and lies can get you and it makes me a bit sad about the world"), and yet you can't provide examples of such claims and lies.
Things are going great, stop in for a chat: https://discord.gg/vlang
It's still smoke and mirrors from a dreadfully unstable language. Criticism from https://christine.website/blog/vlang-update-2020-06-17 still holds to this day.
FALSE. Look at the date and check out: https://github.com/vlang/v
Just saying “FALSE” doesn’t address the big issue: Christine was blocked for asking questions.
I think, if that happened, perceived trolling is the more appropriate interpretation of what happened there to Christine. You're acting angry and critical whereas in reality we should be focused on solving problems and building community to make things good for everyone.
> You're acting angry and critical whereas in reality we should be focused on solving problems and building community to make things good for everyone.
Sorry, but you can't flip a critic into a productive community member by calling them angry. If you want help building community, you need to inspire trust with a kickass product that meets or exceeds your promises
Critics fall away when they can't find valid criticism; browbeating and blocking them will only amplify the criticism. I see crap like this on almost all vlang-related posts. Y'all won't beat the drama with your current approach.
Sorry, but you can't flip a critic into a productive community member by calling them angry. If you want help building community, you need to inspire trust with a kickass product that meets or exceeds your promises
Critics fall away when they can't find valid criticism; browbeating and blocking them will only amplify the criticism. I see crap like this on almost all vlang-related posts. Y'all won't beat the drama with your current approach.
Nobody cares if the Christine wants to contribute or not. If you are going to contribute, contribute in a positive way. Not by being antagonistic. The reaction she/he received will be the same in any office environment if you behave in an angry and antagonistic fashion calling people liars and cheats
I am part of everyone. I can't benefit from a tool I am banned from contributing in for speaking critical of it.
Hello, I am the maintainer of Vinix and main contributor. Feel free to ask me anything about the project!
You mentioned this in another comment but how do you feel about the other new systems level programming languages and how they compare to V like nim, zig, rust etc.
I don't know much about nim but I have seen my fair share of Rust and Zig code. Out of these 2, I'd personally pick Zig if I had to choose. Rust's syntax doesn't resonate with me very much and I feel like it tries to hand hold too much at times.
That said I am a programmer and as such I am more into what I can get done with these tools rather than the tools themselves. Whatever I feel can get the job done for whatever I need to do is okay with me. In Vinix's case, I can confirm from personal experience that V has been able to get the job done so far effortlessly.
That said I am a programmer and as such I am more into what I can get done with these tools rather than the tools themselves. Whatever I feel can get the job done for whatever I need to do is okay with me. In Vinix's case, I can confirm from personal experience that V has been able to get the job done so far effortlessly.
[deleted](1)
V is shady AF. Steer clear of it.
Either that's slander, or it needs some explanation and, preferably, documentation.
https://news.ycombinator.com/item?id=27440032
But feel free to look up any older thread on the language. It’s the musk of PLs.
But feel free to look up any older thread on the language. It’s the musk of PLs.
The initial alpha (beta?) release of the project was scheduled for public review, but the developer was accepting payments for early access. I won't comment on the state of the release that some people paid for.
The devs seem to have made a few enemies. Devs of other small projects, specifically Nim and Zig aren't fans of V to say the least. Nim devs allege that the V project has made defamatory remarks about their project. Zig developer, Andrew Kelly, also had some things to say about V. [0],[1]
There have been numerous occasions of the V dev deleting criticism.
There are claims that the V project has been buying stars on github.
The project makes very bold claims about the feature set while not having actually implemented said features.
There is a popular set of blog posts that dives into the issues with claims vs reality [2],[3],[4]
My opinion is that I do find it disingenuous, and borderline scammy, to accept donations and at the same time claim V can do the things it claims. Ultimately, I think the dev is just not great at managing expectations. I highly doubt any of it is malicious intent. Also, somewhere in one of these, Andrew retracts his accusation of fraud, due to the V devs updating the advertised capabilities of the project.
[0] https://github.com/vlang/v/issues/292
[1] https://news.ycombinator.com/item?id=20230351
[2] https://christine.website/blog/v-vaporware-2019-06-23
[3] https://christine.website/blog/v-vvork-in-progress-2020-01-0...
[4] https://christine.website/blog/vlang-update-2020-06-17
The devs seem to have made a few enemies. Devs of other small projects, specifically Nim and Zig aren't fans of V to say the least. Nim devs allege that the V project has made defamatory remarks about their project. Zig developer, Andrew Kelly, also had some things to say about V. [0],[1]
There have been numerous occasions of the V dev deleting criticism.
There are claims that the V project has been buying stars on github.
The project makes very bold claims about the feature set while not having actually implemented said features.
There is a popular set of blog posts that dives into the issues with claims vs reality [2],[3],[4]
My opinion is that I do find it disingenuous, and borderline scammy, to accept donations and at the same time claim V can do the things it claims. Ultimately, I think the dev is just not great at managing expectations. I highly doubt any of it is malicious intent. Also, somewhere in one of these, Andrew retracts his accusation of fraud, due to the V devs updating the advertised capabilities of the project.
[0] https://github.com/vlang/v/issues/292
[1] https://news.ycombinator.com/item?id=20230351
[2] https://christine.website/blog/v-vaporware-2019-06-23
[3] https://christine.website/blog/v-vvork-in-progress-2020-01-0...
[4] https://christine.website/blog/vlang-update-2020-06-17
I am the author of articles [2], [3], and [4] if you have any questions.
Is V still vapourware in your opinion since you made your posts? Seems to have improved significantly since then.
Personally I think it is something that should be ignored until it dies into obscurity. There are good ideas there, but if you sell someone the moon and give them a block of cheese that's kind of a scam.
I get your point, but it doesn't look like this project would be ignored for some time, though it also makes some sense to market some features of the language with some demos, UI, GL and even an OS to show its capabilities.
And if you ask me, it's very impressive that an OS can be written in V as well.
And if you ask me, it's very impressive that an OS can be written in V as well.
It's not terribly impressive when the compiler just outputs C and invokes TCC or your platform's compiler to do the actual work. V is far more like a different syntax for C than it is a real language. Perhaps one day that will change but currently V is to C as CoffeeScript is to JavaScript.
hmm. IIRC, C++ also started by compiling to C. Typescript also compiles to JS. CMIIW.
Coffeescript also gained popularity (perhaps until JS caught up and render CS not relevant anymore)
Coffeescript also gained popularity (perhaps until JS caught up and render CS not relevant anymore)
CoffeeScript was popular until Typescript came along and actually added something useful to JavaScript instead of just changing the syntax.
I imagine quite a bit of the dustup might be language issues and cultural issues around what is and isn't okay / how to differentiate between planned feature and existing feature.
It has been somewhat sad in that I have seen cultural / communication problems. There are a lot of folks who just don't talk or comport the same from different regions around the world and it has been easily misinterpreted as negative vs simply not functioning the same socially.
All of this has been addressed and/and resolved elsewhere. Not sure of references of the top of my head, but check Discord (and/or maybe GH).
[deleted]
It's a teenager who doesn't have much CS knowledge [0] thinking he can put two features over golang and make a fortune out of it.
[0] anyone with proper knowledge doesn't claim they can "avoid GC by automatically inserting calls to free"
Its disturbing how this shitfest even gets treated as real, even people who made reasonably good languages (crystal, nim, odin) did not get the hype this got.
[0] anyone with proper knowledge doesn't claim they can "avoid GC by automatically inserting calls to free"
Its disturbing how this shitfest even gets treated as real, even people who made reasonably good languages (crystal, nim, odin) did not get the hype this got.
Zig is shady AF. Steer clear of it. Andrew, Jai coming at you soon ;)
I want to ask V community a question, as they advertise their language as safe, what do they mean by safety and what does V compiler do to maintain this safety?
Have you bought github stars from a click farm again and then show how many stars you have compared to other langs?
did this happen? is there proof somewhere?
for anyone who doesn't use Telegram: the image shows that most of the stars came in short bursts of time, from China. kinda weird that one can't click the image in their browser to enlarge it
You may be curious to see how many people in China are actually contributing and doing stuff in V. That's actually surprising and cool.
How many?
This might be real star history.
https://star-history.t9t.io/#vlang/v
Or, it's better than a meme that needs mOaR jPeG!
https://star-history.t9t.io/#vlang/v
Or, it's better than a meme that needs mOaR jPeG!
Imagine caring about a projects organic growth from GitHub stars from China lol.
The simplest explanation is that maybe they 'like' the project?
The simplest explanation is that maybe they 'like' the project?
Imagine thinking that GitHub stars are indicative of anything at all. You might as well measure popularity by how many times your webpage has been bookmarked.
my point is, who cares? if they like it so what?
Who cares? These people seem to care https://twitter.com/v_language/status/1339223357800263682?s=...
They are the project owners, no shit they would care, To everyone else outside of the project, so what?
Seems like you also care a big deal about these GitHub stars for someone who doesn't like the project and your name checks out too.
Seems like you also care a big deal about these GitHub stars for someone who doesn't like the project and your name checks out too.
They also care about criticism
https://imgur.com/a/8wYsj4C
This reads as a bit more ambitious than the usual HelloWorld or http framework example project.
Ah, they missed the chance to call it VNIX.
an interesting language. Thanks for sharing.
I never heard of V so I looked it up:
https://vlang.io/
An implementation of 2048:
https://github.com/vlang/v/blob/master/examples/2048/2048.v in V