I think you're missing the point here Alex. The amount of work you've put in, the number of projects you've made, and the drive you have are amazing. Everyone w

I think you're missing the point here Alex. The amount of work you've put in, the number of projects you've made, and the drive you have are amazing. Everyone wants you and V to succeed but you make claims that are not true yet. You claim V has safety features but if it's trivially easy to exploit those safety features, then you don't actually have safety features. You claim V is as fast as C but there are many many many cases where V is slower than C. On average, V seems to be much slower than any compiled language. You claim V can compile a million lines of code in a second when that is not the average case. You claim V can do so many things but each time someone actually tries to verify those claims, it turns out there are many cases where it's not true or only true in one very narrow, specialized case. When people read "V compiles itself in less than a second", they expect V to compile itself in less than a second for the general case (not just one very specific case). When people read "as fast as C", they expect V programs to have the same runtime as equivalent programs directly written in C. When people read "no null, no globals, no undefined behavior, immutability by default", they expect there to be no issues with this 99% of the time. When people read "Despite being at an early development stage, the V language is relatively stable", they don't expect this number of issues. I could go on, but the V documentation is filled with this. In my opinion, if you keep going in this direction, no one will ever take V seriously. You might get some GitHub stars, you might get some inexperienced language developers helping you out, but if people can't trust V's claims, if V's claims continue to not hold up, no one will use V anything more than casually. The simple solution to this is to walk back your claims and preface everything as unstable which is more accurate. Your GitHub description should make it obvious this is an experimental language with many issues. You should only list features in your README which are true and work for the average or general case. Any other features can be listed somewhere else as in progress or testing. Toning down your marketing is all it takes to earn back some trust.