A lot of the actual Next-Big-Thing-ism seems to be coming from excited users rather than the author himself. There is a GitHub issue entitled "Very long term consideration: what it takes to get a language adopted by Google?"; there are others about getting "parallelism & concurrency for seamless local and distributed programming" and similarly extraordinarily lofty goals. People love being part of the winning project, and the overall hype history has drawn them like moths. That's OK, they can all go hang out writing V programs and wishing upon stars. It probably shouldn't bother people as much as it has.
When should we "police people feeling proud", then? Here I think there's not so much harm. Legally speaking, pretending he's in my jurisdiction (AU) for a moment, seeking donations can be trade or commerce, and then a bunch of consumer protection laws may apply, esp. ACL s 18. But you still need people who feel they've been wronged. Show me someone who tanked a heap of money into it on the pitch alone and I'll change my mind, but I don't think that's happening.
On the point of design vs actual quality, you can get an idea of OP's perspective by browsing through the GitHub issues. To be fair, the project is only a few years old, but some of the issues there are simply alien to me. It just doesn't seem like it was written in a language that has the features V has. Every new feature seems to have missed matching an enum variant somewhere. I don't understand how a compiler could exist that appears NOT to be made of building blocks that don't completely break when you add new features. I just can't relate many of the errors people get to a "Parse -> Valid Syntax -> Type Checker -> IR -> ... IRs ... -> Machine Code" progression. This is what makes me think it's not going to survive very long -- those kinds of bugs don't simply stop cropping up.
I am optimistic about the future though, so I continue writing and changing V programs (the V compiler itself is a V program mind you)... I am not in the habit of wishing upon stars (or other people), for something that requires just thinking, engineering and time.
p.s. PRs are welcome.
If I were you though, I would stick to coding, your prose is hard to read - at least try to use proper punctuation and spacing.
This project is very much in the seeking ground phase, so having a bunch of hacks is very appropriate. If it turns out useful, then people will fix things. If it turns out not to be useful, then oh well.
The danger of course if there are show stopping bugs which prohibit the transition from interesting project to useful project.
The V language looks beautiful (like an improved version of Go). There's always the chance someone will design something that's too complicated to develop, but that's the same with web design.
You can have a designer say, create a great UI but if they are not aware of the underlying limitations of the tech it can create a lot of headache. This may be even more relevant for language design and implementation. Ideally you have 'all-rounders' around for these issues.
It proved empirically, that compilation does not need to be slow, if the language is simple and carefully designed. Go is also a good example.
Computers are now several orders of magnitude more powerful.
We do NOT have to wait for compilation of simple programs in 2020. In my opinion, waiting is more of a symptom of the current obsession with optimization, and disregard for ergonomics, than a fundamental CS result that is set in stone. Compare for example compiling a program with gcc and tcc (without optimizations, so that they are on equal grounds, because tcc does not strive to do optimizations, but strives to be fast and tiny) .
tcc is usually 4-5 times faster.
I'd be interested in hearing the critique of language, features, claims. Not sure if the implementation details are relevant to end users of language.
The author has been doing periodic reviews of the development of the language: https://christine.website/blog/vlang-update-2020-06-17
V is mostly vaporware with a lot of bombastic marketing.
Have you tried it yourself?
It takes just a minute to clone and build it, if you already have a working C99 compiler like gcc on your machine.
Edit: I would like to add that I once had your optimism and enthusiasm for my projects. I didn't quite manage to achieve them, but I got an awful lot further than most would have predicted and I learnt a great deal in the process. So all power to you.
Perhaps you could show him the way by sending in a pull request or patchset to the project to verify your expertise in fixing these 'annoying' bugs and properly writing a compiler.
Patches are welcome.
I have an idea, let's create a new programming language! I'll be the "ideas" man and come up with syntax ideas. You work on the compiler backend ok? And we'll split the fame 80/20 since I'm the face of the project, you know?
If it's not low-level, you have to make a bunch of implementation decisions - how do your language's killer features work under the hood??
For just one example, for V, the author reuses Go's `go` keyword to launch a new coroutine/green thread. What algorithms do you use to share work between threads equally? What data structures do you use to represent those? What's the right balance between latency, throughput, memory usage, etc etc?
Many common language features are non-trivial to implement, even with the help of the LLVM IR (which I think is wonderful).
A. W. Appel, M. Ginsburg "Modern Compiler Implementation in Java" (2007)
S. Muchnick "Advanced Compiler Design and Implementation" (1997)
The last book focuses entirely on program analysis and optimization. It even has a chapter on optimization for the memory hierarchy! Of course, since it's a rather dated book, the specific details in that chapter are mostly useless today, but the rest is solid.
However, those books mostly cover imperative languages (although Appel & Ginsburg devote a chapter on functional languages, both of strict and lazy variety and discuss some optimization challenges), so if you want to learn about implementing functional languages...
S. L. Peyton Jones et al. "The Implementation of Functional Programming Languages" (1987)
A. W. Appel "Compiling with Continuations" (1992)
Holy fatcats, those are some old books! But sadly, I am not aware of more modern ones. Try searching for papers on the topics that interest you in particular, I guess (for example, there are several papers that discuss appropriateness of using CPS as IL: "Compiling with Continuations, Continued", "Compiling without Continuations", and "Compiling with Continuations, or without? Whatever". Yes, the puns seem to be the noble tradition in the PL implementation circles). The first book starts as a general introduction but starting at about the middle firmly steers into implementing a lazy languages. The second is pretty much a description of how SML/NJ compiler was made, based on its state in about 1991, of course, and has some interesting benchmarks on efficiency of different implementations of closures.
Plus, there are lot of random pages on the web with resources for various compiler implementation courses from different universities. For one arbitrary example, https://course.ccs.neu.edu/cs4410/