я сам долго выбирал стек. Смотрел в сторону php, node.js, python и др. и именно то, что можно легко разместить, определило выбор в сторону php. потому что node.js это надо vps, либо heroku a php на любом сервере есть
для новичка пощупать ноду надо выкинуть 2к денег, при том ему вряд ли надо писать онлайн чятики и прочее, ему статику для начала припилить на хтмл + чуть жс, что хватает примерно 200 рублей аренда хостинга с доменом на пол года, там же и пых и мускул
какое-то все слишком обзорное, ничего не понятно( у меня из описания марафона сложилось впечатление, что он подходит и для новичков, но он явно для тех, кто уже хорошо знаком с возможностями подобных систем. например, перед тем как использовать функцию, сначала бы понять что это за функция, из каких элементов состоит и когда можно/нельзя ее применять и т.д. то же и с ключевыми словами внутри функций. а так ощущение, будто ты просто смотришь как человек работает)) ну, может быть, я действительно описание марафона не так поняла. поищу что-то уровня бегиннер)))
Ну и ещё один коммент. Очередной косяк на 9:30))) В PHP типизация опционально-строгая и опционально-сильная.
1) Это означает, что проблемы с сопоставлением типов в LSP (ослабление/усиление по-Лискову, сопоставление сигнатур и прочее, что выводится на стадии компиляции константных выражений) выкидывают ошибки сразу при запуске. Тоже самое касается и с выводом алгебраических типов, когда дизъюнктивная форма типа int|string|null не может быть усилена в int|null, например.
2) А ещё это означает, что если разработчик хочет и проставляет типы — типизация становится сильной. А если разработчику надо отключить автоконвертацию в рамках единицы компиляции PHP (т.е. в файле), то ещё и статической.
P.S. Ну и define — это не совсем константа, т.к. на уровне языка определяется во время рантайма. А константа — это «const X» — она выводится на стадии компиляции.
О, ну вот ещё не правда (тайминг 8:30). PHP работает иначе =) 1) Исходный код переводится в опкод, всё тут верно. 2) Опкод помещается в mmap (MapViewOfFile) или System-V. Файлы используются только в самом крайнем случае, когда нет возможности хранить его в памяти. 3) Далее опкод оптимизируется и компилируется (всего 14 стадий, если не путаю), включая DCE, инлайнинг константных выражений и прочие приёмы. 4) Далее этот опкод (опционально), переводится в промежуточный ассемблерный код, используя LuaJIT IL 5) После этого происходит прогрев (если стоит дефолтный трейсинг флаг в конфиге), оптимизация (и деоптимизация в т.ч.) и частичная компиляция под текущее окружение (архитектура, ос и прочее). Т.е. полноценная частичная компиляция в машинный код из ассемблера в рантайме. 6) И после этого уже оно начинает воспроизводиться поверх Zend VM.
Т.е. схема работы PHP ничем не отличается от какой-нибудь Java, отличие только в том, что сам исполняемый код не в виде файла лежит, а в памяти. И php отвечает и за компиляцию и за исполнение (в отличие от отдельных бинарей javac + java).
Просили комментарии, пожалуйста: 1) Классический режим работы из под апача — это mod_php (ZTS), где процесс один, а каждый запрос создаёт отдельный тред. Схема довольно сложная, т.к. требует изоляции и виртуализации окружения (вроде env переменных), может сломаться обычным блокирующим sleep, жручая и неповоротливая. 2) Классический режим работы из под энжиникс — это fcgi (NTS), где есть мастер-процесс, делающий префорк и дополнительные форки процесса (если потребуется). Общение с мастером происходит через mmap, sys-v ipc или аналоги.
Но и в первом и втором случае есть шатдаун хендлер, который чистит за собой работу.
3) Есть варианты работы через RR, PPM, Swoole, Amp, React и прочие аналоги, которые держат в памяти весь бутстрап приложения, а остальное пропускают через эвентлуп (т.е. какой-нибудь нгинкс будет как реверс прокси на реалтайм приложение). В этом случае выделяется RR, который содержит две стадии работы: Бутстрап и запрос. В остальном отличий с fcgi режимом никаких. Контролировать GC так же не требуется, сам RR за тебя всё перезапустит если случится косяк. Остальные же работают в аналогичных режимах с существующими питонами, рубями, нодами и проч.
В любом случае общую память можно держать между «запросами», используя любой доступный IPC в системе. А если оно не доступно из-коробки, то PHP позволяет инлайнтить сишные хедеры (FFI), так что можно прокинуть апи (в основном cdecl и fastcall, thiscall сложно запилить из-за манглинга в экспортных функциях, ну или я рукожоп) на любые системные вызовы.
и именно то, что можно легко разместить, определило выбор в сторону php.
потому что node.js это надо vps, либо heroku
a php на любом сервере есть
1) Это означает, что проблемы с сопоставлением типов в LSP (ослабление/усиление по-Лискову, сопоставление сигнатур и прочее, что выводится на стадии компиляции константных выражений) выкидывают ошибки сразу при запуске. Тоже самое касается и с выводом алгебраических типов, когда дизъюнктивная форма типа int|string|null не может быть усилена в int|null, например.
2) А ещё это означает, что если разработчик хочет и проставляет типы — типизация становится сильной. А если разработчику надо отключить автоконвертацию в рамках единицы компиляции PHP (т.е. в файле), то ещё и статической.
P.S. Ну и define — это не совсем константа, т.к. на уровне языка определяется во время рантайма. А константа — это «const X» — она выводится на стадии компиляции.
1) Исходный код переводится в опкод, всё тут верно.
2) Опкод помещается в mmap (MapViewOfFile) или System-V. Файлы используются только в самом крайнем случае, когда нет возможности хранить его в памяти.
3) Далее опкод оптимизируется и компилируется (всего 14 стадий, если не путаю), включая DCE, инлайнинг константных выражений и прочие приёмы.
4) Далее этот опкод (опционально), переводится в промежуточный ассемблерный код, используя LuaJIT IL
5) После этого происходит прогрев (если стоит дефолтный трейсинг флаг в конфиге), оптимизация (и деоптимизация в т.ч.) и частичная компиляция под текущее окружение (архитектура, ос и прочее). Т.е. полноценная частичная компиляция в машинный код из ассемблера в рантайме.
6) И после этого уже оно начинает воспроизводиться поверх Zend VM.
Т.е. схема работы PHP ничем не отличается от какой-нибудь Java, отличие только в том, что сам исполняемый код не в виде файла лежит, а в памяти. И php отвечает и за компиляцию и за исполнение (в отличие от отдельных бинарей javac + java).
1) Классический режим работы из под апача — это mod_php (ZTS), где процесс один, а каждый запрос создаёт отдельный тред. Схема довольно сложная, т.к. требует изоляции и виртуализации окружения (вроде env переменных), может сломаться обычным блокирующим sleep, жручая и неповоротливая.
2) Классический режим работы из под энжиникс — это fcgi (NTS), где есть мастер-процесс, делающий префорк и дополнительные форки процесса (если потребуется). Общение с мастером происходит через mmap, sys-v ipc или аналоги.
Но и в первом и втором случае есть шатдаун хендлер, который чистит за собой работу.
3) Есть варианты работы через RR, PPM, Swoole, Amp, React и прочие аналоги, которые держат в памяти весь бутстрап приложения, а остальное пропускают через эвентлуп (т.е. какой-нибудь нгинкс будет как реверс прокси на реалтайм приложение). В этом случае выделяется RR, который содержит две стадии работы: Бутстрап и запрос. В остальном отличий с fcgi режимом никаких. Контролировать GC так же не требуется, сам RR за тебя всё перезапустит если случится косяк. Остальные же работают в аналогичных режимах с существующими питонами, рубями, нодами и проч.
В любом случае общую память можно держать между «запросами», используя любой доступный IPC в системе. А если оно не доступно из-коробки, то PHP позволяет инлайнтить сишные хедеры (FFI), так что можно прокинуть апи (в основном cdecl и fastcall, thiscall сложно запилить из-за манглинга в экспортных функциях, ну или я рукожоп) на любые системные вызовы.