5 ms·

In general I'm very happy with my choice of Ruby/Rails instead of Python/Django, but PyPy is one of the few things I envy Python developers for. I wish somethi

In general I'm very happy with my choice of Ruby/Rails instead of Python/Django, but PyPy is one of the few things I envy Python developers for. I wish something similar could be developed for Ruby.

postfuturist 15y ago
http://rubini.us/ http://rubini.us/
lobo_tuerto 15y ago
Maybe rubinius will fill this need? http://rubini.us/ http://rubini.us/ Also, this could be an interesting read: http://www.engineyard.com/blog/2010/making-ruby-fast-the-rubinius-jit/ http://www.engineyard.com/blog/2010/making-ruby-fast-the-rub...
- bryanwb 15y ago
  but what is the status of rubinius? is it nearly as far along as pypy? I would think that the metaprogramming features of ruby which make it so much fun would also make it n times harder to build a JIT for.
  - lobo_tuerto 15y ago
    I think the second link I posted in my previous comment could help you get a grasp about what they are doing in respect to the dynamic nature of the language and JIT. Here is the current status towards 1.9 implementation: http://status.rubini.us/ http://status.rubini.us/ From the frontpage: "How compatible is Rubinius? From the start, compatibility has been critical to us. To that end, we created the RubySpec to ensure that we maintained parity with official Ruby. We are currently at a 93% RubySpec pass rate and growing everyday. For now Rubinius is targeting MRI 1.8.7 (1.9 is on the post 1.0 list). Most Gems, Rails plugins and C-Extensions work right out of the box. If you find a bug, let us know and we'll get on top of it."
  - tedunangst 15y ago
    The dynamic features of ruby are not so different than those of python, lua, or javascript. Actually in terms of reasonable memory consumption I think rubinius is quite a bit better than pypy.
irahul 15y ago
> but PyPy is one of the few things I envy Python developers for. Depending on your needs, there are others - numpy, scipy, matplotlib, nltk, gevent. > I wish something similar could be developed for Ruby. Isn't http://rubini.us/ http://rubini.us/ supposed to be the PyPy for Ruby? It's not complete, but then neither is PyPy.
- alphakappa 15y ago
  matplotlib and numpy make Python really awesome. If only there was a way to get matplotlib to work on Lion.
  - iuyterw 15y ago
    Until the patched version is released... pip install -e git+https://github.com/matplotlib/matplotlib#egg=matplotlib-dev https://github.com/matplotlib/matplotlib#egg=matplotlib-dev
  - Nitrof 15y ago
    The solution with HomeBrew is shown here : http://sourceforge.net/mailarchive/message.php?msg_id=27888307 http://sourceforge.net/mailarchive/message.php?msg_id=278883...
  - wynand 15y ago
    I'm using the Scipy superpack (http://stronginference.com/scipy-superpack/ http://stronginference.com/scipy-superpack/) on Lion and Matplotlib has given me no trouble so far.
  - Derbasti 15y ago
    But they don't run on PyPy yet. Now that will be awesome!
- deleted 15y ago
  [deleted]
- stephenjudkins 15y ago
  Rubinius and PyPy take quite different approaches to solving the same general problem. It's inaccurate to analogize them. Rubinius specifies a bytecode (see http://rubini.us/doc/en/virtual-machine/instructions/ http://rubini.us/doc/en/virtual-machine/instructions/) and implements a VM that executes this bytecode. The VM is written in C++. The main difference between Rubinius and other Ruby implementations is that nearly everything else is written in Ruby. The lexer, parser, and parts that compile the AST to bytecode is all written in pure Ruby. Further, large parts of the standard library and Ruby language that are implemented in lower-level languages in other implementations are instead written as runtime-level Ruby. However, large and important parts of the infrastructure (including GC and memory allocation) are written in C++. PyPy takes an altogether different approach. It specifies a restricted subset of Python known as "RPython". Basically, it's statically-typed Python. There is also a "compiler" (also called a "JIT generator"), written in pure Python, that compiles an arbitrary interpreter written in RPython into a fast JIT. (See http://morepypy.blogspot.com/2011/04/tutorial-writing-interpreter-with-pypy.html http://morepypy.blogspot.com/2011/04/tutorial-writing-interp... for an example of writing a very simple, small interpreter in RPython.) A cool feature of RPython is that while there must a statically RPython AST to compile, during the "eval" stage you can leverage the full dynamic capabilities of Python. The second part of PyPy is a full Python interpreter written in RPython. Since RPython is a subset of Python, you can actually run this interpreter sandboxed inside any other Python implementation, albeit very slowly. The PyPy toolchain compiles this down to a very fast Python interpreter that features JIT compilation, among other cool features. The neat part of PyPy (in contrast to Rubinius) is that the toolchain part is largely decoupled and generalized away from Python-the-language. Conceivably, one could write ANY language in RPython (or what's compiled down to RPython) and have a fast JIT interpreter. Experimental language features can be added and changed (see the source code for the different garbage collectors in PyPy) with little mucking with the low-level VM. Rubinius is a neat, pragmatic project that could turn into one of the best Ruby implementations around. However, it's not breaking new ground like PyPy is.
sirn 15y ago
What about Rubinius? Can you also elaborate on why you're happier with Ruby and Rails than Python and Django. Since I'm completely the other way around, while Ruby paid my bills, if there's a Python job offering I would have jumped onto it without much thought. One of few things I envy Ruby developers for is the HAML, SCSS, Jammit stuff. Apart from that, not so much, especially for documentations for Ruby modules. It might be from the fact that I prefers Flask[1] to Django, but I also like Python's explicitness than Ruby's implicit and found Python language design to better suits my taste (e.g. the Python class[1]). [1]: http://lucumr.pocoo.org/2011/7/9/python-and-pola/ http://lucumr.pocoo.org/2011/7/9/python-and-pola/ [2]: http://flask.pocoo.org/ http://flask.pocoo.org/
- mattdeboard 15y ago
  I use SCSS with Django all the time.
- rglullis 15y ago
  As an alternative for scss and jammit, you can try django-css: https://github.com/dziegler/django-css https://github.com/dziegler/django-css
  - StavrosK 15y ago
    I use django-mediagenerator[1], I love it to bits. [1]: http://www.allbuttonspressed.com/projects/django-mediagenerator http://www.allbuttonspressed.com/projects/django-mediagenera...
Freaky 15y ago
If it's mainly the performance you're after, have a look at JRuby. It's already a decent chunk faster than MRI/YARV, and with Java 7 and invokedynamic there's a lot more to look forward to and play with now. Last week one of the JRuby core devs tweeted: "Ok, another set of tweaks in JRuby and fib(35) is another 10% faster (and only about 10% slower than Java. Do I stop now?"

In general I'm very happy with my choice of Ruby/Rails instead of Python/Django, but PyPy is one of the few things I envy Python developers for. I wish something similar could be developed for Ruby.

postfuturist 15y ago

http://rubini.us/ http://rubini.us/

lobo_tuerto 15y ago

Maybe rubinius will fill this need? http://rubini.us/ http://rubini.us/ Also, this could be an interesting read: http://www.engineyard.com/blog/2010/making-ruby-fast-the-rubinius-jit/ http://www.engineyard.com/blog/2010/making-ruby-fast-the-rub...

bryanwb 15y ago
but what is the status of rubinius? is it nearly as far along as pypy? I would think that the metaprogramming features of ruby which make it so much fun would also make it n times harder to build a JIT for.
- lobo_tuerto 15y ago
  I think the second link I posted in my previous comment could help you get a grasp about what they are doing in respect to the dynamic nature of the language and JIT. Here is the current status towards 1.9 implementation: http://status.rubini.us/ http://status.rubini.us/ From the frontpage: "How compatible is Rubinius? From the start, compatibility has been critical to us. To that end, we created the RubySpec to ensure that we maintained parity with official Ruby. We are currently at a 93% RubySpec pass rate and growing everyday. For now Rubinius is targeting MRI 1.8.7 (1.9 is on the post 1.0 list). Most Gems, Rails plugins and C-Extensions work right out of the box. If you find a bug, let us know and we'll get on top of it."
- tedunangst 15y ago
  The dynamic features of ruby are not so different than those of python, lua, or javascript. Actually in terms of reasonable memory consumption I think rubinius is quite a bit better than pypy.

irahul 15y ago

> but PyPy is one of the few things I envy Python developers for. Depending on your needs, there are others - numpy, scipy, matplotlib, nltk, gevent. > I wish something similar could be developed for Ruby. Isn't http://rubini.us/ http://rubini.us/ supposed to be the PyPy for Ruby? It's not complete, but then neither is PyPy.

alphakappa 15y ago
matplotlib and numpy make Python really awesome. If only there was a way to get matplotlib to work on Lion.
- iuyterw 15y ago
  Until the patched version is released... pip install -e git+https://github.com/matplotlib/matplotlib#egg=matplotlib-dev https://github.com/matplotlib/matplotlib#egg=matplotlib-dev
- Nitrof 15y ago
  The solution with HomeBrew is shown here : http://sourceforge.net/mailarchive/message.php?msg_id=27888307 http://sourceforge.net/mailarchive/message.php?msg_id=278883...
- wynand 15y ago
  I'm using the Scipy superpack (http://stronginference.com/scipy-superpack/ http://stronginference.com/scipy-superpack/) on Lion and Matplotlib has given me no trouble so far.
- Derbasti 15y ago
  But they don't run on PyPy yet. Now that will be awesome!
deleted 15y ago
[deleted]
stephenjudkins 15y ago
Rubinius and PyPy take quite different approaches to solving the same general problem. It's inaccurate to analogize them. Rubinius specifies a bytecode (see http://rubini.us/doc/en/virtual-machine/instructions/ http://rubini.us/doc/en/virtual-machine/instructions/) and implements a VM that executes this bytecode. The VM is written in C++. The main difference between Rubinius and other Ruby implementations is that nearly everything else is written in Ruby. The lexer, parser, and parts that compile the AST to bytecode is all written in pure Ruby. Further, large parts of the standard library and Ruby language that are implemented in lower-level languages in other implementations are instead written as runtime-level Ruby. However, large and important parts of the infrastructure (including GC and memory allocation) are written in C++. PyPy takes an altogether different approach. It specifies a restricted subset of Python known as "RPython". Basically, it's statically-typed Python. There is also a "compiler" (also called a "JIT generator"), written in pure Python, that compiles an arbitrary interpreter written in RPython into a fast JIT. (See http://morepypy.blogspot.com/2011/04/tutorial-writing-interpreter-with-pypy.html http://morepypy.blogspot.com/2011/04/tutorial-writing-interp... for an example of writing a very simple, small interpreter in RPython.) A cool feature of RPython is that while there must a statically RPython AST to compile, during the "eval" stage you can leverage the full dynamic capabilities of Python. The second part of PyPy is a full Python interpreter written in RPython. Since RPython is a subset of Python, you can actually run this interpreter sandboxed inside any other Python implementation, albeit very slowly. The PyPy toolchain compiles this down to a very fast Python interpreter that features JIT compilation, among other cool features. The neat part of PyPy (in contrast to Rubinius) is that the toolchain part is largely decoupled and generalized away from Python-the-language. Conceivably, one could write ANY language in RPython (or what's compiled down to RPython) and have a fast JIT interpreter. Experimental language features can be added and changed (see the source code for the different garbage collectors in PyPy) with little mucking with the low-level VM. Rubinius is a neat, pragmatic project that could turn into one of the best Ruby implementations around. However, it's not breaking new ground like PyPy is.

sirn 15y ago

What about Rubinius? Can you also elaborate on why you're happier with Ruby and Rails than Python and Django. Since I'm completely the other way around, while Ruby paid my bills, if there's a Python job offering I would have jumped onto it without much thought. One of few things I envy Ruby developers for is the HAML, SCSS, Jammit stuff. Apart from that, not so much, especially for documentations for Ruby modules. It might be from the fact that I prefers Flask[1] to Django, but I also like Python's explicitness than Ruby's implicit and found Python language design to better suits my taste (e.g. the Python class[1]). [1]: http://lucumr.pocoo.org/2011/7/9/python-and-pola/ http://lucumr.pocoo.org/2011/7/9/python-and-pola/ [2]: http://flask.pocoo.org/ http://flask.pocoo.org/

mattdeboard 15y ago
I use SCSS with Django all the time.
rglullis 15y ago
As an alternative for scss and jammit, you can try django-css: https://github.com/dziegler/django-css https://github.com/dziegler/django-css
- StavrosK 15y ago
  I use django-mediagenerator[1], I love it to bits. [1]: http://www.allbuttonspressed.com/projects/django-mediagenerator http://www.allbuttonspressed.com/projects/django-mediagenera...

Freaky 15y ago

If it's mainly the performance you're after, have a look at JRuby. It's already a decent chunk faster than MRI/YARV, and with Java 7 and invokedynamic there's a lot more to look forward to and play with now. Last week one of the JRuby core devs tweeted: "Ok, another set of tweaks in JRuby and fib(35) is another 10% faster (and only about 10% slower than Java. Do I stop now?"