7 ms·

'Every possible error' could you explain what you mean by every. Additionally how many percentage of errors relate to typing and are solved by static typing? D

'Every possible error' could you explain what you mean by every. Additionally how many percentage of errors relate to typing and are solved by static typing? Don't get me wrong, I have really used C, C++, Java, C# and Ruby for a lot of projects. In my experience basic "types" are reminiscent of cpu architectures; they are a small subset of categories or classes. Beyond standard library you have a lot of risks in correctly programming the business domain. So atatic types don't help me much.

the_af 11y ago
Of course, you always have lots of risks in correctly programming the business domain. Because this is related to human communication, analysis, expectations and an understanding of the requirements, this is a very hard problem in software engineering, and one that cannot be solved by programming languages. That said, static types do indeed help with other problems in software development. If nothing else, writing software using a language with static types means there will be fewer tests you should write to catch silly errors, leaving you free to focus on the truly hard parts of your problem domain; in some sense you can consider types as a kind of test the compiler automatically writes for you. Because powerful type systems can encode a lot, I'd say the answer to "how many errors relate to typing" is also "a lot". For example, do you consider a NullPointerException in production an error? I do, and I've seen plenty of them. Also, consider that Go is probably not the best exponent of static typing out there, so you should be careful not to confuse "flaws with Go" with "flaws with static typing".