They said years ago, when they last took a look. Just a thought, maybe just let all this go, people are complicated, you'll never please everyone. It's not worth the time trying. If anything you're giving them more ammo to prove them right about your attitude to negative takes. I'm not taking sides, just my opinion! :)
I think it is still useful to correct them. The language is not the same as it was a few years ago, it applies to every programming languages (depending on how far we go in time).
Agree. If there is no correction or counter, then this allows a negative narrative or falsehoods to be continually pushed. By people seeing that there is at least another side to the argument, it can promote fact checking, fairness, or open-mindedness.
I have no desire to get into a discussion. You can find plenty of details in feedback from people who have given your language a try over the years. Here's a blog post from September 2024[1]. A quick glance at the open issues yields [2], and many others if you search for "immutable".
To be fair, open issues are a sign of interest and people wanting to move the project forward, which is good. I think what you're trying to achieve is commendable, and I truly wish a language as you envisioned it existed. But it's really hard to take the project seriously when one of its core features is not well defined and causes confusion after 5 years of existence.
I remember running into similar issues when I tried it last year, but just didn't bother to document or report any of it. You can assume that for every person who creates an issue, there are 10x that amount who don't bother and move on.
Such discussions are always the same. You say there are lots of issues, but can never list one. And you point to articles that complain about V using libc or that C2V was released in 2022 and not earlier. It's 2025!
Our documentation is very vast and up-to-date and we try to keep it up-to-date. So if you say it's wrong/missing/outdated, you could post a couple of examples, so that we can fix it. That shouldn't be hard for you.
As for an issue you referenced, yes a pre-1.0 language has bugs. Thousands. Like all other pre-1.0 languages being developed. We fix them quickly (~9k fixed, ~800 open)
Like I said, I didn't want to get into a discussion. This is not the appropriate forum to discuss bug reports. I was simply sharing my experience with the project, which admittedly could be outdated by now, but those were my impressions from a few months ago.
What I don't appreciate is the implication that I'm fabricating this, or that I'm biased, as OP accused me of upthread. I think that the defensive stance that you and some of the people in the V community[1] have historically taken when faced with any sort of criticism continues to be detrimental to your project. Whether the criticism is a misconception or a flaw in the project, if a user is confused it's still on you to address that with documentation, a bugfix, or a friendly response, if nothing else. Most people are not actively making up issues for some Machiavellian reason. This "us vs them" mentality is barbaric.
As for users telling you what is wrong, it's delusional to think that it's somehow their responsibility and that it shouldn't be hard. Creating a bug report that clearly explains the issue requires time and effort. And what is to be gained from that if it's only going to be met with defensive arguments and hostility? Like I said, most people will not bother with this, and you should expect that most issues will not be reported. Most users will simply move on, but they will remember they had a bad experience.
Yes, projects in early stages have many bugs. All projects do. But maybe it would be wise to focus on stabilizing the core features the project claims to have, before moving on to building editors and operating systems with it? After 5 years there shouldn't be any confusion and unexpected behavior of core functionality.
The work done on V is truly impressive, and I do wish the language was successful. But I think that realigning some priorities, being honest about what works now and how well it works, and a major shift in tone from maintainers to users, would go a long way towards earning back the trust the project lacks. Good luck!
I didn't mean to accuse you of being biased, I was just calling you not to be in case you were. I am sorry it came across otherwise. Your point of view is just as valid as anyone else. Also the editor project is completely separate to the main V team, I suppose I help with V itself in my own small way by finding occasional issues and raising them with the core team, but I am not equipped nor frankly interested in putting my own efforts into the language dev itself, it seems pretty well staffed over there atm.
https://vlang.io
GC, sum types, result/option types, interfaces, no OOP, fast compilation.