Может, я отстал от жизни, но ни разу не видел, чтобы на фронт (надеюсь, вы не спутаете с фронтэндом) пихали что-то на Питоне.
WSGI/ASGI-серверы да, на Питоне, но опять же, не видел, чтобы их юзали без прослойки. Впрочем, опять же, может, отстал от жизни, и зумеры готовы выкидывать деньги на железо, лишь бы не писать на C.
NGINX - полноценный HTTP-сервер. Именно поэтому он хрен знает сколько используется как фронтовый HTTP-сервер. То, что он часто работает в режиме reverse proxy, не перестает делать его HTTP-сервером.
Про http.server вообще смешно. Это учебный/отладочный сервер. Вы его в прод пихаете? Серьезно?
Вы понимаете, чем HTTP сервер отличается от веб-фреймворка?
Вы понимаете, что перед сервисами Spotify стоят, как минимум, CDN/Edge, балансировщик, да еще набор API gateway ниже?
Вы понимаете, что прежде, чем до вашего фреймворка долетит запрос, он будет обработан несколькими скоростными слоями? Или вы думаете, что в проде берут голый Django и выставляют встроенным сервером для разработки наружу?
вы реально думаете что ни кто не использует питон в проде???
Может быть всякое, но почему-то я не видел ни одного живого Питоновского HTTP сервера в проде (конечно, имеется в виду не внутренняя тулза для 10 пользователей, а что-то нагруженное). А видел я их много.
Да, понятно, что и с HTTP сервером есть множество сценариев использования, но зачастую требуется производительный сервер. Как реальный пример - мы сейчас выжимаем из нашего S3 сервера каждую миллисекунду (собственные аллокаторы, CPU affinity для потоков, io_uring, кеширование всего, что можно и еще кучу всякого). Я боюсь представить, как бы он работал на Python.
Вспомнил, как реализовывал кольцевой буфер, чтобы гонять данные из ядра в юзерспейс.
Тоже один писатель, один читатель. Загвоздка была в том, что данные были строками разного размера, что сильно усложняло их обработку - из-за требования по производительности нужно было zero-copy, то есть парсить эти строки прямо на месте, в кольцевом буфере, и вот на краю буфера парсеру надо было перескакивать в начало буфера, как-то склеивать элемент с копированием в отдельный буфер. В общем долго, некрасиво.
В итоге все решил очень просто - замапил этот буфер и в ядре, и в юзерспейсе дважды подряд в памяти. В результате продолжение строки на границе буфера просто читалось в начале второй мапы, как будто никакой границы нет.
На C++, например. Дело только не в "на чем программировать", а "что разрабатывать". У меня, например, на рабочем ноуте крутятся тестовые ВМки с тяжелыми серверами облачных хранилищ. Иногда и 64 Гб бывает маловато.
Может, я отстал от жизни, но ни разу не видел, чтобы на фронт (надеюсь, вы не спутаете с фронтэндом) пихали что-то на Питоне.
WSGI/ASGI-серверы да, на Питоне, но опять же, не видел, чтобы их юзали без прослойки. Впрочем, опять же, может, отстал от жизни, и зумеры готовы выкидывать деньги на железо, лишь бы не писать на C.
NGINX - полноценный HTTP-сервер. Именно поэтому он хрен знает сколько используется как фронтовый HTTP-сервер. То, что он часто работает в режиме reverse proxy, не перестает делать его HTTP-сервером.
Про http.server вообще смешно. Это учебный/отладочный сервер. Вы его в прод пихаете? Серьезно?
Если про меня, то, естественно, под HTTP сервером я имел в виду именно HTTP сервер.
Нет, это вы меня извините.
Вы понимаете, чем HTTP сервер отличается от веб-фреймворка?
Вы понимаете, что перед сервисами Spotify стоят, как минимум, CDN/Edge, балансировщик, да еще набор API gateway ниже?
Вы понимаете, что прежде, чем до вашего фреймворка долетит запрос, он будет обработан несколькими скоростными слоями? Или вы думаете, что в проде берут голый Django и выставляют встроенным сервером для разработки наружу?
Не приписывайте мне то, чего я не говорил.
Может быть всякое, но почему-то я не видел ни одного живого Питоновского HTTP сервера в проде (конечно, имеется в виду не внутренняя тулза для 10 пользователей, а что-то нагруженное). А видел я их много.
Да, понятно, что и с HTTP сервером есть множество сценариев использования, но зачастую требуется производительный сервер. Как реальный пример - мы сейчас выжимаем из нашего S3 сервера каждую миллисекунду (собственные аллокаторы, CPU affinity для потоков, io_uring, кеширование всего, что можно и еще кучу всякого). Я боюсь представить, как бы он работал на Python.
И все те же техники есть, например, в Nginx.
Вот вообще не универсально.
Попробуйте бизнесу предложить, например, HTTP-сервер на Python.
Надо заранее регить домены gdeeda.ru и menyajtalony.ru.
Что-то хрень какая-то. Дофига жилья до 5000 находится в СФ.
Вот, например, 200 квадратов за 3600 в месяц - https://www.apartments.com/28-twin-peaks-blvd-san-francisco-ca-unit-a/26jz0s9/
То же самое:
$ g++ -std=c++20 a.cpp && ./a.out
18446744073709551603
Вспомнил, как реализовывал кольцевой буфер, чтобы гонять данные из ядра в юзерспейс.
Тоже один писатель, один читатель. Загвоздка была в том, что данные были строками разного размера, что сильно усложняло их обработку - из-за требования по производительности нужно было zero-copy, то есть парсить эти строки прямо на месте, в кольцевом буфере, и вот на краю буфера парсеру надо было перескакивать в начало буфера, как-то склеивать элемент с копированием в отдельный буфер. В общем долго, некрасиво.
В итоге все решил очень просто - замапил этот буфер и в ядре, и в юзерспейсе дважды подряд в памяти. В результате продолжение строки на границе буфера просто читалось в начале второй мапы, как будто никакой границы нет.
Вот тут совсем не понял. std::string_view просто сохранит указатель и длину строки.
std::string_view s = {"abc", 666666666};printf("%lu\n", s.size());output: 666666666
А ведь, кстати, да. Сделал мемчик с помощью ИИ, и тебе ко всяким "оскорблениям" и "фейкам" добавят отягчающее.
Ну вот, а выше про какую-то квалификацию сварщиков на уровне синьоров затирали. Тут не выше джуна варил.
Ваша?
Довести до абсурда можно все, что угодно.
Чувак постоянно велосипедит и думает, что все вокруг делают то же самое.
За 20+ лет работы нигде такого не видел, всегда начинают с поиска подходящей либы и делают свой велосипед, только если ничего подходящего не нашлось.
На C++, например. Дело только не в "на чем программировать", а "что разрабатывать". У меня, например, на рабочем ноуте крутятся тестовые ВМки с тяжелыми серверами облачных хранилищ. Иногда и 64 Гб бывает маловато.
Кстати, можно юзать подписку Клода:
result =subprocess.run(["claude", "-p", question,"--model", MODEL,"--append-system-prompt", SYSTEM],capture_output=True, text=True, )Что-то похожее было, только я еще проходил через Gentoo с настройкой ядра, компиляцией всего.
Мне кажется, все объясняется гораздо проще: сначала ты играешь с компьютером, потом тебе надоедает.
Да, я просто ps -A сделал, в конце видно два процесса.