>Тысячи фиксов для совместимости с оригинальным Ruby

Вот они, последствия отсутствия четкого стандарта...

щас опять набегут невыдохшиеся жабафобы-погромисты на глобальном и надежом сами знаете чем, и будут ныть.

php фарева

Это что интерпретатор на основе интерпретатора??

m/jaba/java

Забыл уточнить. Это видимо Ruby слишком мало памяти кушало и решили сие сделать поверх Java. Ждем PHP поверх JRuby, а иначе ж нельзя будет сказать, что тормозит.

Вообще ты, конечно, прав. Только этот релиз JRuby содержит компилятор, так что руби-код нормлаьно компилится в jdk-байткод. Компилить можно как в обычном режиме, так и в just-in-time. Кстати, те же рельсы на jruby тоже компилятся. Хотя и как интерпретатор его использовать никто не запрещает.

jrubyphp

php - гавно. Сто тысяч мух не могут ошибаться.

Вообще-то JRuby это интрепретатор Ruby 1.8.6 написанный целиком на Java. Версия 1.1 отличается от 1.0 приростом производительности и наличием JIT. Это если вкратце.

могут или не могут, мухи или тараканы в конечном счёте дело не в языке, а в программистах

Да, да, да. И даже в тех, которые это гавно лепят.

в биореактор

БЫДЛОРЕАКТОР

бугога =)) вот это новость!!! =)

Интересно, как оно по скорости с Ruby/Groovy, а так же, на ряде типичных задач, со Scala?

Компляция в байт-код не означает убыстрения производительности (или JVM уже нативно поддерживает динамические языки и я в танке сижу?)

Стандарты это гут.

>>Тысячи фиксов для совместимости с оригинальным Ruby

>Вот они, последствия отсутствия четкого стандарта...

Стандарт в данном случае один -- эталонная реализация интерпретатора Ruby на C. JRuby задумка хорошая, но раз оно с Ruby не совместимо полностью -- в рубиреактор.

> щас опять набегут невыдохшиеся жабафобы-погромисты на глобальном и надежом сами знаете чем, и будут ныть.

Первыми будут ныть жабофилы со словами "языки, отличные от жабы, не нужны"

>Компиляция Ruby-кода в Jaba-bytecode

Интересно, как скорость его соотносится с оригинальным Ruby?

Бьюсь об заклад, что не на порядок быстрее....

>Ждем PHP поверх JRuby

Есть PHP на Java - Quercus.

>Бьюсь об заклад, что не на порядок быстрее....

Если бы на порядок - это была бы killer feature :)

Так что - интересно. М.б. сам оттестирую, как время будет. Если хотя бы не медленнее - уже будет отлично.

ждем с#jruby-интерпретатор

>Это что интерпретатор на основе интерпретатора??

А ты в курсе, что ты читаешь это сообщение в браузере, код которого интерпретируется?

> А ты в курсе, что ты читаешь это сообщение в браузере, код которого интерпретируется?

Шо? O_o

(читаю в конке)

>Стандарт в данном случае один -- эталонная реализация интерпретатора Ruby на C.

Я о том и говорю: есть только эталон, эталонная реализация != стандарт.

На Euroko 2008 где был аннонсирован JRuby 1.1 создатели рассказывали, что на большинстве тестов сейчас JRuby опережает оригинальный CRuby (Matz version). Не имеются ввиду тесты типа вывода одной строчки в stdout.

>читаю в конке

Угу. А Конк у тебя почти наверняка в машинных кодах x86/x86_64 (я прав?). А они сегодня почти все интерпретируемые. Транслируются во внутренние представления процессора по мере исполнения, а не сразу при запуске :)

А, ну это да, знаем-с. Но формально это не интерпретация, потому что коды х86 уже машинные, просто не нативные ;)

> Угу. А Конк у тебя почти наверняка в машинных кодах x86/x86_64 (я прав?). А они сегодня почти все интерпретируемые. Транслируются во внутренние представления процессора по мере исполнения, а не сразу при запуске :)

Как минимум JavaScript на этой странице интерпретируется :)

И зачем оно надо?

Оно надо.

А делфи на жабе будет? Чтобы поверх него запускать пхп.

captcha: sourter

а кому оно надо?

Здорово! Чем больше будет зрелых языков на платформе Java, тем меньше будет преимуществ у .NET-а.

Кстати, как у JRuby интероперабельность с джавой? Туда-назад можно нормально вызывать методы? У Scala, например, всё почти замечательно.

Вот людям делать нефиг.

>> Бьюсь об заклад, что не на порядок быстрее....

> Если бы на порядок - это была бы killer feature :)

На синтетических тестах иногда обогоняет 1.9(который сам в 3х быстрее 1.8). Практически всегда быстрее 1.8.

Эта версия Руби еще интересна тем, что поддерживает нативные потоки без GIL-a(привет питону :)) и может работать прозрачно с явовскими библиотеками. Кроме того есть glassfish gem для удобного деплоймента на соответствующий веб-сервер.

> Кстати, как у JRuby интероперабельность с джавой? Туда-назад можно нормально вызывать методы?

http://wiki.jruby.org/wiki/Calling_Java_from_JRuby - судя по этому все шеколадно.

> а кому оно надо?

Мне однажды понадобилось. В Руби 1.8 зеленые нити и библиотека ICE реализует только клиент для Руби. В JRuby потоки честные да еще и без GIL-a. Кроме того для ICE есть явовская библиотека. Соответственно JRuby + JavaIce дали возможность выполнить эту задачу.

рубикапец?

> ruby

> java

Оу! Они, наконец, нашли друг друга!

Дождались.

> ждем с#jruby-интерпретатор

Чего ждать-то, уже Ruby.Net есть. Вот когда Java на dotNet напишут...

>Интересно, как оно по скорости с Ruby/Groovy, а так же, на ряде типичных задач, со Scala?

с Oroovy примерно одинаково и медленнее программ на жаба/Scala в 10-100 раз (как и Groovy).

Ура JSR-223! http://jcp.org/en/jsr/detail?id=223

> Вот они, последствия отсутствия четкого стандарта...

+1

Лучше иметь устакененный стандарт языка на котором что-либо пишешь. Хоть я не люблю Java и C#, но у них есть свой стандарт. C, C++, Scheme, Common Lisp, Fortran имеют свой стандарт. Поэтому я выбираю их. А всякие там Ruby, Python, Scala бла, бла, бла имеют только одного "benevolent dictator" и ЯП может просто погибнуть от маразма аффтара.

> Чего ждать-то, уже Ruby.Net есть. Вот когда Java на dotNet напишут...

Очнись, уже давно есть J# - http://ru.wikipedia.org/wiki/Visual_J_Sharp

>Оно надо.

Весьма категорично.

>C, C++, Scheme, Common Lisp, Fortran имеют свой стандарт. Поэтому я выбираю их.

Роль стандарта Си долгое врема выполняла нетленка K&R. А С++ менял концепт на протяжении всех 90-х.

> Вот они, последствия отсутствия четкого стандарта...

+1

Python наше всё!

>Как минимум JavaScript на этой странице интерпретируется :)

он тоже компилится в код JS VM, просто для неё ещё камня нет. так что ничем не отличается от «native» x86. %-)