Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

> Also, Rubinius still has to fully implement Ruby 1.9, so its not like you could just flip a switch.

The only serious piece missing from 1.9 is the encoding support. There's a number of other relatively minor failures remaining, but those are simple enough to fix (and several people, contributors new and old, are doing so at this very moment).

And the switch is -X19.



I know that they are on a good track towards 1.9 support. My point still stands: they are not there yet. So, if you were an MRI developer: would you switch to an interpreter where would have to build that whole stuff from the last 3 years again?


I can imagine a world where Rubinius never gets 1.9 encoding support, and declares it a non-goal. It's not that outlandish.


Which is something that I'd regard as a major setback. Here in Europe, a solid encoding support is pretty much a must-have for any up-to-date programming language. There's much more than utf-8 and not being able to handle that is a deal-breaker for me.


Leaving aside the fact that encoding support is explicitly a goal, it would be an incredibly daft thing to do to decide that Rubinius was going to take a regressive, all-the-world-is-one-encoding point of view and break compatibility with much existing Ruby code.


It's being worked on right now and the infrastructure for it already in place. It's a goal.




Consider applying for YC's Fall 2026 batch! Applications are open till July 27.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: