The fastest JavaScript engines and LuaJIT are closer in speed to Crystal than Crystal is to C.
Granted - all these languages are really fast - and unless you're doing something INSANELY performance dependent and you REALLY know what you're doing - I think familiarity trumps all. You're almost certainly going to write faster Crystal code if you're a Crystal expert than you would write C, C++, or Rust.
There's a crazy amount of engineering effort that has to counteract a missing "this has one parameter and it's either a string or a float" annotation.
In practice if you don't have a world class well funded team - yes, static typing is necessary for performance.
It uses a method JIT so it is deterministic and easy to analyze unlike JavaScript.
You can lookup ahead of time how each function will get compiled with given input types.
You can't analyse functions like this ahead of time:
function foo(x)
x + y
end
It's very explicit in almost anything the language designers wrote from the beginning. Julia has always had it's language semantics designed around a JIT. Keep in mind, julia's JIT is not at all like JS JITs, julia's style is often called 'just ahead of time'.
For the you quote, the only thing causing a problem is the global y. Using global variables is very frowned upon in julia for this reason. However, if you write
function g(y)
function f(x)
x + y
end
end
If there's a point in the program where type inference fails to produce concrete types, then the compiler just generates code up to that point and then waits until the types are resolved at runtime, and then using the new runtime type information does static analysis going forward from that point until it either encounters another type instability, or the program is finished.
This is why writing code that isn't concretely inferrable can carry a heavy performance penalty in julia, but it's also why inferrable code can be so fast. The trick is just to keep type dynamism away from performance bottlenecks and you'll be fine.
Sometimes discipline must be enforced on the programmer.
Next generation climate models are built with Julia. You would not pick a slow language for such a high performance dependent task.
You're confusing dynamic typing and type inference.
As an implementation detail, it has a statically typed intermediate representation that's used for very aggressive and impressive optimization.
But that's an implementation detail, and is not what most people mean when they talk about a language being dynamically or statically typed.
> Julia is dynamically typed, feels like a scripting language, and has good support for interactive use.
Literally on the front page.
Absolutely yes. If you don't know the shape of your data at compile time then you're going to destroy your performance discovering and validating it at runtime.