Вышел новый JRuby 9000! Зачем нужен JRuby?

Одна из загадок лично для меня - взлет жраби и невзлет того же жытона. Чем они отличаются?

Вопрос знатокам в зале - зачем нужен JRuby?

Чтобы альтернативно одаренным было с чем коротать время?

невзлет того же жытона

Потому что жытон не нужен, когда есть сытон

Sython? Wtf?

Сходи по ссылке, там немного годноты имеется, как ни странно.

NesSython ЯП для любителей экспериментировать

Сходи по ссылке, там немного годноты имеется, как ни странно.

Сам ходи, когда тема касается руби ходить по ссылкам - это пустая трата времени =)

А почему ты считаешь что жруби взлетел а житон нет?

Потому что это так). Жраби 9.0.0.0 соответствует текущей версии руби, 2.2. А насколько отстает жытон, я даже не знаю.

Занятный факт: в любой теме, связанной с руби, обязательно отмечается неудовлетворенный жизнью пистонист :)

и да, JRuby не нужен

Я на продакшене ни разу не встречал жруби, а вот с житоном работал более 2х лет. Так что это ещё вопрос кто где взлетел.

И да, я считаю, что жруби и житон нинужны так же как руби и питон.

Не нужное не нужно. В жабе для скриптов есть Groovy, а в Ruby интеграция с жабой не нужна.

Потому что питон без кучи библиотек на С не нужен.

JRuby

Была ниша для сексуально не удовлетворённый пользоваталей Groovy.

Сдается мне, что в реальном мире не нужно только то, что не успело обрести статус «легаси».

А что нужно по-твоему?

Чем хуже куча библиотек на Java? Чудаки вон даже какашкель с лишпом на джава-машину натянуть норовят, не хотят чо-то кучу библиотек на Си писать, а готовых, видимо, не хватает.

Тем что к java библиотекам биндингов нету. Ну и интероп у jython какой-то не очень.

Да и когда делали jython, был уже groovy.

Давайте поставим вопрос по другому: зачем нужен раби?

Это внутренний скриптовый язык одного мелкого веб-фреймворка.

Лучше так: зачем нужен логопед? :}

Тебе весь список нужных вещей?

Зачем весь? Парочку нужных в противовес ненужным руби и питону.

А насколько отстает жытон, я даже не знаю.

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

И это при том, что разница между вторым третьим питоном, как между минорными релизами руби.

взлет жраби и невзлет того же жытона

На самом деле ответ очевиден: руби гораздо лучше питона и любого другого языка. Это абсолютно беспрецедентный язык в истории программирования. Ни для одного другого языка не писали такое количество доведенных до ума интерпретаторов. Потому очевидно, что руби просто лучший язык программирования, потому он и взлетает везде. Ни гo, ни питон, ни кложур не годятся руби в подметки.

Еще более очевидный ответ: у того, кто оплачивает разработку jruby, он очень хорошо стоит и работает. Питон и пр. лабуда не встали.

Вот и весь секрет.

зачем нужен раби?

Руби нужен, чтобы программировать.
JS нужен потому, что он в браузере.
Питон не нужен.
Го не нужен.

Питон в линуксе. А руби нет.

Питон в линуксе. А руби нет.

Че?

Жытон делает не команда разработчиков Python core. И ты теплое с мягким сравниваешь, так что - ноу коментс.

Жытон делает не команда разработчиков Python core.

Я о сообществе в целом.

Быстрее работает?

Вообще, вроде как да.
http://jruby.org/bench9000/

https://github.com/jruby/jruby/wiki/Truffle
JRuby+Truffle is a project of Oracle Labs

Походу jruby идет в Ынтерпрайз.

Ближайшее направление, в котором последуют новые большие изменения — это конкуренси. Как всем уже известно, Матц несколько месяцев назад писал, что хочет добавить в язык новую абстракцию для конкуренси и убрать GIL.

В сообществе идеи на первую тему уже давно довольно успешно исследуются (в итоге у нас есть гем concurrent-ruby с очень сильной командой разработчиков, который предоставляет всевозможные примитивы и абстракции для конкуренси (в том числе и более экзотические, например, software transactional memory и dataflow)).

Но решение убрать GIL свидетельствует о серьезности изменений, а не простом копировании какой-то библиотеки в ядро руби. И речь идет не о более мелких локах, которые Матц отвергал на протяжении долгого времени. Судя по последним презентациям Koichi Sasada (ko1, один из трех членов команды Матца), нас ожидает модель с раздельной памятью и ограниченным регионом общей памяти. Раздельная память будет представлена, скорее всего, с помощью актеров. Доступ к общей памяти будет, видимо, с каким-то защитным механизмом, чтобы из актеров не получилось обычных тредов с дополнительным режимом коммуникаций. Но не уверен, что такой компромис на практике сработает.

Предложение от Tony Arcieri (известен больше всего по celluloid): возможность привязывать связанные объекты к конкретному треду (с автоматическом рейзом ошибки при обращении из других тредов) — позволило бы текущим реализациям актеров и каналов решить проблему с изоляцией данных между тредами весьма эффективным и простым способом.

Неважно, какой в итоге способ будет выбран, главное что начало диалогу в области конкуренси положено, а предыдущие обсуждения (например, с рефайнментами) показывают, что Матц готов к конструктивному диалогу (надеюсь, протолкнут формализованную модель памяти).

Не стоит бояться или надеяться на радикальные решения. Принимаемые Матцом решения достаточно эволюционны, чтобы все сообщество двигалось вперед и не фрагментировалось по версиям из-за трудностей перехода.

Поэтому в области больших изменений языка, наверное, это все на ближайшее время. Надо дать время, чтобы общество не просто поддерживало руби 2.x, но и сформировался консенсус по использованию нового функционала, например, keywords, prepend, refinements. Поэтому новость о том, что в 5 рельсах будут поддерживать только руби 2.2+ радует.

Что будет среди мелких изменений, гадать не буду, благо, в каждом релизе таких изменений, сформированных в результате фидбека от сообщества, хватает. Главное, что постепенная модернизация стдлиб идет.

Зато в области развития самой MRI и дополнительных средств для анализа рантайма все будет и дальше лучше с каждой версией. Теперь трейсить и мониторить исполнение методов и аллокаций объектов в руби проще чем когда-либо с помощью гема stackprof (автор — инженер гитхаба и контрибутор руби Aman Gupta), не хватает лишь веб интерфейса для более простого интерактивного анализа профайл-дампов.

Из грядущего нас ожидает, скорее всего, JIT-компилятор для MRI от Koichi, хотя Матц не исключает и AOT.

Несмотря на эти хорошие новости, я связываю будущее развитие руби с jruby. Но не просто jruby, а поверх truffle (в комбинации с graal и substrate VM). Нашему сообществу значительно повезло, что талантливые ребята из отдела Oracle Labs VM Research решили обкатать свои теоретические наработки в области разработки и оптимизации ВМ на руби. Рекомендую следить за блогом Chris Seaton, который объясняет, как они на порядок ускоряют руби. Еще одно отличие от обычного jruby состоит в поддержке C-расширений без деградации скорости. Надеюсь, увидеть публичный релиз в 2015 году. В планах на чуть более далекое будущее достичь время стартапа как у MRI (что, как демонстрирует прототип функциональности, достижимо).

Про рельсы.

От 5-ых рельс, которые будут этой весной, ожидаю, в основном, поверхностное обновление АПИ, связанное с уже упомянутым прекращением поддержки предыдущих версий руби. Больше символов, проще логика с prepend, чище методы с keyword arguments и тому подобное.

Надеюсь, под руководством Аарона Патерсона rack 2.0 будет доведен до ума. Поддерживать стриминг без костылей — это самая простая постановка задачи. В конце года выйдет стабильная спецификация HTTP 2.0 и формата request-response даже со стримингом недостаточно. Нативная поддержка семантики HTTP, как пытаются сделать webmachine и http-2 гемы, упрощает решение разных специфичных задач, но усложняет общее АПИ — сложность, как обычно, в поиске компромиса.

Параллельно с рельсами будет развиваться и дальше сопутствующая инфраструктура. На базе докера появятся инструменты для девелопмента, которые, с одной стороны, полностью предоставляют все необходимые сервисы и библиотеки для приложения (включая версию руби), при этом, с другой стороны, работа с ними будет абсолютно прозрачной: зашел в папку проекта, написал setup и у тебя поднялись все необходимые сервисы, а бинарники ruby, bundle, rails и остальные проксируются к запущенному образу. Система девелопера всегда чистая, проект всегда готов к запуску на любой системе, при этом разницы между разработкой никакой. В области деплоя переход на докер тоже может принести много бенефитов, но для этого нужен более высокоуровневый инструмент поверх него, который будет отвечать за развертывание, проксирование для переключения и ролбека без даунтайма, сбор логов, контроль крона и тому подобное.

Формирование новых конвенций для рельс-приложений далеко от завершения, общие идеи понятны, но общепринятого консенсуса по деталям пока нет. Более комплексные подходы, такие как гем trailblazer, имеют больше шансов на распространение, так как многие конвенции лучше всего работают в связке. В этом же геме есть идея концепций, которая может прижиться в сообществе, в котором хотят достичь большей модульности, но не всегда готовы к оверхеду полноценных сервисов или в ситуациях, когда обычные энджайны рассматриваются как оверкил.

Возможно, в дальнейшем поверх стриминга в рельсы добавят абстракции для построения датафлоу с клиентом (пока эксперименты с реактивной связью между сервером и клиентом вызывают довольно широкий интерес, даже если смотреть только в рамках руби сообщества, то voltrb стал популярным довольно быстро, хоть и находится на очень ранней стадии разработки).

ведущий разработчик Oh My Stats Равиль Байрамгалин
http://habrahabr.ru/company/railsclub/blog/237617/

Приятно излагает. Жаль, на ЛОР'е вместо таких людей клоуны одни, вроде нас с тобой, ха-ха-ха ))

А насколько отстает жытон, я даже не знаю.

Че жытон, цытон сам от себя отстает! Третьему питону 6.5 лет, а все застряли на 2.7.

конкуренси

Приятно излагает.

фууу.

Ты у меня в игноре, так что не старайся особо воевать с ветряными мельницами :).

Ты вообще кто и почему ты меня должен волновать? Я — человек идейный, воюю с идеями. Кто их сморозил — совершенно не важно.