Let a Thousand Flowers Bloom

TODO: typey sounds silly, so maybe call it something else, like Ur-wrexlang: basically a platonic ideal that typey languages seek to instantiate; or an attractor that they're part of.

The idea of "strong" and "weak" type systems is contentious. What I will describe is often called a "strong" type system, but I'll call it a "typey" type system instead.

Consider a type system that involves: - first-class functions - tuples aka product types - linked lists - variants aka tagged enums aka sum types - universal polymorphism - existential polymorphism (through typeclasses)

Some programming language probably comes to mind, like Haskell or Rust.

If you've programmed in multiple typey languages before, I think you'd agree that writing typey code feels a certain way no matter the language. The type system begets a peculiar form of boilerplate, which often involves pattern matching; and if your pattern matching code grows too hairy, you can abstract it away with monads, until the monads grow hairy as well, and you have to offload even more onto the type system, straining it to its limits. As your code makes increasingly greater demands of the typey type system, it becomes apparent that you really need a theorem prover. And even the best theorem provers are inept, or else they wouldn't be under active development.

Typey type systems are all the rage in $CURRENT_YEAR, and every language that adopts one comes to more closely resemble its typey brethren. There's a typey language for the JVM, the BEAM, the web, for systems programming, for Ruby interop, and so on.

Perhaps it betrays a lack of creativity. But otherwise, what's the matter? Typey languages are far more safe than the alternative, or at least appear to be.

Someone else could make the case that they're not as safe as advertised, or that they make codebases more difficult to maintain, but lack of creativity is actually my main concern here.

When does it not matter that code is correct? Is there a valid use-case for a language like Perl or Ruby in 2025? Once a codebase reaches a certain size, or a project becomes sufficiently critical, why not rewrite it in typeylang?

Rewriting may get you stronger guarantees of reliability, but I would argue that these languages are far less fun when you realize how limited they are, and how they're all really the same thing.