Typing Is Hard

> People build huge programs in untyped languages

So? People build huge programs in typed languages as well. Whether people do something one way says nothing about how that approach compares to others.

> The cost of not having null is that all initialization and generic code gets much harder to write and work with

Could you provide examples of how lack of a null value makes these so much harder?

> the benefit is that once in a blue moon you get a hard to debug null pointer error

This is like saying that the only drawback to not having smart pointers in C++ is that once in a blue moon you get a hard to debug segfault. Sure, segfaults may be more common when working with raw pointers, but there are also substantial drawbacks in terms of mental overhead due to potential uncertainties about ownership/lifetimes.

In that vein, NPE/NREs are not the only drawback to a type system with null; the additional state space means mental overhead for the programmer and an increased risk of mistakes.

In addition, introducing universal nullability into a type system entails performance penalties. Null increases the state space of a given type, so if a type uses all of its bits (e.g., int) you need to introduce indirections (java.lang.Integer) or increase the size of the type (C# Nullable/int?) to shoehorn in a null value.

> Instead of just cleanly solving a few key issues they recreate a programming language in their types and even worse they force you to use said programming language if you want to code.

I'm not sure what you're trying to get at here. This seems to be a criticism of generics/similar mechanisms, but you seem to be fine with C#/similar type systems, which has generics and makes use of them?

What's especially confusing is that type systems with generics and null are precisely equivalent to type systems with generics without null, as all instances of nullable types can be replaced with Option/Optional/Nullable/etc. (with appropriate sugar for other operations, of course). So I'm a little lost as to what the problem is.

Perhaps via reference to https://en.wikipedia.org/wiki/BlooP_and_FlooP ?

EDIT: though, in that context, I would parse "out-floop" as a transitive verb meaning "to FlooP more, to a greater extent, or faster, than ", rendering its opposite actually "under-floop".

It's very relevant. In fact I would argue that type systems only address the simplest possible errors and do absolutely nothing about the most complex, time-consuming errors such as those related to unpredictable state mutations caused by multiple events being processed in parallel or having different parts of the code operate on the same instances.

In fact, I would argue that static typing encourages developers to define more complex function interfaces which creates stronger coupling between components in the code and this leads to instances being passed around/shared between more different files and this is more likely to lead to unpredictable mutations of those instances' state. It makes it easier for developers to neglect good separation of concerns.

Dynamic languages make it more difficult to keep track of complex instances between different functions and files so they encourage developers to pass more primitive 'pass by value' arguments; this results in looser coupling between the components.

Dynamic languages encourage more modular, more interchangeable code. This is why the most popular package managers of all time are based on dynamic languages like JavaScript (npm) or Ruby (RubyGems) and not on statically typed languages; it's not a coincidence.

Thanks, I don’t think I learned the about these concepts in college; granted, I dropped out because I am ADHD to the max. I usually adopt or adapt what I observe in others code, my old code, or idea from other fields entirely. I like to adapt and improve techniques I see and fit them best into my projects.