Да, Python медленный, но меня это не волнует

https://hackernoon.com/yes-python-is-slow-and-i-dont-care-13763980b5a1
  • Перевод
Разговоры о снижении производительности ради продуктивности.


Я беру паузу в моём обсуждении asyncio в Python, чтобы поговорить о скорости Python. Позвольте представиться, я — ярый поклонник Python, и использую его везде, где только удаётся. Одна из причин, почему люди выступают против этого языка, — то, что он медленный. Некоторые отказываются даже попробовать на нём поработать лишь из-за того, что «X быстрее». Вот мои мысли на этот счёт.

Производительность более не важна


Раньше программы выполнялись очень долго. Ресурсы процессора и памяти были дорогими, и время работы было важным показателем. А уж сколько платили за электричество! Однако, те времена давно прошли, потому что главное правило гласит:
Оптимизируйте использование своих самых дорогих ресурсов.
Исторически самым дорогим было процессорное время. Именно к этому подводят при изучению информатики, фокусируясь на эффективности различных алгоритмов. Увы, это уже не так — железо сейчас дёшево как никогда, а вслед за ним и время выполнения становится всё дешевле. Самым дорогим же становится время сотрудника, то есть вас. Гораздо важнее решить задачу, нежели ускорить выполнение программы. Повторюсь для тех, кто просто пролистывает статью:
Гораздо важнее решить задачу, нежели ускорить выполнение программы.

Вы можете возразить: «В моей компании заботятся о скорости. Я создаю веб-приложение, в котором все ответы приходят меньше, чем за x миллисекунд» или «от нас уходили клиенты, потому что считали наше приложение слишком медленным». Я не говорю, что скорость работы не важна совсем, я хочу лишь сказать, что она перестала быть самой важной; это уже не самый дорогой ваш ресурс.



Скорость — единственная вещь, которая имеет значение.


Когда вы употребляете слово «скорость» в контексте программирования, скорей всего вы подразумеваете производительность CPU. Но когда ваш CEO употребляет его применительно к программированию, то он подразумевает скорость бизнеса. Самая главная метрика — время выхода на рынок. В конечном счёте неважно насколько быстро работают ваши продукты, не важно на каком языке программирования они написаны или сколько требуется ресурсов для их работы. Единственная вещь, которая заставит вашу компанию выжить или умереть, — это время выхода на рынок. Я говорю больше не о том, насколько быстро идея начнёт приносить доход, а о том, как быстро вы сможете выпустить первую версию продукта. Единственный способ выжить в бизнесе — развиваться быстрее, чем конкуренты. Неважно, сколько у вас идей, если конкуренты реализуют их быстрее. Вы должны быть первыми на рынке, ну или как минимум не отставать. Чуть затормозитесь — и погибните.
Единственный способ выжить в бизнесе — развиваться быстрее, чем конкуренты.

Поговорим о микросервисах


Крупные компании, такие как Amazon, Google или Netflix, понимают важность быстрого развития. Они специально строят свой бизнес так, чтобы быстро вводить инновации. Микросервисы помогают им в этом. Эта статья не имеет никакого отношения к тому, следует ли вам строить на них свою архитектуру, но, по крайней мере, согласитесь с тем, что Amazon и Google должны их использовать. Микросервисы медленны по своей сути. Сама их концепция заключается в том, чтобы использовать сетевые вызовы. Иными словами, вместо вызова функции вы отправляетесь гулять по сети. Что может быть хуже с точки зрения производительности?! Сетевые вызовы очень медленны по сравнению с тактами процессора. Однако, большие компании по-прежнему предпочитают строить архитектуру на основе микросервисов. Я действительно не знаю, что может быть медленнее. Самый большой минус такого подхода — производительность, в то время как плюсом будет время выхода на рынок. Создавая команды вокруг небольших проектов и кодовых баз, компания может проводить итерации и вводить инновации намного быстрее. Мы видим, что даже очень крупные компании заботятся о времени выхода на рынок, а не только стартапы.

Процессор не является вашим узким местом


Если вы пишете сетевое приложение, такое как веб-сервер, скорее всего, процессор не является узким местом вашего приложения. В процессе обработки запроса будет сделано несколько сетевых обращений, например, к базе данных или кешу. Эти сервера могут быть сколь угодно быстрыми, но всё упрётся в скорость передачи данных по сети. Вот действительно классная статья, в которой сравнивается время выполнения каждой операции. В ней автор считает за один такт процессора одну секунду. В таком случае запрос из Калифорнии в Нью-Йорк растянется на 4 года. Вот такая вот сеть медленная. Для примерных расчётов предположим, что передача данных по сети внутри датацентра занимает около 3 мс, что эквивалентно 3 месяцам по нашей шкале отсчёта. Теперь возьмём программу, которая нагружает CPU. Допустим, ей надо 100 000 циклов, чтобы обработать один вызов, это будет эквивалентно 1 дню. Предположим, что мы пишем на языке, который в 5 раз медленнее — это займёт 5 дней. Для тех, кто готов ждать 3 месяца, разница в 4 дня уже не так важна.

В конечном счёте то, что python медленный, уже не имеет значения. Скорость языка (или процессорного времени) почти никогда не является проблемой. Google описал это в своём исследовании. А там, между прочим, говорится о разработке высокопроизводительной системы. В заключении приходят к следующему выводу:
Решение использовать интерпретируемый язык программирования в высокопроизводительных приложениях может быть парадоксальным, но мы столкнулись с тем, что CPU редко когда является сдерживающим фактором; выразительность языка означает, что большинство программ невелики и большую часть времени тратят на ввод-вывод, а не на собственный код. Более того, гибкость интерпретируемой реализации была полезной, как в простоте экспериментов на лингвистическом уровне, так и в предоставлении нам возможности исследовать способы распределения вычислений на многих машинах.

Другими словами:
CPU редко когда является сдерживающим фактором.


Что, если мы всё-таки упираемся в CPU?


Что насчёт таких аргументов: «Всё это прекрасно, но что, если CPU становится узким местом и это начинает сказываться на производительности?» или «Язык x менее требователен к железу, нежели y»? Они тоже имеют место быть, однако вы можете масштабировать приложение горизонтально бесконечно. Просто добавьте серверов, и сервис будет работать быстрее :) Без сомнения, Python более требователен к железу, чем тот же C, но стоимость нового сервера гораздо меньше стоимости вашего времени. То есть дешевле будет докупить ресурсов, а не бросаться каждый раз что-то оптимизировать.



Так что, Python быстрый?


На протяжении всей статьи я твердил, что самое важное — время разработчика. Таким образом, остается открытым вопрос: быстрее ли Python языка X во время разработки? Смешно, но я, Google и кое-кто ещё, могут подтвердить насколько продуктивен Python. Он скрывает так много вещей от вас, помогая сосредоточиться на основной вашей задаче и не отвлекаясь на всякие мелочи. Давайте рассмотрим некоторые примеры из жизни.

По большей части все споры вокруг производительности Python скатываются к сравнению динамической и статической типизации. Думаю, все согласятся, что статически типизированные языки менее продуктивны, но на всякий случай вот хорошая статья, объясняющая почему. Что касается непосредственно Python, то есть хороший отчёт об исследовании, в котором рассматривается, сколько времени потребовалось, чтобы написать код для обработки строк на разных языках.


В представленном выше исследовании Python более чем в 2 раза продуктивнее Java. Многие другие также языки программирования дают похожий результат. Rosetta Code провёл довольно обширное исследование различий изучения языков программирования. В статье они сравнивают python с другими интерпретируемыми языками и заявляют:
Python, в целом, наиболее краток, даже в сравнении с функциональными языками (в среднем в 1,2-1,6 раза короче).

По-видимому, в реализации на Python будет как правило меньше строк кода, чем на каком-либо другом языке. Это может показаться ужасной метрикой, однако несколько исследований, в том числе и упомянутых выше, показывают, что время, затраченное на каждую строку кода, примерно одинаково на каждом языке. Таким образом, чем меньше строк кода, тем больше продуктивность. Даже сам codinghorror (программист на C#) написал статью о том, что Python более продуктивен.

Я думаю, будет справедливо сказать, что Python более продуктивен, чем многие другие языки программирования. В основном это связано с тем, что он поставляется «с батарейками», а также имеет множество сторонних библиотек на все случаи жизни. Вот небольшая статья, сравнивающая Python и X. Если вы мне не верите, можете сами убедиться насколько этот язык программирования прост и удобен. Вот ваша первая программа:

import __hello__

Но что, если скорость действительно важна?


Мои рассуждения выше могли сложить мнение, что оптимизация и скорость выполнения программы вообще не имеют значения. Во многих случаях это не так. Например, у вас есть веб-приложение и некоторый endpoint, который уж очень тормозит. У вас могут быть даже определённые требования на этот счёт. Наш пример строится на некоторых предположениях:

  1. есть некоторый endpoint, который выполняется медленно
  2. есть некоторые метрики, определяющие насколько медленными может быть обработка запросов

Мы не будем заниматься микро-оптимизацией всего приложения. Всё должно быть «достаточно быстро». Ваши пользователи могут заметить, если обработка запроса занимает секунды, но они никогда не заметят разницу между 35 мс и 25 мс. Вам нужно лишь сделать приложение «достаточно хорошим».

Дисклеймер
Должен заметить, что есть некоторые приложения, которые обрабатывают данные в реальном времени, которые нуждаются в микрооптимизации, и каждая миллисекунда имеет значение. Но это скорее исключение, чем правило.

Чтобы понять как оптимизировать, мы должны сначала понять что именно надо оптимизировать. В конце концов:
Любые улучшения, сделанные где-либо помимо узкого места, являются иллюзией. — Джин Ким.

Если оптимизация не устраняет узкого места приложения, то вы просто потратите впустую своё время и не решите реальную проблему. Вы не должны продолжать разработку, пока не исправите тормоза. Если вы пытаетесь оптимизировать нечто, не зная конкретно что, то вряд ли результат вас удовлетворит. Это и называется «преждевременной оптимизацией» — улучшение производительности без каких-либо метрик. Д. Кнуту часто приписывают следующую цитату, хотя он утверждает, что она не его:
Преждевременная оптимизация — корень всех зол.
Если быть точным, то более полная цитата:
Мы должны забыть об эффективности, скажем, на 97% времени: преждевременная оптимизация — корень всех зол. Однако мы не должны упускать наши возможности в этих критических 3%.

Другими словами, здесь говорится, что большую часть времени вам не нужно думать об оптимизации. Код и так хорош :) А в случае, когда это не так, нужно переписать не более 3% Вас никто не похвалит, если вы сделаете обработку запроса на несколько наносекунд быстрее. Оптимизируйте то, что поддаётся измерению.

Преждевременная оптимизация, как правило, заключается в вызове более быстрых методов <прим пер. видимо, подразумеваются ассемблерные вставки> или использовании специфичных структур данных из-за их внутренней реализации. В университете нас учили, что если два алгоритма имеют одну асимптотику Big-O, то они эквивалентны. Даже если один из них в 2 раза медленнее. Компьютеры сейчас настолько быстры, что вычислительную сложность пора измерять на большом количестве данных. То есть, если у вас есть две функции O(log n), но одна в два раза медленнее другой, то это не имеет большого значения. По мере увеличения размера данных они обе начинают показывать примерно одно и то же время выполнения. Вот почему преждевременная оптимизация — это корень всего зла; Это тратит наше время и практически никогда не помогает нашей общей производительности.

В терминах Big-O все языки программирования имеют сложность O(n), где n — кол-во строк кода или инструкций. Не имеет значения, насколько медленным будет язык или его виртуальная машина — все они имеют общую асимптоту. <прим. пер. автор имеет ввиду, что даже если сейчас язык X в два раза медленнее Y, то в будущем после оптимизаций они будут примерно равны по скорости> В соответствии с этим рассуждением можно сказать, что «быстрый» язык программирования всего лишь преждевременно оптимизированный, причём непонятно по каким метрикам.



Оптимизируя Python


Что мне нравится в Python, так это то, что он позволяет оптимизировать небольшой участок кода за раз. Допустим, у вас есть метод на Python, который вы считаете своим узким местом. Вы оптимизировали его несколько раз, возможно, следуя советам отсюда и отсюда, и теперь пришли к выводу, что уже сам Python является узким местом. Но он имеет возможность вызова кода на C, а это означает, что вы можете переписать этот метод на C, чтобы уменьшить проблему с производительностью. Вы без проблем можете использовать этот метод вместе с остальным кодом.

Это позволяет писать хорошо оптимизированные методы узких мест на любом языке, который компилируется в ассемблерный код, то есть вы продолжаете писать на Python большую часть времени и переходите к низкоуровневому программированию лишь вам это действительно нужно.

Существует также язык Cython, который является надмножеством Python. Он представляет из себя смесь с типизированным C. Любой код Python является также валидным кодом и на Cython, который транслируется в C. Вы можете смешивать типы C и утиную типизацию. Используя Cython, вы получаете прирост производительности только в узком месте, не переписывая весь остальной код. Так делает, например, EVE Online. Эта MMoRPG использует только Python и Cython для всего стека, проводя оптимизацию только там, где это требуется. Кроме того, есть и другие способы. Например, PyPy — реализация JIT Python, которая может дать вам значительное ускорение во время выполнения долгоживущих приложений (например, веб-сервера), просто путем замены CPython (реализация по умолчанию) на PyPy.



Итак, основные моменты:

  • оптимизируйте использование самого дорогого ресурса — то есть вас, а не компьютера;
  • выбирайте язык/фреймворк/архитектуру, которая позволяет вам разрабатывать продукты как можно быстрее. Не стоит выбирать язык программирования лишь потому, что программы на нём работают быстро;
  • если у вас проблемы с производительностью — определите, где именно;
  • и, скорее всего, это не ресурсы процессора или Python;
  • если это всё же Python (и вы уже оптимизировали алгоритм), реализуйте проблемное место на Cython/C;
  • и побыстрее возвращайтесь к основной работе.

Спасибо за внимание!
Поделиться публикацией
AdBlock похитил этот баннер, но баннеры не зубы — отрастут

Подробнее
Реклама
Комментарии 213
  • +10
    Скорость это не только скорость, но и максимальная нагрузка на сервис. 30 rps или 6000rps с ноды. А значит меньше серверов, меньше поддержки, меньше трат и немаловажная фича, которую бизнес хорошо понимает: возможность расширяться в N раз, не сталкиваясь с поблемами со стороны сервисов.
    • +4
      Да, автор на это тоже обращает внимание и приходит к выводу, что дешевле будет доставить ещё один сервер, чем тратить время программиста. Ну, по крайней мере там :) Я не думаю, что это можно и нужно делать бесконечно, но гораздо проще будет провести оптимизацию комплексно в спокойное время.
      • +7
        Все зависит от нагрузки, 1 сервер + 1 сервер может и не пробелма, а вот если количество растет, типа 10 серверов вместо 5, или когда объемы доходят до сотен. 50 серверов или 100 серверов, есть ведь разница.

        А скорость разработки — это не язык, а года существования компании или года практики разработчика, у которых все уже готово и остаются только " частные случаи". Сегодня back-end совсем упростился, в компаниях на 5 front-end 1 back end, потому поднять базу данных и API для CRM — нужен 1 день, ну еще парочка на частные случае или если есть какие-то особенные вычесления, а вот на Front-end постоянно уходит огромное количество времени.
        • –6
          Чем больше серверов, тем больше нужно админов, тем выше капитализация компании. Так работает бизнес, так работает экономика… Глядишь и унылый говно-чат уже проходит многомиллиардное IPO :D

          Именно поэтому бизнес так любит python.
          • +1
            сомневаюсь что бизнес любит капитализацию в ущерб прибыли
            • –7
              посмотри на твиттер
              • +4
                Он прав. Мне как-то объяснили этот момент тоже (речь идет о компании NetCracker). Я приходил каждый раз с рационализаторскими предложениями. Каждый раз мне объясняли, что на это нет времени. Это конечно же неправда — эти люди умеют считать деньги.
                А правду мне объяснили потом в курилке: все рационализаторские предложения приводят к сокращению штата. А сокращение штата приводит к проигрышу тендеров у крупных корпораций, для которых маленькая компания == компания однодневка.
                Другими словами, сокращение штата — потеря денег, если принять во внимание не только технические, а все особенности бизнеса.
                NetCracker до сихпор собирает Java-код руками (даже есть целый отдел «релиз-инженеров»). Результат превзошел все ожидания. Сегодня это крупнейшая в своем рынке компания…
            • 0
              Еще ведь и от задачи зависит. Скажем на сервере крутится вычислительное ядро, которое реализует сверх сложную с алгоритмической точки зрения задачу. И запросто может так сложиться, что добавление любого количества серверов не даст результата.
            • +8
              Сказать «дешевле поставить еще один сервер» можно только тогда, когда мы сравним траты в обоих случаях, то есть данное утверждение надо подкрепить цифрами и показать, масштабируется ли оно, то есть справедливо ли по прежнему будет сказать «дешевле поставить еще 3000 серверов, чем иметь 200 и научить программистов один раз и навсегда писать более качественный и шустрый код». Мне не кажется, что ответ так однозначен, как преподносится в статье. Особенно с точки зрения бизнеса.
              Как говорится «скорость — это тоже фича».
              • +1
                Да, кстати, цены можно обсудить. m3.medium (1xCPU, 4Gb) стоит $350 за год, то есть ~20 000 руб. Насколько я знаю, это месяц работы джуниора (вряд ли ему кто-то доверит такую задачу) или 4 дня мидла. А у него задачи могут быть расписаны на недели вперёд.
                Смотрите на это как на технический долг — да, мы сейчас ставим более дорогое железо, но в будущем эту ситуацию обязательно исправим.
                • +4
                  А когда речь про 1000 серверов и не medium? Я про то, что обобщать по меньшей мере странно. Что может быть верно для небьльшого или среднего проекта, то оказывается фантастическими убытками на больших нагрузках, когда число тех же серверов давно идет на сотни и тысячи. Дешевле несколько заняться бизнес-процессами и устроить обучение в расках компании, заодно с нагрузочным приемочным тестированием. Как итог иметь разовые вложения в программистов против регулярных плат за впустую используемые мощности.
                  • 0
                    Вложения в программистов не бывают разовыми — любой код приходится сопровождать и развивать, чтобы он не умер. Если код меньше, его дешевле поддерживать. Оптимизированный код очень часто сложнее для понимания. Времена нынче таковы, что все быстро меняется и время жизни кода стало существенно меньше, чем раньше. Пока вы доведете до ума хорошо оптимизированный код, его, возможно, уже надо будет переделывать.
                  • –1
                    Исправление этой сетуации, если оно упрется вдруг в язык, на котором написана система, может похоронить. Долг долгу рознь. Если у нас спокойный сублинейный рост по мощности серверов, то можно такой долг и запланировать, когда и как его возвращать. А если рост в разы как минимум? Смогут ли программисты решить проблему такого «долга», когда требования растут от месяца к месяцу?
                    Я вновь возвращаюсь к вопросу, что обозначенное выше утверждение справедливо только в определенных рамках касательно размера бизнеса и размера нагрузки.
                    • 0
                      Еще момент про который часто забывают. Ваш сервис не застыл. Его надо развивать. Постоянно вносить изменения…
                    • +4
                      Люто бешенно плюсую.
                      Мало того, что нужно учесть цифры в разных перспективах (за год, за 5 лет, за 10), так я заметил и еще одну особенность — люди иногда пересказывают догму «программист дороже железа» без привязки к реальности.
                      Они не учитывают, что догма эта родилась в западных странах, где цены на железо такие же, как в России + куча скидок и отсроченных платежей, а зарплаты в 10 раз выше. Для России, где разработчики получают $1-2k нужно еще много раз пересчитать и убедиться, что догма не обратная. И опять же: с ростом экономики России нужно снова и снова ее пересчитывать.
                    • +1
                      возникает вопрос: что дешевле — платить квалифицированному по части оптимизаций специалисту или покупать новый сервер?
                      • +1

                        Автор как-то упускает/замалчивает тот момент, что для самой возможности "доставить ещё один сервер" приложение должно быть горизонально масштабиремо. А для этого, нередко, нужно чтобы разработчики достаточно сильно "вложились" в обеспечение такой возможности.


                        Бывают ситуации, когда быстрее и дешевле сделать решение на более производительном языке, и которое не будет (изначально) масштабироваться, но будет обрабатывать нагрузку с достаточной производительностью, чем делать мастабируемое решение на более удобном языке и тратить существенные усилия на обеспечение масштабируемости.

                        • 0
                          Думаю все уже знают и понимают, что если у вас проблемы с производительностью, то решение только в горизонтальном масштабировании т.к. ресурсы одного сервера имеют вполне конкретные ограничения и скорее всего всё равно придётся масштабировать горизонтально т.е. нет смысла тратить деньги на оптимизацию работы на одной железке, лучше сразу заниматься горизонтальным масштабированием.
                          Помимо этого горизонтальное масштабирование ещё и добавляет отказоустойчивости т.е. его всё равно придётся делать в том или ином виде.
                        • –1
                          Вот бы с автора подобных заявлений, с зарплаты вычесть все затраты (дешевле будет) всех пользователей приложения.
                        • –3
                          максимальная нагрузка на сервис. 30 rps или 6000rps с ноды

                          Представим что у вас 10 000 000 ежемесячных посетителей. То есть ваш сайт входит в US топ150 по посещаемости и находится рядом с такими ребятами как airbnb.com и steamcommunity.com Пусть каждый посетитель просматривает 10 страниц. Таким образом у вас 10000000*10/30/24/60/60 = 38 rps. Стоило оптимизировать сервис до уровня 6к?
                          • +5
                            Ах, если бы 1 страница это был 1 запрос.
                            • 0
                              Эх… Солидарен. Если бы одна страница == один запрос…
                              • –2
                                Легко, если данные важные, можно отдавать кеш 1 раз 5 секунд из файла, а если данные не очень важные то в любое назначенное время.

                                Сайты которые мы сдаем на Wordpress, вообще не используют Wordpress для вывода страниц, сразу отрубается WP и кешированные странциы достаются 1 запросом прямо из index.php, получается безумно быстро
                                • 0
                                  А есть еще миир realtime и highload…
                                  Нельзя там кэшировать страницу целиком в файл. Максимум отдельные куски.
                                  • –1
                                    realtime можно кешировать на 2,1 и 0.5 секунд если мы говорим про страницу, а не про какой-то интерактив

                                    Представьте если за пол секунды заходит 20 человек, это 1 сборка вместо 20

                                    Но суть с отдельными частями такая же, кешируйте все, что можно, а realtime оставьте
                                    • 0
                                      А если заходят тысячи покупателей и цены меняются очень часто и склады, опять-таки, а операционные издержки по отмене нескольких тысяч заказов, сделанных в момент, когда остатков на складах уже нет, будут весьма велики. Не считая ущерба для репутации.
                                      И если у нас сотни серверов, тысячи, то мы приходим к задаче инвалидации кэша, которая, как известно, сложна.
                                      • –2
                                        Можно обновлять кеш по факту изменения цены, все просто. Контролировать кеш не только по времени, но по факту изменений, тогда изменения применяться моментально.

                                        PS. Контролировать кеш при большом количестве серверов извне сложно, но можно делать 1 запрос на проверку изменений, а изменения хранить как отдельное поле, тогда будет 1 запрос, но не такой критичный.
                                        • 0
                                          Это инвалидация кэша. И это сложная задача. Цену могут обносвлять разные сервисы: массовый импорт, просто редактирование продукта, изменение не самой цены, но скидки на нее, которая может считаться несколькими сервисами с совершенно различной бизнес-логикой, стоимость доставки и скидка на стоимость доставки для этого клиента. И кто и где должен сбрасывать кэш? Это не тауой простой вопрос и тут немало копий сломано, чтобы добиться качественной инвалидации.
                                          • –2
                                            Придумать что-то можно, тут уже как с лекарствами «принимайте, если риск от болезни выше, чем риск от лекарства» )
                                            • 0
                                              Придумать можно и оно зовется инвалидация кэша. Это сложная задача, но поверьте, она не сводится к тому, чтобы выставить время кэша страницы в 0.5 секунды.
                                      • 0

                                        Это если у вас в отдельных частях ничего не зависит от user_id и от фильтров, которые он вводит.

                                  • –1
                                    Мои цифры не претендуют на точность и учет всех параметров для проектов разной тематики. Они о том что ОЧЕНЬ МНОГО пользователей не значит что каждый элемент вашей системы нужно тестировать на абстрактные 6k rps. Нужно максиально быстро запускаться, выявлять под реальной нагрузкой узкие места и тюнить их.
                                    • 0
                                      Соглашусь, если под «максимально быстро запускаться» имеется в виду «мы заранее подумали и обозначили миинимальные требования к системе, в том числе и по производительности и масштабированию, и быстро запускаемся, выполняя их».)
                                • 0
                                  Представим, что столько за приходит за час или меньше.
                                • +9
                                  Почему-то все считают, что их проект обязательно доберется до той точки, где ему понадобятся сотни и тысячи серверов и при этом будет использоваться тот же код, что и в начале. Таких больших проектов реально единицы и обычно они начинают с дешевого говнокода от фрилансеров, который все равно потом приходится переписывать.
                                  • +4
                                    Верно и обратное: почему-то люди считают, что их проект никогда не столкнется с теми задачами, которые появляются при резком росте.
                                    В сущности я весь разговор подвожу к тому, что оба суждения не верны, если обобщать. Нельзя утверждать, что проблемы решаются любым языком программирования + пара лишних серверов; равно для сервисов с нагрузкой в несколько тысяч в день или час не нужно кидаться оптимизировать для сокращения времени ответа с миллисекунд до микросекунд.
                                    На мой взгляд статья неверна именно в своих основах: обобщение неправомерно и в чем-то непрофессионально — в стиле «надо быстро фигачить код, а плохую скорость компенсируем, это, мол, всегда работает». Нет, не всегда. Можно оказаться один на один с громадным техническим долгом и успешным проектом, который быстро растет по нагрузке, а времени уже не хватит, чтобы сделать хорошо. Должен быть заранее определенный порог, ниже которого не опускаемся по производительности и способности масштабироваться под нагрузку. И порог этот должен учитывать различные бизнес-сценарии, как негативный, так и позитивный.
                                    • +1
                                      Не согласен с вами. Поведение под нагрузкой предсказать всегда сложно, и оно может упираться не в RPS, или не в тот RPS, который вы задумали. Уже было очень много случаев, когда делали оптимизированный сервер на Java/C++/Go/etc. и в большинстве случаев все равно все заканчивалось тем, что под взрывом нагрузки сервис несколько дней лежал, так как упор был не в процессор, а например в базу. Почитайте для примеров истории разных io-игр или погуглите на хабре словосочетание «не выдержал хабраэффекта».

                                      Еще мне кажется, что автор не имел в виду, что надо всегда оставаться на питоне в любой ситуации. Вы можете наговнокодить за неделю прототип на Django и размножить его на 100 серверов при необходимости, а убедившись что 100 серверов действительно нужны, нанять в это время высокооплачиваемую Java-команду, которая за три месяца перепишет проект и уместит все в один мощный сервер.

                                      И тогда цена проекта получится полностью оправданной — и 100 серверов, и профессионалы покупаются только если они действительно нужны. А если сервис понадобится только 1.5 пользователям, все что вы потеряете — это деньги на микроинстанс и неделю времени.
                                      • 0
                                        Вот про последнее, про команду java: у вас был такой опыт и подобные задачи решались за квартал java командой или нет?
                                        Про «не выдержал нагрузки» — где мне доводилось работать с приемочным нагрузочным тестированием с таким не сталкивались. Такое происходит, когда методология тестирования нарушена. Если есть обратные примеры, где и нагрузочное приемочное было и методология тестирования доступна для проверки, но все равно уперлись в неожиданное нечто, что тестирование не предсказывало, то буду рад примерам. Иначе несколько голословно звучит.
                                        • +1
                                          Про 3 месяца я загнул конечно, но если изначально был проект сделанный за неделю, то за 3 месяца уже могут что-нибудь да выкатить на прод. По опыту знакомых джавистов-аутсорсеров, где-то так все и происходит: приходят люди и просят переделать говнокод на питоне или еще чем-то во что-то приличное.

                                          Такое происходит, когда методология тестирования нарушена.

                                          Тут мы и приходим к тому, что чтобы проект выдерживал нагрузки сразу, разработчик должен быть опытным (дорогим) и чтобы просто проверить идею (которая скорее всего не взлетит по статистике), придется потратить много денег и скорее всего времнеи. Естественно я не говорю о проектах, где большая нагрузка точно будет.
                                          • +2
                                            Тогда наши мнения вполне совпадают.
                                            Однако же изначальное утверждение статьи «Производительность более не важна» все также выглядит сомнительно.
                                    • +2

                                      Даже если проект добирается до такой точки, камнем преткновения, по-моему, становится не язык, а задачи и алгоритмы. В тех проектах, где работал я, сложности появлялись не из-за того, что Python «медленный» а из-за того, что какие-то задачи в принципе в лоб быстро сделать невозможно. И кэширование применить невозможно (потому что каждый вызов кода должен был возвращать уникальные данные). Приходилось придумывать какие-то алгоритмы и структуры данных, чтобы можно было максимально быстро генерировать требуемую информацию. И напиши это место хоть на C, ничего не изменилось бы, так как требовалось достать сотни тысяч строк из базы данных, и произвести над ними какие-то действия.


                                      Кстати, Reddit, если не ошибаюсь, на Python написан, а это очень высоконагруженный сайт.

                                      • –1
                                        Бывает, что и в язык. Никто в здравом уме и трезвой памяти не будет делать жадные до данных алгоритмы на php, опыт был. Один и тот же алгоритм выявления спама на php съедал 32+ оперативки и прогноз работы был в день. Лоб в лоб переписанный на java без знания java алгоритм отработал в пределах 5и минут. Это времена php 5.6.
                                        • –1

                                          В PHP нет сборщика мусора, во всяком случае, раньше не было. Так что неудивительно, надо было все-таки сравнивать хотя бы с минимально полноценным языком.

                                          • +2
                                            Только что вы говорили, что язык не имеет значения и уже перешли к тому, что PHP — неполноценный? Вы противоречите своему утверждению «Даже если проект добирается до такой точки, камнем преткновения, по-моему, становится не язык, а задачи и алгоритмы».
                                            Кстати, python на той задаче бинарной кластеризации показал не лучший результат.
                                            • +1
                                              И кстати http://php.net/manual/ru/features.gc.php
                                              • 0
                                                погодите. Сборщик мусора не увеличивает быстродействие (за исключением редких случаев, когда вм за сотни циклов понимает, что можно перевести пару выделения/освобождения памяти с кучи на стек).

                                                Понятно, что оптимизировать питон в питон вряд ли есть резон, но если исходить из принципа достаточной эффективности, то далеко не всегда есть резон переписывать в си то, что достаточно быстро отработает на джаве. А иначе и выбора-то нет.
                                      • +6
                                        Подправьте меня пожалуйста. Что если аренда сервера стоит 250$, и мы добавляем второй, вместо оптимизации, то это 500$. 6000$ каждый год, Программиста можно уволить или перевести на другой проект, а расходы останутся, а кто эти два сервера будет администрировать? Админу теперь вместо 1, надо администрировтать 2 сервера.

                                        А что буде тесли 1 сервер упадет? (Риторический вопрос)

                                        Это все сказки, что железо дешевое работы программиста, программисты разные и железо разное, если мы считаем VPS по 10-50 долларов в месяц и Senior с окладом 4000$ в месяц, то да, но если сервер стоит хотябы 250$, то тут другая история.

                                        — Более того, я не согласен про скорость, понятие скорости очень размыто и зависит от прокладки. Такое ощущение, что каждая новая работа — это чистый лист. Потратил на 4000$ больше, зато экономишь каждый год 3000$, а это 15000$ за 5 лет
                                        • +1
                                          Уверен, что в компании, которая нуждается в серверах m4.2xlarge (а это 32Gb RAM и стоят они всего $2000/год), зарплаты программистов гораздо больше $4000/mo. К тому же я б разбил такой сервис на кучу маленьких серверов и засунул в autoscale группу — удобнее будет и спокойнее по ночам. Ну и ещё раз повторюсь — оптимизации никто не отменял, но это работа с высокими рисками по времени (может занять день, а может и неделю), так что лучше её проводить в спокойное время.
                                          • 0
                                            Уверен — не аргумент, вы так уверенно считаете чужие деньги ) Проекты очень разные, даже там где есть деньги, есть автоматические скрипты, которые не требуют суппорта годами. А есть проекты, где денег мало, клиентов мало, но данных очень много.

                                            А что делать, если данные ждут сначала жесткий или SSD, а потом приходится еще и проц ждать )
                                            • +2
                                              Про зарплаты — это не так. Достаточно вспомнить те же зарплаты в яндексе, которые несколько ниже рыночного уровня.
                                              В больших компаниях спокойного времени часто не бывает вовсе: всегда есть горящая кампания, выход на новый рынок, развитие нового направления, мега-важная бизнес задача. По сути просто выше планка минимального приемлимого уровня по производительности.
                                              С aws и большими компаниями тоже неоднозначно. Не дешевое оно удовольствие в highload: когда счета переваливают за тысячи в день, и когда понимаешь, что отсутствие возможности лично решать проблемы со связью — это задержки в недели и месяцы в важных задачах, а если вот прямо сейчас идут сотни и тысячи заказов в секунду… Все приходят к своим дц в итоге. И своей поддержке. И мы возвращаемся к вопросу оптимизации издержек на железо и поддержку.
                                            • 0
                                              > Программиста можно уволить или перевести на другой проект

                                              это только в сказочном мире так бывает, обычно программистов нужно всё больше если проект живёт, а если не живёт, то и сервера будут не нужны

                                              > Админу теперь вместо 1, надо администрировтать 2 сервера.

                                              для нормального админа разницы нет, сервера то типовые, хоть 50
                                            • +1
                                              Замерил я производительность для своей задачи.

                                              1 млн объектов в массива + легкая арифметика заняли около 30 секунд на Python и 11 секунд на php7, NodeJS и C = 9 секунд.

                                              Убедительная прозьба не лошить на замеры, замеры сделаны аматорки, был написал 1 алгоритм на всех языках и запускались из под консоли не для точных замеров, а для быстро решения в чем массив обрабатывать.

                                              Так вот, 20 секунд разницы против тоже простого, но более уродливого языка.

                                              на 100 000 000 — это уже 2000 секунд, что есть 30 минут. Откуда берутся 100 млн циклы? Это когда у вас вложеные циклы. Вложеные циклы плохо? Ну а что делать, если задача брать 1 обхект из массива, у которого например 20 полей, проверять каждое поле по определенным патеррнам и тд (безумловно много чего было придумано для уменьшенитя этих итераций, но суть остается)
                                              • –2
                                                Чтобы убрать эти 30 минут, мне надо докупить еще 1 сервер за 500$, именно столько стоит текущий, мне этого делать не хочется, а я не корпоративная компания монстр с огроными бюджетами, а задача такая есть. И я не вижу разницы в скорости разработки между Python, NodeJS, php, можете объяснить где же это узкое место.

                                                На конференциях везде проталкивают Джанго, как джина с батарейками, где все есть и ничего делать не нужно.
                                                • +5
                                                  Бизнес-логику писать на python, а критичные числодробилки переписывать на C. Об этом и статья. Из личного опыта, за 5 лет пришлось написать два экстеншена на чистом C. И что, из-за двух мест писать весь продукт, например, на Java? И потерять на этом пару десятков человеко-лет?
                                                  Если эта числодробилка и есть весь ваш проект, то безусловно, выбираем язык под потребности. Но, мне кажется, есть много всего вокруг этого алгоритма: пользовательские интерфейсы, API и т.д. Их тоже обязательно писать на супер-быстром языке, жертвуя своей производительностью? Python как раз дает такую гибкость.
                                                  Поводом выбрать Java может быть наличие статических анализиторов кода, широкое сообщество, кол-во доступных разработчиков на рынке, особенности продукта. Но точно не скорость работы языка как такового.
                                                  • 0
                                                    Узкое место есть, просто оно дальше. В большинстве же небольших проектов оно в язык вряд ли упрется, разве что в вопрос, на каком языке лучше и шуствее код писать и поддерживать, то есть в первую очередь, читать, в том числе и новичками.
                                                  • +1
                                                    Подобные числодробилки и пишутся на Cython, о чем говорится в статье (и о чем говорил Гвидо).
                                                    Для примера вот вычисление чисел Фибоначчи на Python и Cython:
                                                    Python
                                                    def fib(n):
                                                        a, b = 1, 1
                                                        for i in range(n):
                                                            a, b = a + b, a
                                                        return a
                                                    
                                                    %timeit fib(1000)
                                                    10000 loops, best of 3: 104 µs per loop
                                                    


                                                    Сython
                                                    def cfib(int n):
                                                        cdef int i
                                                        cdef double a=0.0, b=1.0
                                                        for i in range(n):
                                                            a, b = a + b, a
                                                        return a
                                                    
                                                    %timeit cfib(1000)
                                                    1000000 loops, best of 3: 1 µs per loop
                                                    


                                                    Время выполнения говорит само за себя.
                                                    p.s. А для работы с многомерными массивами, математическими функциями и т.п всегда есть NumPy.
                                                    • 0
                                                      Справедливости ради стоит отметить, что целые числа в python — с абсолютной точностью(не ограничены по размеру), а значит сравнивать сложение их со сложением double совсем не корректно(потому что чем больше числа тем сложнее их складывать) подкорректировал чтоб считать модуль по большому простому числу каждый раз:
                                                      Python
                                                      In [11]: def fib(n):
                                                         ....:     p = 10**9 + 7
                                                         ....:     a, b = 1, 1
                                                         ....:     for i in range(n):
                                                         ....:         a, b = (a+b)%p, a
                                                         ....:     return a
                                                      
                                                      In [12]: %timeit fib(1000)
                                                      10000 loops, best of 3: 58.5 µs per loop
                                                      



                                                      Cython
                                                      In [16]: %%cython
                                                         ....: def cfib(int n):
                                                         ....:     cdef int p=10**9 + 7
                                                         ....:     cdef int i
                                                         ....:     cdef int a=1, b=1
                                                         ....:     for i in range(n):
                                                         ....:         a, b = (a+b)%p, a
                                                         ....:     return a
                                                      
                                                      In [17]: %timeit cfib(1000)
                                                      100000 loops, best of 3: 6.02 µs per loop
                                                      


                                                      Разница уже не в 100 раз, а в 10, но конечно все еще существенна.
                                                      • +1
                                                        Ваш пример станет работать в 2..3 раза быстрее, если отключить zero division error специальным декоратором:
                                                        import cython
                                                        
                                                        @cython.cdivision(True)
                                                        def cfib(int n):
                                                            cdef int p=10**9 + 7
                                                            cdef int i
                                                            cdef int a=1, b=1
                                                            for i in range(n):
                                                                a, b = (a+b)%p, a
                                                            return a
                                                        


                                                        До отключения


                                                        После отключения
                                                      • 0
                                                        Почему в Cython 1000000 loops а в Python 10000 loops, при этом n что там что там 1000?
                                                        • 0
                                                          Для уменьшения погрешности. %timeit автоматически выбирает количество итераций чтобы суммарное время исполнения было выше некоторого порога. n это номер числа. Он влияет на количество итераций только косвенно, через время одной итерации.
                                                    • 0
                                                      Зачем сравнивать C и Python, сравнивайте современные развивающиеся языки, которые намного быстрее, а во многом и удобнее питона.
                                                      И разница в серверах (а значит и всей инфраструктуре) может быть на порядки, если задача выполняется не в 2 раза медленнее, а в 100.
                                                      • +3
                                                        Топ языков по исследованию SO: JavaScript, SQL, Java, C#, Python, PHP, C++, C. Все они стартовали в прошлом тысячелетии. И все они современные и развивающиеся, ИМХО.
                                                        • +1
                                                          ачем сравнивать C и Python, сравнивайте современные развивающиеся языки


                                                          Вы, даже если не сравнили, то хотя бы перечислили какие именно и для чего предлагагаете сравнивать.
                                                        • 0
                                                          В точку! автор прав, но это справедливо только для некоторой части рынка.
                                                          Но к сожелению это не относится к одной из самых крупных индустрий — игровой. Там проблемы с оптимизацией, которые последнее время стали бичем ААА проектов, равносилен провалу и убыткам.
                                                          • +2

                                                            Но ведь они пишут на C++, oh wait…

                                                            • +1
                                                              Что даёт нам понять, что при плохой оптимизации дело не в языке.
                                                            • 0
                                                              Для геймдева это точно так же справедливо, и питон там вполне успешно используется, в том числе и в AAA проектах.
                                                            • +2
                                                              ИМХО статья несколько найвна, всё зависит от задачи.
                                                              Архитектура приложения и технологии выбираются исходя из постановки задачи и требований.
                                                              Если вам нужно приложение в короткие сроки ваш заказчик должен понимать чем он рискует и какие возможности буду ущемлены.
                                                              Другое дело если заказчик ставит изначально целью высоконагруженную систему которой точно будут пользоваться милионы пользователей. Для таких случаев систему требуется проектировать по другому и использовать другие технологии для возможностей горизонтального и вертикального маштабирования.

                                                              А Python отлично занимает свою нишу среди других ЯП и справляется со своими задачами в сферах big data & machine learning. Сравнивать его с другими ЯП как сравнивать молоток и ножницы.
                                                              • +1
                                                                > найвна
                                                                Как вы это произносите?

                                                                Добавлю в коллекцию к андройду, гиперболойду, Тайланду, таблойду, гуманойду…
                                                                • 0

                                                                  Тайланд, кстати, в этом списке лишний, потому что, в отличие от остальных слов, произносится именно с краткой и, как, например, в "не делай". До кучи, слова "тайцы", "тайский" пишут именно с "й".

                                                              • +3

                                                                Расскажите эти сказки производителям батареек. Они очень порадуются и расскажут как увеличить их емкость в сто раз.

                                                                • 0
                                                                  Да, питон медленный, но иногда(давненько на хабре видел) питоп побыстрее плюсов. Но это редкость)
                                                                  • 0
                                                                    А можно ссылку? Прям даже интересно
                                                                    • +1
                                                                      Питон относительно медленно работает с простыми объектами типа чисел, но относительно быстро со сложными — хэш-таблицы и т.д. А множество встроенных функций для их обработки (всякие сортировки, поиски, слияния и пр.) написаны на C людьми, которые в этом разбираются гораздо лучше среднего C/C++ программиста, чья кастомная реализация наверняка будет медленнее. Что не отменяет того факта, что для C/C++ уже полно библиотек, которые делают то же самое.
                                                                      • 0
                                                                        А ещё Python уже давно двигается в сторону ленивых вычислений везде, где это оправдано. Это один из поводов переходить на Py3.
                                                                        • +1
                                                                          Но ведь это не совсем «но иногда(давненько на хабре видел) питоп побыстрее плюсов».
                                                                          • 0
                                                                            Я помню такую статью. Насколько я помню автор написал два файла на Си. В одном объявлялась функция для сложения двух чисел int, а во втором вызывалась. И аналогичный код на Python. И засчёт того, что компилятор Си анализирует файлы только по отдельности, питоновская версия получалась быстрее. Но точно не помню.
                                                                            • 0
                                                                              Ага, я кажется видел что-то подобное но связанное с PyPy (возможно даже в их блоге).
                                                                              Но это ведь спекуляция, по сути? Если дать компилятору заинлайнить ф-ию, то сишная версия будет как минимум так же быстра.
                                                                              • 0
                                                                                Конечно, в сложении чисел Python Си обогнать никак не сможет.
                                                                              • 0
                                                                                это невозможно как минимум потому, что питон хранит инты в куче и на создание/освобождение каждого инта в питоне уходит больше времени, чем на простой вызов (пусть и не встроенной) функции.
                                                                                • 0
                                                                                  Если инты маленькие, они уже предсозданы.
                                                                        • 0

                                                                          Да, такое бывает в случае, когда Python используется просто как обёртка над вылизанной и оптимизированной нативной библиотекой, то есть скорость выполнения зависит не от скорости интерпретации Python, а от производительности библиотеки.


                                                                          Если для выполнения одной и той же операции C++ программист будет использовать более медленную библиотеку, то в данном случае код на Python будет более быстрым.


                                                                          Пример: библиотеки для работы с регулярными выражениями. Стандартная библиотека C++ в этом отношении очень медленная, поэтому её обходят все, кому не лень.

                                                                        • 0
                                                                          Разработка на python действительно достаточная быстрая. Недостаток в производительности компенсирую за счет pyopencl(заодно можно запускаться на GPU).
                                                                          • 0
                                                                            Время на решение задачи на C меньше, чем на Java (и C++)?

                                                                            Это что за задача такая? Задачу в студию! Хочу ознакомиться и лично сравнить.
                                                                            • 0
                                                                              Вопрос не в задаче, я думаю, вопрос в решении.
                                                                              Если Вы вместо строки на С типа
                                                                              if (A>B) do_something(); else do_other();
                                                                              начнете создавать класс для A и делать у него перегруженный метод сравнения, одним из вариантов будет выше приведенное выражение, то да, время на подобные экзерсисы уйдет больше.
                                                                              Недавно был диспут на подобную тему в ответ на заявление «Ну тут нужна фабрика ....».
                                                                              • 0
                                                                                Это все хрень, которую зачем-то проталкивают вот такие авторы статей. У любого уважающего себя программиста на любом языке программирования есть инструментарий, с помощью которого он может быстро решить типичный набор задач. Никто не будет писать свой класс строки на плюсах, несмотря даже на то, что в стандартной либе поддержка так себе.

                                                                                Мне кажется, отлично все эти споры разруливает Геннадий Короткевич под ником tourist, почти что ежегодный победитель соревнований Яндекс.Алгоритм, Google Code Jam и многих других. А фишка в том, что они пишет везде, где возможно, на Pascal. Хотя казалось бы.
                                                                                • 0

                                                                                  Зашел посмотреть его решения на Codeforces. Сплошь и рядом С++.

                                                                                  • 0
                                                                                    На TopCoder он юзает С++, на International Olympiad in Informatics и Яндекс.Алгоритме он юзает Pascal.
                                                                                  • 0

                                                                                    Ну как бы задача решения олимпиадных задач и задача промышленного программирования — это очень разные вещи. В олимпиадных задачах обычно не так много кода, довольно много работы с числами и жесткий лимит времени выполнения кода при выходе за который задача не засчитывается. А заниматься переписыванием узких мест на компилируемый язык просто нет времени, потому что решить надо всё как можно быстрее. Это не очень похоже на то, с чем обычно приходится сталкиваться в реальной жизни

                                                                                    • 0

                                                                                      Начнем с того, что в проде надо писать читаемый и поддерживаемый код. На олипмиаде быренько набросал алгоритм и заслал. Зашло — супер, не зашло — фиксим и сдаем.
                                                                                      Но согласитесь, навыки прокаченого пресловутого problem solving skill помогает в продакшене.

                                                                                      • 0

                                                                                        Навыки помогают, кто ж спорит, но речь-то о другом — о выборе языка. Я про то, что пример Туриста и его языков для олимпиады мало показателен для прода

                                                                              • 0
                                                                                Вопрос в решаемой задаче. Если внешнее устройство типа онлайн-кассы отвечает с задержкой в секунду, то нет никакого смысла бороться за доли секунды. Питона+GTK3 хватает за глаза.
                                                                                • 0
                                                                                  У онлайн-кассы есть другая проблема — надёжность. Я бы не стал использовать Python, когда нужны какие-то реальные гарантии.
                                                                                  • 0
                                                                                    То есть питон, менее надежен чем любой другой язык?
                                                                                    • +7
                                                                                      Динамическая типизация это + N багов отлавливаемых только во время выполнения.
                                                                                      • –4
                                                                                        То есть в установке неверного типа, виноват язык а не программист, который позволил неверному типу в то или иное место программы?
                                                                                        Второй момент, типизация хоть и динамическая но сильная, и поэтому все баги с типами которые Вы описываете, целиком и полностью вина программистов… у нас тут массивы с числами не складывают.
                                                                                        • +5

                                                                                          Виноват программист, но в языках со статической типизацией ошибка вылезет в худшем случае на этапе компиляции, а вообще IDE сама подскажет, что с кодом что-то не так.

                                                                                          • 0
                                                                                            Нужно решить задачу, а не разобраться на кого возложить вину. В типизированных языках на этапе компиляции можно отсеять кучу явных багов.
                                                                                        • +1
                                                                                          Я не могу сказать про любой. Я про C/C++. На этих языках вы, приложив некоторые усилия, можете написать ПО, предъявляющее какие-то гарантии времени выполнения (в пределах, допустимых операционной системой и железом). На питоне заниматься системным программированием тоже можно, но подводных камней и ограничений слишком много.
                                                                                          • 0
                                                                                            Если под надежностью Вы подразумеваете время отклика онлайн кассы, в пределах опять таки железа, то тут ни Си ни любой другой язык не сможет этого обеспечить, из за присутствия сети между терминалами.

                                                                                            Второй момент, с которым я солидарен с автором, что критический участок можно переписать на Си/ASM и прочее, но зачем простите писать на Си бизнес логику? Или например UI? При умеренных количествах Python может реализовать отличный UI, при очень скромных затратах на разработку.

                                                                                            В целом, думаю данный разговор можно свести к утверждению «на каждую задачу — свой инструмент», но мне кажется, утверждать без контекста что питон — ненадежен, это реально преувеличенно и совершенно неверно.
                                                                                            • +1
                                                                                              Я не про время отклика. В питоне довольно трудно писать адекватные обработчики сигналов, особенно когда начинается мультитрединг/мультипроцессинг и всё в таком духе. В стандартной библиотеке все модули работают на глобальных локах, так что элементарное логирование может повесить программу и убить логику завершения транзакции, например.
                                                                                              • 0
                                                                                                А почему бы не запускать UI в одном-двух потоках, а все остальное написать на С/С++ и пусть себе работает в многих потоках, посылая сообщения в UI? Я никогда не писал на питоне UI больше пары полей ввода, но вдруг стало интересно, насколько возможно в нем создать сложный асинхронный интерфейс к многопоточному приложению.
                                                                                                • +1

                                                                                                  Мне кажется, что Python для UI — не лучший выбор. Если речь идёт исключительно об UI, то почему бы не использовать для этого более удобные средства, да хоть те же WinForms?

                                                                                                  • 0
                                                                                                    потому что это win forms
                                                                                                    • 0

                                                                                                      Ну на Java можно написать, если религия того просит.
                                                                                                      А если речь об энтерпрайзе, то там ОС — всего лишь инструмент.

                                                                                                    • 0
                                                                                                      Ну как раз-таки UI я бы предпочёл писать на Питоне. Другое дело, что годных библиотек для этого как-то не видно на горизонте, но если бы они были, уверен, Питон бы отлично справился.
                                                                                                      • 0
                                                                                                        чем плох PySide/PyQt? (Впрочем, имея Qt можно сразу писать на QML)
                                                                                                        • 0

                                                                                                          А почему, если не секрет? Никаких причин, кроме как незнания другого языка/технологий, я здесь не вижу.

                                                                                                          • 0
                                                                                                            Ну, высокоуровневый язык, как минимум удобно обработчики событий писать.
                                                                                                            • 0

                                                                                                              Верно, но ровно то тех пор, пока не придётся бодаться с многопоточностью и асинхронностью.

                                                                                                              • 0
                                                                                                                Если всё, кроме ui живёт в отдельных потока с отпущенным GIL, то почему нет (с тем же PyQt например). Отлично всё работает, даже довольно шустро, сам пользовался.
                                                                                                • +2
                                                                                                  Мой опыт пока что показывает, что предоставление гарантий в одном месте приводят к их исчезновению в другом. Да, в питоне можно намудрить с типами, но в результате обработать исключение и восстановить процесс выполнения. В С можно намудрить с памятью-указателями, разыменовать null и получить необрабатываемый Access Violation. Умные указатели помогают, но всегда находится другой метод намудрить, источник багов воистину неиссякаем.

                                                                                                  Хотя в том, что Pytjon не самый подходящий язык для системных задач — я полностью согласен. Но мы вроде бы и не про них сейчас.
                                                                                          • 0
                                                                                            Графики, конечно, это да. Наверное, брался срез среди каких-то ученых, которым писать на Perl, Python быстрее чем на Java/.Net. Все соревнования показывают, что практически код одинаково пишется на всех языках С++, Java, Pascal (если умеешь писать конечно). По себе могу сказать, что пишу код быстрее, чем на python и чем другие пишут на питоне, правда, они вообще очень медленно пишут на Java. Знаю людей, которые еще быстрее пишут на С++.
                                                                                            Вброс про производительность против продуктивности не засчитан. Выучи язык и пиши на нем, если человек выучил только питон, то это его трудности.
                                                                                            • 0
                                                                                              А если человек выучил и Питон, и C++? :)
                                                                                              • +6

                                                                                                Вы не поверите, на питоне я буду писать скрипты не более 500 строк (примерно естественно). После этого объёма я возьму компилятор, бьющий по рукам хоть немного. Потому что в динамике любой мало-мальски объёмный рефакторинг — боль.

                                                                                                • 0
                                                                                                  Отчего же, охотно верю. Но это отражает удобный Вам подход к разработке. Я, например, прежде чем кодить собственно проект, пишу много маленьких эскизов-черновичков, в которых решаются-проверяются-тестируются частные задачи-идеи-библиотеки, предположительно необходимые для реализации проекта. А потом вспоминаю паттерны проектирования и пишу большое полотно с учётом общей картины (видение которой как раз формируется на эскизном этапе). Причём подобным образом работаю и на С++ и на Питоне (надо ли говорить, что на Питоне в таком стиле работать удобней). Кстати, в последнее время стал замечать, что «большое полотно» всё чаще оказывается не таким уж большим, если правильно подобрать «фреймворк».

                                                                                                  Что касается ошибок, отлавливаемых во время компиляции — ну вот честное слово, не припомню, чтобы на Питоне меня долго мучил какой-то неуловимо-критичный баг, связанный именно с перепутыванием типов (да, бывает, конечно же, но отлавливается очень быстро — активное использование аннотаций типов служит хорошую службу).

                                                                                                  Про порог в полтысячи строк не совсем ясный принцип — это на весь проект или на один модуль (класс, компонент)?
                                                                                                  • 0

                                                                                                    Дело вкуса и подхода. Я скорее пишу первичный каркас, на который навешиваю дополнительные плюшки и рефакторю по мере необходимости. Вот в процессе такой "перестройки" система типов помогает очень сильно.


                                                                                                    Я сталкивался с подобным. Конечно подобные баги "мучили" меня не неделю и не день, а часа 2-3. Но осадочек остался. По поводу аннотаций — я работал с 2.7, и скрипт был подсобный, для прогона своего рода интеграционных тестов. Собственно, я столкнулся с неприятностями на немного извратном сравнении двух JSON документов.


                                                                                                    Порог на один файл, и конечно очень условно. За счёт того, что питон таки умеет инкапсулцию на уровне файлов. Читаемым и легко поддерживаемым может быть и 1000-строчный скрипт.

                                                                                              • 0
                                                                                                сейчас работаю на проекте на C++ и смотрю в сторону Python, потому как просто нравится. Я диплом на нем написал за 1.5 дня, а на cpp заняло бы минимум 1 неделю
                                                                                                • +2
                                                                                                  а разве разрешают брать в качестве темы дипломной работы калькулятор с таблицей умножения?
                                                                                              • +13
                                                                                                Удачи в использовании браузера, в написании которого программисты руководствовались идеей «производительность не важна».

                                                                                                Она не важна ровно до тех пор, пока не становится важна.
                                                                                                • +3
                                                                                                  Мы живём в эпоху тормозных неотзывчивых интерфейсов.

                                                                                                  Браузер тут скорее в качестве исключения, как пример штучного оптимизированного приложения. Вся электроника ужасно тормозит — давно вы видели быстрый интерфейс в банкомате, информационное табло, которое сразу реагируюет на нажатия или телевизор без секундной задержки на любое действие?
                                                                                                • +1
                                                                                                  В веб-разработке важен только один показатель скорости — как быстро веб-приложение работает с точки зрения пользователя. Вот это и надо оптимизировать.
                                                                                                  • +1

                                                                                                    У меня впечатление, что я слышал эту мантру 10 лет назад.


                                                                                                    Есть конечно задачи, которые отлично масштабируются горизонтально; есть задачи, где СУБД в любом случае узкое место. Но есть и задачи, в которых в зависимости от качества (говно)кода пользователь будет ждать или секунду, или минуту.
                                                                                                    Правда, в таких случаях больше на скорость влияют эффективные алгоритмы, а не языки. И, кроме оптимизации (преждевременной или нет) этих алгоритмов, мало что может помочь.

                                                                                                    • +7
                                                                                                      Вот сравниваю я Skype и Telegram на своём смартфоне. И становится понятно, разработчики которого из IM руководствовались принципом «зато быстро накодили и оно даже работает». Мобильным Skype невозможно пользоваться без боли.
                                                                                                      • +6
                                                                                                        Так вам же сказали, вам просто мощнее смартфон надо купить, это дешевле времени разработчика
                                                                                                        • +1
                                                                                                          Кстати, да, вся эта демагогия про «время разработчика дороже» имеет право на существование до тех пор, пока затраты на отсутствие оптимизации не перекладываются на пользователей. ВСЕХ пользователей. Таким образом принцип — «лучше сэкономить на разработке» работает только с бэкендом онлайн приложений. А фронтенд уже работает в браузере и его извольте оптимизировать. Не только под последний Chrome. Не только под последний макбук разработчика. А для десктопных приложений, мобильных приложений производительность имеет большое значение. При прочих равных люди будут выбирать Telegram вместо FB Messenger, The Old Reader вместо Feedly, Google Keep вместо Microsoft OneNote и т.д.
                                                                                                          • +1
                                                                                                            Не мощнее, а ещё один.
                                                                                                        • +1
                                                                                                          Тема сравнения с perl не раскрыта. Зачем в вашей метрике продуктивности нужен питон, когда есть перл?
                                                                                                          • +4
                                                                                                            Питон аккуратно спроектирован, прямо вылизывается создателями, они всё стараются делать логично, выразительно, прямо радуешься когда читаешь как оно в питоне, а перл это перл, это альтернативное видение и синтаксиса и концепции ЯП — сигилы, глобальные переменные, контексты и так далее.
                                                                                                            • 0
                                                                                                              Эм, вас перл заставляет использовать глобальные переменные? use strict, my/our вот это всё. В перле есть довольно много разумных неявных умолчаний, удобных для его класса задач — сколько там строчек в питоне займёт аналог while(<>) { s/--MYVAR--/$ENV{MYVAR}/; print ;}? Другое дело, что если вам нужен не однострочник «прям щас», а нужен код, который прочитают и будут поддерживать другие люди, на перле надо писать как на питоне или на java. Но он не заставляет вас так делать (а питон да, пытается).
                                                                                                              • 0
                                                                                                                В приведённом вами коде используются как минимум две глобальные переменные.
                                                                                                                • 0

                                                                                                                  Ваш пример годится только для однострочника, накиданного в командной строке по месту. Как только вы захотите переиспользовать этот код — упрётесь в чтение этой клинописи. Почему-то многие при сравнении "одноразовых" языков и "многоразовых" не учитывают, что сам автор может и не прочитать своё творение через недельку — из-за того, что писал в клинописном стиле.


                                                                                                                  По поводу use strict/my/our — у меня есть перед глазами замечательный пример в виде основного инструмента, С++. Языка, на 50-60% состоящего из легаси. Можно писать хорошо и красиво — но для этого придётся написать свою мини-обвязку, а также следовать правилам, в порверке которых компилятор вам просто так не поможет. Короткий вывод — есть языки, на которых легко писать криво и неправильно — и есть языки, на которых если писать криво и неправильно, придётся постоянно ублажать компилятор "обходными манёврами".

                                                                                                                  • 0
                                                                                                                    Ну тут уже вопрос вкусовщины/личного комфорта/корпоративных стандартов/сложности поддержки в долгую. Основной поинт автора статьи был в том, что интерпретируемые языки с динамической типизацией и компактным синтаксисом в лице питона экономят время программиста, которое — ключевой ресурс. При этом ровно в метрике времени на решение разовой задачи перл не хуже питона, как минимум. Другое дело, что да, питон строже и наваять на нём странный стрёмный нечитаемый код — сложнее. Но не невозможно. И да, если писать на перле с нужной обвязкой (какой-нибудь perlcritic на pre-commit навесить, например) — должно получаться неплохо. Но свобода этого не делать — остается.
                                                                                                                    • +1

                                                                                                                      Как по мне, вырисовывается вполне себе зависимость, где объём свободно поддерживаемого кода обратно пропорционален условной сложности компилятора


                                                                                                                      • На перле или APL/K (из-за эзотеричности их синтаксиса) легко писать короткострочники, но код средних размеров уже может стать нечитаем. Уточню, что и Перл может быть читаем в среднем объёме, если не использовать "клинопись".
                                                                                                                      • Питон, человеческий перл, яваскрипт и т.п. динамика читаемы и поддерживаемы в рамках среднего объёма (мои наблюдения — в среднем 500, до 1000 значащих строк). И в этом объёме в среднем более продуктивны чем языки со статической типизацией. Так как содежимое модуля и связи внутри вполне можно удержать в голове.
                                                                                                                      • Всё что выше — требует статической типизации, т.к. кол-во связей и общий объём уже таков, что прилетевший из ниоткуда инт вместо строки в рантайме приводит к боли при отладке. А транслятор в этом помогать не желает. И рефакторинг превращается в охоту за тараканами.
                                                                                                                      • 0
                                                                                                                        Биллинг на ~400 000 значащих строк на перле, строгие конвенции на проверку и передачу параметров (т.е. эмуляция статической типизации на уровне взаимодействия компонент), объектная модель, клинопись выпилена, юнит-тесты местами (увы), ~70% функций влезают в экран — полёт нормальный. Да, есть вещи, которые «пора бы отрефакторить», время от времени это делается. Может быть, если это вот всё делать сейчас и с нуля — покурить про язык можно было бы с большим выбором, но особого смысла переписывать столько с нуля сейчас нет и не предвидится — сложность поддержки вполне разумная.