Какой ЯП выбрать как дополнение к php — Go или Python?

Question

[MVP_Master]

Пока разрабатываем продукты ипользуя монолитную структуру. На backend у нас php фреймворки.
Собираемся внедрять микросервисную структуру и есть пара идей для проектов, на которых это можно будет испытать и набить шишки. Проекты примерно как Авито - торговые площадки, биржи. Местами требуется большая скорость отклика и обработки информации.

Интересует какой помимо php выбрать язык программироания для ускорения отдельных микросервисов на бэкэнде - Go или Python ?

Понятно, что GoLang быстрее, но Python богаче в плане библиотек и функционала.

Или иными словами какой язык программирования будет хорошим дополнением к php для ускорения ?

Comments

[Ярослав Иванов]

Хороший дополнением для ускорения - прямые руки. Языки тут практически не являются главной причиной.

[Дмитрий]

Ярослав Иванов, Наличие поддержки concurrency и параллелизма в языке может являться помимо прямых рук.

[Денис Юрьев]

Ярослав Иванов, тише, не пали контору

[ThunderCat]

Дмитрий, Наличие чего-либо конкретного под конкретную задачу - может являться, а в абстрактном же функционале в вакууме важнее прямые руки и наличие мозга. Все остальное вообще не сильно важно.

[Дмитрий]

ThunderCat, Причем здесь конкретная задача? Если обрабатываются большие объемы данных или множество запросов, как в случае с авито, то поддержка параллелизма может заметно убыстрять работу приложения относительно языков без данной поддержки.

[MVP_Master]

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

[Дмитрий]

MVP_Master, Да, дешевые понты с намеком что у них-то руки точно прямые. Хамство и самоутверждение увы неотъемлемый атрибут русских программистов. На англоязычных ресурсах такого почти нет.

[Евгений Самсонов]

Для микросервисной архитектуры лучше Go. Менять шило на мыло (PHP на Python), думаю, нет резона. Go компилируем, быстр, можно писать конкурентные приложения

[Сергей П]

Причем здесь конкретная задача? Если обрабатываются большие объемы данных или множество запросов, как в случае с авито, то поддержка параллелизма может заметно убыстрять работу приложения относительно языков без данной поддержки.

Дмитрий, очень даже "при чем"
Без мозгов, как выразился ThunderCat, параллелизм может как убыстрить, так и замедлить что угодно.
Параллелизм бывает разный и его действительно нужно использовать с умом. На абстрактном уровне это утверждение бессмысленно. Особенно смешно звучат рассуждения о том, что Го заточен на параллелизм, а питон нет.

Скорость бывает разная и нагрузки тоже. Обработка больших объёмов данных - это, по-вашему, что? Переконвертирование, вотремаркинг, пережатие, картинок, поиск и замазывание автомобильных номеров на них - это подпадает под большие объёмы данных, но для решения этих задач не требуется мультитрединга. Нам не критична скорость обработки каждой картинки, важно просто успевать обрабатывать их все в приемлемые сроки. В этом случае питон удобнее за счет кучи полезных библиотек (в том числе для ML), за счет простоты и прозрачности кода, за счет большого количества относительно недорогих специалистов, которых вы можете позвать себе в проект. Тот факт, что питон медленнее в числодробительных алгоритмах тут роли практически не играет, поскольку мы можем очередь задач растянуть по времени и по числу инстансов.

Вот игровой движок для мультиплеерной RTS, наверно, эффективнее было бы писать действительно на го.
В любом случае всякая эта бигдата и низкие задержки решаются в основном не за счет языка, а за счет продуманной архтектуры, где (привет, ThunderCat), грамотно применены очереди, горизонтальное и вертикальное масштабирование, правильные БД, правильные уровни изоляции, своевременная подготовка данных, кэширование, рендер и раздача статики где это возможно.
Язык, по сранению с перечисленными мерами. не сделает вам ольшого выигрыша в производительности, за его счет вы сможете добить лишь каие-то проценты производительности там, где более дешевые, простые и быстрые архитектурные способы уже применены.

[Сергей П]

Евгений Самсонов,

Менять шило на мыло (PHP на Python), думаю, нет резона.

Как это нет?! Слышали поговорку про "шило в жопе"? Вот про мыло в этом ключе обычно не говорят.
Как можно вообще сравнивать взрослый настоящий язык с пхп?=)

[Дмитрий]

Сергей Паньков,

за его счет вы сможете добить лишь каие-то проценты производительности там, где более дешевые, простые и быстрые архитектурные способы уже применены.

Спасибо кэп, но именно это я и имел ввиду.

[Сергей П]

Спасибо кэп, но именно это я и имел ввиду.

Дмитрий, не благодарите.

На самом деле топикстартеру следовало бы ответить, что не важно что он там освоит и в каком порядке после ПХП: питон, го или js. Хороший специалист в любой из этих областей без работы сидеть не будет и на хлеб с маслом заработает. А вот плохой специалист освоив что угодно не сможет этим эффективно пользоваться.
Так что иучать нужно то и в том порядке, что и к чему лежит душа и есть интерес.

[Дмитрий]

Сергей Паньков,

На самом деле топикстартеру следовало бы ответить, что не важно что он там освоит и в каком порядке

Это верно, но топик континьюерам очень важно внимательно ли они читают пост или тут же строчат горы хлама в ответ. Потому что если внимательно прочитать пост, то можно обратить внимание "мы собираемся внедрять", что совершенно не указывает на то, что автор разработчик и интересуется изучением языков, а указывает скорей на то, что он выбирает язык для реализации высоконагруженной системы для конкретной компании. Но если цели такой нет - внимательно читать, и нажимание на клавиши само по себе доставляет топикконтиньюеру удовольствие, то порядок конечно не имеет значения - можно упоенно строчить свою лабуду, не читая топик.

[Евгений Самсонов]

Сергей Паньков, Сорян, у меня неудачный опыт со "взрослым" языком, который так же как php не умеет в бинарь. Переписали один проект с python на go, в 4 раза производительность повысилась. На python теперь только скриптики простые, но это лично мой опыт

[Сергей П]

Дмитрий, да вы не нервничайте, я просто высказал своё мнение. Пусть автор аккуратнее и точнее формулирует свой вопрос, а так он абстрактный, не удивительно что прилетело много абстрактных соображений.

[Сергей П]

Евгений Самсонов, если у вас всего лишь 4-кратное повышение производительности перевесило необходимость полного переписывания проекта на совершенно другом стеке, то это, может быть, вполне оправдано. Ну бывает такой потолок встречается.
Однако при правильной архитектуре иногда проще (и дешевле) навалить лишних мощностей, благо они нынче дешевы и при правильном подходе их лего и быстро разворачивать.
Опять же, четырёхратная экономия на паре VDS - то это одни бюджеты, а четырёхратная экономия на гео распределённом кластере из сотни виртуалок в разных датацентрах - это совсем другие деньги. Обычно, если у вас такие масштабы как во втором случае то вы не задаёте вопросы какой язык выбрать или не принимаете решений о смене стека.
Всё таки переписывание большого проекта сильно дороже нескольких VDS.

[Дмитрий]

Сергей Паньков, Да я не нервничаю, просто вслух рассуждаю по увиденному =)

[MVP_Master]

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

[d'Ivan]

MVP_Master, а в вашей архитектуре используются брокеры сообщений?

[ThunderCat]

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

Где-то может дать профит, а где-то нет, а где-то может дать, но это может быть неоправданно по сложности и надежности...

Еще раз - инструмент точится под конкретную задачу (а не под "ускорить все, и шоб летало и шеф доволен был"). Если вы просто думаете что взяв голанг прям сразу полетите в космос - хрен там. И возвращаясь к Авитам и иже с ними - 99% задержек НЕ В КОДЕ. Притормаживают обычно хранилища и внешние сервисы, мало где логика приложения является прям пипец узким местом. И даже там где это не так, бывает неоправданно переходить на что-то более быстрое.

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

[MVP_Master]

ThunderCat, конечно конечно )) зачем брать BMV если можно купить ладу-калину. Все ведь от квалификации водителя зависит, а не от мощности двигателя... Зачем расставаться с парнем, у которого 15 см и начать встречаться с парнем, у которого 18 см. Ведь дело не в размере, а в умении пользоваться....

Вы сами то верите в то, что пишете?

[Ярослав Иванов]

MVP_Master, Ну так дело в руках инженеров. И те и те делают двигатель практически из одинаковых материалов. Но у других получается а у других нет.

Причем тут готовый продукт BMW и Языки программирования, которые готовым продуктом не являются?

Зачем брать комбайн если есть паяльник? Сравниваете несравнимое.

В-третьих зачем вы спорите с ThunderCat ? Человек опытнее вас в разы. Вы пришли чему-то научится или спорить ради спора?

[MVP_Master]

Ярослав Иванов, дело не в руках инженеров. Инженеры - это обезьянки одинаковой квалификаци.и Дело в технологии. У кого правильная технология, тот и прав.

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

[ThunderCat]

MVP_Master,

Это как на ассемблере написать игру и на бейсике - скорость в первом случае будет в разы быстрее.

Вы не видели код, который пишут "обезьянки одинаковой квалификации". Там такое бывает... Это раз. И заодно это ваше "обезьянки" показывает вашу "причастность и вовлеченность" в сферу, то есть говорит от том что вы в предмете ни в зуб ногой и все свои измышления строите на том что "ассемблер безусловно быстрее бейсика, по этому все надо писать на нем".

Отрицает важность быстродействия языка программирования, когда она неоспорима.

Вау, в 21 веке кто-то еще верит в "неоспоримость" чего-либо??? Даже если вам еще нет 20 лет - это самая большая глупость. Банальный пример - калькулятор на визуал бэйсике и на ассемблере - что быстрее и на чем делать правильнее? Ну, как коммерческий продукт?

вместо того чтобы отвечать на вопрос топикстартера уводить его в другое русло

Да вас никто не неволит хвататься за мои, либо еще чьи-то советы и бежать исправлять проблемы там где они есть, вместо того чтобы решать те, которых нет, ради бога... Возможно я даже своими крамольными высказываниями пытаюсь лишить парочку голангеров теплого местечка, а вы им уже обещали... Я привык советовать инструмент под задачу, а не "есть голанг, он быстрый, пофиг что проблема не в коде". Вы бы привели конкретную задачу - ну, типа "есть расчет графа неопределенной вложенности, надо найти самое короткое расстояние между произвольными узлами, пхп делает это медленно, че делать?". Вооот тогдаааа получите максимально верный и четкий ответ, а так создается впечатление что вы даже не знаете в каких местах затык, тупо пытаетесь средствами программной среды покрыть ВСЕ недостатки приложения.

[Ярослав Иванов]

MVP_Master, Где я на личности перехожу?

Отрицает важность быстродействия языка программирования

Какое быстродействие у гаечного ключа? А у молотка? Может все же дело в руках?

У вас что - это модно на сайте подлизывать вместо того чтобы отвечать на вопрос топикстартера

Я уже ответил. Самый первый комментарий.

[MVP_Master]

ThunderCat, вот именно в этом и был вопрос - для отдельных участков где требуется скорость.
А так я согласен со всеми что если проект крупный, то одними вставками быстрого кода не обойтись.
Придется много чего оптимизировать. Вот ВК и Фейсбук же ощутили на себе большие нагрузки
и по быстрому переписали свой движок.

[ThunderCat]

MVP_Master,

для отдельных участков где требуется скорость.

Примеры в студию, а то все слишком как-то туманно.

Вот ВК и Фейсбук же ощутили на себе большие нагрузки и по быстрому переписали свой движок.

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

Мы всегда поддерживали в первую очередь собственные движки ВКонтакте. KPHP не умеет в Redis, MongoDB и другое. Даже Memcache у нас свой, который по RPC работает... Мы никогда не поддерживали стандартные базы, потому что это не было нужно.

То есть из области - "сам себе хранилище / поиск / кеш", отсюда и тормоза в этих местах, отсюда и необходимость в ускорении всего что шевелится... В нормальных структурах веб приложений ЯП - большей частью прослойка между хранилищем и пользователем, с несложной логикой, вся скорость работы как раз и основана на специально обученных алгоритмах хранения и выборки. Да, есть куски где нужно напрячь электромозги, например ресайз картинок или конвертация видео, но вот это как раз чаще всего можно выделить в отдельные потоки внешним приложениям, причем как раз это суть те же микросервисы с фасадом на пыхе/питоне/етц, существуют мильон лет как. Большинство остальных операций выполняются в разы быстрее чем запросы из базы на 10М строк. Пример обратный ФБ и ВК - букинг.ком. У них до сих пор во многих местах все работает на перле. И норм. Так как в бд все суперзатюнено, местами суперденормализовано и пипец как закешировано. Но вот на перле (на перле, Карл!), и все шустро работает.

[MVP_Master]

ThunderCat, я не буду дальше продолжать этот спор. Вы и ваша свита не добрые люди.

[ThunderCat]

MVP_Master, так о чем спорить то? Где тут спор? Только в вашем воображении. Предмета для спора то нет... Это так, больше советы и немного истории, чем какая-то конкретная рекомендация. Хотя бы задачи бы обозначили, которые решаете...

[MVP_Master]

ThunderCat, понимаете. я знал что масштабирование и прочие навороты это неминуемо для крупного проекта. Но пока на данном этапе когда проект еще только зарождается мы хотели попробовать внедрить golang и проверить как это скажется на производительности. Часто у нас будет использоваться парсинг текстов. Ну и обработка картинок.

[ThunderCat]

MVP_Master, это вообще легко выводится за фасад, особенно картинки, но и текст тоже легким движением руки кидается за фасад, то есть работаете с любым веб-ЯП, задачи такого плана выполняете тупо через exec()/system() и ждать ответа не надо, он будет взят например из результирующего файлика/таблицы/памяти позже. С ffmpeg/imagemagick так чаще всего и работают. С текстами - зависит от задач, но чаще всего тоже есть отдельные уже готовые библиотеки/приложения, в частности алгоритмы поиска с нечеткими соответствиями и прочими наворотами. Или можно написать что-то прям под свои нужды, и вот тут выбор не всегда в пользу голанга, например всякие нейронные фишки уже есть на притоне в большом количестве готовые, и переписывать их под го - не всегда есть смысл, проще добавить мощностей. Но тут опять же - надо смотреть по задаче.

[MVP_Master]

ThunderCat, вот я слышал что для парсинга хорошо заточен python

[ThunderCat]

MVP_Master, для парсинга и си заточен, и ява, но под питон написано много готовых качественных модулей, так сложилось исторически... Кто-то из яйцеголовых облюбовал питон как простой язык с большим функционалом, ну и в сайнс среде понеслась мода на питон, ну и большим плюсом ему было отсутствие компиляции, что сильно плюсануло ему в карму от непрофессиональных прогеров с научным уклоном.

[MVP_Master]

ThunderCat, а если так вопрос поставить: Владение каким дополнительным языком программирования даст позвожность быть более интересным для нового работодателя (Go, Python, Java) ? Просто те навыки, про которые вы везде говорите их очень тяжело получить не работая в какой-нибудь продуктовой серьезной конторе где есть реальные high load проекты. А освоить язык программирования как дополнительный можно и самостоятельно дома. И вот хотелось бы чтоб в резюме помимо php, mysql, css, html, js стояло еще что-нибудь типа GoLang или Python.

Есть в этом смысл?

[d'Ivan]

MVP_Master, так вам для резюме нужно... Так бы сразу и написали.
Я думаю, что для резюме будет логичнее, если вы добавите слово RabbitMQ. Потому что если вы не сможете обосновать свой выбор в пользу некоторого ЯП, то у работодателя будут вопросы по вашей квалификации.
Вот, взять проекты Facebook, Wikipedia. Работают на немодном языке PHP. Но, "наверное", у них все таки помимо PHP есть и другие технологии. Подозреваю, что без очередей их просто никак не смогли бы построить в таком масштабе.

[MVP_Master]

Роман Мирр, ну дак RabbitMQ, Redis, Memcached, docker, nginx, .... - это уже другая строчка )

[MVP_Master]

Роман Мирр, одно другому не мешает. чтоб в резюме указывать надо же на практике еще пощупать язык или технологию.

[ThunderCat]

MVP_Master, хз, даже не знаю, точно могу сказать что узкий профиль (в любом языке) более ценен нежели "комбайн", который всего понемногу умеет, в юности тоже был уверен что должен знать 4-5 языков, линух, фряху и винду на уровне хорошего админа, и еще на балалайке и швейной машинке... Жизнь показала что всем нужен спец в узкой области, но с реально хорошим скилом. Так что пофиг какой язык, главное в нем хорошо разбираться. А еще парочку - ну разве что для души...

[MVP_Master]

ThunderCat, ну вот я тоже к этому пришел. и полностью переключился на бэкэнд. фронтэнд отдал партнеру.
но как ответственному за развитие проекта ищу способ дальше развиваться.

[d'Ivan]

MVP_Master, определитесь какая у вас проблема и какова ее причина (в цифрах, по возможности). А потом взвесьте варианты для ее решения.

[MVP_Master]

Роман Мирр, а проблем пока нет. я за год вперед пытаюсь планировать куда развиваться.

Answer 1

[Сергей П]

Питон проще осваивать, к нему больше примеров, библиотек, обучающих курсов, книг и открытого кода в инете. А ещё полно удобного инструментария. Для любых ваших проектов питон подойдёт не хуже го.
Когда вы готовы разрабатывать на Го, у вас уже не возникает вопроса питон или го. А если возникает, значит питон.
ИМХО.

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

Comments

[MVP_Master]

ну у нас основная задача - это покрыть более скоростными языками слабые места.

[Сергей П]

MVP_Master, звучит как ошибка. Как попытка закидать шапками обрушенный мост. Обычно проблема не в скорсти языка. а в неправильной архитектуре. Я уж еговорил про кэширование, использоание статики где это возможно. про уровни изоляции, про горизонтальное масштабирование. Если переход на другой язык у вас мотивирован лишь скоростью абстрактных вычислений на нем, то вам не поможет ни один из этих языков, проблема глубже.

[MVP_Master]

Сергей Паньков, здесь же архитектура микросервисов. только отдельные микросервисы планируется переписывать. Например, многопоточное обновление прайсов и обработка изображений.

Ну а про кэширование это конечно учтется. Просто нельзя говорить "косите сено косой, только хорошо заточите ее и наймите опытного косильщика. Газонокосилка вам не поможет". Поможет же по факту.

[Сергей П]

MVP_Master,

многопоточное обновление прайсов и обработка изображений.

Я, конечно, не телепат, но звучит так, будто вы не очень понимаете суть микросервисов или пытаетесь макросервисы делать.
Обработка изображений требует SharedMemory? Задержка обработки каждого изображения настолько критична, что вы готовы усложнять код парралельной обработкой отдельных участков одного изображения в разных потоках? Я понимаю, если вы реализуете своеобрахный "фотошоп" с тонким клентом, где гигапиксельные панорамы польоватль обрабатывает фильтрами и хочет как можно ыстрее видеть результат в реальном времени. Тут действительно нужен параллелизм и многопоточность. Для обычно йобработки катинок, врое вотермаркинга и ресайзинга вам нужен брокер очереди задач и масштабируемое количество простых однопоточых воркеров в отдельных процессах. Воркеров может запускать кубернет в количествах. которые требуются на текущий момент и не более. Ночью, скажем, вы вовсе освободите ресурсы и сэкономите, а при наплыве загрузок сможете мгновенно и многократно увеличить производительность своего кластера.

обновление прайсов

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

Просто нельзя говорить "косите сено косой, только хорошо заточите ее и наймите опытного косильщика. Газонокосилка вам не поможет". Поможет же по факту.

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

Я понимаю. что вы, наверно, не газонокосилку имели в виду, а триммер какой-нибудь, но тут ваш же пример попал в цель гораздо точнее, чем вы сами задумали, но диаметрально обратным способом.

Если вы сделаете на Го микросервис, который в много потоков будет грузить и изолированно ретушировать много фоток за раз, то это будет ошибкой. Такой "микросервис" будет излишне сложен для своей функциональности. он будет трудномасштабируем и его сложнее будет поддерживать, диагностировать, мониторить...

[MVP_Master]

а на питоне шабашки легко находить?

[Сергей П]

MVP_Master, ну то, что я наблюдаю вокруг - это работы всегда и гораздо больше, чем времени. Можно даже выбирать.

Answer 2

[xmoonlight]

Ускорение - это нужные алгоритмы и архитектура проекта. Язык - вообще ни при чём.
Хотите быстро - используйте параллельную обработку запросов к бд (+кеширование запросов-ответов) с последующим объединением результатов, согласно запрошенному фильтру. Всё это - в оперативке (Redis, etc.).
И не закрывайте http2-соединение, если пользователь работает (есть активность) с формой/фильтром поиска.

Comments

[MVP_Master]

одно + другое. в данном случае вопрос был не в оптимизации а в использовании других языков и выбора между ними.

[MVP_Master]

это если вы застали программирование под дос, то раньше программировали на Си и Паскаль, но вставляли ассемблерные куски кода для ускорения в отдельных местах. Особенно при взаимодействии с железом.

[xmoonlight]

MVP_Master,

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

Лично вставлял, программируя на паскале.
Тогда - микросервисы на асме - это ваш выбор!

PS: даже видел сборку веб-сервера на асме (на гитхабе).

[MVP_Master]

вы посмотрите что другие люди отвечают - здравые люди. а вы как белая ворона. Большинство же правильно истолковали вопрос и выбрали Go

[xmoonlight]

MVP_Master, если проблема в планировании развития (как вы упомянули) и вы считаете, что у того же php нет возможности к использованию параллельной обработки данных, асинхронности, мультипоточности или отсутствует возможносиь создания низкоуровневых модулей - советую ещё раз хорошо ознакомиться с возможностями php, python, Go и сравнить самостоятельно.

PS: А кто тут здравый - это минимум тот, у кого больше опыта.

Answer 3

[Сергей]

ИМХО, кроме PHP, разраб должен знать хотя бы азы JS и SQL.
Конечно, сейчас не 2000-е годы, но, во многих случаях, фронт - это JS/JQUERY, а бэк - это PHP/SQL.

Comments

[MVP_Master]

ну так и есть. наверняка любой пхп прогер знает еще js и sql и html )

Answer 4

[Борис Меньшаков]

Я лично остановился на Go, так как он очень прост в освоении. Для ускорения каких-то частей php-приложения мне он показался оптимальным (обработка транзакций, отдача контента и прочие почти автономные задачи). Ну и писать код (имхо) приятнее (кроме вечных проверок ошибок). В общем, попробуйте сами написать небольшие сервисы и на том и на том. Это будет самый верный способ.

Answer 5

[hatman]

Авито написан на PHP, golang используется на микросервисах для постройки пайплайнов, которые выплевывают данные после обработки.

1) Если вам "круто попробовать и потыкаться, при этом заказчик не понимает, что вы делаете" - то, все, что угодно.
2) Если вам "круто попробовать и потыкаться, при этом заказчик понимает, что вы делаете" - то готовьте вещи и на мороз, когда заказчик увидит ваш выбор, ибо это ненужное усложнение системы и увеличение стоимости поддержки системы.
3) Если у вас проблемы с производительностью, то сначала попробуйте решить проблему докупкой железа, потом сделайте оптимизацию на php, а только потом задумайтесь о переписывании на Go.

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

Comments

[MVP_Master]

мы для своих проектов это делаем. и для нас это способ освоить новые направления. На тестовых проектах.

Answer 6

[Игорь Воротнёв]

Если нужно дополнение к php + скорость работы + микросервисы то однозначно Go, ибо компилирование, многопоточность и concurrency, сборка мусора и все такое. И не забывайте про FFI.