Underrated comment. Yeah, if you want C-like performance, you have to do some low-level considerations, that is unavoidable at some point. So the "speed of C, convenience of Python" is misleading.

However, for many, many small tasks, today's compilers are smart enough that you can express your idea in a high-level language and the generated code will be maximally efficient. The real killer feature of Julia is that, where ever you can gain maximal performance with high-level syntax, you can just choose to do that. A more correct but less sexy slogan for Julia is that it has the best performance/expressiveness tradeoff you have ever seen.

"A more correct but less sexy slogan for Julia is that it has the best performance/expressiveness tradeoff you have ever seen."

This I almost fully agree

That's still a massive selling point. In python, getting speed can be weird and counterintuitive. In C, a straightforward algorithm can be blazing fast. For example, finding the length of the longest word in a string, you can just iterate through the string keeping track of a few indices. In cases like that, where the obvious simple C function is incredibly faster than the same python, where does Julia fit in? Would that kind of naively written function be closer to C or Python?

In that case, it's closer to C in speed, and usually more generic and "easy on the eyes". I don't know much about C, but seem to recall that it doesn't play well with unicode, usually treating text as bytes. Here's an equivalent Julia example:

    function longest_word(st::Union{String, SubString{String}})
        len = 0
        start = 1
        @inbounds for i in 1:ncodeunits(st)
            if codeunit(st, i) == UInt8(' ')
                len = max(len, i - start)
                start = i + 1
            end
        end
        max(len, ncodeunits(st) + 1 - start)
    end

This takes about 8.2 µs for a 8.5 Kb piece of text on my laptop, but that only works on ASCII text and only treats ' ' as whitespace, not e.g. '\n'. For a more generic one, you can do:

    function longest_word(st::Union{String, SubString{String}})
        len = i = 0
        start = 1
        for char in st
            i += 1
            if isspace(char)
                len = max(len, i - start)
                start = i + 1
            end
        end
        max(len, i + 1 - start)
    end

This is 20 µs for the same text, so still only 3 ns per char. The underlying functionality, namely String iteration and the `isspace` function, is also implemented in pure Julia.

In general, if you code like Python (highly dynamic code with no consideration to performance) it will be closer to Python in speed, and if you code like C/Fortran (completely static, overspecified types) it should be closer to C in performance, the variance in performance in terms of naive implementations is pretty high. That means it's easy to get into Julia and start programming no matter your background, but idiomatic Julia (which it's not something you'll learn in a day) should be concise and high level like Python (and frequently more concise) and close to C in speed.

For example, what other dynamic languages do like verbosely typing everything doesn't really work in Julia (the compiler already knows pretty much every type even without hints), what works is treating the variable as a polymorphic container instead of a dynamic container: you don't know yet what type the variable has (only the behaviour), but whatever it is you should avoid changing it if possible (what they call type stability). Which is kinda why it might not be obvious reading proper high performance Julia code, as it is not something you do to make it fast, but what you don't do (change a variable type, forcing the compiler to create a low performance dynamic box, plus other stuff like global variables).

Yes - if you have a real problem Julia is the way to go. If you are just banging something out to prove a point or make a delivery then Python is often much easier.

Ofc this is like Excel and Notebooks - I start doing things in Excel because I can sort out an answer in like 30seconds. Doing it in a notebook requires 5 minutes, or maybe a little longer. But... see me there, a week later after the feedback and next questions from the customer... now I am in Excel hell and I wish wish wish I had started out in a Notebook.

This is my favourite comment about julia for like last few years +1 on that.

Ecosystem is extremly poor outside very few niches and most of the Deep Learning stuff isn't even faster than python api (+C ofc.) so swaping is just usless if u dont have time to write your own GPU kernals for every new opertaion.

At least for the GPU case, the ecosystem is slowing moving towards writing generic kernels that can be executed on both the CPU (multithreaded) and the GPU, without doing anything special in the kernel itself, via KernelAbstractions.jl. It's still got a little way to go, but already some larger codes are using it to great effect. Also, as a member of the JuliaGPU group, I know that AMD and Intel GPUs should be supported by KernelAbstractions within the next month or two, so a single generic kernel will be able to run unmodified on all major GPUs.