Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 23
Ну когда же уже будет вторая версия!!!
Учитывая, сколько времени и как разрабатывалась 1.9, я бы предположил, что в течение 3-4 лет.
Мацумото в своем докладе обещал к концу этого года.
Я имел в виду то время, которое потребуется на допил до состояния, в котором действительно можно пользоваться — ну, скажем, индикатором этого может быть работающий Rails.
YARV ведь тоже в 2006 году вышла, а широкого использования когда достигла? На 2.0 запланировано достаточно много значительных изменений, и хотя совместимость, конечно, сохранится, какое-то время на миграцию потребуется.
Возможно, я переборщил. Оценка в 2-3 года реальнее.
YARV ведь тоже в 2006 году вышла, а широкого использования когда достигла? На 2.0 запланировано достаточно много значительных изменений, и хотя совместимость, конечно, сохранится, какое-то время на миграцию потребуется.
Возможно, я переборщил. Оценка в 2-3 года реальнее.
www.rubyinside.com/ruby-core-speaks-on-ruby-1-8-8-1-9-3-and-2-0-4172.html — 2.0 будет через несколько лет, это 1.9.3 выйдет к концу года.
А чем плох 1.9.2?
— нет экономии памяти, как у REE
— 'а'..'я' не включает 'ё'
— вроде бы еще какие-то проблемы с кодировками были
— есть еще много всяких мелочей, связанных с метамоделями (как например описанные в статье выше)
— проблемы работы в асинхронном режиме, чтобы как node.js работать (больше к стандартным библиотекам вопрос, а не к самому языку)
— можно было бы еще как-нибудь над скоростью поколдовать, движки же яваскрипта постоянно ускоряют
— встроенная поддержка shareware-программ, а то сейчас только практически исключительно в saas используется (широко известно только о mingle и github:fi, оба через jruby).
— 'а'..'я' не включает 'ё'
— вроде бы еще какие-то проблемы с кодировками были
— есть еще много всяких мелочей, связанных с метамоделями (как например описанные в статье выше)
— проблемы работы в асинхронном режиме, чтобы как node.js работать (больше к стандартным библиотекам вопрос, а не к самому языку)
— можно было бы еще как-нибудь над скоростью поколдовать, движки же яваскрипта постоянно ускоряют
— встроенная поддержка shareware-программ, а то сейчас только практически исключительно в saas используется (широко известно только о mingle и github:fi, оба через jruby).
— проблемы работы в асинхронном режиме, чтобы как node.js работать (больше к стандартным библиотекам вопрос, а не к самому языку)
EventMachine отлично справляется с тысячами асинхронных подключений.
— встроенная поддержка shareware-программ, а то сейчас только практически исключительно в saas используется (широко известно только о mingle и github:fi, оба через jruby).
Ну это проблема всех интерпретируемых языков, нет?
EM справляется, но тот же rails не больно-то. Уже есть экспериментальное асинхронное приложение на rails, но нужно вручную следить как бы синхронный ввод/вывод где-нить не вылез. Пока что сложно сказать, что ruby/EM такой уж серьезный конкурент для node.js.
Проблема — да, но изначально тот же Rubinius ставил это как одной из главных бизнес-целей. До приемлемого уровня можно довести защиту шаревар.
Проблема — да, но изначально тот же Rubinius ставил это как одной из главных бизнес-целей. До приемлемого уровня можно довести защиту шаревар.
Экономия памяти в REE — по сути порт GC из 1.9. Собственно, REE1.9 до сих пор не вышел именно поэтому. В нем нет смысла — все REE-оптимизации уже есть в 1.9 изначально.
Спасибо, очень интересный перевод. Ждем продолжения.
Руби уже сейчас язык с одним из самых высоких порогов вхождения. После введения всех предложенных изменений, там может начаться такая магия, что это отпугнет много людей.
Самое отпугивающее, что изменения довольно быстро появляются и знания устаревают за полгода-год…
Не могу согласиться. В последних релизах 1.8 сколь-нибудь значимых изменений вообще не было, а из нововведений 1.9 кардинальными мне представляются лишь изменение области видимости block local variables и, конечно, кодировки.
Полный список того, что было запланировано, есть здесь (учтите, что некоторые из описанных там вещей в итоге в 1.9 не вошли).
Еще по поводу быстро появляющихся изменений. Про traits и namespaces matz рассказывал аж в 2005 году, а их до сих пор нет; другие пункты с того же слайда были окончательно реализованы лишь 1-2 года назад в 1.9.
Полный список того, что было запланировано, есть здесь (учтите, что некоторые из описанных там вещей в итоге в 1.9 не вошли).
Еще по поводу быстро появляющихся изменений. Про traits и namespaces matz рассказывал аж в 2005 году, а их до сих пор нет; другие пункты с того же слайда были окончательно реализованы лишь 1-2 года назад в 1.9.
Сначала подумал, что перевод не очень. Потом посмотрел на оригинал.
Перевод очень даже.
Спасибо за перевод :)
Перевод очень даже.
Спасибо за перевод :)
Следующий перевод еще лучше.
Ставлю под сомнение то, что необходимо будет задумываться о правильном способе подключения модуля.
Сведет с ума любого здравомыслящего.
mix, include, prepend, using Сведет с ума любого здравомыслящего.
На самом деле многое из этого уже реализовано, причем гораздо более мозговыносящим методом. Скажем,
prepend — это alias_method_chain в Rails, где он подменяет старую функцию новой и в итоге к старой нельзя обратиться напрямую без каких-то совсем хитрых костылей.mix же как раз-таки должен заменить include насовсем, а using — решить проблему monkey patching, активно использующегося в тех же Rails и приводящего к некоторому хаосу.
Если бы вы хоть раз использовали
Старый метод доступен по имени
И вообще какие там костыли?
alias_method_chain, то не писали бы такого бреда.alias_method_chain :foo, :featureСтарый метод доступен по имени
foo_without_feature. Как же иначе обратиться к нему из оберточного метода?И вообще какие там костыли?
alias_method_chain Это замена такого кода:alias_method :foo_without_feature, :foo
alias_method :foo, :foo_with_featureЗарегистрируйтесь на Хабре, чтобы оставить комментарий
RubyConf 2010: настоящее и будущее Руби (I)