[eigenspace]

You apparently aren't familiar with dynamic languages at all. I'd recommend exploring more before answering.

In particular, you seem to be conflating being dynamic with being interpreted. Julia is an incredibly dynamic langauage whose JIT compilation strategy is essentially lazy AOT compilation. As soon as a method is called the first time, that method and all it's inferred dependent methods are compiled down to very efficient machine code and run. If one writes statically inferrable code, all sorts of code optimization, theorem proving and eliding will be done just like in a static language.

However, we also have the option to write non-inferrable dynamic code where the called methods depend on runtime values when needed. This will (obviously) come with a performance hit, but as long as you know what you're doing, it can be a great boon so long as you keep type instabilities outside of performance critical code.

> Julia is still pretty niche at this point, and just recently got tools as fundamental as a debugger.

Julia has had debuggers for ages. It's just that when 1.0 launched last year we moved to a new intermediate representation which broke all the existing debuggers. The old ones could have been updated, but it was decided that people wanted to start over from scratch having learned a lot of lessons from debuggers like Gallium.jl.

Julia is indeed a niche language. However, in the field of scientific computing, compared to Swift's ecosystem julia might as well be python. Swift has no scientific computing ecosystem to speak of.

[taharvey]

I'm not conflating. Just like Julia, Swift can JIT... after all both are built on top of the inventor of Swift's LLVM compilation environment.

That is not what I'm talking about. Nor am I talking about dynamic dispatch. Swift supports 4 different dispatch models from static to dynamic, depending on how the compiler optimizes.

What I'm talking about is a static type system. From Julia's documentation: "dynamic type systems, where nothing is known about types until run time".

What is fascinating, is ML/AI developers develop deep infrastructure to support ontologies for their target problems, but then forget to adopt the same for their code tooling. You can go though a series of proofs to demonstrate that you can't extract intent from a language that doesn't enforce it. And what is possible in a language's future can be expressed by how much intent can be extracted.

Like Julia, Swifts scientific computing ecosystem is still evolving. But keep in mind that Swift can call Python, C, objC & C++ directly, works in Jupyter notebooks, has already large general purpose open source library ecosystem.

[eigenspace]

Your comment that I responded to was making claims about the optimization opportunities available to statically versus dynamically typed languages and I believe those claims were false.

If I have a function f and I call f(x, y, z), julia will compile a specialized method of f based on the types of x, y and z, and then will do type inference and build a computational graph for all the computations carried out by f, de-virtualizing and often inlining function calls inside the body of f.

If type inference was successful, all types are known throughout the computational graph and the language has just as many optimization opportunities available to it as a statically compiled language and is free to do as much or little theorem proving as is asked for. The only major difference is that if type inference fails, the program can still run instead of erroring. It will just lazily wait until it has enough information to compile the next method.

For instance, consider the following:

    julia> f(x) = x + 2
    f (generic function with 1 method)

    julia> function g(x)
               for i in 1:100
                   x = f(x)
               end
               x
           end
    g (generic function with 1 method)

    julia> code_llvm(g, Tuple{Int})
    define i64 @julia_g_17491(i64) {
    top:
      %1 = add i64 %0, 200
      ret i64 %1
    }

I defined a function f(x) = x + 2 and then put that function inside a simple loop in another function g and then asked for the compiled LLVM code for g if x is an Int64. The compiled code is simply x + 200 because the compiler was able to prove that those two programs are identical. Obviously this is a simple example, but I assure you, julia's compiler is able to do some pretty impressive theorem proving and program transformations by leveraging it's very powerful (yet dynamic) type system. I fully agree that type systems are fantastic for expressing programmer intent, but I do not believe that the type system needs to be static to get the behaviour one wants. Dynamic type systems are strictly more expressive after-all and it's nice to be able to fall back on dynamic behaviour.

Of course Swift offers opt-in dynamism whereas in julia it's more just that a programmer is expected to write statically inferrable code if they want performance optimizations comparable to static languages. This is just a question of what defaults one prefers, but I think in many scientific and exploratory contexts, julia's default is preferable.