[jakobnissen]

Very cool article! I think it does a good job of diving into the tradeoffs of a dynamic type system versus a static one.

I guess the conclusion depends on what priorities you come to the table with. If your starting point is that 1) code must be optimally fast (so no unions are acceptable), and that 2) programmers cannot be trusted to keep track of the types they are using, and so must always explicitly opt-in to union-like types (like e.g. Rust does), then yes, you will naturally conclude that implicit unions are a bad design.

However, if your starting point is the observation that scientists and engineers overwhelmingly prefer dynamic languages for data analysis, because all the boilerplate caused by forcibly, explicit type handling, then you naturally conclude that anything _other_ than explicit union-types are a complete non-starter for a language for technical computing.

One could write a just as legitimate and valid blog post about the 'tradegy' of Rust's enum types, highlighting how they inevitably lead to boilerplate and extensibility issues.

I would also argue against the author's claim that it's unrealistically hard to reach type safety (really: avoiding unions) in Julia. If you write a Julia function with good performance, it will continue to have good performance in the future - union types will not show up spontaneously. Sure, performance can regress if you refactor - just like in any other programming language. So you need to benchmark - like in every other language.