How I switched from Python to Julia (and why)

A little background about Python

What is good numpy?

np.count_nonzero(x[:-1] - x[1:])

1. Numba jit. If she worked as described on the main page of Numba, then I think it would be worthwhile to finish the story. Over the prescription I had forgotten a little what had gone wrong with her; the bottom line is that the acceleration was not as impressive as I expected, alas.
2. Cython. OK, raise your hands to those who believe that cython is a really beautiful, elegant solution that does not destroy the very meaning and spirit of Python? I do not think so; if you’ve gotten to Cython, then you can stop deceiving yourself and move on to something less sophisticated like C ++ and C.
3. Rewrite bottlenecks on C and jerk them out of your favorite Python. OK, but what if I have the whole program - it is solid calculations and bottlenecks? C does not offer! I'm not talking about the fact that in this decision you need to know well not one, but two languages ​​- Python and Xi.

Here comes the JULIA!

1. Fortran . And do not laugh, which of us did not pull the BLAS / LAPACK of their favorite languages? Fortran is a really good (better SI!) Language for SCIENTIFIC calculations. I did not take it for the reason that since the times of Fortran they have already invented a lot of things and added them to programming languages; I was hoping for something more modern.
2. R suffers from the same problems as Python (vectorization).
3. Matlab - probably yes, I unfortunately have no money to check.
4. Julia is a dark horse, it will take off — it won't take off (and it was natural until stable-version 1.0)

Some obvious advantages of Julia

1. It looks like Python, in any case, the same "high-level", with the ability, if necessary, to go down to the bits in the numbers.
2. There is no messing around with memory allocations and things like that.
3. Powerful type system. Types are prescribed optionally and very dosage. You can write a program without specifying a single type - and if you do it STRONGLY, then the program will be fast. But there are nuances.
4. It's easy to write custom types that are as fast as built-in types.
5. Multiple dispatch. You can talk about it for hours, but in my opinion, this is the best thing about Julia, it is the basis for the design of all programs and in general the basis of the philosophy of language.
   Thanks to multiple dispatch, many things are written very uniformly.
   
   
   Examples with multiple dispatch

   rand()               # выдать случайное число в диапазоне от 0 до 1rand(10)          # массив длины 10 из случайных чисел от 0 до 1rand(3,5)         # матрица размера 3 х 5 из случайных ....
   using Distributions
   d = Normal()   # Нормальное распределение с параметрами 0, 1rand(d)             # случайное нормально распределенное числоrand(d, 10)      # массив длины 10 ... и так далее

   
   То есть, первым аргументом может быть любое (одномерное) распределение из Distributions, но вызов функции останется буквально тем же. И не только распределение (можно передавать собственно сам ГСЧ в виде объекта MersenneTwister и многое другое). Ещё один (на мой взгляд показательный) пример — навигация в DataFrames без loc/iloc.
   
6. 6. Arrays are native, embedded. Vectorization out of the box.
   

Cons, silent about which would be a crime!

1. New language. On the one hand, of course, a minus. In some ways, perhaps immature. On the other hand, he took into account the rakes of many past languages, stands “on the shoulders of giants,” absorbed many interesting and new things.
2. Immediately fast programs are unlikely to write. There are some unobvious things that are very easy to deal with: you step on a rake, ask the community for help, you step in again ... etc. Basically it is type instability, type instability and global variables. In general, as far as I can judge by myself, a programmer who wants to write quickly on Julia goes through several stages: a) he writes like in Python. This is great and possible, but sometimes there will be performance problems. b) writes as in C: prescribing manic types wherever possible. c) gradually understands where it is necessary (very metered) to prescribe types, and where they interfere.
3. Ecosystem. Some packages are raw, in the sense that something is constantly falling off somewhere; some are mature, but not compatible with each other (conversion to other types is necessary, for example). On the one hand, this is obviously bad; on the other hand, there are many interesting and bold ideas in Julia just because “we are standing on the shoulders of giants” - a tremendous experience has been gained in attacking the rake and “how not to do it”, and this is taken into account (partially) by the developers of the packages.
4. The numbering of the arrays with 1. Ha, kidding, this is of course a plus! No, well, seriously, what's the matter, with what index does the numbering begin? You get used to it in 5 minutes. Nobody complains that integers are called integer, not whole. These are all matters of taste. And yes, take at least the same Cormen on the algorithms - there everything is numbered from one, and sometimes it is inconvenient to rework in Python.

Well, what about the speed of something?

defprocess_fft(x, boundary):return np.count_nonzero(np.abs(np.fft.fft(2*x-1)) > boundary)
%timeit process_fft(x, 2000)
84.1 ms ± 335 µs per loop (mean ± std. dev. of 7 runs, 10 loops each)

functionprocess_fft(x, boundary)
    count(t -> t > boundary, abs.(fft(2*x.-1)))
end
@benchmark process_fft(x, 2000)
BenchmarkTools.Trial:
  memory estimate:  106.81 MiB
  allocs estimate:  61--------------
  minimum time:     80.233 ms (4.75% GC)
  median time:      80.746 ms (4.70% GC)
  mean time:        85.000 ms (8.67% GC)
  maximum time:     205.831 ms (52.27% GC)
  --------------
  samples:          59
  evals/sample:     1

deflongest(x):
    maxLen = 0
    currLen = 0# This will count the number of ones in the blockfor bit in x:
        if bit == 1:
            currLen += 1
            maxLen = max(maxLen, currLen)
        else:
            maxLen = max(maxLen, currLen)
            currLen = 0return max(maxLen, currLen)
%timeit longest(x)
599 ms ± 639 µs per loop (mean ± std. dev. of 7 runs, 1 loop each)

function longest(x)
    maxLen = 0
    currLen = 0
    # This will count the number of ones in the block
    for bit in x
        if bit == 1
            currLen += 1
            maxLen = max(maxLen, currLen)
        else
            maxLen = max(maxLen, currLen)
            currLen = 0
        endendreturnmax(maxLen, currLen)
end
@benchmark longest(x)
BenchmarkTools.Trial:
  memory estimate:  0bytes
  allocs estimate:  0--------------minimumtime:     9.094 ms (0.00% GC)
  mediantime:      9.248 ms (0.00% GC)
  mean time:        9.319 ms (0.00% GC)
  maximum time:     12.177 ms (0.00% GC)
  --------------
  samples:          536
  evals/sample:     1

What happened in the end?

Why did I write all this?