11–20 of 190 posts
Forgive me for asking what may be a very stupid question: Can someone explain to me the need for a Ruby interpreter built on top of Python? He mentions performance in the announcement, but is this really going to be faster than, say, MRI? Thanks in advance.
Forgive me for asking what may be a very stupid question: Can someone explain to me the need for a Ruby interpreter built on top of Python? He mentions performance in the announcement, but is this really going to be faster than, say, MRI? Thanks in advance.
Forgive me for asking what may be a very stupid question: Can someone explain to me the need for a Ruby interpreter built on top of Python? He mentions performance in the announcement, but is this really going to be faster than, say, MRI? Thanks in advance.
To be clear, this isn't "Ruby running on top of Python." This is "Ruby specified in RPython."
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.
Forgive me for asking what may be a very stupid question: Can someone explain to me the need for a Ruby interpreter built on top of Python? He mentions performance in the announcement, but is this really going to be faster than, say, MRI? Thanks in advance.
Although the most well-known language implemented in the pypy "vm" is python, the toolchain is completely language agnostic.
So, this is more akin to Apple writing a C interpreter on top of llvm than it is to building a ruby interpreter on top of python.
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.
Its implemented on top of RPython, which is something completely different then Python, the runtime.
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.
Forgive me for asking what may be a very stupid question: Can someone explain to me the need for a Ruby interpreter built on top of Python? He mentions performance in the announcement, but is this really going to be faster than, say, MRI? Thanks in advance.
If Topaz was able to give me the ability to access NLTK, but still write in Ruby? I'd be overjoyed.
Forgive me for asking what may be a very stupid question: Can someone explain to me the need for a Ruby interpreter built on top of Python? He mentions performance in the announcement, but is this really going to be faster than, say, MRI? Thanks in advance.
Think of Pypy as somewhat like LLVM, except the language it's built on is a subset of the python language, called RPython. Although the most well-known language implemented in the pypy "vm" is python, the toolchain is completely language agnostic. So, this is more akin to Apple writing a C interpreter on top of llvm than it is to building a ruby interpreter on top of python.
* RPython comes with a good garbage collector
* the language where you specify what's going on is RPython in which you write an interpreter. Then you get a JIT using a few hints. This is difference than "interpreter in C + compiler to LLVM" scenario by quite a bit.
* RPython comes with a set of data structures that are higher level (lists, dicts, etc.) and is a GCed language. JIT is also well aware of those.
Earlier quoted context omitted.
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-…
(Also, LLVM is not a language...)