This post illustrates one of the reasons why I love Julia.
When talking to Python colleagues about Julia one response is "well, but I don't really care about performance _that_ much".
The thing about Julia is that you can code without caring about performance (and the performance will be Python-like). If later on it turns out that you DO care, you CAN optimize it. With Python you don't have that option, as in Python "optimizing" means using cython/numba over numpy arrays, and all the limitations inherent to that approach.
This is obviously good, and I'm not even sure what the trade-off is. What am I losing?
Python isn't the competition for satellite image processing. That is very much a C++ world. The existing code is already so absurdly optimized that you're not going to compete on that basis. Where you can compete is the code is also absurdly complex and it's very hard to find developers who can productively use it. If Julia can get close to similar performance but be much easier to understand, that could be a huge boon.
Someone needs to be a first mover, though. The unfortunate thing I've seen in the satellite world is companies think they can take Java developers and teach them C++ and the transition will be seamless. It definitely isn't, but the basic OO concepts and syntax is similar enough that the idea is easy to sell. Trying to sell these huge enterprise and government systems on a programming language that hasn't even existed for a decade won't be easy, in contrast, no matter how simple and no matter how performant it is. Somebody is going to need to step up and just do it, with or without some huge corporate or government sponsor.
You said "The thing about Julia is that you can code without caring about performance (and the performance will be Python-like)."
This is not my experience. Even if you code without caring about performance it is way faster than Python. Also, it is not any harder to code in than Python. It is as high level if not more.
> This is not my experience. Even if you code without caring about performance it is way faster than Python.
It is very usecase dependant.
If your Python code is writing lots of loops and scalar processing then naive julia code will trash it.
but if it is basically spending all its time in numpy/BLAS routines then they will be comparable.
and Julia will looks like its not worth it, since compile time makes it overall slower etc.
> Also, it is not any harder to code in than Python.
If you already know Python then it is easier to use what you know.
Furthemore, if you already know Python (or even more so Matlab) it can cause some stumbling blocks.
Some idiomatic code in other languages, (like writing everything as big array operations), is unidiomatic in julia
(since it causes a lot of allocations tht you don't need)
Yeah, that's often the case but I wanted to make a conservative claim.
Two personal examples where Julia turns out to be much much faster than Python without me having to do anything but the most naive implementation:
- order of 10 float arrays with order of 1_000_000 elements each. Broadcasting an element-wise function in Julia or just doing a for-loop in Julia is way way faster than a pandas operation like col1 * col2 + col3 etc.
- the first time I tried one of Julia's optimizers (I think Optim.jl) it took 1ms on my problem. Sci-kit took 200ms. That's crazy.
When talking to Python colleagues about Julia one response is "well, but I don't really care about performance _that_ much".
The thing about Julia is that you can code without caring about performance (and the performance will be Python-like). If later on it turns out that you DO care, you CAN optimize it. With Python you don't have that option, as in Python "optimizing" means using cython/numba over numpy arrays, and all the limitations inherent to that approach.
This is obviously good, and I'm not even sure what the trade-off is. What am I losing?