You're saying that if Go had the same design flaws as C/C++, then it wouldn't be possible to write LLVM in it.
But Go doesn't most of the design flaws you mentioned. For example, there are no multiple Go compilers wildly diverging in what they understand. That's unique to C++. In Go, like in Java or C#, a compiler either implements the whole spec or it cannot be called a compiler.
Go also doesn't have the portability problems that have accumulated in C/C++ over decades.
Go doesn't have macros (which enable the mess that C/C++ code finds itself in).
Go doesn't have manual memory management, pointer arithmetic, array access is always bounds checked etc. - it's radically safer language than C/C++.
I also fail to see the logic connection between unused variables or unused imports and any of that.
Or how fixing the error caused by unused variable is a "maintenance nightmare". Count the number if #ifdef statements in boost and then let's have a discussion about what is and isn't a maintenance nightmare.
But Go doesn't most of the design flaws you mentioned. For example, there are no multiple Go compilers wildly diverging in what they understand. That's unique to C++. In Go, like in Java or C#, a compiler either implements the whole spec or it cannot be called a compiler.
Go also doesn't have the portability problems that have accumulated in C/C++ over decades.
Go doesn't have macros (which enable the mess that C/C++ code finds itself in).
Go doesn't have manual memory management, pointer arithmetic, array access is always bounds checked etc. - it's radically safer language than C/C++.
I also fail to see the logic connection between unused variables or unused imports and any of that.
Or how fixing the error caused by unused variable is a "maintenance nightmare". Count the number if #ifdef statements in boost and then let's have a discussion about what is and isn't a maintenance nightmare.