- small binaries and fast compilation
- cross-platform support
- cross-compilation
- cross-platform drawing library (GDI+/Cocoa Drawing, OpenGL)
- native GUI toolkits (V-UI)
- value types
- auto-free engine that adds necessary free() commands
- C transpilation (both ways, allegedly emits human-readable C)
- C foreign function interface ("V can call C Code and any language with C-interop can call V Code")
- hot-code reloading (not mentioned how, but probably dynamic library hot swapping)
- package manager
- autoformatter
- profiler
- documentation-from-source generator
- V-to-JavaScript/WASM transpilation
- built-in testing framework
- built-in web framework (vweb)
- ORM ("you can just write V instead of SQL while interacting with databases")
Vinix - An open-source Operating System that can already run GCC, Bash, V etc.
Volt - A 300Kb native desktop client for Slack, Discord, Skype, Gmail, Twitter, Facebook, and more. (only supports MacOS at the moment)
VSQL - A single-file SQL database written in pure V with no dependencies.
Gitly - Open-source light and fast alternative to GitHub/GitLab, written entirely in V.
Vorum - Right now it's a very basic forum/blogging software, but in the future, it will be a full-featured light alternative to Discourse. The V forum runs on Vorum.
Vgram - A bot library for Telegram Bot API.Such as the famous "autofree" where everyone doubted it could work and the solution now was.... to drop in boehm-gc.
for anyone unfamiliar with v, take everything on that list with a giant spoon full of salt.
Though I’m still not confident enough on the usability and stability of the language. Almost all claims of the usability/stability of the language seems to come from the main creator himself, I would like to hear some takes from people other than him who have used the language in any serious form.
That's just bashing. It's one thing to actually use something and criticize, its another to not even use the language and assume things.
> Such as the famous "autofree" where everyone doubted it could work and the solution now was.... to drop in boehm-gc.
Autofree is still part of Vlang. Also, many other languages have multiple methods of memory management. Which many argue is a good thing. Take for example, Nim, which has several (see below). Yet, I have never seen anybody at HN lose their minds over it and bash Nim about it.
Nim has: gc:refc, gc:markAndSweep, gc:boehm, gc:go, gc:arc, etc...
So exactly why can't Vlang have both AutoFree and GC? Yeah, the correct answer is that it should not be a problem. And as a newer developing language, they should be allowed to experiment to find what works best, as the other languages before it.
They definitely have a hacker mindset to get the minimum working examples through and keep on developing, which is admirable in some ways. The downside is I don't think there's a lot of development experience hanging around that project, so things stick to minimal implementations.
V's compile time memory management demo. Running the Ved editor on an 8 MB file with 0 leaks.
Because of this dichotomy, there cannot be completely objective discussion about the language. I would strongly urge anyone thinking of spending time on V to first examine it closely and see if it holds up to detailed scrutiny. In my opinion, V does not and the author knows this but deliberately pretends otherwise for his own personal gain. Of course, you should not solely take my word for this any more than you should take Alex's to the contrary. Consider, if it really was so easy to build a language with the speed of C, the ease of use of Python and the simplicity of Go, why haven't those languages with orders of magnitude more funding simply done so? There are fundamental tradeoffs to language design and it's clear the author does not understand this.
The core problem with V is that while many language implementations tread a middle ground between the "just get an MVP out so users can give feedback; ship fast, ship often; as long as it works" engineering mindset and the "ivory tower" academic mindset, V picks the former while giving the finger to a burning pile of compiler books. The author appears willfully ignorant of the basic tecnhiques used to build compilers even going so far as to state that V won't use an abstract syntax tree because "AST is going to require lots of extra CPU power and RAM" [1]. The author later discovered that implementing an AST was actually necessary to make developing the compiler easier and made the compiler faster not slower as he originally proclaimed [2].
A few notes on the advertised feature list:
- cross-compilation
Cross compilation in V depends on having a C compiler toolchain present for the given target. That is to say, V's cross-compilation story is exactly the same at present as C's is. I'm sure some one will mention the "native backend" which has recently started to be able to build "hello world" without miscompilations. Until such time as it is able to build even slightly complex programs, this is a complete non-sequitur.
- native GUI toolkits
Native in this context means "compiled code", not that it uses the platform's native UI toolkit. V-UI draws it's own components to the screen and does not use native platform libraries at all other than to open a drawing surface.
- auto-free engine that adds necessary free() commands
Autofree does not work anywhere close to as well as advertised. Autofree will both leak memory in trivial programs [3] [4] [5] [6] as well as introduce use-after-free and double-free Undefined Behaviors [7] [8] [9] [10]. The autofree Ved demo required changes to Ved to work around autofree's broken state [11].
Autofree cannot work as well as advertised (90%+ of variables handled automatically, down from 100% orignally) without extensive inter-procedural analysis which doesn't exist [12] and would destroy V's compiler performance claims if it did. For anyone who still thinks there might be something to autofree, please explain how this logic for inserting a call to free could possibly be sound [13]:
mut af := g.is_autofree && !g.is_builtin_mod && node.op == .assign && node.left_types.len == 1
&& (node.left[0] is ast.Ident || node.left[0] is ast.SelectorExpr)
The profiler works by adding instrumentation calls to every function generated in your binary [14]. This can completely change the performance of your program and invalidates the results produced. No mention of this problem exists anywhere in the documentation.
In conclusion, people need to stop treating this as some kind of serious up-and-coming language and instead see it as the massive pile of poorly implemented hacks it is.
[1]: https://github.com/vlang/v/issues/1255#issuecomment-51356505...
[2]: https://github.com/vlang/v/issues/4128
[3]: https://github.com/vlang/v/issues/14033
[4]: https://github.com/vlang/v/issues/13821
[5]: https://github.com/vlang/v/issues/13539
[6]: https://github.com/vlang/v/issues/12201
[7]: https://github.com/vlang/v/issues/13554
[8]: https://github.com/vlang/v/issues/13398
[9]: https://github.com/vlang/v/issues/12455
[10]: https://github.com/vlang/v/issues/12453
[11]: https://github.com/vlang/ved/commits?author=medvednikov&befo...
[12]: https://github.com/vlang/v/search?q=is_autofree
[13]: https://github.com/vlang/v/blob/704e3c6e7275336b5b4f8da27438...
[14]: https://github.com/vlang/v/blob/3fa9128716cdc8a794b2ec0be4fb...
Also I'd like to add that V's first feature, "no null" is a myth. V supports initializing a reference with 0, which is null/nil or whatever you call it.
I'm pretty sure v's author will not bother responding to a well laid out facts.
As with any attempt at propaganda and misinformation, you are taking elements of truth and then greatly distorting it to fit your agenda. Which is possibly to hurt your competition, because of developing or being heavily invested in a competing language. It would be much more honest to come out and say what your preferred language is and what your involvement with it is, than to put on a troll costume and do hit posts.
> ...Because of this dichotomy, there cannot be completely objective discussion about the language.
No, you have created a false dichotomy. You can not be objective, because of your bias and possible investment in other languages.
> Consider, if it really was so easy to build a language with the speed of C, the ease of use of Python and the simplicity of Go, why haven't those languages with orders of magnitude more funding simply done so?
This is a straw man argument. It would be like someone saying, "If the car was really such a good idea, why wasn't it invented by the Egyptians back in 1000 BC? They had plenty of gold and engineers."
Programming languages are built upon and borrow from each other. It is the prior existence of C, Python, and Go that something new which is blended from various elements of each, with various new concepts added, can be created. Thus we can have Vlang and various other newer languages.
-Cross compilation
You didn't refute that Vlang can do it, but rather it doesn't meet your preferences. So damn what it makes use of C compilers, for now or as an option in the future? So have other languages. Not to mention, Vlang has very strong interop with C, to begin with.
And they are working on the native backend, which is producing results, and will only get better. It must also be kept in mind how young Vlang is as a language, which started from 2019. So its level of progress and popularity is arguably amazing, and has surpassed a number of its rivals. It is asinine to compare a language of such young age to those from say 2008 or the 1990s, who at the same comparative stages were less advanced.
- native GUI toolkits
Again, you are spouting out your preferences. Furthermore, Vlang has a number of GUI wrapper libraries. Such as: vsdl/vsdl2, vig (ImGui), vnk (nuklear), viup (IUP), etc... If a person doesn't want to use the VUI (written in V), they can hop over to a bunch of others.
- Autofree
The developers have repeatedly said that it wouldn't be ready until 0.3 of the language. It exists and functions, but they are working on improving it, which is not anything unusual at this stage. People can disable it with -noautofree, and do manual memory management. There is -prealloc too. There is also GC (-gc boehm).
The developers have stated there would be a few memory management options, of which there will be at least -autofree and -gc boehm. Not sure why certain people are getting their panties all twisted, when a number of other programming languages also have multiple memory management options, to include those languages having had all kinds of development problems and they still have issues.
- GitHub Issues
This is probably the more ludicrous part of your post. All popular programming languages on GitHub will have a long list of issues. The more popular, the more you will see. For example, Rust has nearly 8,000 OPEN issues. If someone listed them all on HN, would they win any points?
The true point is that issues submitted, are those that contributors and developers work on to resolve. Using an open issue as a reference to attempt to prove a language is somehow deficient is very, very deceptive. That's a problem they are fixing and will usually fix (sooner or later), or discover it's not really an issue as user error. More importantly, is how useful those users, supporters, and contributors feel the language is. That's why Vlang is constantly gaining in popularity, despite angry detractors and competitors.
Troll hit jobs will simply not stop Vlang, and just reflects an odd desperation in wishing it would. Whatever programming language that you prefer or are developing, it should be able to stand on its own merits, without the need for trolling others.
Anyone with any familiarity with the V project will know it's been mired in controversy from day 1, thanks to the [often hyperbolic] claims of its inventor. All of which seems to have passed the author of this article by, as he just gushingly repeats them unquestioningly.
Mind you, he does describe V as "all new", so maybe he missed all that previous discussion.
> a 15 year old student who likes to code and blog
for some perspective :)
We all could learn from this.
> What a piss-poor excuse for an article!
The article is no different from many new-sexy-js-framework blog posts I see here, but these never get that amount of hate. Why is that?
Additionally, somehow other newer languages like Odin, Crystal, and Zig seem to escape their wraith and trolling despite having some similar developmental issues. Very selective "hate".
Yes that is why I am surprised it is still on the front page. Normally anything to do with Vlang get flagged within a few hours on HN.
Then there's; vweb, vorum, volt and ved [all of which feature prominently on the front page too] which have been little more than alpha quality proofs of concept for a similarly long time.
Don't get me wrong; I was actually interested in V when I first heard about it a few years back. And I was prepared for there to be a lot of 'WIP' since the language was so new. But I lost interest as the years passed and nothing more polished ever seemed to emerge.
In fact the whole ethos of the V community seems to be to take the maxim "Move fast and break stuff" and stretch it to breaking point. Instead of anything actually being worked on, polished and finished, you just keep throwing out new headline grabbing 'projects' which, as per the examples above are barely functional and seem to be abandoned almost as soon as they are announced. One week it'll be a new game engine [naturally, because it's V, better, stronger faster than anything already out there], the next week a web framework [better, stronger, faster...etc], the week after that it'll be a new 3D engine [better, stronger, faster...]
I even remember a while back someone[s] in the V community announced they were building an OS in V. [presumably better, stronger, faster than Linux, OSX, Windows, etc]
That's why you get so much negative press. It's not because people want to hate V. A hell of a lot of people [especially in the HN demographic] were genuinely interested in the project. But the endless hyperbole just ends up making you sound like a snake oil salesman and your crowd loses interest and drifts away.
I imagine things have improved since 2019, though.
To be fair.. I always see this in HN comments about V, and at this point it sounds just as a non-objective and prejudiced evaluation as the article is.
I agree that the article should have presented some downsides. But to start a discussion, how about presenting some valid criticisms?
Clearly people have worked on this project for a while. Have they completely failed to implement the “hyperbolic” claims? Or are they doing something good?
I’ve been intrigued about V for a while, i haven’t had the time to look into it yet.
I wish we had an objective discussion about it..
It'd be better if the documentation reflected that the language was in an alpha state rather than touting stability guarantees etc.
[1] https://github.com/vlang/v/issues?q=is%3Aissue+is%3Aopen+lab...
But as usual, people are looking to have an opinion spoonfed and are upset when it's not the narrative they wanted.
Very thorough documentation: https://github.com/vlang/v/blob/master/doc/docs.md
One of the coolest latest projects is the Vinix OS, written fully in V:
https://github.com/vlang/vinix
It's a POSIX OS that already runs libc, bash, GCC, g++, and Doom.
It would be nice if you were upfront about this in your posts or profile, especially when you jump in to dismiss people's complaints about your project. https://news.ycombinator.com/item?id=25512003
Pure functions by default
V functions are pure by default, meaning that their return values are a
function of their arguments only, and their evaluation has no side effects
(besides I/O).
I will be more than happy to learn that I am wrong and the situation has considerably improved, but other than that infamous GitHub issue "The language is not what is promised", I haven't seen a more recent (as of 2022) objective, skeptical analysis of the language by someone from outside their community. Maybe someone has links?
Not really, here's a benchmark of V compiling itself in 0.3 seconds that includes all steps (including the C -> binary part) and results in the compiler binary:
https://www.youtube.com/watch?v=pvP6wmcl_Sc
This video is linked on the home page.
> crashed the compiler on trivial inputs
We have thousands of tests, lots of big projects written in V (V itself is 220k loc, Vinix OS, Ved editor, Gitly, vsql etc), and they all work fine, no compiler errors.
Can you give an example of a trivial input resulting in a crash/C error?
The infamous "The language is not what is promised" you referenced has claims like "there's no way V is written in V", and "there's no way to do json serialization without an AST". These things are simply not true.
Here:
https://github.com/vlang/v/issues/14023
I've seen quite a few such issues in the GitHub repo.
>We have thousands of tests, lots of big projects written in V (V itself is 220k loc, Vinix OS, Ved editor, Gitly, vsql etc), and they all work fine, no compiler errors.
Do these projects have large userbases (actual users, not just as a toy project)? How many contributors? I wrote a transpiler myself and I know that if you write in a safe subset (avoiding known gotchas) a project no one uses, then there's going to be zero problems with the project :)
I'm skeptical but I'm open to learn that I'm wrong.
From what I've seen, you've used tcc for the benchmark, right? If so, that's kinda cheating, since tcc is written to be a simple as possible (and therefore as fast as possible), so the compilation time is essentially zero. Benchmarking with gcc with optimization turned on should give you a more realistic result.
> We have thousands of tests, lots of big projects written in V (V itself is 220k loc, Vinix OS, Ved editor, Gitly, vsql etc), and they all work fine, no compiler errors.
To quote Djikstra:
Program testing can be used to show the presence of bugs, but never to show their absence.Thanks for reading and commenting. I appreciate it and hope to use these comments to improve myself as both a researcher and a writer. Thanks again!
Focus on what information you're trying to convey and try to say it in the minimum amount of words. Prefer sentences that convey information ("V is has a 10MB compiler" - we learned the size of V compiler) to sentences that don't ("V-lang is an extraordinarily powerful language that can help you create a variety of applications" - we learned nothing, since "powerful" is subjective, and all languages can be used to write applications). That will help you focus on communicating your ideas clearly and tersely, which will make your articles much more attractive to technical readers.
Good luck with your research and writing!
https://news.ycombinator.com/item?id=24481883 (144 points, 191 comments)
https://news.ycombinator.com/item?id=19403271 (191 points, 182 comments)
https://news.ycombinator.com/item?id=19526924 (61 points, 101 comments)
https://news.ycombinator.com/item?id=20229632 (146 points, 137 comments)
https://news.ycombinator.com/item?id=21296855 (123 points, 91 comments)
https://news.ycombinator.com/item?id=20250990 (180 points, 155 comments)
https://news.ycombinator.com/item?id=20258485 (63 points, 33 comments)
https://github.com/vlang/v/releases (releases) https://modules.vlang.io/ (modules) https://github.com/vlang/v/blob/master/doc/docs.md (documentation)
It’s a great language, though. Looking forward to using it in the future.
Can you link to the pg benchmark you did? We need to fix this asap.