4 ms·

Strangely, the only mention of Cython is to point at that we have had less developers than Julia: "as evidenced by the over 500 committers to just the Base lang

Strangely, the only mention of Cython is to point at that we have had less developers than Julia: "as evidenced by the over 500 committers to just the Base language, more than projects like Cython has ever had!"

ChrisRackauckas 9y ago
I don't find it strange: I wrote this to say why I like using Julia and point out what the community is missing, not as a comparison to every other JIT in existence. But if you want to know why I gave up on Cython, I'll lay it out for you. I tried it almost 2 years ago because some documents in a course had IPython notebooks which used it. So I did some standard scientific computing stuff like write some Runge-Kutta methods and yes its speed was fine (that was a pretty big part of the blog post: if you try hard and use the right tools you'll get pretty much the same performance anywhere). That's not the problem at all. The problem was extending it to be more widely useful in my own research. I wanted to make those same compiled functions also work with complex numbers to integrate spectral discretizations of a stochastic PDE (instead of the finite difference one from before). I found some SO posts like: https://stackoverflow.com/questions/30054019/complex-numbers-in-cython https://stackoverflow.com/questions/30054019/complex-numbers... https://stackoverflow.com/questions/27906862/complex-valued-calculations-using-cython https://stackoverflow.com/questions/27906862/complex-valued-... At that point it stopped looking like Python at all. I always found the SciPy syntax a little verbose since I had used a lot of MATLAB before (but I wanted to make this project not require a license to run) (this QuantEcon cheatsheet is a good demonstration of what syntax is like in my domain: https://cheatsheets.quantecon.org/ https://cheatsheets.quantecon.org/). But to make this kind of "complex or not" logic work in compiled Cython, I resorted to conditional compilation (http://cython.readthedocs.io/en/latest/src/userguide/language_basics.html#conditional-compilation http://cython.readthedocs.io/en/latest/src/userguide/languag...). These days I understand that what I created was essentially a multiple dispatch mechanism. Anyways, at around that time I started experimenting with other tools, especially Julia, because I really was getting frustrated whenever I had to "go beyond doubles" and write something that was extendable instead of a one-use script. Maybe there's some tricks I was missing, but I found it really hard in Python and MATLAB. Soon after, my PhD adviser and I started arguing about whether one of the properties in the simulation's solution was due to floating point errors. I couldn't convince him, so I wanted to write this integrator so it was fast and compiled, but allowed arbitrary precision so that way I could prove that it still existed even with very high precision. I couldn't find a page which explained how to do high precision arithmetic in Cython or Numba, so I completely gave up. Needless to say, I decided to re-write a small portion of this in Julia and it worked really well, pretty much instantly. Then I was digging around the Julia package listing and Viral pointed me to a big opportunity (https://github.com/JuliaDiffEq/ODE.jl/issues/64 https://github.com/JuliaDiffEq/ODE.jl/issues/64) and I have been developing a lot of Julia differential equation solvers ever since. Obviously YMMV, but after computing a lot without a "first-choice language" (between R, Python, C, MATLAB, Mathematica) for quite awhile, I kept with Julia because I didn't have issues when I hit less standard tasks, and I found it very easy to contribute fixes to other people's projects because it was just Julia code. This stochastic PDE integrator story is just one (significant) project that led me in this direction.
- williamstein 9y ago
  > I couldn't find a page which explained how to do high precision arithmetic in Cython or Numba, so I completely gave up. When that happened to me, I wrote Sage (http://sagemath.org http://sagemath.org).
- syllogism 9y ago
  Well...It is strange to omit Cython, because that's what the package authors actually use :). It's a huge part of answer to the question you pose about how package development works in Python. Cython isn't perfect, but it works very well. To answer the specific question you had about multiple dispatch: Cython's had fused types for a while now, although I guess they weren't so prominent in the docs when you were trying to solve your problem. The other problem with your argument is, I think you have the dynamics slightly backwards. Complicated libraries will go where the users are, not the other way around. Maybe my NLP library spaCy would've been easier to write in Nim or D. This didn't matter. I wrote it in Cython because I saw that the userbase would in Python. This has proven correct. It also has the effect of drawing slightly more users to Python, continuing the feedback loop. But each library's marginal impact on the developer community is small, so you're never going to get the marginal package author to switch language for the sake of convenience. What good is it to have a convenient experience developing a package nobody will use?
  - ChrisRackauckas 9y ago
    The problem is, I needed the library. I didn't have the time and resources to build it in Python, while it was a night project for a week to build it in Julia. As a methods researcher I'm going to use the tool that doesn't impede my research but allows me to distribute robust and performant implementations, which after trying lot of other tools I've found is Julia.
- bluescarni 9y ago
  From your list of "first-choice languages", C++ is conspicuously missing. That seems rather peculiar, as the type of genericity you are praising Julia for has been one of the core concepts of generic programming in C++ since basically the late nineties with the standardization of the STL (and it's become an increasingly emphasized part of the language throughout its evolution in the last 10 years or so, see C++11 and later). The example you mention, numerical integrators using different number types (complex, arbitrary precision, intervals, etc.), is the type of stuff which would seem a perfect fit for a template-based implementation.

ChrisRackauckas 9y ago

I don't find it strange: I wrote this to say why I like using Julia and point out what the community is missing, not as a comparison to every other JIT in existence. But if you want to know why I gave up on Cython, I'll lay it out for you. I tried it almost 2 years ago because some documents in a course had IPython notebooks which used it. So I did some standard scientific computing stuff like write some Runge-Kutta methods and yes its speed was fine (that was a pretty big part of the blog post: if you try hard and use the right tools you'll get pretty much the same performance anywhere). That's not the problem at all. The problem was extending it to be more widely useful in my own research. I wanted to make those same compiled functions also work with complex numbers to integrate spectral discretizations of a stochastic PDE (instead of the finite difference one from before). I found some SO posts like: https://stackoverflow.com/questions/30054019/complex-numbers-in-cython https://stackoverflow.com/questions/30054019/complex-numbers... https://stackoverflow.com/questions/27906862/complex-valued-calculations-using-cython https://stackoverflow.com/questions/27906862/complex-valued-... At that point it stopped looking like Python at all. I always found the SciPy syntax a little verbose since I had used a lot of MATLAB before (but I wanted to make this project not require a license to run) (this QuantEcon cheatsheet is a good demonstration of what syntax is like in my domain: https://cheatsheets.quantecon.org/ https://cheatsheets.quantecon.org/). But to make this kind of "complex or not" logic work in compiled Cython, I resorted to conditional compilation (http://cython.readthedocs.io/en/latest/src/userguide/language_basics.html#conditional-compilation http://cython.readthedocs.io/en/latest/src/userguide/languag...). These days I understand that what I created was essentially a multiple dispatch mechanism. Anyways, at around that time I started experimenting with other tools, especially Julia, because I really was getting frustrated whenever I had to "go beyond doubles" and write something that was extendable instead of a one-use script. Maybe there's some tricks I was missing, but I found it really hard in Python and MATLAB. Soon after, my PhD adviser and I started arguing about whether one of the properties in the simulation's solution was due to floating point errors. I couldn't convince him, so I wanted to write this integrator so it was fast and compiled, but allowed arbitrary precision so that way I could prove that it still existed even with very high precision. I couldn't find a page which explained how to do high precision arithmetic in Cython or Numba, so I completely gave up. Needless to say, I decided to re-write a small portion of this in Julia and it worked really well, pretty much instantly. Then I was digging around the Julia package listing and Viral pointed me to a big opportunity (https://github.com/JuliaDiffEq/ODE.jl/issues/64 https://github.com/JuliaDiffEq/ODE.jl/issues/64) and I have been developing a lot of Julia differential equation solvers ever since. Obviously YMMV, but after computing a lot without a "first-choice language" (between R, Python, C, MATLAB, Mathematica) for quite awhile, I kept with Julia because I didn't have issues when I hit less standard tasks, and I found it very easy to contribute fixes to other people's projects because it was just Julia code. This stochastic PDE integrator story is just one (significant) project that led me in this direction.

williamstein 9y ago
> I couldn't find a page which explained how to do high precision arithmetic in Cython or Numba, so I completely gave up. When that happened to me, I wrote Sage (http://sagemath.org http://sagemath.org).
syllogism 9y ago
Well...It is strange to omit Cython, because that's what the package authors actually use :). It's a huge part of answer to the question you pose about how package development works in Python. Cython isn't perfect, but it works very well. To answer the specific question you had about multiple dispatch: Cython's had fused types for a while now, although I guess they weren't so prominent in the docs when you were trying to solve your problem. The other problem with your argument is, I think you have the dynamics slightly backwards. Complicated libraries will go where the users are, not the other way around. Maybe my NLP library spaCy would've been easier to write in Nim or D. This didn't matter. I wrote it in Cython because I saw that the userbase would in Python. This has proven correct. It also has the effect of drawing slightly more users to Python, continuing the feedback loop. But each library's marginal impact on the developer community is small, so you're never going to get the marginal package author to switch language for the sake of convenience. What good is it to have a convenient experience developing a package nobody will use?
- ChrisRackauckas 9y ago
  The problem is, I needed the library. I didn't have the time and resources to build it in Python, while it was a night project for a week to build it in Julia. As a methods researcher I'm going to use the tool that doesn't impede my research but allows me to distribute robust and performant implementations, which after trying lot of other tools I've found is Julia.
bluescarni 9y ago
From your list of "first-choice languages", C++ is conspicuously missing. That seems rather peculiar, as the type of genericity you are praising Julia for has been one of the core concepts of generic programming in C++ since basically the late nineties with the standardization of the STL (and it's become an increasingly emphasized part of the language throughout its evolution in the last 10 years or so, see C++11 and later). The example you mention, numerical integrators using different number types (complex, arbitrary precision, intervals, etc.), is the type of stuff which would seem a perfect fit for a template-based implementation.