Недавно PHP-проекты Avito перешли на версию PHP 7.1. По этому случаю мы решили вспомнить, как происходил переход на PHP 7.0 у нас и наших коллег из OLX. Дела давно минувших дней, но остались красивые графики, которые хочется показать миру.
Первая часть рассказа основана на статье PHP’s not dead! PHP7 in practice, которую написал наш коллега из OLX Lukasz Szymanski (Лукаш Шиманьски): переход OLX на PHP 7. Во второй части — опыт перехода Avito на PHP 7.0 и PHP 7.1: процесс, трудности, результаты с графиками.
Часть 1. PHP 7 в OLX
Компания OLX Europe управляет десятью сайтами, самый большой из которых — OLX.pl. Все наши сайты должны работать максимально эффективно, поэтому миграция на PHP 7 стала для нас основным приоритетом.
В этом посте расскажем, с какими проблемами пришлось столкнуться и чего удалось получить с переходом на PHP 7. Про переход было рассказано на конференции PHPers Summit 2016.
Переход
Вопреки нашим опасениям, миграция прошла гладко. За исключением стандартного списка необходимых изменений из официальной документации, пришлось внести лишь некоторые правки, связанные с нашей архитектурой.
Стоит упомянуть, что десять наших сайтов работают в разных странах. И изменения мы выкатываем последовательно: на один сайт за другим. Такой подход особенно важно применять при серьёзных изменениях.
Мы начали обновление версии с самого маленького сайта и переходили ко всё более крупным, поглядывая, чтобы тесты проходили успешно. Это позволило следить за возникновением неожиданных проблем и снизило потенциальный ущерб.
Memcache
Отказ от поддержки Memcache в PHP 7 подтолкнул нас к переходу на Memcached. Пришлось поддержать две версии сайта: PHP 5 + Memcache и PHP 7 + Memcached.
Для решения задачи использовали простенькую обёртку. Она выбирает подходящий PHP-модуль для соединения с кэшом, исходя из информации о сервере, на котором выполняется код.
<?php
$factory = new CacheWrapperFactory();
$factory->createServer(
extension_loaded('memcache') ? 'memcache' : 'memcached',
$uri
);
Однако, приключения с Memcached на этом не закончились. Выяснилось, что объекты, сериализованные с помощью Memcache, не могут быть десериализованы с помощью Memcached.
Но кэш — он на то и кэш, что его можно легко удалить. Поэтому мы просто удалили старые проблемные объекты из кэша, и они были пересозданы с помощью нового модуля.
APC, APCu и OPCache
Немного о терминах.
APC (Alternative PHP Cache) — это кэш байт-кода и пользовательских данных.
APCu (APC User Cache) — только кэш пользовательских данных.
OPCache — только кэш байт-кода.
В PHP 7 нет APC, нам пришлось взять и APCu, и OPCache. Ранее мы использовали API APC во многих критичных частях нашего фреймворка, управляющего кэшем, поэтому мы прикрутили к APCu модуль apcu-bc, совместимый с API APC.
Результаты
Ниже представлены результаты самого большого из наших сайтов, OLX.pl.
CPU на Apache
Наши веб-серверы (Apache) крутятся на 20 физических машинах с 32 ядрами процессора каждая. Пиковое потребление процессора в результате миграции снизилось с 50% до 20%.
LA на Apache
Подобным образом снизился и Load Average на веб-серверах.
Числа говорят сами за себя: снижение нагрузки, экономия ресурсов, повышение эффективности. Если ваши проект-менеджеры или клиенты не дают достаточно времени на миграцию — эти графики наверняка смогут их убедить.
Причины эффективности PHP 7
Таких поразительных результатов удалось добиться благодаря оптимизации в трёх основных областях.
Меньше операций выделения памяти
PHP 5 расходовал 20% потребляемого им процессорного времени только на операции выделения памяти. Разработчики языка обратили на это внимание, уменьшили количество операций выделения памяти, чем значительно снизили потребление процессора.
Меньше потребление памяти
Этот набросок показывает путь, который процессору нужно пройти для доступа к оперативной памяти (RAM), с указанием времени на каждый шаг. Как видно, отрезок до оперативной памяти — самый длинный. Разработчики PHP снизили потребление памяти, ускорив отклик приложений.
Меньше промежуточных указателей
Последняя причина улучшения эффективности PHP 7 — уменьшение числа промежуточных указателей. Для этого разработчики PHP избавились от множества указателей, ссылающихся на другие указатели; вместо этого они заставили указатели ссылаться непосредственно на запрашиваемые сущности.
Код
Помимо улучшения эффективности, PHP 7 припас небольшую революцию структуры кода.
Скаляры в объявлении функции
До PHP 7 типами аргументов функции могли выступать только объект, интерфейс, массив или функция обратного вызова (callable). Возьмём для примера следующий код.
Очевидно, что использование таких методов сулит множество проблем, если вы не уверены в корректности входящих аргументов.
Помимо добавления проверок типов в каждый метод, можно использовать конструкт ValueObject из предметно-ориентированного программирования (DDD).
PHP 7 позволяет просто указать скаляры, такие как string, int, float, bool. Кроме того, можно указать тип возвращаемого значения.
Strict-режим
Но простое добавление вышеуказанных конструкций в код может не дать ожидаемых результатов. Всё потому, что PHP 7 по умолчанию работает в coercive-режиме, в котором происходят обычные преобразования типов. Если вы принудительно не включили strict-режим, можно переписать вышеуказанный метод следующим образом.
К сожалению, даже добавление конструкции declare(strict_types=1) в файл PHPisNotDead.php не включает strict-режим. Объяснение в примере ниже. В комментариях указаны возвращаемые значения.
Почему так происходит? Строгая типизация в методах класса PHPisNotDead включилась только для возвращаемых значений.
Если вам нужно включить строгую типизацию также и для аргументов, придётся добавить декларацию strict_types и во все файлы, в которых вызываются методы класса.
Больше информации об указании типов и его влиянии на выполнение программы можно прочитать в документации. Чтение этой документации убережёт от сюрпризов при выполнении вашего кода.
Будущее
Если даже сейчас вы всё ещё не решились перейти на PHP 7, загляните в список поддерживаемых версий PHP. Версия 5.6 уже не получает активной поддержки, а в конце 2018 года перестанут выходить даже исправления критических уязвимостей. Активная поддержка продолжается для версий 7.0 и выше.
Следите за новостями мира PHP и планами относительно новых верий. Наиболее интересные посты: дружественные классы, generic-типы и функции. Найти другие предложения о развитии языка можно в PHP RFC.
Итоги
PHP 7 впечатляет: помимо повышения эффективности, он помогает разработчикам писать более качественный код. Я набросал небольшое пособие, которое поможет вам принять решение о переходе.
— Когда стоит перейти на PHP 7?
— Прямо сейчас.
Часть 2. PHP 7 в Avito
Процесс перехода на PHP 7.0
Мы так же, как и OLX, осуществляли перевод наших сервисов на PHP 7 постепенно. Сначала перевели небольшие отдельностоящие сервисы, протестировали их, исправили возникшие ошибки. Далее перешли к последовательному обновлению серверов админки сайта, после чего раскатывали на PHP 7 оставшиеся сервисы и сайт.
Трудности перехода
Мы прочитали список обратно несовместимых изменений. Однако это не уберегло ото всех бед.
В старом коде нашёлся класс с названием String. PHP 7 выдал ошибку “Cannot use 'String' as class name as it is reserved”. Класс переименовали. Обратите внимание на список зарезервированных слов.
В PHP 7 изменился формат кеш-файла для WSDL-схемы в SoapClient. Можно настроить сохранение кэша в разные директории в зависимости от версии PHP или полностью очищать кэш перед сменой версии интерпретатора.
Расширение mongo, которое мы активно использовали, перестало поддерживаться в новом PHP. Вместо него мы стали использовать официальную библиотеку MongoDB PHP Library. Прошлись по всему коду и заменили MongoCollection::insert() на MongoDB\Collection::insertOne(), MongoCollection::remove() на MongoDB\Collection::deleteMany() и далее по списку. Стали использовать классы для работы с BSON из нового драйвера MongoDB, например, MongoDate вместо MongoDB\BSON\UTCDateTime.
Результат
Админке полегчало.
Бэкенд сайта тоже доволен.
Обновление до PHP 7.1
В PHP 7.1 появилось несколько очень приятных нововведений: тип void для возвращаемых значений, iterable, возможность вернуть null для типизированных возвращаемых значений, область видимости констант и прочее. К тому же, период активной поддержки PHP 7.0 заканчивается уже в конце этого года. Решили обновиться до PHP 7.1.
Неожиданности
При обновлении на ровном месте образовалась проблема. Пакет php-memcached для 7.1 потянул за собой пакет php-igbinary. Когда поставили PHP 7.1 на один из боевых серверов, с остальных серверов начали сыпаться ошибки, в которых фигурировало слово “igbinary”.
Старый друг Memcache, снова различия сериализации, но немного под другим соусом. Выяснилось, что модуль php-memcached по умолчанию использует первый доступный сериализатор из списка: igbinary (в отдельном модуле), msgpack (в отдельном модуле), php (не требует отдельного модуля, доступен всегда). И тот сервер, на котором мы поставили 7.1 с igbinary, начал записывать данные в мемкеш, сериализованные igbinary. А на остальных серверах не было поддержки этого сериализатора, и они не могли прочитать данные, записанные сервером с обновлённым PHP. Локализовали проблему, установили igbinary на всех остальных серверах, ошибки прекратились.
Послесловие
Разработчики PHP взяли хороший курс. Они добавляют полезные инструменты, избавляются от недостатков, связанных с наследием языка, всерьёз задумываются о производительности.
Ранее мы уже рассказывали о переходе Avito на сервисную архитектуру (раз, два). Такая архитектура позволяет писать на любых языках, и новые сервисы мы чаще всего пишем на Go или Python’е. Однако об отказе от PHP речи не идёт: основная логика сайта (монолит) всё ещё на PHP, а команда отлично знает, как с ним работать. Новые версии интерпретатора позволяют сделать код лучше, а его выполнение быстрее.
Делитесь вашим опытом перехода на PHP 7 и выше, будем рады обсудить открытия и грабли, которые встретились вам на этом пути.
Комментарии (77)
Legion21
18.09.2017 14:12-22PHP умер для меня с появлением Go ;-) А кто говорит, что на Go нельзя так же быстро создавать web приложения, как на Symfony (или аналогичных фреймворках) просто не умеет грамотно кодить ;-P
neuotq
18.09.2017 15:20+2Ну таки сегодня лучше всего из всего перечня бэкэнд задач Go себя показывает в микросервисах, а вот всякие Симфони подобные штуки на нем выглядят громозко, ну как минимум сегодня. Как я понял жизнь скорректировала изначальные планы развития языка и возможно он станет примерно как php/python, но только Go.
Время покажет, но в данный момент мне кажется нецелесообразно тратить ресурсы на разработку мощных штук со сложной бизнес логикой, крудами-шмудами и тд, лучше использовать там где он однозначно силен — к примеру микросервисы, он в этой области показывает и отличную производительность, высокую надежность, прозрачность работы в общем в целом все обычно очень предсказуемо и просто, даже в сравнении с python.
Хотя если откровенно говорить то лично с моей тчк зрения «серебрянной пулей» Go назвать нельзя.
wdforge
20.09.2017 11:05Позволю не согласиться с Вами, всё зависит от программистов и от их навыков.
Подходя к задаче массовых микросервисов, написал с коллегами специальный фреймворк, для построения микросервисов, вот пример построения на нём микросервиса, согласитесь не выглядит громоздким.
maxru
20.09.2017 12:32В микросервисах основная проблема как раз не в том, чтобы написать микросервис )
wdforge
20.09.2017 15:40Вы наверно намекаете на меж-микросервисное взаимодействие,. так оно тоже реализовано на стороне фреймворка.
Используется обработчик событий, паттерн обсервер.
Если я обращаюсь к какому-нибудь репозиторию, который описан в другом микросервисе, то подключение ресурсов этого микросервиса произойдет автоматически, есть так же ручное подключение ресурсов, в общем проблемы нет.
oxidmod
20.09.2017 16:07И тут внезапно появляется задача внедрить отдельный сервис с очень высокими требованиями к перфомансу. И сервис будет пилится на го, к примеру. И как вы будете его интегрировать со своим фреймворком?
зы. Идея фреймворка для микросервисов абсурдна сама по себе. Основное преимущество микросервисов в том, что под каждую задачу можно выбрать наиболее подходящий инструмент и стек технологий.wdforge
20.09.2017 16:30Ну, речь то про PHP шла, конечно, если если вы написали отдельный сервис на Go при его использовании на стороне микросервиса необходим некий дополнительный инструмент, что-то вроде API адаптера, пока таких задач не возникала, но была обратная задача. Скажем так некая среда сайта не PHP, использовала мои микросервисы через API которое работает по умолчанию.
По поводу «абсурдности», думаю вы просто ещё не знакомы с приведенной архитектурой. У микросервиса в фреймворке, стеки технологий у каждого остаются свои, но есть некие требования, это использование фреймворка и загрузка ядра, а дальше может быть всё что угодно, любые библиотеки, компоненты подключение в микросервисе. Просто чаще всего нет никакой необходимости писать обработчик запросов для каждого микросервиса свой, работа с данными она тоже везде практически одинакова. Фреймворк хоть и компактен, но в нем есть собственная ORM, DI, логирование, обработка запросов и ошибок.
Возможно к зиме выкачу вторую версию, опишу на хабре, любопытно узнать, что вообще люди думают о таком подходе.oxidmod
20.09.2017 16:40wdforge поделитесь ссылкой на то что есть, а то с приведенного ошметка кода мало что понятно.
wdforge
20.09.2017 17:00К сожалению разработка фреймворка была в рамках коммерческого проекта, согласно договору не могу делиться кодом.
Собственно, по этой причине работаю над второй версией, она будет открытой, и гораздо более доработанной.
Основная идея в том, что если мы работаем с сервисом через HTTP то получаем JSON, если же микросервисы используются в неком существующем сайте на PHP, то отправляя запрос с экшена, мы уже получаем то, что возвращается по существу, а не JSON. При этом м-сервис остается независимым, у него даже может быть собственный хост.
Подобный подход видел в SocialEngine, но там не было микросервисной архитектуры.
«Огрызок» накидал за 5 минут, в нем действительно есть 1 экшен который возвращает объект по id, это как ни странно и есть объявление микросервиса, только без настроек.oxidmod
20.09.2017 18:21wdforge Ну тогда линкой на новую версию. Может кто еще поконтрибьютит))
wdforge
20.09.2017 18:54Да, так и сделаю, у меня есть цель вообще привлечь кого-то ещё к этому проекту, так как, сил одного разработчика для такого проекта маловато.
Помогает что до этого было 1.5 года разработки и сейчас идет просто обратный реинжиниринг.
Если архитектура будет открытой, то в идеале можно будет разработать какие-то общие микросервисы, сделать некий банк микросервисов…
Разработка пока на собственном гитлабе, в общих чертах что-то работает, на выходных наверно переложу на github, скину сюда ссылку.
calg0n
21.09.2017 15:11Go не для web создавался и в качестве бекенда держать его можно чисто как микросервис.
Это конечно круто пихать один инструмент во все стеки, но в реальности такой подход попахивает идиотизмом.
maxru
18.09.2017 14:59+1Про мемкеш по мне так достаточно очевидное капитанство. Кроме вышеупомянутого, написание враппера побудило так же плавно переехать с memcached на redis.
По адаптации кода — на 90% помогла утилита sstalle/php7cc, на остальных 10% ожидаемо упали unit-тесты (изменения в работе бизнес-логики были самые опасные и неочевидные, в отличие от явных несовместимых с php 7 фрагментов кода, выявленных stalle).
NickyX3
19.09.2017 15:32На самом деле я удивился, что кто-то в таких объемах использует memcache(d), когда есть Redis.
maxru
20.09.2017 12:31- Legacy и очень старый.
- Зачем менять, пока работает.
NickyX3
20.09.2017 13:071. Тут надо было сработать на опережение, а лучше даже, в случае мемкеша, сериалайзить в php. У Redis, опять же, сериалайзер можно выбрать, я в свое время во многом из-за этого и перешел на него.
2. Лучше поменять раньше, чем позже. Именно из-за такого подхода я в данное время разгребаю и переписываю совсем уж олдовое legacy наследство, времен этак php4, которое никто не трогал очень долгое время, которое как-то работало даже на 5.3, но уже на 5.6 просто начало трещать по швам.maxru
20.09.2017 13:41сериалайзить в php
Что? Зачем?
Лучше поменять раньше, чем позже
Лучше решать проблемы по мере их поступления.
Вы рассматриваете проблему, как разработчик, а я как менеджер.
Rinz
18.09.2017 19:21При обновлении на ровном месте образовалась проблема. Пакет php-memcached для 7.1 потянул за собой пакет php-igbinary. Когда поставили PHP 7.1 на один из боевых серверов, с остальных серверов начали сыпаться ошибки, в которых фигурировало слово “igbinary”.
Раз раз и в продакшен делаете?)) Dev серверы не нужны для тестирования, берешь и пишешь «pacman -Syu or etc» и все, гениально, аплодирую стоя xD
pik4ez Автор
18.09.2017 19:34+1Для каких-то вещей у нас ещё нет стейджинга, полностью повторяющего боевую инфраструктуру (для большинства сервисов, к слову, есть). Эту неприятность поймали как раз из-за расхождения боевых и дев-серверов.
Melis777
18.09.2017 19:27+1пыхыпы не умрет, кто думает что он умрет, то вам я скажу, что это вы умрете быстрее чем пыхыпы =)
Ivan_83
18.09.2017 19:27Иногда немного юзаю пхп когда требуется что то отдать через хттп чего я не могу сделать силами самого nginx и чего лениво/нет смысла корябать на сях.
При переходе с 5х до 7.1 вылезло два косяка с SoapServer.
1. Чего то там сломалось в XML, лечится так:
/**
* Apply workaround for the libxml PHP bugs:
* link bugs.php.net/bug.php?id=62577
* link bugs.php.net/bug.php?id=64938
*/
if (function_exists('libxml_disable_entity_loader')) {
libxml_disable_entity_loader(false);
}
2. Раньше у меня SoapServer ходит за wsdl по хттп на этот же сервер, но после апгрейда оно почему то странно сломалось: клиент приходил забирал после рестарта пыха при первом обращении, потом минут через 10-20 пых начинал жаловаться что файл не найден, сам даже не пытался спрашивать. А может оно было из за предыдущего бага, просто я это сначала поправил, и так оставил ибо более правильно.
Вылечилось хождением без хттп:
$server = new SoapServer(dirname(__FILE__)."/../descr/ContentDirectory.wdsl",
мне так больше нравится, просто я не знал/не подумал что так можно когда говнокодил.
Что касается перспектив — не вижу причин отказываться от пхп, даже не смотря на все недостатки, большая часть которых сосредоточена в сами пхп пограмистах.
Синтаксис пхп си подобный и мне это удобно, в отличии от питона.
Всякое го и раст — там же голяк, смысла нет даже смотреть. (перспективы тоже сомнительны, но мне плевать, ибо речь про вспомогательный язык для говнокодинга)
sand14
19.09.2017 11:54-2Удивительно. Половина новостей связана с тем, что в язык/платформу добавляются базовые возможности, которые в языках общего назначения (C++, C#, Java, множество других) есть с рождения и "из коробки".
Взять хотя бы void для возвращаемых значений (хотя идея void уже устарела — в наиболее современных языках используется понятие Unit для void) или добавление статической типизации для аргументов (хотя и тут — оказывается, написанный код не работает, если не добавить в файл некую директиву условной компиляции).
В чем пуля всех этих нововведений? Уж если язык динамический (а динамические языки имеют свои сильные преимущества), то и развивать его стоит именно как динамический.
NoPluses
19.09.2017 15:54-4Плюсую, но я из-за динамичности положил школьный сайт вместе с бд
Потом пришлось писать тонны регулярных выражений, хотя защиту от иньекций написал до этого
AmdY
PHP всё же умирает.
С новыми фичами мы лишились конкурентного преимущества — быстро и дешево. С фреймворками вроде Zend и Symfony и заморочками с типизацией время и объёмы кода стали сравнимы с Java и C#, в которых данные фичи существуют давно и реализованы не так костыльно как в PHP. И пока мы изобретаем гибернейт и играем во взрослый язык, конкуренты наоборот становятся проще и более дружественными к вебу.
А на рынке «быстро и дешево» позиции заняли nodejs и go, на подходе kotlin. Спасает ещё популярность laravel, но уровень разработчиков там печален.
aliev
Все таки не в языке дело, а в архитектуре и навыках разработчика.
И на Java и на C# можно писать так, что из глаз кровь пойдет
PHP разрабы дешевле, но все таки будущее за раздельным бэкендом VueJs + GoLang + PostgreSQL допустим для начинающего будет вполне правильным выбором в изучении чем PHP.
PHP никогда не умрет, я даже встречал веб морду на VisualBasic у одного крупного хостера, а вы тут PHP умирает пишите
AmdY
Я говорю о проектах с нормальным бюджетом, где php-шники получают как минимум не меньше коллег c других языков. Такие проекты исчезают. За последних пару лет их количество сократилось в разы, отделы php начали сокращать и переучивать на javascript ± node.
p.s. У меня информация о Минских компаниях, который в основном работают на запад. «Диджитал» и Битрикс конторы с дешёвой и некачественной рабочей силой я не считаю.
vlx
Magento будет еще достаточно долго жить. Разрабам М1/2 порой платят и поболе синьер джавистов.
Siddthartha
называется невалидная выборка.
цеховой снобизм фронтендщика мечтающего о тотальной победе js?)) очень, знаете ли, много кого вы таким образом "не считаете".) в абсолютном отношении нода даже приблизительно не близка к вытеснению php из реального сектора. и квалифицированные разработчики нормально зарабатывают.
AmdY
Я php-шник, потому хорошо знаю о чём говорю. Среди моих знакомых хороших программистов практически не осталось чистых php-шников, теперь для хорошей зарплаты надо нырять во фронтэнд. Дело не только в джавасрипте, есть ещё джава и шарп.
Да и в целом веб рынок сжался с приходом фейсбуков, уже не нужно столько типовых стэнд элон сайтиков и магазинов.
Siddthartha
и это при некой "стагнации", а уж теперь, с "новым дыханием"...) так что не переживайте, коллега.
AmdY
Ну раз у вас так хорошо с проектами, может со мной поделитесь? Я с легкостью найду исполнителей за хорошие деньги, которые с радостью согласятся бросить адский легаси.
vleonov
А у нас в Avito нормальный бюджет. И PHP-шники получают не меньше коллег с других языков. Да и вообще мы стараемся развивать и брать разработчиков-полиглотов.
Дело же не в языке, а в умении решать задачи.
Arris
— Здравствуйте, PHP уже умер?
— Как, опять?
(с) по мотивам OS/2 FAQ
AmdY
Понятное дело, что умирать он будет долго, вон даже Fortran, COBOL до сих пор используются в проде. Но с новыми проектами с нормальными бюджетами уже туго, это сильно бросается в глаза.
Даже простая проверка трендов это демонстрирует. trends.google.com/trends/explore?date=all&q=%2Fm%2F060kv
vlx
Полно в Европе новых проектов с нормальными бюджетами, в основном ECommerce.
Arris
Простая проверка трендов показывает нам график. Просто ломаную линию. Для сравнения нам нужно эту простую линию сопоставить с трендами других языков.
Мне не удалось заставить этот странный инструмент показать Питон и ноду как «язык программирования», возможно у вас получится.
Но вот мой график. Да, питон набирает популярность. Да, у PHP наблюдаются колебания и медленный спад (его долю отжирают другие ЯП).
Но говорить о смерти — преждевременно.
К тому же, если пролистать страницу ниже (и включить только поисковые запросы, а не ЯП), мы увидим крайне любопытную картину.
Китай впереди планеты всей по потреблению новых трендов.
TheShock
Очевидно, что не получилось. Ведь язык — JavaScript
Arris
Мы то говорим о серверных языках. А простое включение ЯП Javascript добавить нам еще и лишние в данном случае данные об использовании на фронте.
vashkatsi
График трендов PHP, Ruby, Go, Javascript если PHP умирает, то значит Ruby и Go мертворожденные ЯП.
Arris
Ну я вам не скажу за Go, а на руби написана прикольная имиджборда. Правда задеплоить эту имиджборду мегаквест, проще докером.
Впрочем, я ни с Руби, ни с Го не встречался на практике, некомпетентен, потому спорить не буду.
vashkatsi
Своим комментарием я хотел показать, что эти графики не показывают популярность или востребованность того или иного ЯП.
TheShock
Знаете, что JS дает тот же результат на трендах?
Arris
О.о
Забавно.
Ну тогда тем более нужно сравнивать. А то получится — «100% опрошенных всё поняли»
sumanai
Нда, судя по этим трендам, нужно переходить на GO.
TheShock
На самом деле пик тренда go был летом 2014-ого и с тех пор постоянно падает, так что переходить смысла уже нету.
Вообще, что старанно, согласно трендам с 2004-ого падают все языки: Java, JS, C, C++, C#, Lisp, Haskell, Ruby.
Чуть иначе в более современных языках — D, Scala, Go, Elixir. Но если их сравнивать с даже упавшей Java — они все находятся в районе нуля.
firk
Какой ужас. "Видим тренд что очередной язык набирает популярность — надо срочно присоединиться!"
А вообще, php конечно имеет много недостатков, но всякие активно пирящиеся nodejs по-моему намного хуже.
TheShock
Это ведь юмор про тренд то, на GO не стоит переходить даже при положительном тренде))
JekaMas
Почему? Вакансий стало больше, на международном рынке ценники ползут вверх, в США больший ценник только у Java и совсем немного больший.
Сейчас искал работу: PHP или GOlang. На golang нашлись лучшие предложениЯ на удаленку.
vlx
Потому что специалистов относительно мало еще пока, готовы взять и на удаленку. Через пару лет насмотревшиеся на тренды гугла заполнят рынок и проще будет найти человека в офис, чем мучиться с фрилансерами.
JekaMas
Вы ответили на какой-то другой вопрос.
И тут есть неточности: я не говорил про фриланс, я говорил про полный рабочий день (в моем случае, одни предлагают оформлание по трудовой в России, и две фирмы предлагают контракты на представительства в Европе, сроками от года); PHP вроде давно на рынке, но уменьшения удаленных вариантов (кроме прямой работы на США) я не заметил — у вас есть другая информация?
vlx
Я чет не понял, а что фриланс ограничен только биржами типа фрилансер.ру? Фриланс точно так же может быть и с контрактом и с полным рабочим днем. На западе фрилансерами называют независимых подрядчиков.
JekaMas
Тогда вы используете свое определение фриланса.
Работник на трудовом контракте — мало свободный работник. Да и фрилансер может работать в офисе, не переставая быть фрилансером.
В любом случае, «почему не go при положительном его тренде» открыт.
vlx
Я использую общепринятое определение фриланса. Фрилансер это просто частный предприниматель, по сути.
Когда я работал удаленно на немецкую контору у меня было аж два контракта — NDA и обычный контракт. И тем не менее, я считался фрилансером по всей отчетности. Контора не имела никакого представительства в СНГ, работал я сам на себя с ними удаленно.
JekaMas
В ваше определение не попадает мой случай с оформлением по тк рф, но с удаленной работой.
PQR
Если смотреть на эти гугл-тренды — все языки стагнируют! Так что выбираем язык, которые стагнирует медленнее других :)
trends.google.com/trends/explore?date=all&q=%2Fm%2F060kv,%2Fm%2F09gbxjr,%2Fm%2F02p97,%2Fm%2F07sbkfb,%2Fm%2F0jgqg
vashkatsi
Не уверен
AmdY
Да сcc..., странные результаты.
Вот сравнение за 5 лет php, nodejs и javascript trends.google.com/trends/explore?date=today%205-y&q=%2Fm%2F060kv,%2Fm%2F0bbxf89,%2Fm%2F02p97
Популярность php уходит и его вытесняют другие языки.
Но даже это не важно, беспокоят именно хорошие проекты с хорошей оплатой, их стало значительно меньше.
NoPluses
Но даже на данный момент это одна из самых простых и популярных платформ бэкэнда
calg0n
Да ну, ерунду вы пишете. Пыха хоть имеет свои болячки, но количество специалистов и проектов несравнимо больше чем у соседних языков, есть поле для манёвров. Бывает такое что попадаются проекты под которые пыха не подходит архитектурно, но это очень нишевые продукты. Опять же, под каждую задачу созданы свои инструменты, сделать всё на пыхе в крупном проекте несомненно странное решение, но то для чего она была создана — бекенд для веба, с этой задачей справляется на отлично.
AmdY
Знаете какой самый популярный вопрос по тегу laravel в местном тостере? Про неймспейсы, люди не понимают почему у них не работает как в примерах Foo::bar();
В посте я написал о том, что PHP оброс новыми фичами и так называемые специалисты в них до сих пор не разбираются. Порог входа значительно вырос. Найти специалиста, который знает ООП и может спокойно писать на фреймворке уровня symfony невероятно сложно и дорого, потому и теряется конкурентное преимущество.
Sannis
Быть может это проблема "уровня" Symfony?
calg0n
И что? Поэтому пыха говно и умирает? :) То что люди «входят в айти» через пыху напрямую определяет язык как говно? У вас очень странная логика.
Найти толкового специалиста — это всегда сложно и дорого и язык тут на самом деле второстепенен. Знаю достаточно крутых специалистов которые легко после пыхи осваивали и питоны и руби и go. Способность учиться и подстраиваться под рынок — это и определяет специалиста как профи, а не то что он знает symfony или ООП. Всё остальное приходит с опытом.
AmdY
Ну вот же. Я об этом же, если требование по знаниям такие же как в шарпах и джавах, то зачем писать на костылях и год ждать новую версию, чтобы в возращаемых типах указывать вариант с нулл.
Нормальные PHP-шники достигли потолка и пробили его, влезли на территорию других языков.
Я писал о том, что получрность и количество хороших проектов на php становится меньше. Если 5 лет назад php-отделы были самыми растущими, то нынче их начали сокращать, требования к знаниям стали выше, требования к коду жёстче.
Сам php становится лучше, более функцинальным, качественным и т.д. Но и вход в него растёт.
calg0n
Так можно сказать про любой язык.
JS влез на территорию бекенда и что? Не вижу ничего плохого, это развитие. Каждый язык что-то заимствует у другого.
Не стоит судить по себе. Я не вижу чтобы сокращали. Зато вижу что внутри компаний появляются специалисты которых вообще не найти сейчас, типа спецов по го.
Это же хорошо. Значит говнокода станет меньше и будет расти кол-во хороших проектов.