With Java vs Go the little bits of forced correctness are more subtle than they are compared to dynamic languages or some of the less "modern" static languages (and less to do with types, though I could attempt to start a raging debate over the merits of interfaces versus traditional OO), but they do still exist. One example off the top of my head: if bracing.
Java:
if (state)
doThis();
doThat();
This type of error is not uncommon if you don't enforce really strict code-style standards or some sort of linting step that isn't part of the language proper.
Programmer A writes an if statement with one line because that's all that's needed at the time, programmer B comes in to expand the logic and is either just having a bad day or is more of a Python programmer dabbling in Java and so doesn't automatically see the error. Then programmer B dev-tests the code, but only when state == true, so he still doesn't notice the problem because he was expecting both doThis and doThat to be called anyway.
In Go this is an explicit compile-time error, all if statements require opening and closing curly braces. This is exactly the sort of thing, IMO, that might seem like an annoyance to someone who "knows what they are doing and just wants the compiler to stfu" (eg. younger, stupider me) but is, in the long run, actually really helpful for software correctness.
thanks for the example, it makes perfect sense to me.
That would be the same reason that when coding in java I moved from "how do I disable warnings" to "how do we automate findbugs+checkbugs for all devs" :)
Java:
This type of error is not uncommon if you don't enforce really strict code-style standards or some sort of linting step that isn't part of the language proper.Programmer A writes an if statement with one line because that's all that's needed at the time, programmer B comes in to expand the logic and is either just having a bad day or is more of a Python programmer dabbling in Java and so doesn't automatically see the error. Then programmer B dev-tests the code, but only when state == true, so he still doesn't notice the problem because he was expecting both doThis and doThat to be called anyway.
In Go this is an explicit compile-time error, all if statements require opening and closing curly braces. This is exactly the sort of thing, IMO, that might seem like an annoyance to someone who "knows what they are doing and just wants the compiler to stfu" (eg. younger, stupider me) but is, in the long run, actually really helpful for software correctness.