V looks interesting, and I wish it the very best. However the attitude of the lead developers toward criticism or negative feedback (even if it's not valid) is highly off-putting imo. Everything negative that people say appear to be taken as an "attack", and as far as I've seen they are quick on the trigger in regards to banning or blocking people that they disagree with. And at the very least they just completely disregard all negative feedback as lies, scams, conspiracies, etc.
The responses I've read by the devs are in stark contrast to what I've seen in other languages I use, such as Rust. I hope that as the language evolves, the developers will start reflecting on the way that they interact with others and how it impacts people's view of V. I could never justify using a language like V in production if I couldn't even trust the lead developers to be level-headed during criticism.
I'm sorry for ranting, I really wish the best for V and its maintainers.
> I'm sorry for ranting, I really wish the best for V and its maintainers.
I appreciate you posting this. I like the premise of V and really want for it to suceed, but this is a good summary of why I think so many people dislike V: the lead dev and community do not engage criticism in good faith.
I'm sure V receives its fair share of unwarranted criticism, but a lot of legitimate criticism and questions are either met with a) hostility or b) incredulity, which causes people to dislike the language for fundamental reasons.
Both the creator and community members gaslight (for lack of a better word) and act as if they're happy to receive questions or feedback, but even in this thread you can see people being treated like I mentioned above.
I don't really agree. V seems to attract a much larger than normal swath of people who enjoy trying to score points off of technicalities. e.g. people claiming the entirety of V is an unsafe language because they found a single bug in the compiler, etc. Languages like Rust never garner this sort of point scoring in the comments.
> as far as I've seen they are quick on the trigger in regards to banning or blocking people that they disagree with
Do you have any source for this claim? Without a source this simply reads as another person trying to sow uncertainty and doubt. I haven't seen anyone banned or blocked on Github.
I think the problem initially was that people accused the creator of malice for no reason other than not being more specific about which features were a work in progress. I agree that it's not good to treat every criticism as an attack, but sometimes criticism of V (as an outsider, I've never used it) feels more like anger towards the creator rather than a helpful suggestion. For example, there's a difference between saying "I've found a bug in an advertised feature" and "You're a liar", which is how much of V's critics sound to me.
FWIW, my view is that even the best programmers don't always have perfect non-programming skills and it is better to give them specific objective feedback via bug reports/technical comments etc and not focus on how they are not doing the expected thing or behaving in an expected manner. Focus on and encourage their good work if possible.
> However the attitude of the lead developers toward criticism or negative feedback...
I disagree about that, because there is a major difference between submitting a bug or disagreeing about a claim or feature versus outright trolling, smearing, instigating drama, or trying desperately to create negative public perception.
Issues and discussions can be brought to V's GitHub (https://github.com/vlang/v/issues, https://github.com/vlang/v/discussions), but instead what various competitors and detractors do is create drama filled smear blogs or bad joke posts (on various websites) against the author or language. That's not any attempt at being helpful or constructive, that's more about slander or to create such negative sentiment in the hope of killing off the language.
When issues and discussions are brought peacefully to V's GitHub, they are discussed and debated intelligently. If any such issues have any validity, then they are usually fixed.
> Everything negative that people say appear to be taken as an "attack"...
That's simply not true. What does happen, is various competitors and detractors do specifically attack and smear the language or author, and who have no intention to want to be helpful or make any improvements. To include engaging in downvoting or trolling those who appear to be V supporters.
Such attacks and smears are not about fixing anything, their point is to be destructive, create negative publicity, and dissuade others from using a rival language.
If there are those that don't think that is the case, then simply ask yourself why many of those engaging in such attacks and smearing who claim to be technically knowledgeable or interested in using the language are not making their case on V's GitHub? That's where a person can go to improve V and get it production ready. Continually engaging in smearing is not about fixing, improving, nor reaching out to V's developers or community.
This is a big one. 5769 commits pushed to master, 1697 bugs closed. The highlights of this release are C2V, a fully automatic C => V source code translator, closures, and no more memory leaks by default.
The "autofree" memory management [1] seems quite interesting, and a very cool mixture between garbage collection with static memory management. Has been there been any seminar / conference talk held on this topic related to the pros / cons of this approach vs a pure GC memory management strategy, since it seems like it could be used in _almost_ all modern GC languages.
I tried c2v on some very simple commands in freebsd /usr/src/bin/ such as ls and pwd and it failed. Still, very good to see this progress! May be you can add some FreeBSD commands to your test cases?
Thank you for digging!
I really appreciate your attention.
There are lots of bug fix in 1 year, and will be better time by time.
I started to use Vlang 1 year ago, and I created lots of ISSUES on GitHub, and most of them are already fixed.
I like Vlang (also like Rust and ...) so,
I'm happy for your attention & deep insight.
I hope you to dig and share again sometime.
2) The author of the "review" used a throwaway account for the apparent purposes of recommending to not use V.
The author of the "review" can run away and hide, where the creators and developers of V are accountable to the public and supporters.
This includes that the author of the review never has to update or make corrections to his hit piece, while still spreading links to it all over the internet.
3) The "review" is used as a linked reference document for further attacks by competitors and detractors. And as has already happened on various other internet sites, including here.
4) If the author of the "review" was really eager to use and fix the V language, he could have brought those issues (he has a GitHub account) to the V GitHub (https://github.com/vlang/v/issues).
Who is going to fix any issues that the author believes is a problem?
It is going to be the V developers. So if the author of the review wanted those things that he believes are a problem fixed, that's who he has to bring them to.
5) The author of the "review" starts it by linking to a number of very contentious posts from competitors and detractors of V, to include those that smear the author and language.
This turned the "review", right off the bat, into setting off drama. A smear campaign on the V language will never get any of the issues fixed on its own, just only invite more drama, smearing, and attacks. Which looks like the original intent.
6) The author of the "review" has shown no interest in working with V developers, and that's prior to publishing the review and spreading links to it.
No intent has been shown to modify his review for correctness, fairness, or language version.
7) The author's review doesn't provided the necessary context and is highly opinionated.
Without feedback or the opinions of the V developers, this is a one-sided negative review full of many debatable points, that does little to help readers outside of trying to produce a negative impression and smear the language.
If the review author is not interested in working with V developers, and rather produce and disseminate drama or facilitate smearing, then that's a reflection of their real intent.
I've been following vlang's GitHub issues lately and it feels like every second issue is about broken codegen in areas which seem so basic you wonder why it was even merged in that state. So I have mixed feelings about this. On one hand, the list of features/fixes is impressive and there's a growing community, and even a book, on the other hand there are endless edge cases which weren't properly thought out/tested and which break the compiler. Maybe vlang needs some sort of fuzzing?
Are there plans for docs to be updated? The 0.3 release notes claim:
> Option and Result are now separate types: ?Foo and !Foo respectively. Old code will continue working for 1 year and will result in a warning/hint.
Yet, doc/docs.md still states:
> V combines Option and Result into one type, so you don't need to decide which one to use.
Is there an up-to-date doc, or how does one find out more about these types? I found parts of the RFC overhauling the error handling [0] pretty bizarre, so I'm interested to see how the implementation turned out.
I've had my eye on this language for a couple months; in particular, V UI subproject, a SwiftUI-like code-first framework for doing GUIs, caught my eye, since I rather like SwiftUI and I still need to make a human-friendly KyuWeb client for the server to be of any use. Unfortunately V UI doesn't seem to have progressed much since I last had a look on it. Here's hoping it gets the attention it deserves, because from what I've researched of GTK, it looks about as fun as a kidney stone to use, and having a modern low-level language with a closely-integrated, cross-platform modern GUI framework could really put V above the rest (SwiftUI does not have first-class support outside of Apple platforms currently).
Wow. Despite a lot of the negativity here, V looks great. I might take a stab at writing something over the weekend with it. Congratulations on the release.
Lovely language, but above scares me off for now. Respect to all involved and hope one day will be a day where there will be only a super sophisticated bugs left that affects 0.01% of users.
Before using V I had a similar concern. However I then looked at Go and see it has 7.5k issues on GitHub. Granted much bigger user base = more stuff uncovered.... So for right or wrong, 7.5k issues in 100K stars versus 750 issues on 30k stars... It doesn't look so crazy suddenly. Personally I like to see issues as it means people are actually using the language, finding bugs, and driving incremental improvement.
A project with 0 issues barely indicates flawless implementation no more than the possibility it simply has 0 users.
TBH, I have criticized V before, because when it launched things and claims were weird and maybe inflated, honestly don't quite remember looking at V in a good light is still hard for me.
But I am willing to give it a try, so here's a shot.
Can you pls, explain a few things in short really don't want to read all of the docs to figure out the basics.
1. What platforms are well supported by V and how does it work non traditional or extension based C code?
2. What happens for edge cases where the C compiler quirks are being used for code when you transpile C to V?
3. How safe is V really? Like is it memory safe, if so maybe a quick description as to how, does it provide a memory model? What about an ABI? does it match the platform C ABI or something?
4. What happens to linking to C code, is it as easy as Zig? maybe something like zig cc?
5. How is the multithreading in V? Does it have something like openmp atleast something like rayon or do we use platform threads?
6. What about the C++ interop? anything interesting more than what other languages can do?
7. What's the current state of the compiler in terms of stability? And especially the std lib?
8. Lastly anything you want to point out as a very interesting feature in V that is not hype but so comfy that I would like to atleast use V somewhere in my stack? Maybe something like Zig's cc or Nim's metaprogramming or Haskell's mind bending type system, Idris's dependent types, etc.?
Preferrably not like Rust's safety thing, I love Rust but just saying things like it's safer is very weird claim without any context. Just some details are fine no need to waste your time on making a hater change their mind.
Personally I am trying to keep open mind to things, I might be harsh because of ignorance or preference or just because of being a young douchey programmer but being mean to something that has stuck around, and where a bunch of people seem to be putting in effort somehow seems worse than just shitty on it, even if it's a scam.
2. For stuff like i++ expressions, V allows them. Some stuff gets translated to adapted V code. Some (~2% of the syntax) will result in an error. Those will be fixed this year.
3. Memory safe, bounds checking, C ABI.
4. Ridiculously easy. The main reason it was created (was using Go before). Just run `C.foo(1,2,3)`. Use C2V to generate V wrappers.
5. Only system threads for now.
6. Same as with C. Need export "C".
7. Very stable, at least for me. Never had a crash/segfault.
8. Hard to pick. Fast compilation, hot code reloading, nice clean sum types, clean json serialization and ORM (mysql,sqlite,postgres).
With 30K stars on GH, I feel late to the party but Vlang looks amazing. Given this is the 0.3 release, it's almost shocking how much has already been achieved.
The comparison page was very useful to quickly get a feel for V's "aesthetic" and design goals: https://vlang.io/compare
Great job with the language. I’ve always found the controversy quite interesting. You know you’re doing something right when everyone attacks you. How did you get GitHub to support V just one month after release?
Can I suggest: On your github homepage (https://github.com/vlang/v) you should put some sample code, I scrolled all the way through it and did see anything.
I'm curious about the status and/or roadmap of REPL for vlang? Do you plan for an expressive experience with the REPL, like in interpreted languages (python, ruby...), or it just compiles each line?
It's interesting how the language author of V was bullied and harrassed for his early language [0] and with time V has made very substantial progress with C2V [1], and an OS written in V [2] and various language improvements.
This (and many future updates of V) has now rendered pretty much most criticisms in this attack post irrelevant, after all of this V is gaining traction, a community forming around the language and with great backing, It goes to show that programmers are far too quick to jump the gun on languages.
[+] [-] Xevi|3 years ago|reply
The responses I've read by the devs are in stark contrast to what I've seen in other languages I use, such as Rust. I hope that as the language evolves, the developers will start reflecting on the way that they interact with others and how it impacts people's view of V. I could never justify using a language like V in production if I couldn't even trust the lead developers to be level-headed during criticism.
I'm sorry for ranting, I really wish the best for V and its maintainers.
[+] [-] richbell|3 years ago|reply
I appreciate you posting this. I like the premise of V and really want for it to suceed, but this is a good summary of why I think so many people dislike V: the lead dev and community do not engage criticism in good faith.
I'm sure V receives its fair share of unwarranted criticism, but a lot of legitimate criticism and questions are either met with a) hostility or b) incredulity, which causes people to dislike the language for fundamental reasons.
Both the creator and community members gaslight (for lack of a better word) and act as if they're happy to receive questions or feedback, but even in this thread you can see people being treated like I mentioned above.
E.g. https://news.ycombinator.com/item?id=31947510, https://news.ycombinator.com/item?id=31947121, https://news.ycombinator.com/item?id=31947212, https://news.ycombinator.com/item?id=31947014, https://news.ycombinator.com/item?id=31946715, https://news.ycombinator.com/item?id=31947977
[+] [-] amedvednikov|3 years ago|reply
There's actual valid criticism and feedback like in https://github.com/vlang/v/discussions/7610
But there's also trolling, harassment, and completely baseless attacks.
[+] [-] johnfn|3 years ago|reply
> as far as I've seen they are quick on the trigger in regards to banning or blocking people that they disagree with
Do you have any source for this claim? Without a source this simply reads as another person trying to sow uncertainty and doubt. I haven't seen anyone banned or blocked on Github.
[+] [-] mllllv|3 years ago|reply
[+] [-] corford|3 years ago|reply
The language used on the main vlang site also seems calm, clear and unsensational (at least to me).
[+] [-] bakul|3 years ago|reply
[+] [-] unknown|3 years ago|reply
[deleted]
[+] [-] Tozen|3 years ago|reply
I disagree about that, because there is a major difference between submitting a bug or disagreeing about a claim or feature versus outright trolling, smearing, instigating drama, or trying desperately to create negative public perception.
Issues and discussions can be brought to V's GitHub (https://github.com/vlang/v/issues, https://github.com/vlang/v/discussions), but instead what various competitors and detractors do is create drama filled smear blogs or bad joke posts (on various websites) against the author or language. That's not any attempt at being helpful or constructive, that's more about slander or to create such negative sentiment in the hope of killing off the language.
When issues and discussions are brought peacefully to V's GitHub, they are discussed and debated intelligently. If any such issues have any validity, then they are usually fixed.
> Everything negative that people say appear to be taken as an "attack"...
That's simply not true. What does happen, is various competitors and detractors do specifically attack and smear the language or author, and who have no intention to want to be helpful or make any improvements. To include engaging in downvoting or trolling those who appear to be V supporters.
Such attacks and smears are not about fixing anything, their point is to be destructive, create negative publicity, and dissuade others from using a rival language.
If there are those that don't think that is the case, then simply ask yourself why many of those engaging in such attacks and smearing who claim to be technically knowledgeable or interested in using the language are not making their case on V's GitHub? That's where a person can go to improve V and get it production ready. Continually engaging in smearing is not about fixing, improving, nor reaching out to V's developers or community.
[+] [-] rvz|3 years ago|reply
[deleted]
[+] [-] amedvednikov|3 years ago|reply
We're really excited about this release.
This is a big one. 5769 commits pushed to master, 1697 bugs closed. The highlights of this release are C2V, a fully automatic C => V source code translator, closures, and no more memory leaks by default.
There's a really cool C2V demo:
https://www.youtube.com/watch?v=6oXrz3oRoEg
Translating DOOM from C to V, building it in under a second and running it!
[+] [-] Chio|3 years ago|reply
[1] https://vlang.io/#memory
[+] [-] bakul|3 years ago|reply
[+] [-] ducktective|3 years ago|reply
> Translating DOOM from C to V
Like, you can literally translate a C project to V without any manual intervention?
[+] [-] ketzu|3 years ago|reply
[1] https://mawfig.github.io/2022/06/18/v-lang-in-2022.html
[+] [-] xiphias2|3 years ago|reply
[+] [-] ken0x0a|3 years ago|reply
I like Vlang (also like Rust and ...) so, I'm happy for your attention & deep insight. I hope you to dig and share again sometime.
[+] [-] Tozen|3 years ago|reply
1) The "review" is now significantly wrong and already outdated.
Doesn't mention it is reviewing an Alpha or even the version.
Anything of substance in the review was mostly minor and has already been fixed:
https://github.com/vlang/v/issues/14803 https://github.com/vlang/v/issues/14787 https://github.com/vlang/v/issues/14786
2) The author of the "review" used a throwaway account for the apparent purposes of recommending to not use V.
The author of the "review" can run away and hide, where the creators and developers of V are accountable to the public and supporters.
This includes that the author of the review never has to update or make corrections to his hit piece, while still spreading links to it all over the internet.
3) The "review" is used as a linked reference document for further attacks by competitors and detractors. And as has already happened on various other internet sites, including here.
4) If the author of the "review" was really eager to use and fix the V language, he could have brought those issues (he has a GitHub account) to the V GitHub (https://github.com/vlang/v/issues).
Who is going to fix any issues that the author believes is a problem?
It is going to be the V developers. So if the author of the review wanted those things that he believes are a problem fixed, that's who he has to bring them to.
5) The author of the "review" starts it by linking to a number of very contentious posts from competitors and detractors of V, to include those that smear the author and language.
This turned the "review", right off the bat, into setting off drama. A smear campaign on the V language will never get any of the issues fixed on its own, just only invite more drama, smearing, and attacks. Which looks like the original intent.
6) The author of the "review" has shown no interest in working with V developers, and that's prior to publishing the review and spreading links to it.
No intent has been shown to modify his review for correctness, fairness, or language version.
7) The author's review doesn't provided the necessary context and is highly opinionated.
Without feedback or the opinions of the V developers, this is a one-sided negative review full of many debatable points, that does little to help readers outside of trying to produce a negative impression and smear the language.
If the review author is not interested in working with V developers, and rather produce and disseminate drama or facilitate smearing, then that's a reflection of their real intent.
[+] [-] gompertz|3 years ago|reply
[deleted]
[+] [-] amedvednikov|3 years ago|reply
Since it was another anonymous attack, it's not going to be updated and will stay like this for years.
And the issues discussed are questionable at best. Half the article is about a type checker bug, which was a 3 line fix.
Then false claims like being able to modify array.len.
[+] [-] kgeist|3 years ago|reply
[+] [-] amedvednikov|3 years ago|reply
We also have thousands of tests.
Do you have any examples?
[+] [-] sjustinas|3 years ago|reply
> Option and Result are now separate types: ?Foo and !Foo respectively. Old code will continue working for 1 year and will result in a warning/hint.
Yet, doc/docs.md still states:
> V combines Option and Result into one type, so you don't need to decide which one to use.
Is there an up-to-date doc, or how does one find out more about these types? I found parts of the RFC overhauling the error handling [0] pretty bizarre, so I'm interested to see how the implementation turned out.
[0]: https://github.com/vlang/rfcs/pull/7
edit: linked to the wrong RFC initially.
[+] [-] mwexler|3 years ago|reply
Simple, fast, safe, compiled language for developing maintainable software. Compiles itself in <1s with zero library dependencies. https://vlang.io
I first learned about it from https://simonknott.de/articles/vlang (2019), which was an interesting introduction, if a touch dated now
[+] [-] Cyberdog|3 years ago|reply
https://github.com/vlang/ui
(I'd also like to see first-class support for the BSDs, but I know better than to hold my breath on that one.)
[+] [-] dimgl|3 years ago|reply
[+] [-] danielEM|3 years ago|reply
https://github.com/vlang/v/issues
Lovely language, but above scares me off for now. Respect to all involved and hope one day will be a day where there will be only a super sophisticated bugs left that affects 0.01% of users.
[+] [-] gompertz|3 years ago|reply
A project with 0 issues barely indicates flawless implementation no more than the possibility it simply has 0 users.
[+] [-] amedvednikov|3 years ago|reply
[+] [-] amedvednikov|3 years ago|reply
[deleted]
[+] [-] minraws|3 years ago|reply
But I am willing to give it a try, so here's a shot. Can you pls, explain a few things in short really don't want to read all of the docs to figure out the basics.
1. What platforms are well supported by V and how does it work non traditional or extension based C code?
2. What happens for edge cases where the C compiler quirks are being used for code when you transpile C to V?
3. How safe is V really? Like is it memory safe, if so maybe a quick description as to how, does it provide a memory model? What about an ABI? does it match the platform C ABI or something?
4. What happens to linking to C code, is it as easy as Zig? maybe something like zig cc?
5. How is the multithreading in V? Does it have something like openmp atleast something like rayon or do we use platform threads?
6. What about the C++ interop? anything interesting more than what other languages can do?
7. What's the current state of the compiler in terms of stability? And especially the std lib?
8. Lastly anything you want to point out as a very interesting feature in V that is not hype but so comfy that I would like to atleast use V somewhere in my stack? Maybe something like Zig's cc or Nim's metaprogramming or Haskell's mind bending type system, Idris's dependent types, etc.?
Preferrably not like Rust's safety thing, I love Rust but just saying things like it's safer is very weird claim without any context. Just some details are fine no need to waste your time on making a hater change their mind.
Personally I am trying to keep open mind to things, I might be harsh because of ignorance or preference or just because of being a young douchey programmer but being mean to something that has stuck around, and where a bunch of people seem to be putting in effort somehow seems worse than just shitty on it, even if it's a scam.
[+] [-] amedvednikov|3 years ago|reply
2. For stuff like i++ expressions, V allows them. Some stuff gets translated to adapted V code. Some (~2% of the syntax) will result in an error. Those will be fixed this year.
3. Memory safe, bounds checking, C ABI.
4. Ridiculously easy. The main reason it was created (was using Go before). Just run `C.foo(1,2,3)`. Use C2V to generate V wrappers.
5. Only system threads for now.
6. Same as with C. Need export "C".
7. Very stable, at least for me. Never had a crash/segfault.
8. Hard to pick. Fast compilation, hot code reloading, nice clean sum types, clean json serialization and ORM (mysql,sqlite,postgres).
[+] [-] corford|3 years ago|reply
The comparison page was very useful to quickly get a feel for V's "aesthetic" and design goals: https://vlang.io/compare
[+] [-] emblaegh|3 years ago|reply
[+] [-] mllllv|3 years ago|reply
[+] [-] frenchie4111|3 years ago|reply
[+] [-] alephnan|3 years ago|reply
[+] [-] goingtosleep|3 years ago|reply
[+] [-] amedvednikov|3 years ago|reply
https://github.com/vlang/v/blob/master/vlib/v/eval
[+] [-] pawelduda|3 years ago|reply
[+] [-] colejohnson66|3 years ago|reply
[+] [-] kennywinker|3 years ago|reply
[+] [-] amedvednikov|3 years ago|reply
It needs to be inited recursively with
app := App { gg: &gg.Context { ... app } }
And that doesn't work yet. It used to work in the initial V, but not right now.
It'll be fixed in 0.4.
[+] [-] colesantiago|3 years ago|reply
This (and many future updates of V) has now rendered pretty much most criticisms in this attack post irrelevant, after all of this V is gaining traction, a community forming around the language and with great backing, It goes to show that programmers are far too quick to jump the gun on languages.
I congratulate Alex for persisting on V.
[0] https://xeiaso.net/blog/series/v
[1] https://github.com/vlang/c2v
[2] https://github.com/vlang/vinix