Hacker News Reader

Comment by rmoriz | Hacker News Reader

Why not implemented on Erlang OTP? Ruby and Python share the same scaling issues, so I don't see a benefit it combining them or migrate from one to the other.

I also dislike the "high performance" claims without showing a single performance comparison. Not to mention the state of implementation completeness of the language.

View on HN

I think you're missing the point. It's not written in Python. It's written i RPython, which is vastly different. Technology behind this and PyPy is the same, however there is no Python usage here.

Additionally, erlang has avoided scaling issues by being functional. This might be good or bad, depending on your viewpoint, but just implementing a ruby interpreter in erlang won't cut, because you're not answering any of the hard questions about the state. You might answer "meh, ruby is just a broken language", but well, this has nothing to do with that article.

"Topaz is written in Python on top of the RPython translation toolchain (the same one that powers PyPy)." [1]

"Topaz - An implementation of the Ruby programming language, in Python, using the RPython VM toolchain." [2]

[1] http://docs.topazruby.com/en/latest/blog/announcing-topaz/ [2] https://github.com/topazproject/topaz/blob/master/README.rst

As RPython is a subset of Python, that statement is technically correct but misleading. Stating that Topaz is "Ruby written in Python" leads to the idea that it's written in / runs on CPython, which is really not the case.

Well, it can be run on CPython if you wanted (that's how we run many of our tests). It's just crazy slow.

The Erlang runtime imposes a different set of constraints than Python that would impact the design of the language being built on top of it. Given that, someone already has come as close as you can to porting Ruby to the Erlang VM, it is called Elixir. http://elixir-lang.org/

Its implemented on top of RPython, which is something completely different then Python, the runtime.

No it's not. Technically speaking yes, but without Python there would be no RPython. In other words you're betting on three language/vm communities: Ruby language, Python (RPython!), LLVM (iirc).

I don't believe introducing a lot more dependencies and complexities will cure any problem. Sure, it's a nice project and the work shows the great skills of the developer. But it's not practical to use this besides some non-crictical fun projects.

Pretty sure LLVM has nothing to do with this, it's not currently used in PyPy.

(Also, LLVM is not a language...)

Yes, but betting on Python is the whole point of PyPy. The idea is to build a toolchain using a relatively high-level programming language like RPython to build new languages.

As far as I understood is that this allows for low-level concepts to be changed more easily, while low-level implementations always suffer from basic decisions (e.g. you will never get reference-counting out of CPython, while you might be free in to change that in an RPython-implemented language).

So, the entire point of PyPy is being able to implement other high-level languages in RPython, so an attempt to implement Ruby is definitely very interesting! Also, the resulting binary is not depending on Python whatsoever.

That's not really rebutting the GP's point, though, which is that despite using a Python-derived language, we're not running Topaz on top of a Python runtime.

Build an Erlang backend for PyPy. Should be doable, but what benefits would it bring?

It's not quite Ruby on top of Erlang, but you might be interested in Elixir (http://elixir-lang.org/). Elixir has some of the syntax of Ruby but is built on the Erlang VM.

What does that have to do with the article?

Reply on news.ycombinator.com