Hello V-Lang(blog.hackersreboot.tech) |
Hello V-Lang(blog.hackersreboot.tech) |
- 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")
Some tools in pure V: 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)
- profilerThe 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.
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).
https://github.com/vlang/v/blob/master/doc/docs.md#pure-func...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?
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.
> 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.
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.If you notice, HN doesn't have zig1dot0, nim1dot0, or odin1dot0 accounts trolling any threads they can find pertaining to the language or alluding to why they aren't at 1.0 yet. Despite the fact that both Zig and Odin started around 2016 (3 or more years before Vlang) and have yet to achieve 1.0. Zig only managed self-hosting this year (2022), after more than 6 years of existence. Nim took 11 years to reach 1.0 (created 2008 to achieved 1.0 in 2019).
Add to this, the incessant and demonstrably false claims that V is vaporware or fake despite it having over 90 releases, applications written in it, and thorough documentation about the language.
https://github.com/vlang/v/releases (releases) https://github.com/vlang/v/blob/master/doc/docs.md (documentation) https://modules.vlang.io/ (modules)
By the way, types in V are zeroed by default. Zeroed means that they are assigned default values. Empty string for string types, 0 for integers, and false for Boolean types. When not sure what to initialize variables with, it is recommended to make them mutable, so to be updated as needed. In V, you don't assign null or nil. There isn't any *ptr = NULL or Var := nil. That is the context in which they are referring to.
Regarding autofree/gc, here's a good summary from another comment here:
That just strikes me as youth and inexperience
And HN has a hatred for Vlang because arguably it start off in the wrong foot with too many over promising features. I thought we should give Vlang some benefits of doubt. Instead HN simply shoot down all Vlang submission. And it only takes a few people flagging it for it to disappeared from the front page. Yes I dont think it is fair. I wish we can all submit some obscure, unknown programming language to the front page. Unfortunately I am not sure what the solution to that would be, may be email @dang about it?
yes, the os is being developed in V, and it can already run bash, GCC, G++, and Doom.
https://github.com/vlang/vinix
the person working on it, is an osdev, and not a compiler developer
I'm not a professional coder though. I only knock together hacky stuff for my own purposes. So I have to bow to the superior collective opinion on HN when it comes to the more esoteric qualities of any language, such as its memory handling, efficiency, etc.
So I am a long way from being the 'Hater' half the comments seem to suggest. Although the younger generation are hypersensitive these days that just disagreeing with someone else's opinion is enough to have you accused of 'hate crime'.
PS: I've also been dabbling with Crystal, which has for me the nicest syntax out of the Go / V / Crystal triumvirate that I keep drifting between, in my quest for the "One True Language to Rule Them All" that I can learn relatively easily and use for my personal hacking needs. Unfortunately Crystal suffers from a lack of tooling and some of the most unhelpful error messaging I've come across.
So there you go. That was some love for V.... or was it a 'hate crime' against Crystal? It's so hard to not cause offence, these days.
You shouldn't do that. There's a lot of misinformation regarding V on this site.
Always best to try things yourself, with V it's very fast and simple.
The absolute dichotomy being "doers" and "criticizers" is false. Linus could criticize things just fine.
Healthy people saw V, maybe read about it, saw the great promises, and thought "Ha, that sounds unlikely, but it's not a bad idea, it would be insane if this worked! Shoot for the stars, aim for the moon.".
For others, the promises were outrageous and anything remotely close to them "impossible". I don't get why it got personal for some of us, and it's stupid how involved people were over the years (hey Xe, you're so skilled, why waste your energy) into bashing this random project.
I don’t think it is like that anymore …
For example, the performance of V is measured on a debug build, without vlib cached, without vfmt disabled, with a 10x slower backend.
Here's V compiling itself in 0.3 seconds:
https://www.youtube.com/watch?v=pvP6wmcl_Sc
Also complaining about not running on all Linux flavors on day 1. Right now V runs on literally everything.
And so on.
That's why I asked to list the specific claims the poster had in mind here in the comments.
Citation needed. Or is the source for that claim the same as that for V benchmarks?
> I think it is something that should be ignored until it dies into obscurity
[see Kickstarter et al.]
300+ contributors.
Can someone share why this guy and vlang are so hated? It seems like he is ironing out the kinks even years after the hate keeps piling on.
He keeps this up he's going to win.
Looking at the homepage and the projects it feels like everything is ready and, if the claims were true, it would be the most ground breaking language of the last decades. When you go to look at the code or try to run something you find out: - some things are still closed source - some are broken - some are wins from C
It's a great strategy for collecting a check from VCs and I wish the author the best of luck, but it won't fly with developers.
What is also very interesting, is that when various trolls make their derogatory claims or bash on his creation, he responds to them with facts and references. Many of them never respond back and run away.
This is correct.
> Also, the choice of Boehm GC is a little bit disappointing
Which one would you recommend?
> Almost all claims of the usability/stability of the language seems to come from the main creator himself
The creators of Vinix and vsql don't have any issues with the usability/stability.
boehm is conservative. this is a costly and very unnecessary implementation for a language which already has a compiler and knows explicitly which values are pointers.
We'll have our own GC in the future anyway.
The problem is that in the initial releases the "high goals" were listed as "features" of the language, not as planed improvements of the initial implementation. So even now when I read a list like in the article, I'm not sure which are already implemented and which are just wishes, but after the initial bad impression I'm not bother to check.
I'll make it more clear on the website.
There's already a comparison to Go, the language V is most similar to:
Quite a lot of improvements.
V is basically about having the performance of C, the ease of use of Python, the simplicity of Go.
The feature differences in list form are helpful; but the priorities and motivation for individual features would also be interesting; e.g. why is "variable shadowing" bad and why is the V approach better, and how can smaller runtime and binaries smaller by a factor of 100 be achieved with a feature set that is at least 80% the same as Go? Does this really have to do with the language definition, or rather with the implementation?
For example, Rust has 8000 open/35000 closed. Yet it's a very mature language.
V is very stable for its age. The compiler can build itself since the release (it now has 220k lines of V!) and we have big projects like the Vinix OS written entirely in V, and it can already run GCC/g++ and Doom for example.
I thought it was a gag and only these comments make me think it might possibly be a real language.
So just that would be enough for me to use V.
Variable shadowing makes code more bug prone and confusing.
As for the size: V uses system's official API (libc), including networking. Go has their own libs that have to be statically linked in to the binary.
You don't need an article to clone the repo, build the language in <1s and play with it.
Autofree works:
https://www.youtube.com/watch?v=gmB8ea8uLsM
But it's not finished yet. We saw a better performance with a GC (due to all the extra copying autofree has to do), and made it the default.
I've always been anti-GC, but V is so minimal and doesn't result in many allocations in the first place, GC works really well with it.
In the end the user will have full control over how they want to do memory management: manual, autofree, gc.
On vlang.io I can find this:
>Most objects (~90-100%) are freed by V's autofree engine: the compiler inserts necessary free calls automatically during compilation. Remaining small percentage of objects is freed via GC.
So it's been 2 years and it's still unfinished, and you just use Boehm GC instead (from what I understood). Isn't your landing page a little misleading? This is the problem with V: a lot of grandiose claims but at the end of the day you use a GC used in every other toy language.
Note: right now autofree is hidden behind the -autofree flag. It will be enabled by default in V 0.3.
Using gc means it's a toy language? Got you.
> No things are closed source. Never have been.
That's not correct. I seem to remember that when V was released initially, the compiler was available for download in binary form only. The source code was only released later on.
So saying now 2.5 years later some things are closed source is ridiculous.
What things are broken for you?
What claims are not true?
it's on the website and in the video I referenced here
(I think you are the author, or at least involved in the language? I don't want to come off as simply bashing your language. Most people here seem to do enough of that... Definitely didn't try it out enough to have any opinion on the advanced features mentioned. I enjoyed the Go-like syntax with different ideas though. So definitely keep going)
We'll make it stable this year.
It has tradeoffs, for the project developer such as the burden of maintaining two significantly different paths for codegen, and for the project user such as the need to trust that these different codegens are largely functionally equivalent (exposing and fixing a bug in debug means it would have been but now will not be present in release). But the tcc approach is arguably one of the better ways to minimize the negatives in this tradeoff, compared to cranelift, etc., as tcc is a small but popular enough project in general usage, meaning it has some battle-testing.
And I think the point about projects that "work fine" was quite reasonable, just showing there has been a non-trivial amount of battle-testing. There is now some basis to claim that the project is not full of trivial bugs, to the point of making it useless. Nowhere was it claimed this was a proof of the absence of all bugs -- that you included the Dijkstra quotation in this context is honestly quite humorous.
My understanding is that there has been some drama in the V community in the past, especially around the feature set and release timeline and promises from its author, but I don't see the justification for all this pompous negativity when it is finally out in the wild, warts and all, but showing some nice capabilities at the same time. I don't plan to use it for any hobby projects myself right now, but if I wasn't in the middle of using a different up-and-coming language with some of the same goals, I might.
It would be absurd for someone to write a frontend to LLVM then claim that their compiler is as fast as LLVM. V uses TCC - TCC is fast at compilation, not V. V is fast at transpilation, but that's not what the author has claimed.
> that you included the Dijkstra quotation in this context is honestly quite humorous
Proving compiler correctness with tests only is like proving that your regex parses html correctly with tests. It's never gonna work.
The tcc backend is just a smart choice, and in TFA it is mentioned up front:
> V compiles ≈110k (Clang backend) and ≈1 million (x64 and tcc backends) lines of code per second per CPU core. (Intel i5-7500, SM0256L SSD, no optimization)
Thank you for a voice of reason :)
Compilation time is very important during development for the quick dev cycle (change, build, test).
You don't need to do -O2 builds dozens of times per day.
-prod (-O2) builds are definitely an order of magnitude slower, that's a fact.
I also disagree with others that using a different compiler is somehow cheating. Engineering is about winning and choosing the right tradeoffs. Being able to choose a faster backend for debug is one that all compilers offer. Most people spend most of the time living with -O0 builds because they need to debug the code. Heck, 90% of complaints about Rust compile times are about its performance making a debug build and it’s where that dev team spends its efforts. This criticism seems misplaced although it’s not clear to me why there’s this much pushback that most other languages don’t see.
20%-100% difference between gcc -O0 and -O2.
No, I mean it's a common characteristic of toy languages to use Boehm GC because it requires zero configuration to work, as it scans conservatively. It doesn't require you to emit stack maps or provide the GC with type metadata. Boehm GC means low effort (in regards to memory management). It's perfectly fine to use it, and it's an amazing library itself, but it contrasts with all the claims on the landing page (in the section "innovative memory management").
For example, I'm really interested in the Volt thingy - a lightweight, multiprotocol chat application:
https://volt-app.com/
But if you open the website, you can see that there is no Linux or Windows support, and most protocols are not yet implemented. I've searched for other projects written in V, and haven't found a single completed project.To the end user it doesn't matter how the binary was generated. Via LLVM or via a bundled C compiler.
The only thing that matters: getting that binary after compilation and getting it fast.
Writing an interpreter is a huge task. It works well without it. Actually I'd say it's quicker, because interpreters have startup costs.
- No null
Then what is `voidptr(0)`?
- No global variables
https://github.com/vlang/v/blob/master/doc/docs.md#global-va...
At least add "by default" to the web site.
- No undefined values
Which is done by initializing all values to 0. Probably not a good idea to do that for references though. (See also "no null values")
- No undefined behavior
`*voidptr(0)` is accepted by the compiler. Unsigned integer overflow is accepted by the compiler and UB in the generated C. How can V generate C code free of UB when it can't even generate C code that compiles all the time?
- Pure functions by default
Excluding I/O, one of the biggest sources of impurity, from your definition of pure is useless.
- Generics
You don't actually have generics, you have templates. Kind of ironic since Go has actually added generics before V has managed to get a 0.3 release out. The distinction is this: with generics the compiler is able to validate that the generic code type checks prior to substitution/monomorphization. With templated code, it's not possible to perform type checking until the concrete types have been instantiated. V implements templates with all the drawbacks including code bloat and inflated compile times that comes with it.
You may find the public `go2v` work interesting. It's being worked on by some other folks in the community: https://github.com/vlang/go2v
I found this in the docs:
>Autofree is still WIP. Until it stabilises and becomes the default, please compile your long running processes with -gc boehm, which will use the Boehm-Demers-Weiser conservative garbage collector
so why do you pick one over the other?
the language is still at 0.2
Because the documentation recommends to use GC instead of auto-free which is "WIP".
I'm not sure how you can argue about that.
But even with the transpilation step, the V transpiler is still unable to output correct code on trivial examples, demonstrated in other comments. The fact that you have thousands of tests (Alex's words) and the trivial examples still fail, makes me completely sure that something about the whole approach is fundamentally wrong; which lead me to the "testing whether your regex parses html properly" comment. Tests are useless if the thing you're testing does not prove anything.
The fact that the author is pushing this unfinished mess as a completed achievement (instead of work in progress), without ever mentioning any downsides (except when presented with undeniable proof, at which point he makes up another justification for the issue), only shows the author's inexperience and disconnection from the community. V compiler is a toy project wrapped up in a pretty box to look like something serious. And when faced with criticism, Alex seems to turn to his three different accounts to argue with the commenters, instead of reading the damn Dragon Book and fixing his damn compiler.
To me, personally, V language is the perfect example of an overhyped griftwork.
I can't assess the quality of V in general, and it may be lacking for my needs, but I know a lot of early stage language projects with a lot of trivial bug reports (I've filed a few), that are still engineering accomplishments capable of real usage. V seems to be in that league. Maybe it's near the bottom of that league, but you can just state that and leave it at that.
Maybe V has a bit of a "dirty main branch" approach, where other languages you're used to tend to instead have long-lasting branches for the work-in-progress stuff. I can see how that would be annoying, being able to use half-finished functionality, and I might not like it myself. Maybe the author claims features are further ahead than they really are -- that would be even more frustrating. But your criticisms are hyperbolic (denigrating the work as at the level of a CS homework assignment, and comparing it to almost entirely non-existent languages that are mathematically provably correct) and often seem vindictive (unlikely to be leveled at other highly analogous early days language projects). Any legitimate criticisms you have are lost in the vitriol.
The real deal are the many users, supporters, and contributors of Vlang. Where on GitHub (which is easy to check), it has more than many other newer languages (in various cases, more support than a couple of newer languages combined). Those people are the ones that count, who are using and improving the language daily.
"You can't put the genie back in the bottle", Vlang is firmly on the road to success and more popularity, despite its detractors and angry competitors.
If you want to look at GitHub, sure let's do that. I see perhaps 5 regularly active contributors, many more who seem to have left the community, and a downward slope of commit activity starting in April 2020. Hardly some vast hub of activity like your comment would suggest.
Given autofree has been practically untouched in 6 months with no major bug fixes to speak of, reality would seem to be that V is on the slow road to nowhere. At the current rate of progress, I doubt we'll see 0.3 before mid 2023 and 1.0 perhaps sometime in the 2030s. It's been 6 months since anything was completed on the 0.3 checklist: https://github.com/vlang/v/commits/master/ROADMAP.md
Maybe it's an impatient rival developer thing, but I'm not quite sure what your laser focused fixation with autofree is about. Its the V developers and contributors prerogative to work on it as they see fit. If you don't use Vlang, then why in the world are you so desperately worried about it?
> Given autofree has been practically untouched in 6 months...
A search on Vlang's GitHub for issues both open and closed shows contributor and developer activity regarding autofree within the last 6 months, to include the last week. Sample- https://github.com/vlang/v/pull/13823
> At the current rate of progress...
Can you show us the HN troll accounts and incessant badgering of the Nim developers, who started in 2008 and didn't achieve 1.0 until 2019 (11 years later)?
Where are the HN troll posts under zig1dot0 about Zig not being 1.0, despite starting in 2016 (3 years before Vlang)?
How about with Odin? Surely there are HN posts by odin1dot0, who is incessantly complaining to Odin developers and fans about slow progress? Since they starting in 2016, but have yet to reach 1.0 either.
Right, not trolling them, but have a vendetta against Vlang for whatever mischievous reasons. Is it jealousy over supporters, funding, or publicity? Who knows. The problem is the trolling is very obvious and excessive. Just give it a rest and allow the fans and supporters of Vlang their peace. Enjoy whatever programming language you are using or developing and don't sweat Vlang so much.
You wrote a bit further up: "The problem is that in the initial releases the "high goals" were listed as "features" of the language". The "features" you mention are obviously the specification. Have e.g. a look at how long they specified Algol 68 and when finally a compiler appeared; CPL is yet another good example; actually at that time Wirth was one of the few who delivered a compiler simultaneously with the language specification.
> Note: right now autofree is hidden behind the -autofree flag. It will be enabled by default in V 0.3.
I'm assuming because it's not considered good enough quality yet. It would be better to be explicit about that, but it's not unreasonable as-is.
I think it's only reasonable to mostly ignore autofree issues when assessing whether the language has trivial issues. Count all those issues as a single "autofree is alpha quality" conceptual issue. Counting each individual autofree issue in order to convey the sense that there is a critical mass of issues in the project in general is quite harsh, I think.
Your attempts to discredit the language are just sad.
You can expect a deep (and public) analysis of everything you've done with V in a couple of months. We'll see who's right.