The nice thing, is that as a julia programmer get to choose how 'fortran-like' things get. You often start off writing naïve dynamic code that is more like Pyth

The nice thing, is that as a julia programmer get to choose how 'fortran-like' things get. You often start off writing naïve dynamic code that is more like Python or Lisp, and then identify performance bottlenecks and optimize those. This prescription is familiar to Python programmers except the 'optimize this bottleneck' step involves leaving CPython and using Cython or Numba or whatever. In julia, you optimize your code by just writing slightly uglier julia code, not leaving the language. This has huge implications for 1) People 'looking under the hood'. Instead of having to read C as well as Julia, they only need to read Julia (albeit, more advanced, ugly technical julia code). This tends to greatly lower the bar for a julia user to become a julia developer and actively encourages learning more about the language. 2) Programs 'looking under the hood'. Code modification, injection and re-use is really common in julia and is part of what makes writing it so magical. Part of that is multiple dispatch code: https://www.youtube.com/watch?v=kc9HwsxE1OY https://www.youtube.com/watch?v=kc9HwsxE1OY but another major thing this enables is prevalent language wide automatic differentiation tools. Julia users tend to take it for granted at this point that they can take just about any function which takes in a number and spits out a number and then take a derivative of that code at compile time, no matter if that function was ever written with auto-diff in mind or if it ever knew about tools like Zygote or Forward diff. This sort of stuff would not be nearly as powerful in a language which did a lot of calling out to other languages to achieve performance. The entire idea of julia is trying to get as much expressiveness and dynamism as possible while still allowing for C/Fortran levels of speed.