strongly typed?

[fanf]

https://dotat.at/@/2025-08-28-strongly-typed.html

What does it mean when someone writes that a programming language is "strongly typed"?

I've known for many years that "strongly typed" is a poorly-defined term. Recently I was prompted on Lobsters to explain why it's hard to understand what someone means when they use the phrase.

I came up with more than five meanings!

how strong?

The various meanings of "strongly typed" are not clearly yes-or-no. Some developers like to argue that these kinds of integrity checks must be completely perfect or else they are entirely worthless. Charitably (it took me a while to think of a polite way to phrase this), that betrays a lack of engineering maturity.

Software engineers, like any engineers, have to create working systems from imperfect materials. To do so, we must understand what guarantees we can rely on, where our mistakes can be caught early, where we need to establish processes to catch mistakes, how we can control the consequences of our mistakes, and how to remediate when somethng breaks because of a mistake that wasn't caught.

strong how?

So, what are the ways that a programming language can be strongly or weakly typed? In what ways are real programming languages "mid"?

• Statically typed as opposed to dynamically typed?

  Many languages have a mixture of the two, such as run time polymorphism in OO languages (e.g. Java), or gradual type systems for dynamic languages (e.g. TypeScript).

• Sound static type system?

  It's common for static type systems to be deliberately unsound, such as covariant subtyping in arrays or functions (Java, again). Gradual type systems migh have gaping holes for usability reasons (TypeScript, again).

  And some type systems might be unsound due to bugs. (There are a few of these in Rust.)

  Unsoundness isn't a disaster, if a programmer won't cause it without being aware of the risk.

  For example: in Lean you can write "sorry" as a kind of "to do" annotation that deliberately breaks soundness; and Idris 2 has type-in-type so it accepts Girard's paradox.

• Type safe at run time?

  Most languages have facilities for deliberately bypassing type safety, with an "unsafe" library module or "unsafe" language features, or things that are harder to spot. It can be more or less difficult to break type safety in ways that the programmer or language designer did not intend.

  JavaScript and Lua are very safe, treating type safety failures as security vulnerabilities. Java and Rust have controlled unsafety. In C everything is unsafe.

• Fewer weird implicit coercions?

  There isn’t a total order here: for instance, C has implicit bool/int coercions, Rust does not; Rust has implicit deref, C does not.

  There’s a huge range in how much coercions are a convenience or a source of bugs. For example, the PHP and JavaScript == operators are made entirely of WAT, but at least you can use === instead.

• How fancy is the type system?

  To what degree can you model properties of your program as types? Is it convenient to parse, not validate? Is the Curry-Howard correspondance something you can put into practice? Or is it only capable of describing the physical layout of data?

There are probably other meanings, e.g. I have seen "strongly typed" used to mean that runtime representations are abstract (you can't see the underlying bytes); or in the past it sometimes meant a language with a heavy type annotation burden (as a mischaracterization of static type checking).

how to type

So, when you write (with your keyboard) the phrase "strongly typed", delete it, and come up with a more precise description of what you really mean. The desiderata above are partly overlapping, sometimes partly orthogonal. Some of them you might care about, some of them not.

But please try to communicate where you draw the line and how fuzzy your line is.

Comments

[simont]

The only true meaning of "strong typing":

https://median.newmediacaucus.org/fall-2011-v-07-n-02-caa-conference-edition-2011-sledgehammer-operated-keyboard/

[rmc28]

Ahahaha I love it

[andrewducker]

My experience is that most people mean "statically typed". But it's always good to agree terms before you get too far into an argument!

[fanf]

The original context for these thoughts was someone asking, how can this TypeScript library be type-safe when TypeScript’s type system is unsound? To which someone else replied, well TypeScript is strongly-typed.

And disentangling that little failure to communicate ended up touching on all five meanings! (Tho coercions are somewhat beside the original point.)

[andrewducker]

Ah yes, I can see that being a massive pain to untangle.

[simont]

Whereas I feel as if I'd most likely expect it to refer to the "few or no implicit coercions" aspect: a thing has one type, and it stays that type until you explicitly tell it to be another type (and perhaps also say exactly how to do the conversion, if there's more than one plausible choice). Like the way Rust makes you write out .into() even for something as harmless as widening a u32 into a u64, and Some() for turning a Foo into an Option<foo>, whereas in C++ the equivalent idiom just looks like a = b; in both cases.

But perhaps this has to do with what language background you're coming from? Among C or C++ programmers, I think if someone says "strong typing" they most likely mean "strong in ways that C/C++ is not", hence my emphasis on those explicit type conversions, and my de-emphasis of static typing which C++ had already. But maybe among (say) Python programmers it means "strong in ways that Python is not", and similarly for other languages.

[andrewducker]

That would make sense.

I've mostly seen it in the sense of "Strongly typed languages" vs "Weakly typed languages", where the former have defined types and the latter don't. (Say, C# and JS for examples of each) Used to be rife on HN, back in ye olden days, until someone pointed out the vagueness of the term, and "Statically typed" became the generally-used term instead.

I suspect it's very context-dependent. Which is why we shouldn't use it, of course!

[fanf]

But of course dynamically typed languages have defined types, it’s just that their values are typed, not their variables! Or, if you mean “declared types” there are of course statically typed languages that don’t need any type declarations (tho complete type inference is much less popular than it used to be). Perhaps I should promote “visible type annotations” to a fleshed-out bullet point… :-)

[bens_dad]

there are of course statically typed languages that don’t need any type declarations

Fortran defaulted to variables beginning with i, j, ..., n being integer and everything else was real. Fortran 77 allowed you to change the defaults and override them.

I wasn't trained as a compsci and found it odd that C was considered "weakly typed" when in POP11 (like Perl) you could change the value of a variable from a number to a string. In C it is not hard to store a value in a variable of the wrong type, but the program will then go and use the value stored in the variable as it it were the variable's type; much more rigid typing than Perl or POP11. Thinking of the blade of grass and the oak tree, does "stronger" mean "more flexible" or "more rigid" ?

Perhaps the proper distinction should be whether the values are typed or the variables ?

* When I started my career I used "fortran77" to tell the computer I didn't want Fortran IV !