LINUX.ORG.RU

Ruby 2.0.0 preview1

 


2

6

Анонсирован Ruby 2.0.0 preview1. Были включены новые фишки, которые делают разработку на Ruby ещё приятнее.

Анонсированные фичи:

  • Уточнения (Refinements) [1]
  • Именованные аргументы в методах (сахар над хэшем) [2]
  • Enumerator#lazy [3]
  • Module#prepend [4]
  • #to_h
  • %i, для массивов символов
  • Движок регулярных выражений изменён на Onigmo [5]
  • Поддержка DTrace [6] (не включено)

Пока что ещё не все новые фишки включены в Ruby, это откладывается на следующие анонсы.

Не забываем устанавливать и находить баги, это только сделает Ruby лучше.

Все программы, которые написаны на ruby-1.9 будут работать на ruby 2.0, если в них не будет особой магии.

>>> Подробности

anonymous

Проверено: tazhate ()
Последнее исправление: tazhate (всего исправлений: 2)

Ответ на: комментарий от Anatolik

Где в Google Closure есть Clojurescript? То что Clojurescript тесно интегрирован с Google Closure не значит что Clojurescript используют в гугле.

anonymous
()
Ответ на: комментарий от anonymous

Где в Google Closure есть Clojurescript? То что Clojurescript тесно интегрирован с Google Closure не значит что Clojurescript используют в гугле.

Так я этого и не утверждал.

Anatolik ★★
()

Вот что интересно - когда у руби новая версия, петонщики набигают и рассказывают, что руби сосет, а когда у питона новая версия, рубистам вообще насрать, у них никакого батхерта. Забавно, правда?

cdshines ★★★★★
()
Ответ на: комментарий от anonymous

тогда получается что сlojurescript никто не использует и у js/coffee в браузере нет конкурентов

Нет же. Clojurescript — это новая технология, число пользователей которой стремительно растет за счет преимуществ, которые она предоставляет в сравнении с аналогами: https://github.com/clojure/clojurescript/wiki/Rationale

Anatolik ★★
()
Ответ на: комментарий от anonymous

Ещё раз. Проблемы языка, т.е. javascript'а. В кофескрипте проблем быть не может, это не язык, это попытка исправить перегруженый, но привычный многим js на менее перегруженый и непривычный всем, ни на что не похожий синтаксис.

А какие проблемы в js - ну тут написано так много, что гугл расскажет лучше меня :)

Alve ★★★★★
()
Ответ на: комментарий от anonymous

Возможно сейчас у ruby и python есть фишки которых нет в node, но: - либо это не нужно

Таки не нужно?) http://www.ruby-doc.org/core-1.9.3/Array.html http://www.ruby-doc.org/core-1.9.3/Hash.html http://habrahabr.ru/post/140362/

либо это сделают в скором времени

Кстати вот реализация js от mozilla более функциональна https://developer.mozilla.org/en-US/docs/JavaScript/New_in_JavaScript/1.8 https://developer.mozilla.org/en-US/docs/JavaScript/New_in_JavaScript/1.7#Blo...
Никто, не знает, публикуют ли они где-нибудь свою js машину с новым IonMonkey?

- скорость

Ы я тут только что доклад посмотрел http://www.youtube.com/watch?v=tCG0aPNvkTs Внезапно: на js надо писать как на си, прототипирование это плохо, функции лучше помещать в объект, а не прототип и даже О_О копировать текст. Короче, я передумал: к черту v8. Кстати докладчик разрабатывает dart, и говоря о преимущества перед typescript (внезапно) назвал пакетный менеджер :р (который «исторически» нужен -_-)

Там не только js есть. Coffeescript вполне няшный язык.

Coffeescript заточен под кроссбраузерность, которая не нужна на сервере вообще.

special-k ★★★★
()
Ответ на: комментарий от Alve

А мужики то и не знали, пишут себе на чем-то, а это оказывается и не язык даже.
С++ который раньше в C транслировался тоже не язык?

anonymous
()
Ответ на: комментарий от anonymous

А мужики то и не знали

The golden rule of CoffeeScript is: «It's just JavaScript». The code compiles one-to-one into the equivalent JS, and there is no interpretation at runtime.

Alve ★★★★★
()
Ответ на: комментарий от Alve

С++ который раньше в C транслировался тоже не язык?

anonymous
()
Ответ на: комментарий от anonymous

В чем заточенность под кроссбраузерность? Кофе про дом ничего не знает.

Например тут http://stackoverflow.com/questions/10773769/optimize-coffeescript-generated-j... хотя и сошлись, что все хорошо, но вероятно есть и другие примеры.

И еще раз

http://www.youtube.com/watch?v=tCG0aPNvkTs

Код который генерит coffee не оптимален с точки зрения V8. Наследование (которое киллер фича по сути) - зло. Вложенные функции, которые coffee повсеместно генерит - тоже не очень хорошо. На js, чем проще, тем лучше.

special-k ★★★★
()
Ответ на: комментарий от anonymous

Дико извиняюсь, но не могу найти ни одной новости про ноду)

special-k ★★★★
()
Ответ на: комментарий от anonymous

Позиция гугловцев: на js надо писать как на си, а в остальных случаях можешь не упоминать слово «скорость» ;)

special-k ★★★★
()
Ответ на: комментарий от Alve

непривычный всем, ни на что не похожий синтаксис.

Ну для тех кто тыкал Clojure или CL вполне привычный, ну или emacs юзал.

st4l1k ★★
()
Ответ на: комментарий от special-k

Анонимус прав, изначально рубисты бегали к явистам и расказывали как на руби все просто.

st4l1k ★★
()
Ответ на: комментарий от anonymous

И какие же такие преимущества?

Я ведь дал ссылку в посте, на который вы отвечаете. Вы по ней сходили?

Там кратко, однако получить представление о подмножестве проблем JS, которые решает Clojurescript и не решает Coffeescript, можно.

Anatolik ★★
()
Ответ на: комментарий от anonymous

Ну я как бы про это и говорил.. Упоротые господа даже на питоне смогут кашу намесить, не говоря о рубях и перле.

unel
()
Ответ на: комментарий от paranormal

Поясните для Gentoo'шника.

НЕНАВИСТЬ! Почему до сих пор не напишут автоупаковку gem'ов в deb'ы? Нахрена мне в одной ОС разводить бардак двумя системами установки пакетов?

Порядочные FreeBSD-шники устанавливают gem из портов.

Поясните для гентушника. Это выглядит примерно как emerge «ruby-on-rails-gem»? Если так, то годно.

Camel ★★★★★
()
Ответ на: комментарий от special-k

Запили APT.

Потому что система пакетов ruby более совершенна. В дистрибутиве мэнтейнеры следят за версиями пакетов, и для дистрибутива верна только одна версия пакета. В руби же ты можешь использовать разные версии пакетов, bundler подберет тебе неконфликтное сочетание. В каждом отдельном приложении может быть свой перечень библиотек. Нафига завязываться на deb? bundle install как-то проще в 1000000 раз.

Так почему же на эту более совершенную систему пакетов ни один дистрибутив не перешёл?

И таки APT умеет отслеживать зависимости и подбирать неконфликтный набор пакетов из имеющегося. А если каких-то функций нехватает, то надо их добавить в APT, а не разводить помойку, когда в одной системе файлы от APT'а, gem'а, CPAN'а и прочих портажей и хаскелей.

Camel ★★★★★
()
Ответ на: комментарий от shybovycha

Я не работаю на Mac/Win.

Один гем работает для Mac/Linux(/win...?). deb работает в Ubuntu/Debian. И усьо.

Я не работаю на Mac/Win. Я хочу чтобы у меня в Ubunt'е ПО ставилось однообразно, через apt-get. То что в ШINDOШS MacOS'ах до сих пор нет нормальных средств управления ПО — проблема негров.

Экосистема gem'ов вторгается в мою экосистему deb'ов и разрушает её. Одна ОС — один пакетный менеджер, иначе бардак и хана.

Camel ★★★★★
()
Ответ на: комментарий от cdshines

Вот что интересно - когда у руби новая версия, петонщики набигают и рассказывают, что руби сосет, а когда у питона новая версия, рубистам вообще насрать, у них никакого батхерта. Забавно, правда?

Поддерживаю!

renya ★★★★★
()
Ответ на: Я не работаю на Mac/Win. от Camel

Я не работаю на Mac/Win. Я хочу чтобы у меня в Ubunt'е ПО ставилось однообразно, через apt-get.

OKAY, ppa:ubuntu-ruby/ppa

renya ★★★★★
()
Ответ на: Я не работаю на Mac/Win. от Camel

Экосистема gem'ов вторгается в мою экосистему deb'ов и разрушает её. Одна ОС — один пакетный менеджер, иначе бардак и хана.

Если в репозитории той же Ubuntu добавить все gem'ы, то он прилично возрастет.
Зачет это простым людея? Конечно же не надо, поэтому у рубистов свой подход, не зависящий от установленной ОС.
Также это очень удобно при деплое web-приложения.
PS: На rubygems насчитывает 46566 gem файлов. Поэтому не говори ерунды.

renya ★★★★★
()
Ответ на: Запили APT. от Camel

Ответ очевиден. Никто не будет поддерживать 46к+ пакетов руби, 20к+ пакетов питона и т.д. То что ставится аптом - это то, что поддерживают мантейнеры, за что они более-менее готовы отвечать, что они смогут более-менее пофиксить в случае багов и т.п.

Обычному пользователю ничего этого не нужно. Такие инструменты как gem, bundler, rvm - нужны разработчику.

Но, с другой стороны даже обычному пользователю это может быть нужно, например аддоны к фф/хрому/опере: апт не умеет их ставить, пользователю приходится ставить их самостоятельно (тебе в том числе), «разводить помойку». Если бы apt умел бы делегировать установку специфичных библиотек, то помойки было бы меньше, а так ее только больше: он что-то ставит(по усмотрению мантейнеров), а что-то нет. Но еще раз, обычных пользователей эта ситуация устраивает, разработчиков нет, потому что им надо больше, больше чем умеет апт.

special-k ★★★★
()
Ответ на: комментарий от Alve

Непонятными программы делают кривые руки программистов, перед которым все языки равны )

Друг заценил технологию RoR и порекомендовал её как стоящую для разработки софта. Я начал читать книжку по Ruby и после того, как я увидел, что есть 4(!) способа присвоить значение переменной, я понял, что Ruby — не мой путь. Я больше смотрю на вопросы поддержки, чем писания. А программа, написанная на языке, дающем делать такие вольности — это кошмар для поддержки.

Ничего не хочу сказать против Ruby, но даже послушав интервью с Matz, я вижу, что данный язык создавался больше как проект, не имеющий четких целей — реальный just for fun. Matz сам не ожидал, как будет использоваться его язык, но что самое плохо для меня — у него даже сейчас, после нескольких лет после создания языка, (как мне показалось по интервью) нет четкой картины по дизайну языка.

dr_dobermann
()
Ответ на: комментарий от st4l1k

расскажите про проекты на пайтоне прикладные и не из веба и чтоб известные. Это не побег это специфичность задач.

Blade of Darkness — ничего круче во время её выхода не было. Написана была на python 1.5.

dr_dobermann
()
Ответ на: комментарий от renya

Разнообразие хуже безобразия.

Если в репозитории той же Ubuntu добавить все gem'ы, то он прилично возрастет.

Если добавить репозитарий свободного ПО той же ШINDOШS, то он прилично возрастёт. Зачем простым людям Firefox, Gimp, Gajim, VLC. Поэтому не говори ерудны.

В ubuntu-ruby/ppa с некоторой задержкой попадают все gem'ы? Если так, то это примерно то что нужно. И таки я не согласен, что добавление gem-deb'ов в основной репозитарий зло. Пользователь набирает apt-get install gimp и получает Gimp, набирает apt-get install some-ruby-application и получает это application. Почему мы должны ограждать пользователя от использования некоторого ПО просто потому что мы не считает его рубистом? Тем более, что всякая рубятина поставится только если будет нужна по зависимостям.

у рубистов свой подход, не зависящий от установленной ОС.

Иногда я начинаю сомневаться в неадекватности людей утверждающих, что все «рубисты» brain damaged.

Camel ★★★★★
()
Ответ на: комментарий от special-k

PPA.

Ответ очевиден. Никто не будет поддерживать 46к+ пакетов руби, 20к+ пакетов питона и т.д. То что ставится аптом - это то, что поддерживают мантейнеры, за что они более-менее готовы отвечать, что они смогут более-менее пофиксить в случае багов и т.п.

PPA ответ на этот вызов. То что в основном репозитарии Ubunt'ы поддерживается мэнтейнерами Ubunt'ы, то что в Ruby PPA поддерживается мэнтейнерами Ruby PPA. Убедили. Все 100500+ gem'ов и pyp'ов (или как они там называются) в основной репозитарий пока добавить не получится.

Camel ★★★★★
()
Ответ на: комментарий от special-k

Два пакета, которые я пишу используют разные версии одной и той же библиотеки, что делать?

По мне так надо в первую очередь задать вопрос: «А нахрена две версии одного и того же?».

Во-вторую очередь задаться вопросом: «А можно ли на одной версии поехать?».

Множить сущности — вносить ненужные ошибки и точки отказа.

Делать сложные вещи — легко, простые — сложно.

dr_dobermann
()
Ответ на: комментарий от dr_dobermann

Blade of Darkness — ничего круче во время её выхода не было. Написана была на python 1.5.

Я тоже люблю BoD, но там было ядро на Си или Си++, и скриптовая обвязка на Питоне.

tailgunner ★★★★★
()
Ответ на: комментарий от DELIRIUM

Как-то пытался выучить ruby, чуть не блеванул от синтаксиса, остался на perl...

!!!! ЭТО ПЯТЬ !!!! :))))

Однозначно в квотезы!

dr_dobermann
()
Ответ на: PPA. от Camel

PPA ответ на этот вызов.

Если apt действительно умеет одновременно держать в системе много(5-6) версий одной либы (чего я, честно говоря, не видел), то теоретически можно. Это можно генерировать автоматически.. Вопрос будет ли кто-то рад выкачивать ppa про 46к пакетов.. Вот тут-то и будет уместна фраза «более совершенная система» :)

special-k ★★★★
()
Ответ на: комментарий от dr_dobermann

А нахрена две версии одного и того же?

Рубисты не задают себе этот вопрос потому что проблемы нет. Но.. например, недавно пришлось заняться старым проектом, выкачал, «bundle install» и поехали.

А можно ли на одной версии поехать?

Это очень гипотетический вопрос. Ну нафига мне стараться ехать на одной либе в разных проектах.. Пакеты обычно содержат множество зависимостей, соответственно где-то что-то может конфликтовать. У раилз там одни зависимости, у голиафа другие (разработчики поставили и друг с другом не советовались), ну вот к чему мне париться.. Сейчас уже практически невозможно не пользоваться bundler, а главное незачем. Тут нет сложного, тут все очень просто, как при написании, так и при установке.

Встречный вопрос, почему бы не запилить нормальный менеджер пакетов, который мог бы все то же, что и gem? Который не будет давить на разработчика, заставлять отслеживать версии либ, заставлять делать меньше зависимостей. Это же ограничение влияющие на повторное использование кода.

special-k ★★★★
()
Ответ на: комментарий от special-k

Вообще в руби есть акцент, на мой взгляд, на удобство в ущерб производительности, т.е. писать криво ради небольшого ускорение кода в руби не приветствуется.

То, что идёт в ущерб производительности языка, идёт в ущерб языку, ограничивая область его применения.

Ты часто опираешься на порядок «именованных аргументов»? хрен-два, все ручками по элементу чекают «аргументы», а не итерируются по ним. Кейсы, когда упорядоченность реально нужна - 1-2% от общей массы кейсов использования хеша. А это значит, что разумный человек ввёл бы новую сущность для этих 1-2%, вместо того, чтобы замедлять остальные 98%.

Ты проверяешь порядок определения методов по результату #methods ? Порядок определения констант по #constants ? Когда ты делаешь

array1 - array2
тебе важно, чтобы используемый для этого хэш был упорядочен? Да хрен-два.

Если уж OrderedHash.new для тебя слишком громоздко, можно было просто добавить ещё один префикс, аналогично %w, %r и прочим:

my_ordered_hash = %o{first: :arg, second: :arg}
и все писались бы кипятком.

А обычный хэш нужно было оптимизировать максимально, вплоть до смены его структуры... Но, разработчики Matz Ruby действительно излишне предпочитают удобство в ущерб производительности.

А почему бы не maglev? У него же вон какая классная фича есть - никакого session_store не надо..

Ты используешь maglev ? Кто вообще использует maglev ? Возможно я отстал, упустил что-то, но мне кажется, что в данный момент он вообще не юзается, а главное, до сих пор не догнал Matz Ruby по производительности, в то время как JRuby уже давно не мендленнее, а JRuby 1.7 становится намного быстрее.

А то, что «session_store» не надо, так это сомнительное удовольствие... Тем более, что по сути там такая же DB (реализованная на файлах berkleydb, если мне память не изменяет). <trololo-mode> Так что, вряд ли он легко выдержит горизонтальное масштабирование. </trololo-mode>

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

funny_falcon
()
Ответ на: комментарий от dr_dobermann

«А нахрена две версии одного и того же?».

Потому что в новых версиях добавляют новые фичи и иногда ломают старые. Соответственно старый код, полагающийся на них, тоже сломается. А переписывать проект под каждую новую версию библиотеки невозможно, если проект чуть сложнее, чем hello world. Золотое правило: работает - не трогай!

anonymous
()
Ответ на: комментарий от funny_falcon

Ты часто опираешься на порядок «именованных аргументов»?

Да, но какая при этом потеря производительности? Крохотная. Потеря производительности должна быть в больших хэшах, а этих еще нужно найти где применить (и там сильно оптимизированных хэш как раз очень пригодится).

Ты используешь maglev?

Я планирую) Просто, если задуматься, то будущее за реализациями на вм, т.е. за jruby, maglev и rubinius. Но rubinius.. не знаю, может быть только если все сообщество бросит mri и начнет пилить вм рубиниуса.. если это вообще по силам открытому сообществу.. Так что остается jruby и maglev. Скажем так, у maglev идеология правильная. К тому же под ним язык близкий к руби.

до сих пор не догнал Matz Ruby по производительности

Вообще я тестил, у меня был побыстрее процентов на 10-20%. Сам посмотри.. rvm install maglev.

А то, что «session_store» не надо

Вот уж хз... минус многочисленная сериализация-десериализация, думается, очень хорошо скажется на производительности. К тому же будет доступно то, что раньше не было, например, хранить невалидный объект AR, а не генерить каждый раз заново. У нас же CGI по сути сейчас: запрос - нагенерил кучу объектов, назапрашивал данные из бд, нагенерил еще объектов, отдал. Никакого состояния => куча лишних действий.

реализованная на файлах berkleydb

http://gemstone.com/products/gemstone

special-k ★★★★
()
Ответ на: комментарий от funny_falcon

[trolmode] Просто тут же не си, тут думать надо) Язык медленный => мы должны за счет правильной архитектуры вытягивать[/trolmode]

special-k ★★★★
()
Ответ на: комментарий от funny_falcon

То, что идёт в ущерб производительности языка, идёт в ущерб языку, ограничивая область его применения.

То, что идёт в ущерб удобству языка, идёт в ущерб языку, ограничивая область его применения. Ассемблер производителен, но неудобен, его область применения узка. Производительность или удобство - это компромисс, баланс между ними зависит от назначения языка. Интерпретируемые языки занимают свою нишу, в которой важнее удобство. Они нужны для того, чтобы писать быстро и просто, а не заниматься преждевременной оптимизацией. Когда появляется нагрузка, можно начинать профилировать, оптимизировать и переписывать проблемные куски на других языках. Всякой задаче свой инструмент.

anonymous
()
Ответ на: комментарий от funny_falcon

У нас же CGI по сути сейчас...

А конкретно на рельсах так еще в один поток.

special-k ★★★★
()
Ответ на: комментарий от special-k

Я как-то поставил джем rails второй и третей версии в одном окружении, не работали ни вторые, ни третьи рельсы)

Это печально.

Не пойму реакции. Тебе правда грустно (возможно за кривые руки) или это таки норма, что в разноверсионной среде есть проблемы при работе?

dr_dobermann
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.