Что касается той выкладки kphp в паблик. И тут уже мое личное мнение.
Это было сделано зря, но не нам уже судить это решение, тем более что с тех пор команда сильно поменялась. Сейчас снова выкладывать kphp и поддерживать этот вариант у нас не готовы. Не в последнюю очередь потому, что мы гораздо внимательнее относимся к публичной деятельности и опенсорсу в частности. Это долгоиграющая ответственность, а не разовый шаг. Что мы можем и готовы публиковать в опенсорс и поддерживать — мы это делаем. Линтер — это один из таких примеров. KPHP, к сожалению ?, сейчас не такой проект.
Повторюсь, это все мое личное мнение.
В KPHP нет синтаксиса, отсутствующего в обычном PHP, т.к. это потребовало бы введение поддержки во всех IDE и редакторах, которые используются в нашей команде. На это мы пока не готовы.
Так что единственное отличие (ну за некоторыми синтаксически совместимыми особенностями): поддержка особых phpdoc, которые помогают kphp лучше понимать намерения разработчика и генерить более правильный и нативный C++ код. Именно большее понимание кода и вывод типов (даже довольно сложных) позволяет дать C++ компилятору код, который будет скомпилен более оптимально. За счет этого и выигрыш по скорости, причем существенный.
Мы прикладываем много усилий, чтобы типы выводились более точно. И тут линтер — один из инструментов. Но это не единственное его предназначение.
Этот файл лежит в архиве рядом с *.json файлами. Из него (его первой строки) нужно получать время генерации датасета, чтобы запрос с today/now работали корректно.
После запуска контейнера в папке /tmp/data будет доступен файл data.zip с архивированными «боевыми» данными (примерно 10 MB данных для предварительного и 1 GB для полного обстрела). Обратите внимание, что каталог /tmp/data доступен только для чтения, поэтому решение должно загружать архив в ОЗУ для обработки. В самом архиве будут лежать файлы с названиями вида «accounts_<номер файла>.json». Внутри таких файлов — валидные данные в формате JSON.
Это скорее как «слепок» на тот момент, который приведен скорее для желающих ознакомиться.
С тех пор развитие убежало далеко вперед, но пока, увы, не до планов по актуализации и поддержанию публичной версии.
И я конкретно про ВК. Разных типов баз/движов несколько десятков видов. Каждый делается под конкретные задачи + оптимально встраивается в общую инфраструктуру.
Вот тут автор уверяет, что еще в 2015 поднял на node.js на амазоновском EC2 600-620к вебсокет соединений. Пусть и с небольшими подпорками, но, видимо, реально.
Да и как раз на проде сложно представить реальную задачу, где Erlang составил бы сильную конкуренцию Go. Разве что какие очень развесистые деревья или подобные структуры.
Это было сделано зря, но не нам уже судить это решение, тем более что с тех пор команда сильно поменялась. Сейчас снова выкладывать kphp и поддерживать этот вариант у нас не готовы. Не в последнюю очередь потому, что мы гораздо внимательнее относимся к публичной деятельности и опенсорсу в частности. Это долгоиграющая ответственность, а не разовый шаг. Что мы можем и готовы публиковать в опенсорс и поддерживать — мы это делаем. Линтер — это один из таких примеров. KPHP, к сожалению ?, сейчас не такой проект.
Повторюсь, это все мое личное мнение.
В KPHP нет синтаксиса, отсутствующего в обычном PHP, т.к. это потребовало бы введение поддержки во всех IDE и редакторах, которые используются в нашей команде. На это мы пока не готовы.
Так что единственное отличие (ну за некоторыми синтаксически совместимыми особенностями): поддержка особых phpdoc, которые помогают kphp лучше понимать намерения разработчика и генерить более правильный и нативный C++ код. Именно большее понимание кода и вывод типов (даже довольно сложных) позволяет дать C++ компилятору код, который будет скомпилен более оптимально. За счет этого и выигрыш по скорости, причем существенный.
Мы прикладываем много усилий, чтобы типы выводились более точно. И тут линтер — один из инструментов. Но это не единственное его предназначение.
Пример такого файла можно взять тут highloadcup.ru/ru/round/3 (раздел «Тестовые данные»)
С тех пор развитие убежало далеко вперед, но пока, увы, не до планов по актуализации и поддержанию публичной версии.
Сам я в ноде практически 0, так что хз.
Но в любом случае такие технические статьи на любом ЯП интересно почитать.
Да и как раз на проде сложно представить реальную задачу, где Erlang составил бы сильную конкуренцию Go. Разве что какие очень развесистые деревья или подобные структуры.
Так себе доводы.