3 ms·

> Python is plenty fast if you use NumPy / CuPy / SciPi. I think this misses the point. You are basically saying that python is fast enough in cases that someo

by ska 5y ago

> Python is plenty fast if you use NumPy / CuPy / SciPi. I think this misses the point. You are basically saying that python is fast enough in cases that someone has written already written a fast package in not-python (plus bindings), whereas the value proposition for julia is basically: writing such packages in the future will be lots better. Obviously the average user doesn't care, but if enough whiz-bang stuff starts to come out in Julia but not python, they'll move.

ummonk 5y ago
I think it will be interesting if enough clever new whiz-bang stuff comes out particularly based on Julia's metaprogramming powers. However, when talking about the "two language problem", the main issue traditionally was prototyping computational code in Python / Matlab / whatever and then having to drop into Fortran / C / Cuda for optimizing it. That's pretty much a solved problem in Python now - thanks to the well developed ecosystem, you don't really have to leave Python to write fast numerical code.
- klaff 5y ago
  The first problems I came to Julia to solve were ODE simulations in which it's just as critical that the stuff I write and rewrite over and over again (the actual differential equations of my model and associated simulated controller callbacks) runs fast as it is that the pre-written stuff of the library (the solvers or integrators) runs fast. To the best of my knowledge I can't do that in python. This example (DifferentialEquations.jl in particular and SciML.ai in general) is one of the places where Julia leads the pack. When I first used Julia it felt rather strange in a lot of ways (I had used python for about 20 years), but after 2 years when I go back to python (and of course there are places where it makes more sense to use python) it feels primitive as there are a lot of very nice features of Julia that I suddenly miss.
- enriquto 5y ago
  > That's pretty much a solved problem in Python now - thanks to the well developed ecosystem, I don't understand this argument. The same C and Fortran libraries that make numeric Python fast can be called just as easily from any other programming language, just like in Python. > you don't really have to leave Python to write fast numerical code. Well, you need to, for example, if you want to write a new numeric algorithm to call from python. As in, not use a numerical solver, but write a numerical solver from first principles. For that, Python is mostly useless and you'd need to use C or Fortran (or Julia).

by ska 5y ago

ummonk 5y ago

I think it will be interesting if enough clever new whiz-bang stuff comes out particularly based on Julia's metaprogramming powers. However, when talking about the "two language problem", the main issue traditionally was prototyping computational code in Python / Matlab / whatever and then having to drop into Fortran / C / Cuda for optimizing it. That's pretty much a solved problem in Python now - thanks to the well developed ecosystem, you don't really have to leave Python to write fast numerical code.

klaff 5y ago
The first problems I came to Julia to solve were ODE simulations in which it's just as critical that the stuff I write and rewrite over and over again (the actual differential equations of my model and associated simulated controller callbacks) runs fast as it is that the pre-written stuff of the library (the solvers or integrators) runs fast. To the best of my knowledge I can't do that in python. This example (DifferentialEquations.jl in particular and SciML.ai in general) is one of the places where Julia leads the pack. When I first used Julia it felt rather strange in a lot of ways (I had used python for about 20 years), but after 2 years when I go back to python (and of course there are places where it makes more sense to use python) it feels primitive as there are a lot of very nice features of Julia that I suddenly miss.
enriquto 5y ago
> That's pretty much a solved problem in Python now - thanks to the well developed ecosystem, I don't understand this argument. The same C and Fortran libraries that make numeric Python fast can be called just as easily from any other programming language, just like in Python. > you don't really have to leave Python to write fast numerical code. Well, you need to, for example, if you want to write a new numeric algorithm to call from python. As in, not use a numerical solver, but write a numerical solver from first principles. For that, Python is mostly useless and you'd need to use C or Fortran (or Julia).