I'll be honest: my decision is that I will come back to Vlang after (at least) six months, and hope that someone does a similar analysis, or do that analysis myself, and then reconsider.
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.
Thanks! I honestly didn't know that, and thought pre1.0 software can be either beta or alpha, arbitrarily. Is there some decimal cutoff between alpha and beta?
> Is there some decimal cutoff between alpha and beta?
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
If I had done the analysis in that blogpost (whose factual accuracy you corroborated) myself, I would have come to the same conclusion. Fortunately, the internet allows people to publish blogs where they share such analyses, so that effort doesn't have to be duplicated.
> 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.
> It would take you literally a couple of minutes to try it yourself and see it all works.
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!
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.