> А что-то большое я бы на нём делать побоялся, разве что используя концепцию
> микросервисов.
+1, в общем-то.
но делать что-то большое на перле я боюсь с использованием любой концепции...
--
Moscow.pm mailing list
moscow-pm@pm.org | http://moscow.pm.org
> А Go? Там же зеленые треды, как в Java, Haskell, Erlang... Или для Go другая
> причина?
в java нет зеленых тредов.
С Go вот какая беда - нет пока массового опыта реально больших проектов на нем.
ни положительного, ни отрицательного.
я вот ввязался, потому что я то ли глупый, то ли смелый.
а
> GO без поддержки гугла ничего не будет стоить
а вот это нам и предстоит выяснить.
но вообще-то, основная польза от Go нами уже получена, планка для
прочих языкоделов качества задралась на приемлемую высоту.
--
Moscow.pm mailing list
moscow-pm@pm.org | http://moscow.pm.org
> * scalar @arr;
> * @arr + 0;
> * @arr . '';
> * @arr = (1) x @arr; return length join('', @arr);
вот это все одно и то же, "приведение массива к скаляру дает длину массива"
> * $#arr + 1;
это, скорее всего, тоже. надо глядеть, как получается последний
индекс, но, скорее всего, вычитанием
> нет ничего хорошего в том что язык вместо очевидного решения предлагает
> привычное
так или иначе все языки этим грешат. нет смысла на этом заострять...
--
Moscow.pm mailing list
moscow-pm@pm.org | http://moscow.pm.org
> Разъясните сферу практического применения для size.
а почитайте, что возвращает хеш-таблица при приведении к скаляру.
сразу все поймете.
--
Moscow.pm mailing list
moscow-pm@pm.org | http://moscow.pm.org
> Я под размером массива понимаю количество элементов, реально
> существующих в памяти.
реально память выделена под capacity элементов. но итераторам и по
индексу доступно size элементов.
capacity больше size делают для того, чтобы push не вызывал при каждом
вызове выделения памяти и копирования
> * Создаете назойливые чатики в IRC/Skype/Jabber/WhatsApp/Telegram?
создаем
--
Moscow.pm mailing list
moscow-pm@pm.org | http://moscow.pm.org
> Новых адептов итак хрен затащишь, да ещё вы “помогаете”. Зачем эта статья?
эта статья (которую я лично не читал), как и весь хабр, для самопиара.
но. какие новые адепты?!
коллеги, ну отдайте себе уже отчет.
все то, что было хорошего в perl, перестало быть актуально лет так 10
уже назад...
--
> А разве Perl чем-либо ограничивает Вас в развитии ваших программ/проектов
> ?
вообще-то - да, ограничивает. и, вроде, все в курсе, где и как.
--
Moscow.pm mailing list
moscow-pm@pm.org | http://moscow.pm.org
> Решили добавить на основе сушуствующего проекта сделать что-то большие, а
> новый людей не набрать...
пока - набрать. перл прикольный язык, до сих пор привлекает адептов...
но!
1. по техническим причинам писать новую систему на перле смысла нет
2. это означает, что вся работа, которая есть на
> Может не в тему, но что пишем и почему нет смысла?
а что ни пиши - проблемы все те же три:
1. нет возможности утилизировать несколько ядер в рамках одного процесса.
2. нет семплирующего профайлера. этот, кстати, мог бы уже и быть -
вроде бы, последний perl5 использует стандартный стек. но - нет
коллеги, ну полная же херня. с практической точки зрения никакого
возврата памяти нет - потребление или стабильно, или растет.
а даже если бы и был - нахера он нужен? другой программе эту память
отдавать все равно нельзя - а вдруг она первой программе понадобится
опять...
и это, согласитесь, хара
я готов, че :)
у меня на руках несколько докладов про go, про перл ничего нет сейчас.
в принципе - можно сделать сравнение регекспов в perl и go, это
нишевая, но интересная тема
2017-08-12 13:57 GMT+03:00 Ilya Chesnokov via Moscow-pm :
> Привет!
>
> Спасибо всем, кто ответил на вопросы! Вот кр
> На чем его писать наиболее удобно и правильно? С хорошим синтаксическим
> сахаром, с уверенностью, что модули зрелые, production ready и поддержка
> завтра не исчезнет.
зачем делать это на perl в 2019 году?
--
Moscow.pm mailing list
moscow-pm@pm.org | http://moscow.pm.org
15 matches
Mail list logo
