[etik]

Ah, that's too bad, but I can't really blame them. Going from a fully-featured Python codebase they already had in https://github.com/brandondube/prysm and translating into Julia would need to be motivated by much more than speed - after all the limiting factor here is FFT and heavy computations like cis, so I'm pleasantly surprised they reported gains from their simple port compared to numpy. It's also much easier to go from a C/C++ computational code to Julia than it is from a Python one, because the mental performance models are more similar.

For reference, we (metalenz.com) have a large Julia codebase centered around optical design, simulation, and analysis. The motivation for that is more along the lines of composability and clarity of abstractions (aided by multiple-dispatch). We can differentiate through our physical optics solver code (forward or reverse) for optimization/ML, plug in our designs across a hierarchy of different E&M solvers, run on GPU, and write very efficient code when our profiling identifies a bottleneck. If we just had to perform one thing (physical optics simulations), then our investment wouldn't be as justified.