Mmmh yes and no. Some languages truly do have more/less restrictions. For example, a garbage collector is the compiler/runtime taking on more work to avoid the

Mmmh yes and no. Some languages truly do have more/less restrictions. For example, a garbage collector is the compiler/runtime taking on more work to avoid the restrictions of proper memory management. This is in some sense analogous to the C++ vs Rust debate. Borrow checking allows the compiler to statically verify whether the program is memory safe. Like statically verified types, it turns a class of undesirable runtime behavior into a compilation failure. Ofc, this is a restriction that may be undesirable, which is why you can turn it off with 'unsafe'. Python and Java though... do you really have that much more to worry about in Java? In my eyes, you've got your problem. Regardless of your language choice, you can write a pseudocode algorithm for it. Terms in your algorithm have types already. When we translate this algorithm into python/Java, the types of the program need to match the types of our pseudocode. Regardless of whether we get feedback on errors at runtime or compile time, we just need to get the types right. I'd prefer my error at compile time. The benefit is tiny for short scripts, but becomes massive when working on a large code base. What about Java (being a "systems" language) makes you worry about so much more than Python (the "scripting" language)? There are definitely differences, but I don't think they stem from this systems/scripting dichotomy that's intrinsically linked to whether you check your types at compile or run time.