Wow. So much for statically typed language.
High-level aggregate findings:
Avg. Java application will throw 9.2 million errors/month
Avg. Java application generates about 2.7TB of storage/month
Avg. Java application contains 53 unique errors/month
The top 10 Java Errors by Frequency were:
This class of statistic seems very hard to interpret given that the domains in which Java is applied after quite dissimilar to the domains in which Julia is applied. If two languages have constant error rates per line of code, but there are very different average line counts per application, you’d get results like this even if the actual causal effect were exactly zero.
Imho, Julia can and should aim higher than Java in terms of static correctness checking (at the very least, because Julia is newer). At the moment however, the static analysis in Julia is still very immature, though hopefully JET will change that someday. A more capable type system would help too, such as the ability express the types of functions like map.
My point was: these are all run-time errors.
Depends on your DAG I guess - if the difference in average LOC is because the lower error language allows you to write shorter code I’d say you can have a causal effect with identical errors/LOC ratio.
Though I take your point, by definition all errors that arise in production with a strictly AOT compiled langauge like Java will be runtime errors 
.
The linked post also doesn’t say much beyond “log less redundant information” and “use our product”. For a very thorough exploration of the topic, see the excellent Literature review on the benefits of static types (which, despite the title, does not conclude anything of the sort).
I think the objection is that there is a fair amount of talk as if static languages prevented runtime errors entirely, which obviously isn’t the case. As long as people are clear on the fact that you both pay a big productivity tax and still don’t even rule out these kinds of problems, then fair enough, but that’s often not how the discourse goes. Of course there are static languages that are better at ruling out more runtime errors than this but the commonly used safe ones like Java and C# are not particularly good at preventing runtime errors, let alone C and C++ where it’s almost impossible to even write code that doesn’t exhibit undefined behavior.
The top 10 Java Errors by Frequency were:
- NullPointerException
- NumberFormatException […]
intriguingly, they do have there a different top-10 list for “a random selection of enterprise production applications over the past 30 days” and NullPointerException doesn’t even make top-10, so apparently some Java programmers manage to debug to a large degree, and “NullPointerException is to blame for all that’s broken in log files” isn’t true for those (debugged) applications. It’s good to use a language without that possibility, i.e. immune to Tony Hoare’s self-admitted billion dollar problem. It’s intriguing how different those two lists are, e.g. the latter having “StringIndexOutOfBoundsException” while both have “NumberFormatException” very high. Julia of course also has similar, and those shouldn’t happen with good (input) data validation.