Вот только проблема-то не ограничивается русским языком. Английский текст, сгенерированный ИИ, точно так же палится на раз. И, зачастую, в тех же местах: "не А, а Б", перебор с тире, неуместные художественные приемы.
Площадь поверхности Земли 510 072 000 км². Откинем половину на высокие широты (хотя, откидывать надо гораздо меньше с учетом двух группировок с 60° наклонением и 88°, но пусть). Получается, 292 спутника обслуживают 255 036 000 км². Площадь РФ 17 125 191км². Также не будем учитывать перехлесты между обслуживаемыми зонами спутников, а они обязательны, но тоже закроем глаза. В таком случае получается, что на всю страну будут в один момент работать 15 спутников.
Может, я отстал от жизни, но ни разу не видел, чтобы на фронт (надеюсь, вы не спутаете с фронтэндом) пихали что-то на Питоне.
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 Гб бывает маловато.
Вот только проблема-то не ограничивается русским языком. Английский текст, сгенерированный ИИ, точно так же палится на раз. И, зачастую, в тех же местах: "не А, а Б", перебор с тире, неуместные художественные приемы.
Вероятность через дуги?
Если все точки лежат в одной полуокружности, то центр не попадает в треугольник. Т.е, если самая длинная дуга больше 180.
Площадь поверхности Земли 510 072 000 км². Откинем половину на высокие широты (хотя, откидывать надо гораздо меньше с учетом двух группировок с 60° наклонением и 88°, но пусть).
Получается, 292 спутника обслуживают 255 036 000 км².
Площадь РФ 17 125 191км².
Также не будем учитывать перехлесты между обслуживаемыми зонами спутников, а они обязательны, но тоже закроем глаза.
В таком случае получается, что на всю страну будут в один момент работать 15 спутников.
Может, я отстал от жизни, но ни разу не видел, чтобы на фронт (надеюсь, вы не спутаете с фронтэндом) пихали что-то на Питоне.
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 Гб бывает маловато.