NEW BOT Телеграм, страница

Channel created

15:53

Про эволюцию языков с точки зрения серверной разработки:

"...Ну смотри, если ты сервера пишешь, то обычно в рамках запроса у тебя будет дофига IO (запросы к базе, запросы к сторонним API и т.п.). Но тебе нужно как-то утилизировать процессор в это же время, обсулживая других клиентов. И у тебя опции:

- PHP - никаких опций, только увеличивая количесто процессов PHP интерпретатора в пуле fpm (т.е. воркеров). Каждый новый процесс будет полностью блокироваться на вызовах IO и в любой момент времени ты не сможешь обсулживать больше скажем 50 HTTP запросов, зависших на IO.
- олдскул Python та же картина, но обычно с потоками, вместо процеесов в качестве воркеров. Но можно хакнуть его с помощью gevent и перестать использовать потоки ОС, а начать использовать “зеленые” потоки и асихронный IO на самом деле. Тогда можно число зависших на IO запросов увеличить до тысяч, потому что зеленые потоки на пару порядок легче потоков ОС.

В обоих этих случаях (PHP, Python, Python + gevent) твой код будет выглядеть как обычный “сихронный код”, без всяких колбеков повсюду или await-ов.

Потом начинается магия - в питоне начинают писать с использованием callback-based стиля (всякие twisted и tornado). Т.е. у тебя всего один процесс, вместо десятков воркеров. Весь IO асинхронный. Каждый вызов "условного" read/write() принимает callback функцию, которую он вызовет при получении результата IO и тут же возвращает управление. Код больше не выглядит “последовательным/синхронным”, его становится труднее понимать. Альтернативный, но не более понятный подход - использовать модный asyncio, где ты пишешь response = await http.GET(‘https://ya.ru’). И код типа все еще выкглядит синхронно (т.е. без колбеков), но на самом деле ты должен париться, когда и кому вернется управление после await.

И тут припирается JavaScript nodejs и говорит, что она асихронная их коробки. Все кидаются на ней писать, потому что типа она решает эти проблемы с IO, но… Там все те же колбеки и всего один процесс, и нечитаемый код. Даже несмотря на то, что из этого "всего один процесс" не может быть проблем с race condition. Потом в JavaScript добавляют async/await синтаксический сахар, код становится “линейным” (без колбеков). Тот же путь, что и у питона, короче.

А вот в Go очень интересным путем пошли. Они придумали горутины (которые на самом деле корутины). И ты запускаешь свою прогу на Go, это один процесс. Но под капотом она может запустить до GO_MAX_PROCESS процессов (обычно по числу ядер). Код в твоем основном процессе выполняется последовательно и синхронно. Но когда ты пишешь go foo(), запускается горутина и тут же возвращает управление твоему основному процессу. Скорее всего она будет выполняться в новом процессе. И если все твои горутины не делают IO, а считают цифры, то ты очень быстро съешь все ядра своего CPU и будешь "играть в ОСь", заменяя ее планировщик планировщиком из Go рантайма. Но вот если твои горутины подвисают на IO, то ты можешь запускать десятки тысяч горутин (фактически зеленых потоков). И код внутри каждой горутины выглядит последовательно и синхронно (и так оно и есть). И ты все еще пишешь в "классическом стиле" (т.е. без колбеков), но при этом можешь очень легко средствами языка утилизировать весь свой CPU. Минусы - race condition, ты можешь из разных корутин модифицировать shared данные и никто тебе по рукам не надает. Но нужно просто channel использовать, а не писать в shared данные )) Т.е. Go - это что-то среднее между классическим воркеро-ориентированном способом параллелить задачи и асинхронно-колбеко-ориентированным."

174 views16:13