Здравствуйте, Cyberax, Вы писали:
C>Здравствуйте, Буравчик, Вы писали:
C>1) Динамичности. Любая реальная большая кодовая база становится крайне лохматой, даже если писать в стиле Питон-с-классами и избегать магии в виде декораторов и прочих страшностей. Тестов обычно бывает недостаточно.
Динамичность добавляет не только проблем, но и большое количество плюсов. Особенно при работе с JSON и другими слабо структурированным вещами.
Ошибки типов часто выявляются с помощью IDE и аннотаций типов (их использование в больших проектах крайне желательно).
C>3) Интерпретируемости. Если нужно делать высокоскоростные сервисы, то можно забыть про высокоуровневые библиотеки типа SQLAlchemy. Теоретически на подходе есть PyPy, но он всё ещё не дорос.
Прикладное программирование это в основном склеивание библиотек. Для клея интерпретируемости вполне хватает.
C>4) Уродский инструментарий. Питон до сих пор нормально ниасилил пакетные менеджеры, так что распространение и установка программ на нём часто весьма нетривиальна. XKCD в тему: https://xkcd.com/1987/
Неплохой инструментарий. Для проектов используются виртуальные окружения с нужной именно тебе версией питона и библиотек, это стандарт де-факто. Pycharm отлично работает и все это очень хорошо поддерживает.
C>Так что пожалуйста, не надо использовать Питон для чего-то сложнее скрипта в сотню строк.
Уверен, что смело можно писать и тысячи строки и десятки тысяч.
Например, связка [Traefik — Cloudflare — Let's Encrypt] будет работать полностью на автомате, бесплатно, С HTTPS/2. При этом полностью самостоятельно (если log rotation правильно сделаешь ). Про возню с SSL сертификатами можно будет забыть.
Ключевые слова:
(AWS ELB или HAProxy или F5 или ...) , Traefik Proxy, PROXY Protocol, Let's Encrypt/ACME
Здравствуйте, Cyberax, Вы писали:
C>Здравствуйте, Calc, Вы писали:
D>>>Нет, как-то миновала меня чаша сия. C>>бери PHP и не выеживайся C>За новый софт на PHP надо расстреливать без разговоров.
весь мир с ним работает, а на RSDN надо расстреливать. Я уже вижу тут застой в IT мозгах.
аргументы в пользу расстрела будут?
Б>>>>Почему оно будет трещать по швам, если будут тесты? C>>>Потому, что Питон.
Атеист, что-ли7
Б>>Откуда такая неприязнь? Расскажи, пожалуйста, про фейлы питона, с которыми ты сталкивался (лучше, если лично сталкивался). C>Проблемы Питона в: C>1) Динамичности. Любая реальная большая кодовая база становится крайне лохматой, даже если писать в стиле Питон-с-классами и избегать магии в виде декораторов и прочих страшностей. Тестов обычно бывает недостаточно.
Самый мой крупный проект содержал более 3-х миллиардов строк на питоне. Работало там 7 тысяч программистов.
Кол-во бардака было такое же как и в проекте на яве. Сравнивомогу по размеру.
C>2) Однопоточности. Это реально проблема — сервер придётся запускать в виде нескольких процессов, что делает невозможным вещи типа разделяемого кэша.
Никогда не нужно. CPython, корутины, сервлеты и вообще торнадо. или твистед. числодробилки не берём во внимание. Их менее 1%
C>3) Интерпретируемости. Если нужно делать высокоскоростные сервисы, то можно забыть про высокоуровневые библиотеки типа SQLAlchemy. Теоретически на подходе есть PyPy, но он всё ещё не дорос.
Алё. CPython и компиляция в ц++.
C>4) Уродский инструментарий. Питон до сих пор нормально ниасилил пакетные менеджеры, так что распространение и установка программ на нём часто весьма нетривиальна. XKCD в тему: https://xkcd.com/1987/
Это о чём?
Докер, хренокер — одной пяткой. Уставновка на виртуалку или в процессе разворачивания — элементарно.
C>При этом начинать проект легко, да. Сначала код пишется как будет сам. Но вот потом всё становится очень уныло. Я и сам попадал в эту ловушку, и в других проектах тоже встречал.
С индусами что-ли работал?
C>Так что пожалуйста, не надо использовать Питон для чего-то сложнее скрипта в сотню строк.
Как раз на сотню строк подойдёт что угодно.
C>Да, всё то же относится к Ruby и немного меньшей степени к NodeJS (он хотя бы быстрый).
Угу, особенно яваскрипт тут поможет.
Здравствуйте, Calc, Вы писали:
C>>За новый софт на PHP надо расстреливать без разговоров. C>весь мир с ним работает, а на RSDN надо расстреливать. Я уже вижу тут застой в IT мозгах. C>аргументы в пользу расстрела будут?
Да. PHP.
Это самый уродливый язык в природе. Если хочется чего-то динамического — можно взять тот же Питон, он хотя и не сильно хорош, но лучше ПХП на порядок.
Здравствуйте, Ватакуси, Вы писали:
C>>1) Динамичности. Любая реальная большая кодовая база становится крайне лохматой, даже если писать в стиле Питон-с-классами и избегать магии в виде декораторов и прочих страшностей. Тестов обычно бывает недостаточно. В>Самый мой крупный проект содержал более 3-х миллиардов строк на питоне. Работало там 7 тысяч программистов. В>Кол-во бардака было такое же как и в проекте на яве. Сравнивомогу по размеру.
Я участвовал в миграции проекта с Питона на Go. Количество бардака после миграции сильно упало, а качество увеличилось. Количество строк там было меньше, в районе десятка миллионов. Миграция заняла несколько лет.
Понятно, что при желании и должной дисциплине можно и на ассемблере всё писать. Но зачем?
C>>2) Однопоточности. Это реально проблема — сервер придётся запускать в виде нескольких процессов, что делает невозможным вещи типа разделяемого кэша. В>Никогда не нужно. CPython, корутины, сервлеты и вообще торнадо. или твистед. числодробилки не берём во внимание. Их менее 1%
Брехня это всё. Оно всё равно будет однопоточным, асинхронность просто размажет тормоза по всем клиентам.
Корутины в текущих реализациях Питона относятся к категории "do not use" из-за "coloured function problem".
C>>3) Интерпретируемости. Если нужно делать высокоскоростные сервисы, то можно забыть про высокоуровневые библиотеки типа SQLAlchemy. Теоретически на подходе есть PyPy, но он всё ещё не дорос. В>Алё. CPython и компиляция в ц++.
Эээ... Ты ТОЧНО писал на Питоне? CPython — это интерпретатор Питона. Есть Cython, но он крайне ограничен и требует писать на (фактически) С с питоновским синтаксисом.
К нему прилагается сложность распространения — если хочется распространять бинарные артефакты, то с Cython начинаются прыжки и ужимки из-за его мега-умности.
C>>4) Уродский инструментарий. Питон до сих пор нормально ниасилил пакетные менеджеры, так что распространение и установка программ на нём часто весьма нетривиальна. XKCD в тему: https://xkcd.com/1987/ В>Это о чём? В>Докер, хренокер — одной пяткой. Уставновка на виртуалку или в процессе разворачивания — элементарно.
Даже с Докером хорошей практикой является создание наиболее лёгкого образа, без компиляторов и сред разработки внутри.
C>>При этом начинать проект легко, да. Сначала код пишется как будет сам. Но вот потом всё становится очень уныло. Я и сам попадал в эту ловушку, и в других проектах тоже встречал. В>С индусами что-ли работал?
В том числе и с ними (разных национальностей), как на любом большом проекте.
C>>Да, всё то же относится к Ruby и немного меньшей степени к NodeJS (он хотя бы быстрый). В>Угу, особенно яваскрипт тут поможет.
JS нынче чаще всего заменяют TypeScript, который более-менее адекватен по сравнению с Питоном.
Здравствуйте, Буравчик, Вы писали:
C>>1) Динамичности. Любая реальная большая кодовая база становится крайне лохматой, даже если писать в стиле Питон-с-классами и избегать магии в виде декораторов и прочих страшностей. Тестов обычно бывает недостаточно. Б>Динамичность добавляет не только проблем, но и большое количество плюсов. Особенно при работе с JSON и другими слабо структурированным вещами.
Не надо работать со слабо структурированными вещами.
Б>Ошибки типов часто выявляются с помощью IDE и аннотаций типов (их использование в больших проектах крайне желательно).
Но проще всего сразу взять типизированный язык.
C>>3) Интерпретируемости. Если нужно делать высокоскоростные сервисы, то можно забыть про высокоуровневые библиотеки типа SQLAlchemy. Теоретически на подходе есть PyPy, но он всё ещё не дорос. Б>Прикладное программирование это в основном склеивание библиотек. Для клея интерпретируемости вполне хватает.
Вот только библиотеки обычно сами на Питоне. И оно всё равномерным образом тормозит.
C>>4) Уродский инструментарий. Питон до сих пор нормально ниасилил пакетные менеджеры, так что распространение и установка программ на нём часто весьма нетривиальна. XKCD в тему: https://xkcd.com/1987/ Б>Неплохой инструментарий. Для проектов используются виртуальные окружения с нужной именно тебе версией питона и библиотек, это стандарт де-факто. Pycharm отлично работает и все это очень хорошо поддерживает.
venv не решают проблем пакетных менеджеров. Это просто способ лёгкой изоляции окружения, который местами глючит.
C>>Так что пожалуйста, не надо использовать Питон для чего-то сложнее скрипта в сотню строк. Б>Уверен, что смело можно писать и тысячи строки и десятки тысяч.
Можно. И миллионы строк можно. Но не нужно.
Здравствуйте, Dair, Вы писали:
D>Наверно, есть что-то ещё.
D>Сервер надо чтобы раздавать контент пользователям. D>Контент сравнительно небольшой — ну десятки мегабайт. Пользователей тыщ 100.
Здравствуйте, Cyberax, Вы писали:
Б>>Ошибки типов часто выявляются с помощью IDE и аннотаций типов (их использование в больших проектах крайне желательно). C>Но проще всего сразу взять типизированный язык.
Продуктивность по-сравнению с питоном садится в разы. Проверенно не на убогом Котлине, а на Скале.
Здравствуйте, novitk, Вы писали:
C>>Но проще всего сразу взять типизированный язык. N>Продуктивность по-сравнению с питоном садится в разы. Проверенно не на убогом Котлине, а на Скале.
Не садится. Продуктивность старой недоброй Java в разы больше, чем у Питона для более-менее размерного проекта. Просто за счёт надёжной навигации в IDE и более удобного отладчика.
Scala? LOL.
Продуктивность определяется не тем, какие в языке есть средства метапрограммирования и мега-супер-фичи, а удобством обычной разработки и отладки. Т.е. как быстро подключить библиотеки, как делать навигацию по исходникам (простейший Find Usage спасает часы разработки) и как отлаживать.
Краткость написания list comprehensions — где-то на 20-м пункте по важности.
Здравствуйте, neFormal, Вы писали:
C>>1) Динамичности. Любая реальная большая кодовая база становится крайне лохматой, даже если писать в стиле Питон-с-классами и избегать магии в виде декораторов и прочих страшностей. Тестов обычно бывает недостаточно. F>это если с дизайном кода плохо
С ним всегда плохо.
F>в статике ровно то же самое будет
До такой степени — не будет. Просто за счёт типов.
C>>4) Уродский инструментарий. Питон до сих пор нормально ниасилил пакетные менеджеры, так что распространение и установка программ на нём часто весьма нетривиальна. XKCD в тему: https://xkcd.com/1987/ F>вообще, все давно проекты держат в локальных окружениях для конкретного проекта
venv — это просто Докер для бедных. Он не решает проблем версирования и повторяемых сборок.
F>поэтому и таким сложностей не испытывают
Те кто пишет что-то серьёзное — испытывают.
F>короче, это всё от незнания
Я продал два стартап с кодовой базой на Питоне почти на 100%.
Здравствуйте, Cyberax, Вы писали:
C>Продуктивность определяется не тем, какие в языке есть средства метапрограммирования и мега-супер-фичи, а удобством обычной разработки и отладки. Т.е. как быстро подключить библиотеки, как делать навигацию по исходникам (простейший Find Usage спасает часы разработки) и как отлаживать.
Имхо, с этим, в питоне все очень хорошо. В PyCharm и отладчик норм, и навигация есть, и Find Usage, и библиотеки легко подключаются.
Здравствуйте, Буравчик, Вы писали:
C>>Продуктивность определяется не тем, какие в языке есть средства метапрограммирования и мега-супер-фичи, а удобством обычной разработки и отладки. Т.е. как быстро подключить библиотеки, как делать навигацию по исходникам (простейший Find Usage спасает часы разработки) и как отлаживать. Б>Имхо, с этим, в питоне все очень хорошо. В PyCharm и отладчик норм, и навигация есть, и Find Usage, и библиотеки легко подключаются.
Отладчик в PyCharm не может нормально работать с gevents или в удалённом режиме.
Find Usages работает за счёт эвристик и очень часто ничерта не находит, особенно если надо смотреть библиотечный код.
Здравствуйте, Cyberax, Вы писали:
F>>это если с дизайном кода плохо C>С ним всегда плохо. F>>в статике ровно то же самое будет C>До такой степени — не будет. Просто за счёт типов.
в типах ты просто не всё можешь сделать. поэтому у тебя меньше точек внимания, голова напрягается меньше, и кажется, что ты всё контролируешь
на самом деле это как отрезать себе ноги с обоснованием "всё равно я не бегаю"
C>>>4) Уродский инструментарий. Питон до сих пор нормально ниасилил пакетные менеджеры, так что распространение и установка программ на нём часто весьма нетривиальна. XKCD в тему: https://xkcd.com/1987/ F>>вообще, все давно проекты держат в локальных окружениях для конкретного проекта C>venv — это просто Докер для бедных. Он не решает проблем версирования и повторяемых сборок.
дык он для разработки, лел
с докером его можно сравнить только от большой фантазии
F>>поэтому и таким сложностей не испытывают C>Те кто пишет что-то серьёзное — испытывают.
у тебя "серьёзное" начинается от сотни строчек кода. а это даже не смешно.
конечно, неосиляторы испытывают сложности, это факт. но это с любыми технологиями
F>>короче, это всё от незнания C>Я продал два стартап с кодовой базой на Питоне почти на 100%.
Здравствуйте, kov_serg, Вы писали:
D>>Наверно, есть что-то ещё. D>>Сервер надо чтобы раздавать контент пользователям. D>>Контент сравнительно небольшой — ну десятки мегабайт. Пользователей тыщ 100. _>erlanglinks
вообще, для такого жрланг лучше не брать.
непривыкшему человеку будет неудобен синтаксис, непонятна платформа. возможно, elixir будет лучше.
оно хорошо для распределённых систем, как эдакий оркестратор.
