> It's amazing to realize that writing down the first thing that comes to your head is usually like 80% as fast as a good, performant implementation. (As someone who has done a decent amount of work in performance engineering for embedded platforms, I really enjoy squeezing out the last drop of performance from most programs, but doing this for every single first-pass at a program, like in Python, is rather annoying if this is what is needed to get a usable implementation.)
Yes, Julia is not necessarily faster than a good C implementation (that doesn't leak, etc), but, like Python, what would be a 300-line C implementation, where one has to somewhat carefully manage typing and the abstraction is really rather complicated for something that is mathematically simple, we can usually write 20 lines of very performant Julia that is 95% as fast.
Attempting to do something relatively similar in Python is often slow enough that giving a practical implementation essentially needs to be coded in C and interfaced with Python, where we return (again!) back to the same problem we had before: writing a 300+ line C file for something that should be rather simple, mathematically speaking.
Now that we're developing in Julia we can realize our designs as we envisioned them with very little code. Features like multiple dispatch have been a lifesaver for us. And we are getting performance that is quite close to C++. Now we're looking forward to using features like composable multithreading.
One could wonder "why not use python?" but for performance reasons one ends up with the 'two-language problem' which we wanted to avoid.
Other than Mir, there is very little to choose from.
D users put the language into a pedestal of language design, but that isn't what grows an eco-system, getting new users and libraries does.
I used to love the language, but so many mistakes have been made during the last 10 years, that it will hardly recover unless some company champions it, Swift/Kotlin style.
So after reading the release notes about 6 sec. of start-up times and people keep complaining about warm-ups, I am smirking about how Julia is a dynamic language when compiling & executing a script written in a static language other than let's say Scala/Rust/C++ can be comparable or even faster in some situations.
The warm-up period is definitely an annoyance, but a surprisingly small one. Even if it takes one minute to compile all the libraries and code I'm working on, my programming session is usually much longer than a few minutes, so that warm-up becomes insignificant as I keep the program alive during all the development process and any new addition are pretty much instantaneously compiled (unlike static languages that have to be frequently recompiled, and it's faster even compared to incremental compilation in languages like Scala) and at the same time running faster after warm-up saves time over the session compared to interpreted language as well. Never bothered with PackageCompiler.
It's a matter of different workflows, and since Julia isn't the same as the usual dynamic languages or the usual compiled languages, it's easy to end up with suboptimal ones especially at the start (which I assume does hurt the image of the language as first impressions are key). That said I'd definitely want the ability of creating small static binaries for deployment or end users (even if they don't help during development, which I'm already more than satisfied).