Introducing Rusthon

Rust is a systems programming language, and too low level for quick prototyping, or simple web backends. It is nice to have all of the low level control so you can fine tune performance later, but it should be optional. Rusthon is a high level Python-like language that compiles to Rust. Rusthon started as a fork of Gython, which is a fork of PythonJS.

The goal of Rusthon is simple and clean syntax inspired by Python. Rusthon will allow you to code at a higher level than normal Rust code, and interoperate well with hand written Rust and the Rust libraries. You can start off writting your application in Rusthon, and drop down to hand written Rust where you need more performance.

http://rusthon-lang.blogspot.com/

That will work for this trivial examples, but not for anything serious.

To properly translate Python to C++ you would have atleast produce a shared_ptr<T> from every T and even that doesn't work with cycles. Rust translation is even more complicated.

Another reason with Rust at least. Rusthon can make the same memory guarantees as Rust.

Personally I wish this was done with Ruby.. But then again I'm not writing it myself, so I can't really complain.

A random last thought, it would be really something if Rust could formally prove its memory safety and then push that whole system of lifetimes and borrow checks into LLVM or a similar abstraction on top of LLVM. Because Rust as a compiler target is very interesting but it wasn't really built for that.

[0] https://github.com/dropbox/pyston/graphs/commit-activity

Pypy is pushing towards full 3.4 slowly, which is good because I want some of that Juicy STM support in my web apps.

Python(2) code/libraries will mainly survive on PyPy/Pyston going forward. With stuff like Nim and Rusthon, I think something like those will carry the torch forward after Python(2), rather than Python3.

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.

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).

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++.

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.

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

Except, Python does work on them.. no one's blaming the platform. Everyone is at the same disadvantage on non-native platforms as everyone else. No ones blaming it. It's just that it's a hard think to retrofit -anything- to Apple or Google's platform that isn't ObjC/Java.

Python is further along here than most, which should be commended.

It is in question. I hate people with these narrow-minded viewpoints as if there's not a ton of flexibility and creativity going on with programming. It's preposterous and you must have a grudge or ulterior motive.

Python is not a stationary target with a fixed set of pros/cons. It's changing all the time.

In fact, I do what you're suggesting it isn't good for, all the time. Distributing single-binary applications using PyInstaller and Nuitka.

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.

if '--cpp' [...] rust=True

Is that a bug?

Doesn't look like there's C++ flag in python_to_pythonjs, so I'd guess not.

  # naming fix :)
  mv Rusthon Pythrust