Это все фреймворки не для многопоточных приложений а multiplexing. Я этим не занимался вообще, так что незнаю.
По поводу многопоточных серверов в плане системного программирования:
Есть fork(), в случае perl можно быть уверенным что если собрались писать сервер (веб сервер, прокси сервер — системное программирование), то он заработает. Сигналы, потоки, библиотеки всё хорошо изучено в этом плане. Фреймворк для системного программирования не нужен.
Тоже хорошо подходят для серверов вроде python и java. Ruby — плохо, его без rails не используют.
Настоящих threads в perl нет.
по поводу числовых данных
perl -Mbignum -le 'print ref(2**255)'
Большие массивы текстовых данные это какие?
1) Большие куски не структурированного текста
2) Структурированные данные, текстовые строки, числа, например всё то что находится в реляционной БД
3) Большие куски бинарных данныех — картинки, архивы, зашифрованные файлы.
Со всем этим perl хорошо справляется, п.3. — естественно native кодом, вызов библиотек для обработки картинок, например. никто же не будет на динамическом языке анализировать каждый пиксель.
Про многопотоковое сетевое — это смотря что это значит. Приведите пример. Обычно сервера отлично пишутся на perl, и нужно там POE или нет зависит от задачи.
На счёт выбора инструмента — кто будет начинать свой стартап с изучения нового языка (из соображений что кто-то где-то написал что он хорошо подходит к задачи)?
Основные программисты, что это писали, знали, как минимум Java и Perl. Не уверен на счёт других языков.
Но я работал с этим кодом, думаю, например, ruby с rails там бы не прижился, код имел отношение не только в Web, но и к обработке больших массивов данных, так же подход к программированию был творческий, применялось KISS (с элементами отрицания DRY), использовались нестандартные паттерны (опять же многие другие подходы отрицались), был изобретён собственный маленький функциональный язык программирования для одной из маленьких задач.
Создание изолированных окружений это одна проблема, она не отменяет портирование кода в новые версии языка (т.к. просто программистов и библиотек по старые не найти).
У perl так же есть perlbrew, функций там поменьше чем в rvm, зато он не написан на bash/zsh.
Bunlder перлу просто не нужен ИМХО, можно указывать минимальные версии подключаемых библиотек, а как таковой проблемы с gem hell как в ruby просто нет.
Мне кажется это связано с monkey patching в ruby (к этом сила и слабость ruby одновременно) — например, вы подключили gem, а он модифицировал код в каком-то другом (системном) геме, из-за этого проявляется ошибка.
Кстати создавать каждому приложению изолированные окружения — это не такое уж и «бесплатное» решение — усложняется deploy на production, или, например rvm+passenger в случае с разными версиями ruby, или не работал нормально или не был stable, когда я последний раз смотрел.
Это такой намёк что если кто-то программирует на Perl, то это обязательно старый древний код?
Вот полтора года назад видел как начанался новый проект на Perl, с нуля. Код был и типичный «web 2.0» веб сайт и нечно более сложное. Получили в этом году несколько миллионов евро инвестиций.
Видел проект, где код — ruby, старой версии, документации нет, тестов нет, комментариев нет. Чтобы разобраться с ним у коллектива ушло больше времени чем на написание (с нуля нельзы было писать, т.к. всё было отлаженно юзерами, к тому же не хотелось юзеров переучивать)
Реально тяжело Ruby developer'ам. Написал код, а он через пару лет уже устарел, все библиотеки не совместимы с новой версией языка, разработчиков под старую версию уже не найти (не охота им с этим возиться).
Кстати, скрит на perl 10-летней давности, скорее всего запустится в новой версии интерпретатора без особых проблем.
1) А представьте что было бы если бы проект был написан не на Perl, а на Ruby 1.8, Rails 2 + куча гемов для Rails 2.
Счас бы точно так же всё пришлось переписывать с нуля, или латать дыры.
2) Простота настройки и скорость разрабоки в начале, могут выйти боком потом.
В Rails по моему оптыту — если действовать по принципу быстро подключать готовую библиотеку и никогда не изобретать «велосипеды», то потом гораздо больше времени уйдёть чтобы это поддерживать, чем на написание этих «велосипедов». Если сайт сложный — нужно часто писать велосипеды, гемами нужно пользоваться с умом, избегать использования их без существенного повода.
Ничего просто так не даётся.
Ленту.ру можно небось вообще на wordpress сделать, а потом плагины писать — вот уж точно будет высокая скорость разработки вначале.
Как Rails программист могу сказать про веб фреймворки.
ИМХО Rails хорошо подходят если нужно:
— быстро делать вебсайты в стиле web 2.0
— главное скорость разработки а не стабильность.
— много программитсов, которые незваисимо друг от друга пилят проект, каждый в своём стиле
— апгрейдить проект под новый ruby и рельсы каждые пару лет — это ок.
в остальных случаях «веб разработки» нужно разбираться — может лучше обойтись без MVC.
На счёт скорости — да, не быстро. Но, например python3 делали 8 лет.
В случае с perl6 делали не только язык но и новую виртуальную машину (универсальную), так же при дизайне языка задумывались о всём том коде который уже написан на perl5, и не только о совместимости но и о идеологии perl.
Ну и наверное не всё шло(идёт) гладко. Жаль что не известно точно что именно там происходит и в чём проблемы.
По моему опыту с предыдущими (k)ubuntu — будут проблемы, может глючить что-то в долгосрочной перспективе (если использовать, обновлять её несколько лет) индикаторы, звук, 3rd party программы всякие, офис.
Их никто не тестирует в какой либо конфигурации кроме самой распространённой, пользователь останется в таком же положении что и пользователи редко используемых дистрибьютивов.
По поводу многопоточных серверов в плане системного программирования:
Есть fork(), в случае perl можно быть уверенным что если собрались писать сервер (веб сервер, прокси сервер — системное программирование), то он заработает. Сигналы, потоки, библиотеки всё хорошо изучено в этом плане. Фреймворк для системного программирования не нужен.
Тоже хорошо подходят для серверов вроде python и java. Ruby — плохо, его без rails не используют.
Настоящих threads в perl нет.
по поводу числовых данных
perl -Mbignum -le 'print ref(2**255)'1) Большие куски не структурированного текста
2) Структурированные данные, текстовые строки, числа, например всё то что находится в реляционной БД
3) Большие куски бинарных данныех — картинки, архивы, зашифрованные файлы.
Со всем этим perl хорошо справляется, п.3. — естественно native кодом, вызов библиотек для обработки картинок, например. никто же не будет на динамическом языке анализировать каждый пиксель.
Про многопотоковое сетевое — это смотря что это значит. Приведите пример. Обычно сервера отлично пишутся на perl, и нужно там POE или нет зависит от задачи.
На счёт выбора инструмента — кто будет начинать свой стартап с изучения нового языка (из соображений что кто-то где-то написал что он хорошо подходит к задачи)?
«You will be given the opportunity to work with the cutting edge of technology»
вообще что мы ищем?
Я искал явные упоминания о том что код старый или о том что нужная его поддержка (багфиксы, минимум новых фич, перевод на новую версию)
Если просят добавить новые фичи или «cutting edge of technology» — это разве поддержка legacy кода?
Если искать только объявления где сказано что продукта (кода) ещё нет и его будем только делать, то таких мало и не только в Perl.
Но я работал с этим кодом, думаю, например, ruby с rails там бы не прижился, код имел отношение не только в Web, но и к обработке больших массивов данных, так же подход к программированию был творческий, применялось KISS (с элементами отрицания DRY), использовались нестандартные паттерны (опять же многие другие подходы отрицались), был изобретён собственный маленький функциональный язык программирования для одной из маленьких задач.
У perl так же есть perlbrew, функций там поменьше чем в rvm, зато он не написан на bash/zsh.
Bunlder перлу просто не нужен ИМХО, можно указывать минимальные версии подключаемых библиотек, а как таковой проблемы с gem hell как в ruby просто нет.
Мне кажется это связано с monkey patching в ruby (к этом сила и слабость ruby одновременно) — например, вы подключили gem, а он модифицировал код в каком-то другом (системном) геме, из-за этого проявляется ошибка.
Кстати создавать каждому приложению изолированные окружения — это не такое уж и «бесплатное» решение — усложняется deploy на production, или, например rvm+passenger в случае с разными версиями ruby, или не работал нормально или не был stable, когда я последний раз смотрел.
Вот полтора года назад видел как начанался новый проект на Perl, с нуля. Код был и типичный «web 2.0» веб сайт и нечно более сложное. Получили в этом году несколько миллионов евро инвестиций.
Видел проект, где код — ruby, старой версии, документации нет, тестов нет, комментариев нет. Чтобы разобраться с ним у коллектива ушло больше времени чем на написание (с нуля нельзы было писать, т.к. всё было отлаженно юзерами, к тому же не хотелось юзеров переучивать)
Реально тяжело Ruby developer'ам. Написал код, а он через пару лет уже устарел, все библиотеки не совместимы с новой версией языка, разработчиков под старую версию уже не найти (не охота им с этим возиться).
Кстати, скрит на perl 10-летней давности, скорее всего запустится в новой версии интерпретатора без особых проблем.
Счас бы точно так же всё пришлось переписывать с нуля, или латать дыры.
2) Простота настройки и скорость разрабоки в начале, могут выйти боком потом.
В Rails по моему оптыту — если действовать по принципу быстро подключать готовую библиотеку и никогда не изобретать «велосипеды», то потом гораздо больше времени уйдёть чтобы это поддерживать, чем на написание этих «велосипедов». Если сайт сложный — нужно часто писать велосипеды, гемами нужно пользоваться с умом, избегать использования их без существенного повода.
Ничего просто так не даётся.
Ленту.ру можно небось вообще на wordpress сделать, а потом плагины писать — вот уж точно будет высокая скорость разработки вначале.
ИМХО Rails хорошо подходят если нужно:
— быстро делать вебсайты в стиле web 2.0
— главное скорость разработки а не стабильность.
— много программитсов, которые незваисимо друг от друга пилят проект, каждый в своём стиле
— апгрейдить проект под новый ruby и рельсы каждые пару лет — это ок.
в остальных случаях «веб разработки» нужно разбираться — может лучше обойтись без MVC.
my $i = 1; for (1..1000000) { $i += 1; }работает в 245 раз медленне чем в perl5.
похоже они вообще не приступили к стадии оптимизации. имхо 2-3 года это минимум прежде чем первый стабильный релиз будет.
В случае с perl6 делали не только язык но и новую виртуальную машину (универсальную), так же при дизайне языка задумывались о всём том коде который уже написан на perl5, и не только о совместимости но и о идеологии perl.
Ну и наверное не всё шло(идёт) гладко. Жаль что не известно точно что именно там происходит и в чём проблемы.
б) В РФ компании принимают Webmoney и прочие «платёжные системы», как-то отчитываются, налоги платят.
при этом всё юзеры спокойно, анонимно (в случае BTC), обмениваются этими интернет деньгами.
Их никто не тестирует в какой либо конфигурации кроме самой распространённой, пользователь останется в таком же положении что и пользователи редко используемых дистрибьютивов.