Comments 54
UFO just landed and posted this here
Начина читать статью, сложилось впечатление, что ее цель — рассказать, сколько млн. строк кода на PHP в вашем продукте…
Судя по всему линтер очень плохо понимает интерфейсы. Неужели в vk их не используют?
Да, интерфейсы мы почти не используем, поскольку KPHP (пока что) их не поддерживает :). Создавайте issue на гитхабе с примерами, постараемся поправить.
А почему было не попробовать использовать именно php storm для этих целей?
Это первое, что приходит на ум, но, к сожалению, это не самый лучший вариант по нескольким причинам:
1) Я не большой фанат Java в целом :)
2) PHPStorm хоть и не самая медленная IDE для PHP в мире, но скорость индексации и анализа у него не такая высокая, как мне бы хотелось. Даже если использовать встроенный кеш PHPStorm, всё равно время переиндексации при переключении веток оставляет желать лучшего (я анализирую как минимум 2 ветки кода при пуше — до и после)
3) Мне неизвестно ни об одном кейсе успешного внедрения PHPStorm в качестве консольной утилиты на сервере. Даже если у PHPStorm есть соответствующий API, есть серьезные сомнения, что эта конструкция будет стабильная, производительная и простая в поддержке. То есть, в теории, в PHPStorm есть всё, что нам нужно, но вот на практике заставить это работать так, как мы хотим, по моим представлениям, потребовало бы очень больших усилий
4) Мы хотим проверять ещё какие-то свои правила и не проверять какие-то вещи, которые проверяет PHPStorm, или делать это лучше. Это решается плагинами, но намного легче эту конструкцию поддерживать, когда у вас полный контроль над тем, как парсится код
5) Вопрос лицензии — у меня нет особого понимания, сколько лицензий нам потребуется и как в целом это должно работать. Например, нужно ли держать phpstorm постоянно запущенным на сервере (иначе время только на запуск IDE будет весьма существенным)? Как с ним взаимодействовать?
В общем, я бы хотел иметь возможность работать с PHPStorm таким способом, но мне кажется, что здесь лежит слишком много (потенциальных) проблем во время эксплуатации. Отдельная утилита будет быстрее, надежнее и проще.
1) Я не большой фанат Java в целом :)
2) PHPStorm хоть и не самая медленная IDE для PHP в мире, но скорость индексации и анализа у него не такая высокая, как мне бы хотелось. Даже если использовать встроенный кеш PHPStorm, всё равно время переиндексации при переключении веток оставляет желать лучшего (я анализирую как минимум 2 ветки кода при пуше — до и после)
3) Мне неизвестно ни об одном кейсе успешного внедрения PHPStorm в качестве консольной утилиты на сервере. Даже если у PHPStorm есть соответствующий API, есть серьезные сомнения, что эта конструкция будет стабильная, производительная и простая в поддержке. То есть, в теории, в PHPStorm есть всё, что нам нужно, но вот на практике заставить это работать так, как мы хотим, по моим представлениям, потребовало бы очень больших усилий
4) Мы хотим проверять ещё какие-то свои правила и не проверять какие-то вещи, которые проверяет PHPStorm, или делать это лучше. Это решается плагинами, но намного легче эту конструкцию поддерживать, когда у вас полный контроль над тем, как парсится код
5) Вопрос лицензии — у меня нет особого понимания, сколько лицензий нам потребуется и как в целом это должно работать. Например, нужно ли держать phpstorm постоянно запущенным на сервере (иначе время только на запуск IDE будет весьма существенным)? Как с ним взаимодействовать?
В общем, я бы хотел иметь возможность работать с PHPStorm таким способом, но мне кажется, что здесь лежит слишком много (потенциальных) проблем во время эксплуатации. Отдельная утилита будет быстрее, надежнее и проще.
Кстати про Java: не раз слышал (в подкастах, типа Разбора полётов и, возможно, ещё каких-то интервью) что в Одноклассниках очень довольны производительностью Java и в итоге у них заметно меньше серверов чем у VK.
Понятно, что вы уже плотно сидите на PHP/KPHP + сервисы на Go и C++, а одноклассники плотно сидят на Java — у каждого своя экспертиза, каждый выжимает максимуму из выбранного стека.
Но вопрос такой: действительно ли в Одноклассниках меньше серверов и можно ли сделать вывод, что команда Java профессионалов может сделать более эффективный/производтельный высоконагруженный сервис, чем команда KPHP/Go/C++ профессионалов?
Понятно, что вы уже плотно сидите на PHP/KPHP + сервисы на Go и C++, а одноклассники плотно сидят на Java — у каждого своя экспертиза, каждый выжимает максимуму из выбранного стека.
Но вопрос такой: действительно ли в Одноклассниках меньше серверов и можно ли сделать вывод, что команда Java профессионалов может сделать более эффективный/производтельный высоконагруженный сервис, чем команда KPHP/Go/C++ профессионалов?
Если смотреть распределение серверов по ролям в ВК, то PHP там будет процентов 20, так что определяющим фактором язык здесь не является. Но, безусловно, на PHP (и, в меньшей степени, KPHP) сложнее писать высокопроизводительный код, чем на Java, так что в среднем эффективность работы всё равно будет ниже при прочих равных. Но поскольку KPHP компилируется в C++, то при необходимости его можно оптимизировать лучше, чем код на Java, и в критичных местах мы это и делаем
Сравнивать общее число серверов довольно странно, у нас их так много не в последнюю очередь потому, что у нас ОЧЕНЬ много пользовательских файлов.
А если сравнивать именно нагрузку от пользовательских запросов на web/api (и эффективную их обработку), то я не знаю что там у них, увы.
А если сравнивать именно нагрузку от пользовательских запросов на web/api (и эффективную их обработку), то я не знаю что там у них, увы.
Насколько я помню, в ВК, из-за хайлоада (разработчики так аргументировали) используются подходы ~20 летней давности, с процедурками, глобалами и прочими весёлыми штуками, а kPHP ( github.com/vk-com/kphp-kdb ) не умеет в ООП и давно заброшен. Отсюда и «детские болячки» с отсутствием поддержки современного кода.
Поправьте, если я ошибаюсь.
Поправьте, если я ошибаюсь.
Все-таки внутри ВК компилятор развивается, и сейчас он уже поддерживает ООП в некотором урезанном виде, и его поддержка потихоньку расширяется. Более того, новый код зачастую проектируется уже с учетом ООП. Тем не менее, старый код действительно написан без него.
Я заранее извиняюсь за излишнюю циничность в словах, но пользуясь случаем, хотел бы поинтересоваться:
Почему бы не делать как FB, Badoo и прочие, и контрибьютить в то, что всем полезно и нужно, в основной язык, вместо того, чтобы тратить время на велосипед, который никому не нужен, кроме VK? Это позволило бы как минимум идти в ногу со временем, а не отставать на 15+ лет (потому что причислять «автолоад» к минусам, а не к плюсам — это как говорить, что «компьютер плохой, т.к. не поддерживает перфокарты»). Плюс, был бы нормальный фидбек со стороны сообщества, плюс позитивный пиар компании, плюс… Короче, очень много положительных факторов.
P.S. Ну и да, линтер бы прогонялся в боевых условиях, а не kPHP проекте. Тогда бы и с интерфейсами был бы полный порядок.
Почему бы не делать как FB, Badoo и прочие, и контрибьютить в то, что всем полезно и нужно, в основной язык, вместо того, чтобы тратить время на велосипед, который никому не нужен, кроме VK? Это позволило бы как минимум идти в ногу со временем, а не отставать на 15+ лет (потому что причислять «автолоад» к минусам, а не к плюсам — это как говорить, что «компьютер плохой, т.к. не поддерживает перфокарты»). Плюс, был бы нормальный фидбек со стороны сообщества, плюс позитивный пиар компании, плюс… Короче, очень много положительных факторов.
P.S. Ну и да, линтер бы прогонялся в боевых условиях, а не kPHP проекте. Тогда бы и с интерфейсами был бы полный порядок.
Поверьте, KPHP не отстает на 15+ лет по фичам :). К тому же, в KPHP есть много фич, которых нет в PHP и которые нужны нам и не нужны никому больше.
> Да и причислять «автолоад» к минусам, а не к плюсам… Ну это как говорить, что «компьютер плохой, т.к. не поддерживает перфокарты».
Это минусы для нашей кодовой базы. Она до сих пор во многом основана на функциях (в основном это про старый код), и если линтер требует автолоада для работы, то проанализировать часть нашей кодовой базы он просто не сможет.
> Да и причислять «автолоад» к минусам, а не к плюсам… Ну это как говорить, что «компьютер плохой, т.к. не поддерживает перфокарты».
Это минусы для нашей кодовой базы. Она до сих пор во многом основана на функциях (в основном это про старый код), и если линтер требует автолоада для работы, то проанализировать часть нашей кодовой базы он просто не сможет.
К тому же, в KPHP есть много фич, которых нет в PHP и которые нужны нам и не нужны никому больше.
Ну, допустим, все эти «фичи» добавляются с помощью расширений или какого-нибудь pre. За исключением, конечно, бизнес-логики.
А что на счёт предложения обратно переехать на нормальный язык? Он за последнее время довольно сильно ускорился и если 7.0 уже местами перегоняла HHVM, то 8ка с asm-jit предполагает ещё больший прирост.
На PHP 7.2 сайт работает в целом сносно, но бОльшая часть разделов всё ещё работает существенно медленней, чем на KPHP. Это связано с тем, что кодовая база VK уже весьма давно существует в рамках того, что позволяет компилятор KPHP и есть довольно много фич, которые сделаны специально для ускорения существующей кодовой базы и наоборот, много кода написано с учетом специфики именно KPHP. Ситуация похожа на то, как у фейсбука с HHVM и Hack — я бы сказал, что назад возвращаться стоило бы бОльших усилий, чем допиливать нужные для нас вещи в KPHP. Но это моё личное мнение, у кого-то может быть противоположное.
Ну понимаете же сами, что учитывая ту публикацию скольких-там-лет-давности о «котиковом пыхе» вообще ничего известно не было, по-этому в некоторых кругах и сложилось подобное впечатление об этом проекте, как и об организации в целом. Это замечательно, что вы его развиваете, но печально, что положили болт на то, что выложили, т.к. открытых иссью в 3 раза больше чем закрытых, а PR висят с 2014го года.
Я не знаю как у других, но лично у меня доверие к ВК после такого подорвано и текущий анонс полурабочего линтера воспринимаю точно так же. «Вбросили, добавили пару коммитов и забыли», а значит и смотреть и оценивать даже не имеет смысла.
И всё же надеюсь что это не так, и в этот раз вы не оплошаете, т.к. анализатор в качестве lang сервера — это действительно крутой вариант.
P.S. Так а всё же на тему оригинального языка, может всё же стоит посмотреть в его сторону тоже? Оформите там RFC с вашими синтаксическими наработками, например, которые показали себя на практике с положительной стороны. М?
Я не знаю как у других, но лично у меня доверие к ВК после такого подорвано и текущий анонс полурабочего линтера воспринимаю точно так же. «Вбросили, добавили пару коммитов и забыли», а значит и смотреть и оценивать даже не имеет смысла.
И всё же надеюсь что это не так, и в этот раз вы не оплошаете, т.к. анализатор в качестве lang сервера — это действительно крутой вариант.
P.S. Так а всё же на тему оригинального языка, может всё же стоит посмотреть в его сторону тоже? Оформите там RFC с вашими синтаксическими наработками, например, которые показали себя на практике с положительной стороны. М?
В KPHP нет синтаксиса, отсутствующего в обычном PHP, т.к. это потребовало бы введение поддержки во всех IDE и редакторах, которые используются в нашей команде. На это мы пока не готовы.
Так что единственное отличие (ну за некоторыми синтаксически совместимыми особенностями): поддержка особых phpdoc, которые помогают kphp лучше понимать намерения разработчика и генерить более правильный и нативный C++ код. Именно большее понимание кода и вывод типов (даже довольно сложных) позволяет дать C++ компилятору код, который будет скомпилен более оптимально. За счет этого и выигрыш по скорости, причем существенный.
Мы прикладываем много усилий, чтобы типы выводились более точно. И тут линтер — один из инструментов. Но это не единственное его предназначение.
Что касается той выкладки kphp в паблик. И тут уже мое личное мнение.
Это было сделано зря, но не нам уже судить это решение, тем более что с тех пор команда сильно поменялась. Сейчас снова выкладывать kphp и поддерживать этот вариант у нас не готовы. Не в последнюю очередь потому, что мы гораздо внимательнее относимся к публичной деятельности и опенсорсу в частности. Это долгоиграющая ответственность, а не разовый шаг. Что мы можем и готовы публиковать в опенсорс и поддерживать — мы это делаем. Линтер — это один из таких примеров. KPHP, к сожалению ?, сейчас не такой проект.
Повторюсь, это все мое личное мнение.
Это было сделано зря, но не нам уже судить это решение, тем более что с тех пор команда сильно поменялась. Сейчас снова выкладывать kphp и поддерживать этот вариант у нас не готовы. Не в последнюю очередь потому, что мы гораздо внимательнее относимся к публичной деятельности и опенсорсу в частности. Это долгоиграющая ответственность, а не разовый шаг. Что мы можем и готовы публиковать в опенсорс и поддерживать — мы это делаем. Линтер — это один из таких примеров. KPHP, к сожалению ?, сейчас не такой проект.
Повторюсь, это все мое личное мнение.
Думаю многие согласны с этим. А по поводу линтера, надеюсь вы доведёте его до ума, чтобы он не выкидывал ошибки, вроде:
ERROR Call to undefined function \ucfirst at ...\Support.php:153
return \ucfirst(\strtolower(\gettype($value)));
^^^^^^^^
ERROR Call to undefined function \strtolower at ...\Support.php:153
return \ucfirst(\strtolower(\gettype($value)));
^^^^^^^^^^^
Ошибка выглядит так, что вы не указали (или неправильно указали?) путь к phpstorm-stubs директории (например, эта директория пустая). Вроде линтер должен проверять хотя бы наличие директории, если этого не происходит, то заведите issue, пожалуйста.
Да, всё верно: #4. Просто такой километр логов, что подобная информация просто затерялась. Думаю стоит добавить ещё "-output" для этого?
А так да, всё круто и очень быстро, но очень много ложных срабатываний (691 critical errors против 0 у Psalm). Я боюсь что довольно проблематично будет заводить иссью под каждый false-positive. В каком формате мне в этом случае стоит прислать фидбек?
А так да, всё круто и очень быстро, но очень много ложных срабатываний (691 critical errors против 0 у Psalm). Я боюсь что довольно проблематично будет заводить иссью под каждый false-positive. В каком формате мне в этом случае стоит прислать фидбек?
По поводу issue #4 — под windows я не тестировал :), поэтому cache-dir так странно себя ведёт :). Пока я это не починил, можете просто не указывать cache-dir вообще, этот параметр не является обязательным.
Что касается фидбека — если вам не запрещает NDA, можете прислать мне исходники проекта и я сам смогу посмотреть :). Второй вариант — попробовать начать использовать noverify в своем проекте в режиме с подсчётом диффа и видеть только новые предупреждения. Тогда их будет так много сразу и легче будет изолировать отдельные проблемы (мы так у себя внутри и делаем, собственно).
Второй вариант — попробовать начать использовать noverify в своем проекте в режиме с подсчётом диффа и видеть только новые предупреждения. Тогда их будет так много сразу и легче будет изолировать отдельные проблемы (мы так у себя внутри и делаем, собственно).
Да, это хорошая идея. Можно добавить его в CI и время от времени присылать фидбек с новыми проблемами.
UFO just landed and posted this here
Сейчас у нас совсем по другому относятся к выкладыванию чего-либо. Плюс сил и желания поддерживать несопоставимо больше.
Пользоваться или нет — тут уже выбор каждого. Можно, например, подождать и посмотреть :)
А вот брать kphp, если он, представим себе, будет повторно выложен, будет ли кто? Кто есть из крупных проектов с подобными нагрузками и крепко сидящих на php, кто не мигрирует на какой-то другой ЯП, либо написал собственную вундервафлю?
Пользоваться или нет — тут уже выбор каждого. Можно, например, подождать и посмотреть :)
А вот брать kphp, если он, представим себе, будет повторно выложен, будет ли кто? Кто есть из крупных проектов с подобными нагрузками и крепко сидящих на php, кто не мигрирует на какой-то другой ЯП, либо написал собственную вундервафлю?
Сейчас у нас совсем по другому относятся к выкладыванию чего-либо.
А можно я тогда чуть вброшу на вентилятор тогда? +)
Берём github.com/VKCOM/vk-php-sdk
1) Где тесты?
2) Где коверейдж?
3) Где настроенный CI?
4) Где PSR? Не только второй, но и для HTTP запросов, для кеша, для миддлварей, хоть какой-нибудь.
5) Где шаблоны для issue и pr?
6) Почему написано, что php 7.1+, а внутри код эпохи 5ки с «array()» и прочими прелестями?
</вентилятор-mode>
UFO just landed and posted this here
Доверие к ВК было утрачено когда они выдавали Дурова, когда без решения суда сливали все данные. Сразу как в проекте появляется мэил.ру груп — к нему больше не стоит прикасаться. Какие моральные принципы могут быть у компании которая сделала мэйл-ру-агент? Которая использовала методики распространения и слежки за пользователями в лучших традициях залива троянов?
Этот проект может только показать что технические специалисты менеджерятся в этих структурах точно по тем же принципам что и остальные.
Этот проект может только показать что технические специалисты менеджерятся в этих структурах точно по тем же принципам что и остальные.
Почему бы не делать как FB, Badoo и прочие, и контрибьютить в то, что всем полезно и нужно, в основной язык, вместо того, чтобы тратить время на велосипед, который никому не нужен, кроме VK?
Импортозамещение)
UFO just landed and posted this here
UFO just landed and posted this here
Юра несколько раз говорил, что у нас очень много уже написанного кода на PHP, и от него никуда не деться. Это данность, с которой приходится уживаться. Там, где мы можем не использовать PHP, мы его и не используем. У нас много кода на C и C++, также прилично на Go и python (последний по наслышке).
> А можете рассказать, почему вы используете KPHP?
Изначальная кодовая база сайта была на PHP, и начиная с некоторого объема кода (который был к тому моменту явно достигнут), было легче написать свой транслятор из PHP в C++, чем руками портировать весь этот код на другой язык, попутно сломав много чего, и сильно затормозив развитие сайта на это время.
KPHP позволяет более плавно перейти с PHP с его полностью динамической типизацией (и сопутствующими принципиальными ограничениями по производительности) в более статически типизированный код, который будет эффективно трансливаться в С++. При этом учить новый язык не нужно, статическая типизация в KPHP работает на уровне phpdoc-аннотаций и специальных комментариев.
К тому же, разработка на PHP имеет и свои плюсы — в development окружении мы используем обычный PHP, поэтому разработчики могут быстро итерироваться во время разработки и обратная связь после правок дается сразу — достаточно перезагрузить страницу или сделать новый API-запрос на сервер. Если с Java и C# в некоторых случаях можно к этому приблизиться, то с C++ так точно не выйдет. Лично я не большой фанат языков с виртуальной машиной и JIT'ом, и, насколько я знаю, наши админы тоже :). А на чистом C++ разработка будет медленной, подверженной ошибкам, и очень дорогой по сравнению с PHP/KPHP.
> Ведь фактически вы создаете свои инструменты
Начиная с некоторого объема кодовой базы, а также начиная с какого-то количества серверов и нагрузки, становится выгоднее разрабатывать свои инструменты, чем пытаться подогнать уже существующие под наши реалии. Это не значит, что мы не смотрим в сторону существующих решений, когда они нам подходят — например, мы используем у себя ClickHouse и очень им довольны.
> чтобы компенсировать демотивацию, вызванную отсутствием прироста опыта работы с мейнстрим экосистемами у сотрудников
Моё мнение, что мотивация у каждого человека своя. Например, мне наоборот очень интересен хайлоад и огромные системы, поэтому для меня наоборот это интересная возможность поработать над таким проектом и пилить свои инструменты там, где стандартные не работают. Для кого-то это возможность повлиять на продукт, которым пользуются почти 100 млн человек ежемесячно, для кого-то просто работать в историческом центре Санкт-Петербурга, и т.д.
> и все это стоит денег. А ради чего?
Как правило, необходимость в своих инструментах возникает тогда, когда вы достигаете определеного масштаба. В ВК несколько десятков тысяч серверов, на которых крутится сайт, поэтому, если, например, можно написать что-то на 30% эффективнее, чем существующие инструменты, то это нам сэкономит тысячи серверов, и оно однозначно того стоит. Ведь бизнес же прежде всего про зарабатывание денег, а свои инструменты позволяют тратить меньше ресурсов и делать так, чтобы сайт работал быстрее, надежнее, и т.д. Плюс, разрабатывать свои инструменты — это же весело :), особенно когда они действительно кому-то нужны.
Изначальная кодовая база сайта была на PHP, и начиная с некоторого объема кода (который был к тому моменту явно достигнут), было легче написать свой транслятор из PHP в C++, чем руками портировать весь этот код на другой язык, попутно сломав много чего, и сильно затормозив развитие сайта на это время.
KPHP позволяет более плавно перейти с PHP с его полностью динамической типизацией (и сопутствующими принципиальными ограничениями по производительности) в более статически типизированный код, который будет эффективно трансливаться в С++. При этом учить новый язык не нужно, статическая типизация в KPHP работает на уровне phpdoc-аннотаций и специальных комментариев.
К тому же, разработка на PHP имеет и свои плюсы — в development окружении мы используем обычный PHP, поэтому разработчики могут быстро итерироваться во время разработки и обратная связь после правок дается сразу — достаточно перезагрузить страницу или сделать новый API-запрос на сервер. Если с Java и C# в некоторых случаях можно к этому приблизиться, то с C++ так точно не выйдет. Лично я не большой фанат языков с виртуальной машиной и JIT'ом, и, насколько я знаю, наши админы тоже :). А на чистом C++ разработка будет медленной, подверженной ошибкам, и очень дорогой по сравнению с PHP/KPHP.
> Ведь фактически вы создаете свои инструменты
Начиная с некоторого объема кодовой базы, а также начиная с какого-то количества серверов и нагрузки, становится выгоднее разрабатывать свои инструменты, чем пытаться подогнать уже существующие под наши реалии. Это не значит, что мы не смотрим в сторону существующих решений, когда они нам подходят — например, мы используем у себя ClickHouse и очень им довольны.
> чтобы компенсировать демотивацию, вызванную отсутствием прироста опыта работы с мейнстрим экосистемами у сотрудников
Моё мнение, что мотивация у каждого человека своя. Например, мне наоборот очень интересен хайлоад и огромные системы, поэтому для меня наоборот это интересная возможность поработать над таким проектом и пилить свои инструменты там, где стандартные не работают. Для кого-то это возможность повлиять на продукт, которым пользуются почти 100 млн человек ежемесячно, для кого-то просто работать в историческом центре Санкт-Петербурга, и т.д.
> и все это стоит денег. А ради чего?
Как правило, необходимость в своих инструментах возникает тогда, когда вы достигаете определеного масштаба. В ВК несколько десятков тысяч серверов, на которых крутится сайт, поэтому, если, например, можно написать что-то на 30% эффективнее, чем существующие инструменты, то это нам сэкономит тысячи серверов, и оно однозначно того стоит. Ведь бизнес же прежде всего про зарабатывание денег, а свои инструменты позволяют тратить меньше ресурсов и делать так, чтобы сайт работал быстрее, надежнее, и т.д. Плюс, разрабатывать свои инструменты — это же весело :), особенно когда они действительно кому-то нужны.
UFO just landed and posted this here
Но ведь KPHP не умеет выполнять код на PHP хотя бы из-за ООП. Вам все равно пришлось переписывать.
Или вы писали без ООП даже до появления KPHP? (Зачем? Производительностью нельзя объяснить, т.к. PHP раньше был медленным хоть с ООП, хоть без него, при этом были гораздо более производительные альтернативы)
Писали почти без ООП, например потому, что реализация ООП раньше в PHP была ещё медленней, чем на объектах.
Но ведь PHP — тоже VM, причем в следующих версиях JIT обещают.
Это всё сильно будущее время :). Решение принималось очень давно, когда не было очевидно даже то, что PHP7 так сильно всё ускорит.
Так почему не Java? KPHP на ваших задачах будет производительнее?
Здесь я могу лишь высказать своё мнение — мне лично Java не нравится, как минимум, следующим:
— излишняя формальность и «энтерпрайзность»
— многословность
— производительность
— потребление памяти
— неудобство эксплуатации (к эксплуатации программы добавляется необходимость ставить и тюнить JVM)
У этого языка есть и плюсы, конечно, но если выбирать между Java и PHP, я наверное выберу второе. Но если давать вообще выбор серверного языка, то это будет ни то, ни другое, это будет скорее какой-нибудь Go :).
мне лично Java не нравится, как минимум, следующим:
— излишняя формальность и «энтерпрайзность»
— многословность
— производительность
Ни разу не поклонник Java, но, справедливости ради, решение на ней занимает 6 место…
Безусловно, на Java можно писать производительный код, который после того, как прогреется JIT, будет показывать хорошую производительность. Но так пишут далеко не всегда :). Go в этом плане мне нравится намного больше — там нет JIT, он работает быстро прямо на старте, не слишком многословен и позволяет быстро писать работающий код. Но это больше вопрос вкуса, как по мне, чем каких-то объективных критериев.
Но ведь KPHP не умеет выполнять код на PHP хотя бы из-за ООП. Вам все равно пришлось переписывать.
Или вы писали без ООП даже до появления KPHP? (Зачем? Производительностью нельзя объяснить, т.к. PHP раньше был медленным хоть с ООП, хоть без него, при этом были гораздо более производительные альтернативы)
Все так, ООП код по замерам того времени выполнялся медленее, чем на функциях. Массовое использование классов php'шных у нас началось не так давно, особенно после того, как kphp научился транслировать php классы в плюсовые структуры без какого-либо ООП'шного оверхеда.
Тут важно вспомнить, что переход на KPHP у нас начался где-то во времена PHP 5.3. Но уже и к тому моменту кода было прилично уже написано.
И зачем в таком случае развивать KPHP, если можно оставить его как есть в виде легаси, а новые сервисы писать уже на Java или Go, постепенно заменяя ими старые?
А тут все просто: у нас монолит. Если собирается специфическая сборка, она вкомпиливает в себя весь достижимый код из указанной точки входа. Соответственно, добавление любого функционала сайту — это добавление PHP кода в этот же монолит.
Последнее время мы занимаемся уменьшением связности и некоторым техдолгом, чтобы что-то с этим сделать.
А если мы можем сделать что-то обособляемое, то как раз и пишем это на Go или Python. Есть небольшие ex-PHP/Python штуки, которые мы переписали на Go: сбор ошибок, демоночки на региональных кешах, обработка анонсируемых префиксов в тех же регионах… Некоторые сложные вычислительные задачи наши C/C++ разработчики оформляют в виде демонов/сервисов.
Так что мы не пишем все на PHP и кайфуем от этого :)
А почему python, а не PHP?
Ну, у нас есть код в обособленных командах, например админы или датамайнеры. Там используются ЯП, которые им больше нравятся. Ну и репы у них свои, а общение через общие прокси до движков.
Так почему не Java?
И после вышенаписанного совершенно не понятно, зачем нам Java. Где мы завязаны на PHP — там будет KPHP, в остальных нагруженных местах — C++ и Go.
UFO just landed and posted this here
PHP тех времен сам выполнялся очень медленно. Почему вы не выбрали другой более подходящий язык?
Так к тому времени уже была куча кода на PHP, которую было не переписать, а в скорость работы уже уперлись.
Правильно ли я понимаю, что вы высказываете свои мысли о том, что был сделан неправильный выбор?
Ну, монолит — это не лучшая архитектура при развитии проекта и росте команды. Но он удобен на первых этапах. Так что в целом нормально.
Вы в минусы джавы написали про производительность. И это сравнивая с низкой производительностью PHP того времени. Вы делали тесты и замеры?
Ну тут опять же про то, что у нас уже была куча кода на PHP.
На Laravel очень плохо работает, он не видит фасады. Есть решение проблемы?
Также помечает переменные, которые в compact() как unused
UNUSED unused: Unused variable companiesList
Также помечает переменные, которые в compact() как unused
UNUSED unused: Unused variable companiesList
Если что-то не работает, и вы примерно понимаете возможную причину, заведите пожалуйста issue на github, постараемся всё разумное исправить.
Функцию compact() и некоторые другие динамические возможности PHP линтер вряд ли сможет анализировать, и пока что непонятно, как это можно проверять статическим анализом, так что да, на такой код линтер будет ругаться всегда :).
Функцию compact() и некоторые другие динамические возможности PHP линтер вряд ли сможет анализировать, и пока что непонятно, как это можно проверять статическим анализом, так что да, на такой код линтер будет ругаться всегда :).
Статический анализ это не совсем про подход, который предлагает Laravel.
В общем случае лучше откажитесь от фасадов в том виде в котором они там есть.
В общем случае лучше откажитесь от фасадов в том виде в котором они там есть.
Sign up to leave a comment.
NoVerify: линтер для PHP от Команды ВКонтакте теперь в открытом доступе