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