3 ms·

Cython already compiles to C and is relatively mature. In my opinion these hacks will always be specialty tools. What the world really needs is more languages

by amit_m 12y ago

Cython already compiles to C and is relatively mature. In my opinion these hacks will always be specialty tools. What the world really needs is more languages that are both expressive and run pretty fast. e.g. Julia.

deleted 12y ago
[deleted]
shadowmint 12y ago
Cython isn't the answer. It's a neat tool, for sure, but it's a very specific thing, and it has several down sides, mainly: - Every module compiles to a shared library. - Requires significant c infrastructure installed on the target machine to compile. - Compiled code cannot be used without the python runtime. This renders it almost useless for generating code for serious applications. It's an adhoc solution to ffi and slowness because those are things are major issues for python. However, this (Rusthon) has some serious upsides: The transpiled (if that's the word?) C++ / rust code is portable and fast. It does not include the bloated standard python library. It can be directly compiled using existing compiler tools for mobile devices (to be fair, as the kivy-ios project shows, this isn't impossible with cython, but it involves patching the python source to load modules differently).
- andreasvc 12y ago
  > - Every module compiles to a shared library. How else would you import a module if it wasn't? If you want to reduce the number of shared libraries you could put all your code in a single module, of course. > - Requires significant c infrastructure installed on the target machine to compile. Anything which involves compilation to native code requires significant infrastructure. > - Compiled code cannot be used without the python runtime. And this is a downside why? Combining the best of both worlds--native code and Python--is the whole point. If you want to take out Python from the equation just use C/C++.
  - shadowmint 12y ago
    The issues I pointed out are related to building distributable targets. Shared library per module and 'wrapped' compiler execution for example, is fundamentally hostile to distribution for mobile environments. Have a look at the hoops kivy-ios jumps though. It's absolutely ridiculous. That's the thing python is the worst at; building a single stand alone application that does not require the user to install a copy of python and run pip to download a million dependencies before it will run. This isn't in question. It's just life; that's not what python is good at. Cython doesn't solve that problem. It solves a different set of problems; namely, ffi and speed. My point is that by choosing an alternative approach (compile to portable C++ / rust) this project gives you the benefits of ffi and speed and distribution.
    - andreasvc 12y ago
      For Cython's intended audience, mostly scientific programming, distribution is just not a primary concern, but rather efficiency and productivity. I think the issues you cite are mostly the fault of the mobile targets themselves; e.g., their app stores put up artificial barriers of which languages may be used. On the server side or on a compute cluster having to pull in a bunch of dependencies is absolutely no problem, and is the very reason the ecosystem of Python provides productivity gains.
      - shadowmint 12y ago
        It's a little bit convenient to blame the platforms when your things don't work on them. The reality is that the tools (cython, python) were built without mobile platforms in mind, and they (currently) are ill suited to supporting them. That's not the platforms fault; it just an artifact of the development history of the projects. Cython is not a general purpose compile to C solution. It solves a different problem to Rusthon. /shrug
        andreasvc 12y ago
        I see your point, Cython is not the right tool for the job when that involves mobile platforms. I just thought that the claim in your original comment came off as sweeping--"Cython isn't the answer"; you didn't mention that you had a specific problem in mind.
andreasvc 12y ago
The trade-offs between a single JITed language versus having a scripting and native language are interesting. I think there are a few advantages to the latter approach though. JIT is never going to beat carefully hand-optimized code, and the amount of code that needs such optimization is small. Furthermore the performance of JIT is not necessarily predictable, and comes with additional memory usage. Finally languages such as Python, R, or Matlab have a vast ecosystem of libraries; this gives a big incentive to keep on interoperating with them instead of switching to a new language.
- BuckRogers 12y ago
  It is interesting and the combo of native compiled and interpreted is IMO preferable over single JIT. The good news is that Python itself offers JIT though PyPy, and now Rusthon offers the former. I prefer Rusthon (or the idea of Rusthon if it works out well) over all else for the future. But with standard Python (meaning 2.x) code carried forward primarily with PyPy at the same time.

by amit_m 12y ago

deleted 12y ago

[deleted]

shadowmint 12y ago

Cython isn't the answer. It's a neat tool, for sure, but it's a very specific thing, and it has several down sides, mainly: - Every module compiles to a shared library. - Requires significant c infrastructure installed on the target machine to compile. - Compiled code cannot be used without the python runtime. This renders it almost useless for generating code for serious applications. It's an adhoc solution to ffi and slowness because those are things are major issues for python. However, this (Rusthon) has some serious upsides: The transpiled (if that's the word?) C++ / rust code is portable and fast. It does not include the bloated standard python library. It can be directly compiled using existing compiler tools for mobile devices (to be fair, as the kivy-ios project shows, this isn't impossible with cython, but it involves patching the python source to load modules differently).

andreasvc 12y ago
> - Every module compiles to a shared library. How else would you import a module if it wasn't? If you want to reduce the number of shared libraries you could put all your code in a single module, of course. > - Requires significant c infrastructure installed on the target machine to compile. Anything which involves compilation to native code requires significant infrastructure. > - Compiled code cannot be used without the python runtime. And this is a downside why? Combining the best of both worlds--native code and Python--is the whole point. If you want to take out Python from the equation just use C/C++.
- shadowmint 12y ago
  The issues I pointed out are related to building distributable targets. Shared library per module and 'wrapped' compiler execution for example, is fundamentally hostile to distribution for mobile environments. Have a look at the hoops kivy-ios jumps though. It's absolutely ridiculous. That's the thing python is the worst at; building a single stand alone application that does not require the user to install a copy of python and run pip to download a million dependencies before it will run. This isn't in question. It's just life; that's not what python is good at. Cython doesn't solve that problem. It solves a different set of problems; namely, ffi and speed. My point is that by choosing an alternative approach (compile to portable C++ / rust) this project gives you the benefits of ffi and speed and distribution.
  - andreasvc 12y ago
    For Cython's intended audience, mostly scientific programming, distribution is just not a primary concern, but rather efficiency and productivity. I think the issues you cite are mostly the fault of the mobile targets themselves; e.g., their app stores put up artificial barriers of which languages may be used. On the server side or on a compute cluster having to pull in a bunch of dependencies is absolutely no problem, and is the very reason the ecosystem of Python provides productivity gains.
    - shadowmint 12y ago
      It's a little bit convenient to blame the platforms when your things don't work on them. The reality is that the tools (cython, python) were built without mobile platforms in mind, and they (currently) are ill suited to supporting them. That's not the platforms fault; it just an artifact of the development history of the projects. Cython is not a general purpose compile to C solution. It solves a different problem to Rusthon. /shrug
      - andreasvc 12y ago
        I see your point, Cython is not the right tool for the job when that involves mobile platforms. I just thought that the claim in your original comment came off as sweeping--"Cython isn't the answer"; you didn't mention that you had a specific problem in mind.

andreasvc 12y ago

The trade-offs between a single JITed language versus having a scripting and native language are interesting. I think there are a few advantages to the latter approach though. JIT is never going to beat carefully hand-optimized code, and the amount of code that needs such optimization is small. Furthermore the performance of JIT is not necessarily predictable, and comes with additional memory usage. Finally languages such as Python, R, or Matlab have a vast ecosystem of libraries; this gives a big incentive to keep on interoperating with them instead of switching to a new language.

BuckRogers 12y ago
It is interesting and the combo of native compiled and interpreted is IMO preferable over single JIT. The good news is that Python itself offers JIT though PyPy, and now Rusthon offers the former. I prefer Rusthon (or the idea of Rusthon if it works out well) over all else for the future. But with standard Python (meaning 2.x) code carried forward primarily with PyPy at the same time.