But my sense is that we're gradually swinging back around to static typing via gradual typing + mainstreaming of ML style features like generics, unions, records that are more expressive than the C/Java model.
In part, I think the move to mainstream more ML features is to finally try and address this.
Meanwhile Julia gives dynamic languages some of the same feel as static ones.
Both dynamic and static languages have benefits, so I don’t find it weird that they borrow from each other.
Personally I prefer opting in to use static type checking over opting out.
The error messages are not as nice as if the types were specified at the top level, but there's usually still enough static type checking to know whether the code will run or not before it runs, which is one of the big benefits of static type checking. The other benefit of static types is performance due to compile time optimisations, which Julia can benefit from if the functions are type-stable.
Do you have type constraints for generic arguments in Julia? I.e. when you're looking at the signature, does it ensure that the operations performed on values inside are going to work?
If I write
f(x :: Number) = x + 1
f(x :: String) = x * x
f(x :: Int) = x - 1
julia> f(1.0)
2.0
julia> f("hi ")
"hi hi "
julia> f(2)
1
> when you're looking at the signature, does it ensure that the operations performed on values inside are going to work?
I guess the answer depends on what you mean. Julia's interfaces are somewhat implicit, and we do not do ahead of time checks by default, so if I define my own type that is a subtype of Number, but that type does not have methods for addition, then f will error on that type.
However, the static checking package JET.jl will easily detect that this will happen statically at compile time.