В прод сторонние решения сложно встраивать + у нас сильная команда сишников.
Если что стороннее и применяется (а такое есть), то только в специфичных случаях.
Казалось бы, как раз таки на Go писать много логики проще и надежнее, чем на Python.
Вот для небольшой и выразительной математики да, лучше Python, из-за его сишных библиотек и особенностей синтаксиса. Но что-то большое и сложное на нем писать странно.
Здесь одинаковый тип элементов, как выше и написали.
И из не приведенных примеров, в Go нельзя без явного приведения типов смешивать очень близкие типы, например сложить байт и инт, или знаковое с беззнаковым.
Это непривычно первое время, но защищает от ошибок и позволяет делать удобные вещи типа 5*time.Second (имеющий тип).
Все же считаю Go языком со строгой типизацией, в отличие от C.
Сравнивать общее число серверов довольно странно, у нас их так много не в последнюю очередь потому, что у нас ОЧЕНЬ много пользовательских файлов.
А если сравнивать именно нагрузку от пользовательских запросов на web/api (и эффективную их обработку), то я не знаю что там у них, увы.
Что-то мне кажется, оно будет заметнее медленнее чистого Go из-за оверхеда cgo. Либо уносить в плюсовую часть практически всё, но это совсем уже странное решение. Go же берут не в последнюю очередь как раз из-за его рантайма и многопоточной разработки, а тут мы того лишаемся по сути.
Но ведь 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.
Сейчас у нас совсем по другому относятся к выкладыванию чего-либо. Плюс сил и желания поддерживать несопоставимо больше.
Пользоваться или нет — тут уже выбор каждого. Можно, например, подождать и посмотреть :)
А вот брать kphp, если он, представим себе, будет повторно выложен, будет ли кто? Кто есть из крупных проектов с подобными нагрузками и крепко сидящих на php, кто не мигрирует на какой-то другой ЯП, либо написал собственную вундервафлю?
Юра несколько раз говорил, что у нас очень много уже написанного кода на PHP, и от него никуда не деться. Это данность, с которой приходится уживаться. Там, где мы можем не использовать PHP, мы его и не используем. У нас много кода на C и C++, также прилично на Go и python (последний по наслышке).
Что касается той выкладки kphp в паблик. И тут уже мое личное мнение.
Это было сделано зря, но не нам уже судить это решение, тем более что с тех пор команда сильно поменялась. Сейчас снова выкладывать kphp и поддерживать этот вариант у нас не готовы. Не в последнюю очередь потому, что мы гораздо внимательнее относимся к публичной деятельности и опенсорсу в частности. Это долгоиграющая ответственность, а не разовый шаг. Что мы можем и готовы публиковать в опенсорс и поддерживать — мы это делаем. Линтер — это один из таких примеров. KPHP, к сожалению ?, сейчас не такой проект.
Повторюсь, это все мое личное мнение.
В KPHP нет синтаксиса, отсутствующего в обычном PHP, т.к. это потребовало бы введение поддержки во всех IDE и редакторах, которые используются в нашей команде. На это мы пока не готовы.
Так что единственное отличие (ну за некоторыми синтаксически совместимыми особенностями): поддержка особых phpdoc, которые помогают kphp лучше понимать намерения разработчика и генерить более правильный и нативный C++ код. Именно большее понимание кода и вывод типов (даже довольно сложных) позволяет дать C++ компилятору код, который будет скомпилен более оптимально. За счет этого и выигрыш по скорости, причем существенный.
Мы прикладываем много усилий, чтобы типы выводились более точно. И тут линтер — один из инструментов. Но это не единственное его предназначение.
Будет ли специализация на около Java тематике, или это все же общая конференция без предпочтений?
Смена типа поля скорее не возможна, чем широко практикуется. Добавляется поле, да.
Если что стороннее и применяется (а такое есть), то только в специфичных случаях.
Вот для небольшой и выразительной математики да, лучше Python, из-за его сишных библиотек и особенностей синтаксиса. Но что-то большое и сложное на нем писать странно.
И из не приведенных примеров, в Go нельзя без явного приведения типов смешивать очень близкие типы, например сложить байт и инт, или знаковое с беззнаковым.
Это непривычно первое время, но защищает от ошибок и позволяет делать удобные вещи типа 5*time.Second (имеющий тип).
Все же считаю Go языком со строгой типизацией, в отличие от C.
P.S. uWS тоже проверить не смог, но у меня она просто не собирается.
А если сравнивать именно нагрузку от пользовательских запросов на web/api (и эффективную их обработку), то я не знаю что там у них, увы.
Так к тому времени уже была куча кода на PHP, которую было не переписать, а в скорость работы уже уперлись.
Ну, монолит — это не лучшая архитектура при развитии проекта и росте команды. Но он удобен на первых этапах. Так что в целом нормально.
Ну тут опять же про то, что у нас уже была куча кода на PHP.
Все так, ООП код по замерам того времени выполнялся медленее, чем на функциях. Массовое использование классов php'шных у нас началось не так давно, особенно после того, как kphp научился транслировать php классы в плюсовые структуры без какого-либо ООП'шного оверхеда.
Тут важно вспомнить, что переход на KPHP у нас начался где-то во времена PHP 5.3. Но уже и к тому моменту кода было прилично уже написано.
А тут все просто: у нас монолит. Если собирается специфическая сборка, она вкомпиливает в себя весь достижимый код из указанной точки входа. Соответственно, добавление любого функционала сайту — это добавление PHP кода в этот же монолит.
Последнее время мы занимаемся уменьшением связности и некоторым техдолгом, чтобы что-то с этим сделать.
А если мы можем сделать что-то обособляемое, то как раз и пишем это на Go или Python. Есть небольшие ex-PHP/Python штуки, которые мы переписали на Go: сбор ошибок, демоночки на региональных кешах, обработка анонсируемых префиксов в тех же регионах… Некоторые сложные вычислительные задачи наши C/C++ разработчики оформляют в виде демонов/сервисов.
Так что мы не пишем все на PHP и кайфуем от этого :)
Ну, у нас есть код в обособленных командах, например админы или датамайнеры. Там используются ЯП, которые им больше нравятся. Ну и репы у них свои, а общение через общие прокси до движков.
И после вышенаписанного совершенно не понятно, зачем нам Java. Где мы завязаны на PHP — там будет KPHP, в остальных нагруженных местах — C++ и Go.
Пользоваться или нет — тут уже выбор каждого. Можно, например, подождать и посмотреть :)
А вот брать kphp, если он, представим себе, будет повторно выложен, будет ли кто? Кто есть из крупных проектов с подобными нагрузками и крепко сидящих на php, кто не мигрирует на какой-то другой ЯП, либо написал собственную вундервафлю?
Это было сделано зря, но не нам уже судить это решение, тем более что с тех пор команда сильно поменялась. Сейчас снова выкладывать kphp и поддерживать этот вариант у нас не готовы. Не в последнюю очередь потому, что мы гораздо внимательнее относимся к публичной деятельности и опенсорсу в частности. Это долгоиграющая ответственность, а не разовый шаг. Что мы можем и готовы публиковать в опенсорс и поддерживать — мы это делаем. Линтер — это один из таких примеров. KPHP, к сожалению ?, сейчас не такой проект.
Повторюсь, это все мое личное мнение.
В KPHP нет синтаксиса, отсутствующего в обычном PHP, т.к. это потребовало бы введение поддержки во всех IDE и редакторах, которые используются в нашей команде. На это мы пока не готовы.
Так что единственное отличие (ну за некоторыми синтаксически совместимыми особенностями): поддержка особых phpdoc, которые помогают kphp лучше понимать намерения разработчика и генерить более правильный и нативный C++ код. Именно большее понимание кода и вывод типов (даже довольно сложных) позволяет дать C++ компилятору код, который будет скомпилен более оптимально. За счет этого и выигрыш по скорости, причем существенный.
Мы прикладываем много усилий, чтобы типы выводились более точно. И тут линтер — один из инструментов. Но это не единственное его предназначение.