Даже интересно, что будет, если всем PHP-разработчикам завтра сказать: отныне вы пишите на плюсах, вот новая репа с одним initial commit, а да, только не на 6 миллионов строк, а на 66, там 250к файлов, а все строковые литералы объединены в оооодну большую строку :)
Потому что PHP это действительно очень удобно для быстрого прототипирования, что очень актуально для продуктовых команд. Исправил, сохранил — и уже работает. 0 степеней ожидания.
Первая часть звучит как синоним «просто откажитесь от PHP», что в разных ветках уже обсуждалось.
Возможность трансляции — да по факту запуск компилятора :) Сработало — всё ок, вывел ошибку — идёшь исправляешь. Да, частично это видно в IDE при плагине, но далеко не всё.
Всегда кажутся странными размышления, что язык определяет опыт. Опыт это намного более высокоуровневая вещь. Опыт работы с хайлоадом, опыт комбинирования технологий, опыт деплоя и отката на миллионах пользователей с разошедшимся клиентсайдом. Язык это всего лишь средство. Обычно это как раз последнее, что волнует в контексте трудоустройства :)
Честно — не знаю. Возможно, в LLVM :)
Но поскольку мы уже несколько лет как завязаны на С++ и бесконечность с этим связанных мелочей, то «давайте полноценно сравним с Rust» звучит как «давайте сменим PHP на Go».
Да, всё правильно описал SerafimArts выше. Реализация tuple() чуть страннее выглядит в реальности, конечно, но принцип такой. У нас это называется «полифиллы» — github.com/VKCOM/kphp-polyfills
Пусть в качестве ответа на «Зачем?» будет «Но ведь хуже-то от этого не станет».
Открытость для нас как для бренда компании — это весьма достойно, хоть и многими воспринимается с изрядной долей скепсиса. Открытость для нас как для разработчиков — это как минимум личная ценность, что ты не просто «где-то там работал», а результаты твоих трудов доступны и лежат в открытом доступе. Тем более, что компиляторная область в целом весьма узкая.
И раз мы переезжаем на гитхаб — то конечно, куда без статьи на Хабре :) Ничего сверхестественного.
> каковы шансы, что KPHP опять не уйдет в тьму на 6 лет
По крайней мере, если в 2014 выложили и всё, то сейчас у нас весь процесс разработки переехал на гитхаб. Да, не факт, что у нас будет много времени на то, чтобы делать что-то для не нужд ВК (и в ближайшее время точно не будет) — но весь процесс разработки в любом случае становится открытым. Так что ответ зависит от трактовки слова «тьма» :)
> лучшие достижения KPHP перенести в основной PHP
Думаю, что шансов примерно 0. Во-первых, мы совершенно сторонняя компания, не имеющая никакого отношения к Zend. Ну и во-вторых, мы ведь живём за счёт ограничений и за счёт анализа всех исходников целиком, а не по мере исполнения.
LLVM это интересный поинт, возможно когда-нибудь и протестируем, но, конечно, чтобы покрыть всё что нам надо — это по факту переписать не только всю кодогенерацию, но и множество вещей вокруг. А этим есть смысл заниматься только при условии, что гарантированно почему-то станет лучше.
А так, когда-нибудь на синтетике сами попробовать хотели, да.
Юрий, по-моему, ты сам ответил на свой вопрос :) Ты ушёл из ВК как раз чуть меньше 2-х лет назад, когда наша разработка входила в активную стадию. На тот момент у нас были просто структуры (без ООП), и мы только начинали свой путь. Но кстати даже тогда, когда повсюду были ассоциативные нетипизированные массивы — даже тогда KPHP выигрывал больше, чем 10%, тут ты занижаешь. Хотя не в 3-10 раз, как сейчас, тут конечно.
И с тех пор как раз мы взяли курс на тотальную типизацию. Полная поддержка ООП, напрямую идущая в плюсы. Типизировали RPC-слой с движками, что TL-байты напрямую маппятся в PHP-типы в обе стороны. Обязали писать типы везде: даже если у тебя legacy и везде mixed — иди и пиши явно. Плюс ряд оптимизаций, не связанных с типизацией — чего стоит одна шаренная память между воркерами с иммутабельным доступом. По факту, почти всё что мы сделали — это как раз после твоего ухода )) Так что да, теперь KPHP значительно быстрее — и как ты правильно сказал, в основном за счёт типизации и за счёт фич, которых в PHP нет. А если его использовать абы как, то PHP кое-где случайно и может окажется быстрее. Но это не наш случай.
У нас всё-таки чересчур много кода, и нестрипанный бинарь получается почти 3 ГБ, который линкуется из более чем 100к объектников (не втупую, там свои приколы). Поэтому линковать его на локальной машине это так себе затея) Но унести бинарник vkcom на флешке домой это можно, получается.
Потому что он появляется вот только-только сейчас, а проблемы с производительностью мы решаем уже несколько лет? )
Я более чем уверен, что для наших задач мы всё равно будем значительно быстрее, уж слишком много сил для этого приложили и слишком много неочевидных моментов под себя заточили, которые не опишешь в статье.
Хотя не исключаю, что PHP 8 в синтетических случаях случайно может оказаться сравним.
Если честно, нет других причин кроме исторических. Как бы слабо ни звучал аргумент «у нас миллионы строк кода» и как бы пафосно сверху ни спускали мысль «давайте всё попилим на микросервисы» — реальность не такая. В реальности всё достижимо из всего, а цикломатичность кода стремится к бесконечности :)
Да, в первую очередь нужно приводить в порядок код. Независимо от того, бить на микросервисы или нет. Но по опыту скажу: те части, где нет Legacy и которые в порядке, они и на PHP очень даже стройно смотрятся. А с учётом того, что и по перформансу теперь быстро — то нам более чем подходит такой вариант.
Про заинлайнить — на самом деле g++ и инлайнит :) А вот прикинуть, какие функции при кодогенераци разбивать на cpp/h, а какие помещать в h с пометкой inline или __attribute__((always_inline)) — это уже KPHP решает. С LTO на десятках тысяч функций там всё не совсем гладко.
Про ошибки на уровне g++ — по-хорошему, конечно, их не должно быть, они должны отбиваться на уровне трансляции с разумной ошибкой. Но в каких-нибудь редких неучтённых сценариях проскакивают — и тогда, обычно, да, PHP-разработчики приходят в наш чат :)
Возможность трансляции — да по факту запуск компилятора :) Сработало — всё ок, вывел ошибку — идёшь исправляешь. Да, частично это видно в IDE при плагине, но далеко не всё.
Но поскольку мы уже несколько лет как завязаны на С++ и бесконечность с этим связанных мелочей, то «давайте полноценно сравним с Rust» звучит как «давайте сменим PHP на Go».
Открытость для нас как для бренда компании — это весьма достойно, хоть и многими воспринимается с изрядной долей скепсиса. Открытость для нас как для разработчиков — это как минимум личная ценность, что ты не просто «где-то там работал», а результаты твоих трудов доступны и лежат в открытом доступе. Тем более, что компиляторная область в целом весьма узкая.
И раз мы переезжаем на гитхаб — то конечно, куда без статьи на Хабре :) Ничего сверхестественного.
По крайней мере, если в 2014 выложили и всё, то сейчас у нас весь процесс разработки переехал на гитхаб. Да, не факт, что у нас будет много времени на то, чтобы делать что-то для не нужд ВК (и в ближайшее время точно не будет) — но весь процесс разработки в любом случае становится открытым. Так что ответ зависит от трактовки слова «тьма» :)
> лучшие достижения KPHP перенести в основной PHP
Думаю, что шансов примерно 0. Во-первых, мы совершенно сторонняя компания, не имеющая никакого отношения к Zend. Ну и во-вторых, мы ведь живём за счёт ограничений и за счёт анализа всех исходников целиком, а не по мере исполнения.
LLVM это интересный поинт, возможно когда-нибудь и протестируем, но, конечно, чтобы покрыть всё что нам надо — это по факту переписать не только всю кодогенерацию, но и множество вещей вокруг. А этим есть смысл заниматься только при условии, что гарантированно почему-то станет лучше.
А так, когда-нибудь на синтетике сами попробовать хотели, да.
Да, всё так. Для распространения своего же кода, для распила монолита, это удобно и стыкуется с привычной разработкой.
Юрий, по-моему, ты сам ответил на свой вопрос :) Ты ушёл из ВК как раз чуть меньше 2-х лет назад, когда наша разработка входила в активную стадию. На тот момент у нас были просто структуры (без ООП), и мы только начинали свой путь. Но кстати даже тогда, когда повсюду были ассоциативные нетипизированные массивы — даже тогда KPHP выигрывал больше, чем 10%, тут ты занижаешь. Хотя не в 3-10 раз, как сейчас, тут конечно.
И с тех пор как раз мы взяли курс на тотальную типизацию. Полная поддержка ООП, напрямую идущая в плюсы. Типизировали RPC-слой с движками, что TL-байты напрямую маппятся в PHP-типы в обе стороны. Обязали писать типы везде: даже если у тебя legacy и везде mixed — иди и пиши явно. Плюс ряд оптимизаций, не связанных с типизацией — чего стоит одна шаренная память между воркерами с иммутабельным доступом. По факту, почти всё что мы сделали — это как раз после твоего ухода )) Так что да, теперь KPHP значительно быстрее — и как ты правильно сказал, в основном за счёт типизации и за счёт фич, которых в PHP нет. А если его использовать абы как, то PHP кое-где случайно и может окажется быстрее. Но это не наш случай.
Я более чем уверен, что для наших задач мы всё равно будем значительно быстрее, уж слишком много сил для этого приложили и слишком много неочевидных моментов под себя заточили, которые не опишешь в статье.
Хотя не исключаю, что PHP 8 в синтетических случаях случайно может оказаться сравним.
Да, в первую очередь нужно приводить в порядок код. Независимо от того, бить на микросервисы или нет. Но по опыту скажу: те части, где нет Legacy и которые в порядке, они и на PHP очень даже стройно смотрятся. А с учётом того, что и по перформансу теперь быстро — то нам более чем подходит такой вариант.
Про ошибки на уровне g++ — по-хорошему, конечно, их не должно быть, они должны отбиваться на уровне трансляции с разумной ошибкой. Но в каких-нибудь редких неучтённых сценариях проскакивают — и тогда, обычно, да, PHP-разработчики приходят в наш чат :)