> If you are NASA, CERN, LLNL, or a bank, maybe it's a good idea to implement your computations once in Python and once in Julia
Doesn’t this negate one of Julia’s main selling points? That it has “solved the two-language problem”. Ironic for them to solve that in the performance domain only to then need a second language to prove correctness.
Note that with the Julia differential equation solvers, you can, without rewriting your code, test it with SciPy's solvers, MATLAB's solvers, C solvers (CVODE), Fortran solvers (Hairer's, lsoda, etc.), and the pure Julia methods (of which there are many, and many different libraries). https://diffeq.sciml.ai/stable/solvers/ode_solve/ Even a few methods for quantum computers. This also includes methods with uncertainty quantification (Taylor methods with interval setups, probabilistic numerics). So no, you can run these kinds of checks without rewriting your model. (Of course, some of the solvers to check against will be really slow, but this is about correctness and the ability to easily check correctness)
I interpreted it more that, in domains where correctness is vital (rather than "good enough"), you want more than one implementation no matter what languages you use.
Maybe that's not what parent was going for, but I think it's like the reproducible/replicable difference in research... can you use the author's code and data, getting the same result... can you use the author's algorithm/pseudocode and data, and get the same result... can you use the author's algorithm/code and different data, and get an _equivalent_ result?
Doesn’t this negate one of Julia’s main selling points? That it has “solved the two-language problem”. Ironic for them to solve that in the performance domain only to then need a second language to prove correctness.