> Do the referenced compile times also include the time to compile from C to machine code
Of course.
Of course.
This is my first time running across V, and it looks like the HN community generally considers Vlang's claims misleading.
I found a factual (IMO) evaluation of Vlang's claims here: https://mawfig.github.io/2022/06/18/v-lang-in-2022.html#summ... . I've tried looking at your replies on the HN thread that discusses it, and what I gathered is that almost all of the deficiencies in that analysis are factually correct, but will be corrected in future, non-alpha, versions of Vlang.
Is that impression correct? If not, is there a centralized place where you debunk the claims? (I understand you're an open source contributor and might not have the time, but I'm just letting you know that I won't engage with the language further without seeing something like that).
If my impression was correct, I would like to say that I concur with the general HN sentiment that the state of the language is so immature/alpha as to really cast doubt on whether the list of claimed features will actually be achieved at some point in the future.
It'd be much faster for the author to submit a couple of github issues, they are fixed very quickly.
The state of the language is anything but immature, all claimed features on the website are very carefully worded, and are all achieved already.
Basically, if the author of that blog posts found (IMO) straightforward ways to invalidate Vlang's claims in ~1 month with the language, I suspect that I will also find _other_ ways to also invalidate Vlang's claims in a straightforward manner. While that's fine for an alpha stage language that I would contribute to, I currently don't have the interest/ability/bandwidth to contribute to a compiler project.
Also, I would like to recommend that you add language to the home page and the Github to the effect of: "Vlang is currently in alpha, and you might discover bugs that contradict some of the claims below. Since this is a WIP project, please contribute!" I literally couldn't Ctrl-F and find the word alpha.
Again, thank you very much for your open source efforts!
Btw, Volt's MacOS app doesn't work (neither the M1 version, nor the Intel). It just displays a blank white page.
No, because they are human labels, not computer generated titles for specific versions. Both are below 1.0 (so, not "production ready",constantly in flux, anything can change, here be dragons etc etc) and that's all that matters. If it's alpha/beta is the same, the project is probably not ready for you to ship to production for real users, right at this moment. That's what those labels are trying to convey.
Note: I'm not talking about V specifically here, but the labels themselves and software versioning in general
0.3 pretty clearly means it's not production ready software.
> 0.3 pretty clearly means it's not production ready software.
Despite the version 0.3 being visible, it is obvious that many more people than normal find that the wording on Github and the home page misleading (me included!). Obviously, this is a bit subjective, and I am telling you what I, personally, would have found a better signal to hone my expectations.
If you're interested in why that might be, I think it's because several other software projects I've used that are pre-1.0 don't have major bugs that interfere with their primary value proposition (like in Vlang). Off the top of my head, neovim, rocket (a rust webframework), mypy, reqwest come to mind.
> If I had done the analysis in that blogpost (whose factual accuracy you corroborated) myself, I would have come to the same conclusion.
No, you would not even be able to reproduce those bugs, because they have been fixed.
> don't have major bugs that interfere with their primary value proposition (like in Vlang).
can you list such major bugs here please?
I had previously said: "if the author of that blog post found (IMO) straightforward ways to invalidate Vlang's claims in ~1 month with the language, I suspect that I will also find _other_ ways to also invalidate Vlang's claims in a straightforward manner."
Unfortunately, I don't have a month of spare time, like that blogger, to put towards that effort.
> can you list such major bugs here please?
It might be (though I doubt it) that the major bugs outlined in that blog post (which your community promptly fixed) happen to be the final set of such major bugs that interfere with Vlang's primary value proposition. Like I said, I'm not willing to put a month of spare time to find out.
I will almost certainly check back after some time (probably more than 1 year), and hopefully by then I will have the spare time to do the inspection, or someone else will have done it. I sincerely hope that you and your community succeed in achieving your goals! Good luck!
Then please don't spread the misinformation that V has "major bugs that interfere with their primary value proposition".