[FacelessJim]

This feels a bit disingenious. All the languages brought as an example need some sort of handling of the `not found` case. In C++ and Go you need to check against null pointers (or don't but then encounter segafults), Haskell and Rust you are forced to unwrap the value. C also has to check against the error code or incur in errors down the line or worse subtler logic errors.

Missing this types of checks is also source of errors in dynamic languages, adding `1+None` as well as `1+nothing` will return an error if not handled properly. If you are absolutely sure your element will be in the array you have to encode it, for example

x = something(findindex([1,2,3], val)) # return value is Int now, or an error.

or even

x === nothing && error("oh no")

are enough for the compiler to correctly infer that x will just be an Int, and remove the Union.

Also, the claim that the only way to check for unfavourable Union types is to visually scan each function is just plainly false. There are many tools to do this sort of checks, just to name a few: @code_warntype, Cthulhu, DispatchDoctor

I do agree though that Julia has mainly users from academia, and therefore is less polished on the more pure software engineering aspects and tooling. But the disclaimer at the end feels just like the author is dismissing the whole language on false premises due to frustration with lack of support/ecosystem for his specific use case.

[cjalmeida]

100% agree. This is a low quality post both setting unrealistic expectations for a dynamic language and at times straight up making false claims.

Suggesting OOP as a solution is probably the most laughable “solution” though. What does this have to do with error handling and union type inference?