I agree with a lot of your thoughts. Here are some areas where I disagree
1. "uninitialized var usage is error": unfortunately impossible without at least one of the following compromises: Automatically initialize variables (wastes CPU); False alarms (see Java); Built-in formal proof system; or, Require compilers to solve the halting problem.
I don't think this is true. It should be pretty easy to detect if a variable is initialized or not. I can potentially see how a false alarm would arise, but I don't think that matters in practice. (All the situations I'm imagining involve writing bad code)
10. Multi-file module: May lead to unmaintainable code
Go does this already and it is fine.
12. Build process difference: Theoretically could speed up compilation. I'm worried for social reasons. In module-based languages, we tend to fall into module hell: one symptom being the infamous 20-page stacktrace (see: Java, Clojure, etc.) The nature of C's #include incentivizes shallow dependency trees (a very good thing).
I can see why this is a concern, but I think it is more a problem with JVM languages because of the type of programming Java encourages.
14. Tooling: This shouldn't be part of the language, it should be separate.
I thought this way too. Then I used Go and realized the huge benefit tooling integrated into the language provides. (Go has other problems, but tooling is not one of them).
I don't think this is true. It should be pretty easy to detect if a variable is initialized or not. I can potentially see how a false alarm would arise, but I don't think that matters in practice. (All the situations I'm imagining involve writing bad code)
It's easy to trace the code-paths between a variable's declaration and its usage, as long as those don't involve procedure calls. Then that problem becomes "static-analysis complete".
Comments
I agree with a lot of your thoughts. Here are some areas where I disagree
I don't think this is true. It should be pretty easy to detect if a variable is initialized or not. I can potentially see how a false alarm would arise, but I don't think that matters in practice. (All the situations I'm imagining involve writing bad code)
Go does this already and it is fine.
I can see why this is a concern, but I think it is more a problem with JVM languages because of the type of programming Java encourages.
I thought this way too. Then I used Go and realized the huge benefit tooling integrated into the language provides. (Go has other problems, but tooling is not one of them).
It's easy to trace the code-paths between a variable's declaration and its usage, as long as those don't involve procedure calls. Then that problem becomes "static-analysis complete".