If you're in a field where symbols have existing meanings, it's asinine to make your code clunky and harder to read by not using those existing meanings.
Python is my main language, and I struggled mightily to get my head around some aspects of Swift (e.g. randomly sticking question marks in different places until it was happy). As an aside, I also found the API incredibly verbose, the documentation poor, and Xcode to be a bad IDE.
In contrast, I enjoyed Julia - while the documentation isn't great either, after a single afternoon of learning (with plenty of Googling) I was able to port code over from Python and have it run perfectly.
That said, for machine learning a static type system (as they are now) is definitely not as much of a boom as in most other areas. Most of it involves tensor operations, and embedding things like it's shape in the generics will often lead to an exponential explosion of possible monomorphizations that the compiler will be forced to create. Even JIT languages like Julia will have trouble even though it only needs to compile when it's used (for example StaticArrays will get to a point when the compiler will take so much time that it's not worth it anymore). And even then I feel like most of the issues that actually take time are deeper than stuff like shapes and not naming dimensions, like numerical instabilities, hyperparameter tuning, architecture search and other stuff that gets more benefit of a language allowing quicker exploration.
The difference is that whenever a function in called in Julia, based on the type of the arguments the compiler can infer every type of every variable and arguments of every subsequent function, immediately compiling them down to machine code (unlike Python there is no such thing as a Julia Virtual Machine or even a Julia Interpreter outside of the debugger). Whenever you enter a function in Julia it becomes a static program, with all the properties of a static language (for example, you can't redefine types, you can define functions but the program can't see them since they are not part of the compiled code, you can't import libraries, and all types were already checked before running). That's why Julia is fast, and the language was entirely designed for working this way (there are lots of things you can do in Python that you can't in Julia to make this work).
No they are not. At least not for my definition of the term "strongly typed". Of course you can use a different definition, but if, as you say, "there isn't really a language" that does not fulfill your definition you might want to reconsider its usefulness. The point of classifying languages is mood when every fan comes along and says "my favorite language also has that, if you tweak your understanding just a bit".
julia> foo(x) = x^2 - 2x + factorial(4x)
foo (generic function with 1 method)
julia> @code_typed foo(4)
CodeInfo(
1 ─ %1 = Base.mul_int(x, x)::Int64
│ %2 = Base.mul_int(2, x)::Int64
│ %3 = Base.sub_int(%1, %2)::Int64
│ %4 = Base.mul_int(4, x)::Int64
│ %5 = invoke Base.factorial_lookup(%4::Int64, Base._fact_table64::Array{Int64,1}, 20::Int64)::Int64
│ %6 = Base.add_int(%3, %5)::Int64
└── return %6
) => Int64
If you're having trouble understanding that code_typed output and are familiar with C, maybe the output LLVM instructions are helpful:
julia> @code_llvm foo(4)
; @ REPL[8]:1 within `foo'
define i64 @julia_foo_17575(i64) {
top:
; ┌ @ int.jl:52 within `-'
%1 = add i64 %0, -2
%2 = mul i64 %1, %0
; └
; ┌ @ int.jl:54 within `*'
%3 = shl i64 %0, 2
; └
; ┌ @ combinatorics.jl:27 within `factorial'
%4 = call i64 @julia_factorial_lookup_17503(i64 %3, %jl_value_t addrspace(10)* addrspacecast (%jl_value_t* inttoptr (i64 140302197922128 to %jl_value_t*) to %jl_value_t addrspace(10)*), i64 20)
; └
; ┌ @ int.jl:53 within `+'
%5 = add i64 %4, %2
; └
ret i64 %5
}
Also what Julia does is not exactly type inference. It is rather a form of specialization. Type inference just gives you the type for an expression using just the syntactical representation. Nothing more.
As an example, if I was to invoke your function f with a floating point number, would Julia not happily specialize it for that too (assuming factorial was defined for floating points or taken out of the equation)? The thing here is, that a type checker needs to know about all the specializations a-priori.
Specialization will only occur if there are more than one "f" that handles your type (for example both "f" with a number and with float), and then the compiler will choose the most specialized (float). If you write your Julia program like you would with a static language (for example using over-restrictive types like just float and int) it will return the same error as the static language as soon as it can infer the types (when it leaves the global namespace and enters any function). Using over-restrictive types (and declaring return types for methods) is considered bad practice in Julia, but that's a cultural thing, not a limitation of the type checking.
It is not a type check if it happens at runtime.
But I understand your point, it's not really like a static language checking as it can't do without running the program, so it's better than fully interpreted (a unit test would catch errors even in paths it didn't take) but worse than static checking (as it can't compile 100% of the valid program at once).
Yes, but I could then define
bar(x::Int64) = x^2 - 1
Now I want to be clear that I'm not saying Julia is a static language, I'm just saying that once specialization occurs, things are much more like a static language than one might expect, and indeed it's quite possible add mechanisms for instance to make a function error if it can't statically infer it's return type at compile time.
Here's a hacky proof of concept implementation, but one could get much more sophisticated: https://stackoverflow.com/questions/58071564/how-can-i-write...