Сча начнется, но призываю к адекватности и разумности!)
Итак... Я могу написать почти всё на php, python, ruby, nodejs или kotlin (последнее почти не знаю, но изучаю).
И чем дальше - тем больше понимаю, что современный php довольно адекватен и покрывает 99,9% моих потребностей.
Важная ремарка: я РЕДКО пишу что-то связанное с ML, асинхронностью или "платформонезависимостью", хотя всё это так или иначе реализовывал на php за последние 10 лет. Например, вебсокет-сервер, фон для рабочего стола под mac с мониторигом серверов, определение тональности или тематики текстов юзеров и пр.
На сегодня я могу выделить буквально 3-4 категории задач, под которые php не зайдет (низкоуровненые таски, ресурсозависимые таски, таски заточенные под конкретные библиотеки, такие как tensorflow, таски заточенные под время ответ, хотя тут swoole или amphp вполне выручают - есть опыт).
А теперь вопрос: есть-ли у других языков (НЕ КОМПИЛИРУЕМЫХ, а интерпретируемых) какие-то огромные ограничения, которые нельзя реализовать, используя php?
P.S.: да, я знаю что php это "фууу" и "как так можно"?!
за «php»
за «other»
На любом ЯП можно писать то, что можно написать на другом ЯП. А если такого ЯП нет, то этот ЯП можно написать на каком-нибудь ЯП, чтобы исполнять те функции ЯП, которых в ЯП не было. А ведь еще биндинги всякие бывают! Классно это короче.
Как @egorzot сказал - предвзятое отношение к ЯП не должно становиться препятствием для его использования. Как и отношение других людей к нему.
Популярность PHP была обсусловлена во многом тем, что это был первый массовый серверный ЯП с "поддежой веба", потому он устанавливался на любом виртуальном хостинге по умолчанию как единственный ЯП. Но мир изменился:
То есть больше нет технических ограничений, вынуждавших использовать PHP. Нравится PHP - используй, всё с ним впорядке.
Но ещё есть "синдром утёнка": большинство программистов в хорошем смысле ленивые. Если они вложились 10 годами жизни в изучение однйо технологии, какой смысл отказываться от неё, если она до сих пор работает? Этот подход годный, но вызывает некоторое закостенение мозга.
Условно, остаёшься жить в старой парадигме, как нынешний разработчики на Коболе. А я не хочу быть разработчиком на Коболе.
Если не нужна многопоточность или скомпилированный бинарник как в Go, то почему нет? Предвзятое отношение к этому языку не должно становиться препятствием для благоразумонсти.
Работал с разными командами, мне лично гораздо приятнее работать с шарпистами, или товарищами из мира джавы. В php в свое время был нижайший порог входа и задачи из серии "сделай сайт и админку", поэтому инженерный уровень среднего php разработчика так себе, а хорошие стоят дорого :)
Я имел опыт работы в проекте с ужасным кодом на PHP, с ужасным кодом на Golang, а потом попал в команду с крайне сильным проектом на PHP + Go и проблема, похоже, была не в инструменте :)
Так что использовать можно что угодно, вопрос именно в квалификации разработчика + специфика самой задачи (многопоточность в PHP не очень (на сколько я помню, ее нет))
Я накушался Пыха в свое время - средний уровень программистов слабый, куча советов в интернете по языку которые откровенно устарели, отсутствие вразумительных способов дебажить код (без print), очень печальные практики тестирования в сообществе, не так уж много библиотек хорошего качества.
Я в принцепи в курсе, что язык и экосистема не стоит на месте и есть куча всего интересного уже. Но желания возвращаться в Пых нету никакого, лучше уж обратно в Яву\JVM.
Но если честно -- современные языки мне нравятся куда больше, и чем больше функциональщины - тем лучше.
А то щас развелось дохрена диванных евангелистов, которые чуть что, любят влезть в уютную тебе экосистему со своими архиважными оценочными суждениями. Судя по дескрипшену, ты признаешь достоинства, недостатки и ограничения PHP-экосистемы, и не замкнут на ней одной - этого уже достаточно чтоб не зависеть от чужих мнений и предпочтений.
ЯП - это инструмент, а инструмент нужно выбирать под задачу.
Но возможно, неправильно сравнивать инструменты только в техническом плане. У проектов есть еще и экономическая, и кадровая составляющая.
Поэтому можно смотреть шире. Например, ты ничего не имеешь против python/go/ruby/java, и на любом языке можно сделать ту задачу, которую ты хочешь сделать в достаточном качестве за удовлетворяющее время. Это скучные рассуждения, можно обложиться метриками LOC, бенчмарками, количествами issue на гитхабе, любой другой статистикой.
Но судя потому, что статистикой можно обложиться, а споры продолжаются, дело не в статистике.
Потому что после оценки производительности и количества строк кода начинается интересное.
Под какой стек (а ЯП неизменно потянет за собой стек) ты быстрее найдешь программистов на том рынке, на котором ты ищешь, удовлетворяющих тем финансовым/квалификационным параметрам, которые ты себе выставил? Искать-то с большой долей вероятности придется - люди увольняются, переходят между проектами, и так далее.
Может быть, ты хочешь, чтобы люди, которые будут делать проект, имели какие-то специфические навыки - например, были знакомы с азами ML. Питонистов ты таких найдешь, рубистов и пхпистов - уже намного сложнее.
Может быть, тебе надо, чтобы эти люди умели писать краулеры и сложные парсеры текста? Тогда, наверное, ты можешь захотеть рубистов, потому что руби впитал в себя много от перла, а перл умеет с текстом работать отлично.
А может, у тебя фетиш - алгоритмы и структуры данных, и ты хочешь, чтобы люди, которых ты будешь нанимать на проект, умели вращать деревья на доске, пусть даже писать им придется тупую перекладывалку json-ов с 1 запросом в час, где нет нагрузки ни по данным, ни по времени, ни по чему. Где ты таких людей проще найдешь, среди питонистов, рубистов или пхпистов? Надо смотреть рынок.
Ну и так далее, любые сторонние условия придумываются легко. Ты можешь делать проект, которому без разницы, какой язык, это какая-то тупая апишка без нагрузки, но ты пишешь ее в конторе, где почти все - на го. И будет логично, имея весь тулинг и всю инфраструктуру, заточенную на го, писать проект на го и искать гошников - если проект обломится, то гошников есть куда девать, а что ты будешь делать с рубистами или пхпистами в такой конторе, захотят ли они учить го, и смогут ли они дотянуться по владению го до остальных в конторе, чтобы их можно было перевести на другой проект? Это уже хороший вопрос и в разных ситуациях ответ будет разным.
Я был на проекте, который надо было переписать, он был на пхп, и решили, что раз уж переписывать все равно полностью, то можно заодно и стек сменить - просто потому, что новый техдир не любил пхп, любил руби и был терпим к питону. Но писали мы на питоне в итоге, потому что рубистов в регионе в то время было уже очень сложно найти, а те, которые были, были развращены удаленкой за доллары и не хотели идти в офис за рубли, притом, довольно небольшие. А питонистов было больше, было ясно, что питон будет и дальше становиться популярней, а пхп тогда был на спаде, поэтому исключительно из соображений кадрового рынка было принято решение писать на питоне. Хотя в конторе вокруг пхп.
Проект не выстрелил, его закрыли, нам всем предложили остаться в конторе и перейти на другие проекты. Почти все, кроме фронтендеров, ушли. Потому что все были питонистами и на пхп писать никто не хотел - а многие и не умели. Кто-то по эстетическим соображениям, а кто-то по рыночным - может быть, человек хочет идти в ту область, где питон куда более востребован, чем пхп, и тогда ему этот пхп никуда не уперся, пусть даже и симпатичен. Такое тоже бывает.
В общем, смотреть нужно не только на язык, а намного шире и часто - на не-технические параметры. И оптимальный ответ в случае каждой ситуации может быть совершенно разным и непохожим на остальные проекты, пусть даже внешне похожие.
Чуть зацепил пхп 7, в целом было удобно, но гуглить и искать бест практис было сложновато. Сейчас пишу на python/c++ и чуствую себя очень комфортно.
Знаю, что в мире крипто бирж много пишется на пхп, как к этому относится решайте сами =)