[lelanthran]

> > languages without types tend to grow them, like PHP in 7.4 and Python type annotations

...

> Not everyone shares that opinion. See ruby.

All programming languages that have values (i.e. all of them) have types, because you cannot have a concrete value that doesn't have a type. This includes Ruby.

The only difference is whether the language lets you annotate the source code with the expected type of each value.

This is why you observe that all languages trend towards visible typing: The types are already there and it's only a matter of whether the language lets the programmer see it, or lets a linter enforce it, and everyone likes linters.

> So the claim "tend to grow them" ... it is not completely wrong, but it also does not fully capture an independent want to add them. It comes ALWAYS from people who WANT types.

Maybe you misidentified where the type declaration is coming from? It might not be coming from people who want to see types in the source code, it most probably is coming from people who want a decent linter.

In 2026, programming without type-enforcement is like programming using an LLM; it's quicker, but less safe.

[jerf]

I also add the observation that while the dynamic typing languages are all growing in the direction of the statically-typed languages, no statically-typed language (that I know of) is adding a lot of dynamically-typed features. If anything the static languages trend towards more static typing. Which doesn't mean the optimum is necessarily "100% in the direction of static typing", the costs of more static typing do eventually overwhelm the benefits by almost any standard, but the trend is universal and fairly clear.

I kind of think there's room for a new dynamically-typed language that is designed around being fast to execute and doesn't cost such a huge performance multiple right off the top, and starts from day 1 to be multi-thread capable, but on the whole the trend is clearly in the direction of static typing.

[lelanthran]

> I kind of think there's room for a new dynamically-typed language that is designed around being fast to execute and doesn't cost such a huge performance multiple right off the top, and starts from day 1 to be multi-thread capable, but on the whole the trend is clearly in the direction of static typing.

Other than the "new" qualifier, Lisp supports all of that - SBCL compiles to native code, ecl/gcl compile to C (IIRC), etc.

[SAI_Peregrinus]

Some languages have only a single type, e.g. BrainFuck only has "byte". Shells tend to only have "string" as a fundamental type, and some helpers to do things like split strings on a separator & iterate over the elements or to treat strings as numbers to do arithmetic. Such single-type languages tend to be esoteric and/or difficult to program in, since every sort of data manipulation not supported by that type has to be done at runtime, by the programmer.

[lelanthran]

> Such single-type languages tend to be esoteric and/or difficult to program in, since every sort of data manipulation not supported by that type has to be done at runtime, by the programmer.

It depends; I recall programming in Tcl in the late 90s, and that has only the string and the list as datatypes, but it felt very powerful, like Lisp but without the easy syntax.

[SAI_Peregrinus]

Powerful, yes. Easy to program in, no.