The parsing rules for templates alone probably make a decent door stopper. They can also trivially kill compile times. The bloat from page long symbol names also isn't something to ignore, just std::map<std::string,std::string>::find() results in a decent chunk once the compiler is done expanding it.
> Java
That is a can of worms, haven't professionally worked with Java in some time, but from memory:
* Compile time only, reflection or serialization heavy code will get raw Object types, yay type safety.
* They do not support primitive types, resulting in object boxing and null-ability issues by default as well as third party copy paste libraries that provide collections specialized for primitives.
* You cannot create an object or array using a generic type as that is unknown at runtime, as result some methods require a concrete array as argument just so they can create their own array with the correct runtime type.
* It is fully backwards compatible, so nothing will tell you if you have a compiled library that uses raw types somewhere in your application dumping Integers into a List that should only contain Strings.
* Calling code has to verify object types using runtime casts, you may not want to pay the cost of that.
I could probably go on ...
> Python
Aren't those just hints that the interpreter completely ignores? I have a python 3 toy project that could have benefited from better type checking - the contents of its sqlite database are a mess.
The parsing rules for templates alone probably make a decent door stopper. They can also trivially kill compile times. The bloat from page long symbol names also isn't something to ignore, just std::map<std::string,std::string>::find() results in a decent chunk once the compiler is done expanding it.
> Java
That is a can of worms, haven't professionally worked with Java in some time, but from memory:
* Compile time only, reflection or serialization heavy code will get raw Object types, yay type safety.
* They do not support primitive types, resulting in object boxing and null-ability issues by default as well as third party copy paste libraries that provide collections specialized for primitives.
* You cannot create an object or array using a generic type as that is unknown at runtime, as result some methods require a concrete array as argument just so they can create their own array with the correct runtime type.
* It is fully backwards compatible, so nothing will tell you if you have a compiled library that uses raw types somewhere in your application dumping Integers into a List that should only contain Strings.
* Calling code has to verify object types using runtime casts, you may not want to pay the cost of that.
I could probably go on ...
> Python
Aren't those just hints that the interpreter completely ignores? I have a python 3 toy project that could have benefited from better type checking - the contents of its sqlite database are a mess.