«Тестами». Constraint solver не будет хорошо работать на тестах с фиксированными данными; ему нужны параметрические тесты ≅ уравнения, которыми непрерывную функцию задать элементарно.
А давайте я чуть по-другому сформулирую. У нас есть тест-кейсы, которые описывают все возможные ситуации, которые могут произойти, и то, что должно происходить при них, а потом constraint solver генерирует код, удовлетворяющий этим параметрам. Почему бы и нет?
Следить за обновлениями гемов на продакшне не нужно, так как приложение жестко зависит от определенных версий гемов в Gemfile.lock и с другими просто не запустится; тут «случайно» пропустить обновление нельзя, это два.
Обновления самого Ruby выходят раз в полгода, ну и да, ничто все-таки не мешает использовать системный Ruby, чтобы обновления вам доставляло APT, это три.
А при чем тут вы? Я говорил о тех разработчиках «за еду», чей код я видел. Он ужасен.
Лично я пользуюсь rvm на продакшне и не парюсь по этому поводу, хотя кое-кто, конечно, скажет, что это жутко неправильно. Избежать сборки гемов вряд ли можно, потому что в Дебиане пакетированные гемы древние, как кости мамонта, и для мало-мальски новых рельс они просто не подойдут по версии.
В принципе, как мне кажется (я не пробовал), если ваша версия/проект на Rails работает через Bundler, то все должно работать и с обычным общесистемным Ruby.
Если Ruby и гемы уже установлены, то вебсервер поднимается за пятнадцать минут по первой ссылке в гугле.
Разработчики «за еду» обычно пишут очень плохой код на PHP и вообще не способны написать сколь-нибудь сложное приложение на Rails. И это хорошо.
Что же до развертки… да, это незначительно сложнее, чем для PHP. Вместо туториала за 10 минут придется прочитать туториал и потратить 30 минут. Для всего, кроме поднятия хоста с двумя сотнями дорвеев, это не является каким-нибудь препятствием. Кроме того, мне что-то подсказывает, что PHP с дефолтными настройками для серьезных задач абсолютно не подходит.
И я о коде. Clang все еще хуже коммерческих компиляторов (icc, keil), но рвет gcc без особого труда.
А разгадка одна: безблагодатностьфанатики из GNU, закопавшие модульный дизайн, благодаря которому LLVM столь гибок, а в кишках gcc разбираются 2.5 монаха.
OH SHI~~~ GCC! clang не просто иногда быстрее gcc, он практически всегда быстрее гцц. Доходит до того, что LLVM-ом шейдеры компилируют для CPU, и они вполне себе конкурируют (google://gallium3d) по производительности с low-end GPU вроде последни Интелей. Да, интели не сильно-то и GPU, но они все-таки параллельные и вполне себе domain-specific.
2) Давайте уж определимся, что мы сравниваем. 99% юзеров используют непатченный MRI (или REE, но в основном из-за COW), и у меня вот нет ни малейшего желания тюнить ГЦ. И без того работы хватает.
Фиберы см. выше. Они там есть и вроде как не тормозят. Вполне возможно, что неправильно что-то делаете вы. Я бы в первую очередь заподозрил себя.
Как хорошо, что сейчас не 2006, а вы — не dhh.
rbx _с оптимизациями LLVM_ вполне возможно и позволит, но до этого еще долго идти. Ту же арифметику без статического анализа (я, кстати, над этим какбе работаю) сделать сложно, а нормальный статический анализ в рантайме а-ля JVM или V8 там появится еще ой как нескоро. В jRuby, во всяком случае, это произойдет явно раньше.
rbx очень сильно популяризовал (ну, в своей песочнице, конечно, которая не такая уж и маленькая) использование ffi, что решает большую часть проблем с Cext. Нормальный ffi искореняет необходимость тупых оберток, а умные с нормальным API библиотеки и не нужны (скажем, всякие еполлы и прочие kqueue отлично делаются через ffi, и собирать ничего не нужно). Остаются штуки вроде narray, но они опять же в меньшинстве.
1) Давайте я дам вам свой код, а вы проверите? На MRI, JRuby и MacRuby. Живой проект с вполне реальной, не синтетической, нагрузкой.
2) Вообще ничего не делал с JVM, только -Xmx увеличил слегка.
мнээ. Фиберы — не гем, а часть языка, по крайней мере начиная с 1.9. Про производительность их в jruby ничего сказать не могу, но я что-то не слышал про нативную поддержку continuations в JVM. Опять же, врать не хочу.
3) В рубиниусе immix GC, который является на настоящий момент самым продвинутым с теоретической точки зрения. Верить на слово не предлагаю — почитайте статью. Реализация, возможно, пострадала, но из моего опыта в rbx тормозил в основном ввод-вывод. Еще раз говорю: rbx нужно допиливать, но в нем проблемы именно что в мелочах.
Не такой уж и клёвый? Руби рулит не потому, что гемов много, и, конечно, не тем, что быстрый, а тем, что его метапрограммирование по возможностям ближе всего (из известных мне языков) к лисповым макросам. Возможность писать в шесть-восемь раз меньше кода не означает возможности в то же количество раз меньше думать или отсутствия необходимости оптимизировать. Тормозят, за редкими исключениями, крохотные куски кода. Их и правда лучше переписать на сях, если уж все настолько критично, причем на рубевом API это существенно проще, чем на просто голых сях. В большей части случаев проблема решается просто применением головного мозга.
Надо написать все на Руби? Отлично, большая часть библиотек на руби пишется на порядок быстрее, чем на сях. Я даже не говорю о том, что есть FFI и все такое.
1) Если верить brixen-у (автору rbx), то MacRuby проигрывает даже MRI. Сам не пробовал, макоси у меня нет и не намечается, но попробуйте все же проверить.
2) У меня на вполне реальном GC-интенсивном workload-е (обработка ~десятков тысяч графов с ~тысячами нод, правда не всех одновременно), jruby рвал MRI в два и чуть-чуть больше раз. Пруфы будут, если желаете, я оптимизацией там аж обзанимался. Даже баг нашел в мастере jruby.
«Работает через раз» не замечал, как и «часть кода», но у меня могут быть нетипичные задачи. Для моих портирование сводилось к замене Cext-специфичных гемов и все.
3) Рубиниус, пусть он и по скорости аналогичен или слегка проигрывает MRI, имеет важное преимущество: его авторы не курили что-то очень вставляющее, когда его писали. По хорошему, MRI бы выкинуть нафиг и заменить (допиленным, чтоб не падал) рубиниусом. Совместимость там уже огого какая (буквально на днях, в т.ч. настоящий момент, допиливаются последние кусочки рубиспека 1.9), а код просто на порядки чище и понятнее. Собственно, в Рубиниусе как бы еще нет практически никаких оптимизаций, в отличие от MRI, где новые уже втыкать-то некуда. (Замену ядра аки MRI→KRI я за оптимизацию не считаю.)
Нет, спасибо, REE с учетом перспектив 1.8 адекватным решением не является. Это костыль для поддержки старого кода и не более того.
А я, как рубист, не был бы. Лучший интерпретатор Ruby на данный момент работает поверх JVM. Rubinius, кхм, слегка нестабилен, а MRI тормозной, как полтора барана. JRuby же — drop-in replacement в большей части случаев и невероятно быстр с invokedynamic.
Copy-on-write-совместимая куча из REE уже годы назад как перенесена в 1.9, а крутилочки для GC можно получить, скормив
rvm install
патч из полтысячи строк. Фичи REE вовсе не проблема.
А так… ну да, старые и плохо написанные (потому что про 1.9 известно уже оч-чень давно) приложения, конечно, сломаются. Туда им и дорога. 1.8 должен умереть. В JRuby, кстати, через одну минорную версию 1.8-режим тоже выкинут.
Следить за обновлениями гемов на продакшне не нужно, так как приложение жестко зависит от определенных версий гемов в Gemfile.lock и с другими просто не запустится; тут «случайно» пропустить обновление нельзя, это два.
Обновления самого Ruby выходят раз в полгода, ну и да, ничто все-таки не мешает использовать системный Ruby, чтобы обновления вам доставляло APT, это три.
Лично я пользуюсь rvm на продакшне и не парюсь по этому поводу, хотя кое-кто, конечно, скажет, что это жутко неправильно. Избежать сборки гемов вряд ли можно, потому что в Дебиане пакетированные гемы древние, как кости мамонта, и для мало-мальски новых рельс они просто не подойдут по версии.
В принципе, как мне кажется (я не пробовал), если ваша версия/проект на Rails работает через Bundler, то все должно работать и с обычным общесистемным Ruby.
Если Ruby и гемы уже установлены, то вебсервер поднимается за пятнадцать минут по первой ссылке в гугле.
Что же до развертки… да, это незначительно сложнее, чем для PHP. Вместо туториала за 10 минут придется прочитать туториал и потратить 30 минут. Для всего, кроме поднятия хоста с двумя сотнями дорвеев, это не является каким-нибудь препятствием. Кроме того, мне что-то подсказывает, что PHP с дефолтными настройками для серьезных задач абсолютно не подходит.
А разгадка одна:
безблагодатностьфанатики из GNU, закопавшие модульный дизайн, благодаря которому LLVM столь гибок, а в кишках gcc разбираются 2.5 монаха.2) Давайте уж определимся, что мы сравниваем. 99% юзеров используют непатченный MRI (или REE, но в основном из-за COW), и у меня вот нет ни малейшего желания тюнить ГЦ. И без того работы хватает.
Фиберы см. выше. Они там есть и вроде как не тормозят. Вполне возможно, что неправильно что-то делаете вы. Я бы в первую очередь заподозрил себя.
Как хорошо, что сейчас не 2006, а вы — не dhh.
rbx _с оптимизациями LLVM_ вполне возможно и позволит, но до этого еще долго идти. Ту же арифметику без статического анализа (я, кстати, над этим какбе работаю) сделать сложно, а нормальный статический анализ в рантайме а-ля JVM или V8 там появится еще ой как нескоро. В jRuby, во всяком случае, это произойдет явно раньше.
rbx очень сильно популяризовал (ну, в своей песочнице, конечно, которая не такая уж и маленькая) использование ffi, что решает большую часть проблем с Cext. Нормальный ffi искореняет необходимость тупых оберток, а умные с нормальным API библиотеки и не нужны (скажем, всякие еполлы и прочие kqueue отлично делаются через ffi, и собирать ничего не нужно). Остаются штуки вроде narray, но они опять же в меньшинстве.
2) Вообще ничего не делал с JVM, только -Xmx увеличил слегка.
мнээ. Фиберы — не гем, а часть языка, по крайней мере начиная с 1.9. Про производительность их в jruby ничего сказать не могу, но я что-то не слышал про нативную поддержку continuations в JVM. Опять же, врать не хочу.
3) В рубиниусе immix GC, который является на настоящий момент самым продвинутым с теоретической точки зрения. Верить на слово не предлагаю — почитайте статью. Реализация, возможно, пострадала, но из моего опыта в rbx тормозил в основном ввод-вывод. Еще раз говорю: rbx нужно допиливать, но в нем проблемы именно что в мелочах.
Не такой уж и клёвый? Руби рулит не потому, что гемов много, и, конечно, не тем, что быстрый, а тем, что его метапрограммирование по возможностям ближе всего (из известных мне языков) к лисповым макросам. Возможность писать в шесть-восемь раз меньше кода не означает возможности в то же количество раз меньше думать или отсутствия необходимости оптимизировать. Тормозят, за редкими исключениями, крохотные куски кода. Их и правда лучше переписать на сях, если уж все настолько критично, причем на рубевом API это существенно проще, чем на просто голых сях. В большей части случаев проблема решается просто применением головного мозга.
Надо написать все на Руби? Отлично, большая часть библиотек на руби пишется на порядок быстрее, чем на сях. Я даже не говорю о том, что есть FFI и все такое.
2) У меня на вполне реальном GC-интенсивном workload-е (обработка ~десятков тысяч графов с ~тысячами нод, правда не всех одновременно), jruby рвал MRI в два и чуть-чуть больше раз. Пруфы будут, если желаете, я оптимизацией там аж обзанимался. Даже баг нашел в мастере jruby.
«Работает через раз» не замечал, как и «часть кода», но у меня могут быть нетипичные задачи. Для моих портирование сводилось к замене Cext-специфичных гемов и все.
3) Рубиниус, пусть он и по скорости аналогичен или слегка проигрывает MRI, имеет важное преимущество: его авторы не курили что-то очень вставляющее, когда его писали. По хорошему, MRI бы выкинуть нафиг и заменить (допиленным, чтоб не падал) рубиниусом. Совместимость там уже огого какая (буквально на днях, в т.ч. настоящий момент, допиливаются последние кусочки рубиспека 1.9), а код просто на порядки чище и понятнее. Собственно, в Рубиниусе как бы еще нет практически никаких оптимизаций, в отличие от MRI, где новые уже втыкать-то некуда. (Замену ядра аки MRI→KRI я за оптимизацию не считаю.)
Нет, спасибо, REE с учетом перспектив 1.8 адекватным решением не является. Это костыль для поддержки старого кода и не более того.
А так… ну да, старые и плохо написанные (потому что про 1.9 известно уже оч-чень давно) приложения, конечно, сломаются. Туда им и дорога. 1.8 должен умереть. В JRuby, кстати, через одну минорную версию 1.8-режим тоже выкинут.