Велика кількість бібліотек, сувора динамічна типізація та проста логіка. Розробники — про переваги та недоліки Python

Python — одна з найпопулярніших мов програмування, про що свідчать різноманітні рейтинги. За даними DOU, з 2020 року Python — улюблена мова програмування респондентів, проте в комерційному використанні вперше за декілька років частка Python знизилась.

Ми запитали в досвідчених Python-розробників про те, за що вони люблять мову, а що хотіли б покращити.

Пишіть у коментарях, про яку мову хочете прочитати далі.

«На Python можна швидко створювати програми. Бібліотеки досить розвинені, мова високорівнева»

Роман Могилатов, VP of Engineering at Portside, Inc.

З Python я працюю з 2013 року. Ознайомився з мовою, вже маючи шість років комерційного досвіду в розробці. Моїм першим продакшн-проєктом на Python був асинхронний високонавантажений сервіс на фреймворку Twisted. Не питайте, чому так було потрібно. Хто писав на Twisted 13-14 під Python 2.7, знає: асинхронне програмування на бекенді вимагає часу, щоб звикнути, плюс треба зрозуміти, як працюють асинхронні співпрограми та реактор.

Попри високий поріг входу в Twisted, сама мова Python дуже сподобалася. Освоюючи кожну нову конструкцію, все більше закохувався в неї. З кожним новим завданням поринав усе глибше — пам’ятаю, яким відкриттям були metaclass, модуль inspect, list comprehensions та генератори. Адже раніше я писав на PHP, і там цього всього не було.

З 2013 року вдалося випробувати мову для різних цілей: для побудови API, мікросервісної архітектури, асинхронних застосунків, ETL-систем, Telegram-бота для пошуку менторів, найпопулярнішого Dependency Injection фреймворку, переписування його на Cython, а також у проведенні понад 300 технічних інтерв’ю.

Отже, які особливості я зауважую?

У Python сувора динамічна типізація — це коли «42» + 42 викидає помилку. З несуворою типізацією результат буде 84 або 4242, залежно від мови. Мені ця сувора типізація в Python подобається, вона допомагає уникнути помилок, і код читати легше.

Динамічна типізація — це коли foo = 42, а не int foo = 42. Можна змінити тип змінної після її створення: foo = «42», а потім foo = 42. Це корисно, коли наводиш типи перед обчисленнями foo = int(foo ). З іншого боку, можна зробити так: foo = 42, а потім foo = {}. Python це дозволяє, але я намагаюся так не робити. Коли змінна змінює тип на несумісний, то такий код важко виправляти.

У Python мені завжди подобалося, що не потрібно вказувати тип, але останнім часом я перестав цим користуватися. У Dependency Injector я обираю Cython і майже всюди вказую типи для підвищення продуктивності. Коли пишу на Python, використовую mypy. Так звик, відмовлятися не хочу.

Я завжди вважав, що mypy — це більше про engineering perfection. Пам’ятаю своє здивування, коли під час першого використання вдалося знайти кілька справжніх помилок.

Підкреслення як спосіб інкапсуляції. Якщо ім’я методу, функції або властивості Python починається з підкреслення «_foo», значить воно protected — його не можна використовувати за межами класу. Хіба що дуже хочеться: мова не викине помилку, якщо ви зробите foo._bar().

Але ми в Python-спільноті домовилися так не робити. І не робимо. У будь-якого Python-розробника, який побачить foo._bar(), почне посмикуватися око і з’явиться відчуття, що тут щось не те. На код-рев’ю вам нагадають, що так робити не варто, тому що це порушує інкапсуляцію і може призвести до помилок.

Виходить, що ключового слова protected немає, а його функція виконується — ідеальне рішення за TRIZ. Я завжди відчуваю піднесення, коли про це розповідаю. Тобто можна просто домовитися і прибрати ціле ключове слово з мови? Це ж так круто, домовмося ще про щось!

Сфера застосування. Я ознайомлений з Python з погляду бекенд-розробки. Але сфера застосування мови значно ширша. Python хороший (або навіть найкращий) для роботи з даними, на ньому можна написати десктоп GUI, а незабаром, може, і фронтенд (привіт, WASM, pyodide). Асинхронна мережна програма, CLI-скрипт, плагін для Sublime — без проблем.

Думаю, це сильна сторона — більше користувачів, бібліотек і підходів — усе це розвиває та зміцнює мову.

Продуктивність. За продуктивністю Python — не майстер спорту. Принаймні його еталонний інтерпретатор CPython. Python-розробник скаже, що продуктивність — не завжди вузьке місце, є інші інтерпретатори (PyPy, Jython тощо), і взагалі, проблемні місця можна переписати на Cython/C/C++ або Rust. Це так, щоправда, краще б усе просто працювало швидко з «коробки». I have a dream that one day.., як казав Мартін Лютер Кінг.

Коли я переписував Dependency Injector на Cython, приріст у швидкості був приблизно в 50 разів. Фактично DI створював об’єкти з «ін’єкціями» так само швидко, як якби я вказав їх вручну. Зараз перевірити неможливо, тому що немає точного аналога DI на чистому Python, але думаю, порядок цифр такий самий.

Багатопотоковість, мультипроцесинг та IPC. У багатопотоковості в Python є відома особливість — GIL. GIL накладає певні обмеження на застосування потоків. Він робить їх марними, але якщо не знати цю особливість, можна значно погіршити продуктивність програми навіть у порівнянні з роботою в одному потоці. Користь від GIL теж є — про це завжди можна запитати на інтерв’ю :)

Мультипроцесинг у Python, на мій погляд, зроблено класно. З системного погляду все організовано правильно, API є високорівневим і зрозумілим, всі потрібні перемикачі на місці. IPC (Inter Process Communication): у стандартній бібліотеці є реалізація черги, shared memory об’єктів і всіх необхідних примітивів синхронізації.

Поширеність. Зараз моя робота — менеджерська, і частина моїх обов’язків — це пошук спеціалістів. У Python тут все дуже добре. У 2021 році мова стала найпопулярнішою за версією сайту Statistics and Data.

Також помітив, що мова стає все популярнішою за статистикою відвідування документації з Dependency Injector. Щороку щонайменше на 30%.

Скриншот з Google Analytics

Вважаю популярність мови великим плюсом як для фахівців, так і для бізнесу.

Швидкість розробки. На Python можна швидко створювати програми. Бібліотеки досить розвинені, мова високорівнева. На фреймворках Django та REST можна за місяць зробити REST API для кількох десятків сутностей. Django-адмінка — у подарунок. Так, до неї багато претензій, але бізнесу подобається.

«Щоб закрити слабкі сторони Python, ми у вакансіях вказуємо, що потрібні знання анотацій типів, а також вміння писати автоматизовані тести»

Володимир Обризан, технічний директор Design and Test Lab, к. т. н.

Популярність мови виражається в кількості претендентів на позицію Python-програміста та у великій кількості технічної документації та рішень на Stack Overflow.

Сильні сторони мови: низький поріг входження для програмістів-початківців, стандартна бібліотека та велика кількість пакетів з відкритим вихідним кодом. Таким чином, можна підібрати готове рішення під практично будь-яке завдання.

Наприклад, в одному з наших проєктів з аналізу та моделювання інженерних мереж міст треба було вирішити завдання, пов’язані з алгоритмами на графах: пошук найкоротшого шляху, декомпозиція, досяжність. Ми скористалися готовою бібліотекою NetworkX, в якій реалізовано сотні алгоритмів та операцій над графами, заощадили багато часу, а замовнику — грошей.

Окремо зауважу про підтримку у вигляді Python SDK від різних вебсервісів (наприклад, бібліотека boto3 для роботи з будь-яким сервісом Amazon Web Services).

Серед недоліків — те, що в ніші розробки вебсайтів і вебсервісів Python більше асоціюється з невеликими програмами, MVP, тому є небагато джерел інформації, як розробити великі програми, наприклад інтегрувати безліч доменів і сервісів.

А ще тут є анотації типів (type hints): проанотований код не дає гарантії, що там немає помилок типізації, адже типізація перевіряється тільки на етапі введення інструкцій і під час лінтингу, а в момент виконання можна підставити об’єкт будь-якого типу (інтерпретатор Python каже: «Я все це хаваю, у мене немає вибору» :)

У результаті, щоб закрити слабкі сторони, ми у вакансіях вказуємо, що потрібні знання анотацій типів, а також вміння писати автоматизовані тести. А якщо кандидат їх не знає, то доучуємо на етапі адаптації. Подітися нікуди — на код-рев’ю ми не приймаємо код без анотацій і тестів.

«Python став основою сучасних мов програмування. Він показав, що спрощувати синтаксис і знижувати поріг входження — це правильно»

Михайло Кашкін, Founder в Okumy та автор курсів з Python

Я розглядаю Python на кількох рівнях: як програміст, який колись виділив час, щоб його вивчити, і як менеджер, який вибирає Python як технологію. Почну з того, чому це моя улюблена мова.

Стабільність. Основи Python мало змінилися протягом останніх 15–20 років, отже, знання мови не знецінюються, на відміну від багатьох інших технологій. Були деякі зміни, пов’язані з переходом з Python 2 на Python 3, але незначні.

Простота. Спочатку програмування було для людей з вищою освітою. Але Python показав, що зрозуміле краще, ніж незрозуміле. У синтаксисі Python дуже мало складних рішень. Гвідо ван Россум, творець мови, охороняв її від впливу різних модних віянь. Python має філософію — «Дзен Python» (The Zen of Python), і вона вплинула на майже всі нові мови програмування. Код Python дуже зрозумілий, й інші мови теж прагнуть спрощувати синтаксис.

Чітка структура. Раніше вважали, що це не актуально, мовляв, навіщо ж там мільйони пробілів. Але майже всі нові мови програмування випускають із вбудованим форматувальником, який робить те саме, що й Python.

Багатий вибір інструментів. Мову використовували в науковому середовищі, де заведено втілювати колаборації, працювати спільно над чимось. І замість того, щоб створювати 10–15 технологій, які конкуруватимуть, люди з різних середовищ об’єднувалися над однією і доводили її до пуття. Якщо порівнювати з якоюсь екосистемою — Perl, PHP, JavaScript, то там багато бібліотек повторюють ту саму функціональність, а Python спочатку позиціонували як «клей» між технологіями. Якщо ми говоримо про бази даних, то складно знайти таку, яка б не мала драйверів на Python.

Недоліки. Перше — це те, що немає широкої підтримки мобільної розробки. Хоча я гадаю, що це питання часу.

Друге — багато хто називає Python повільним. Я не згоден. Щоб зрозуміти ціну «повільності», спочатку варто усвідомити, яку роль відіграє саме мова у конкретному бізнесі.

Наприклад, візьмемо Djinni, де колись були проблеми з продуктивністю. Припускаю, що його обслуговують два сервери, і якби ми використовували якусь технологію, яка збільшила б швидкість у 500 разів і достатньо було одного сервера, то, найімовірніше, протягом року Макс Іщенко на своєму проєкті Djinni зміг би заощадити дуже маленьку суму грошей. У нього є співробітники, обороти, рекламні компанії тощо — і це великі статті витрат. Оренда серверів коштує недорого — наприклад, на сайт заходить 10 тисяч людей на день, і його може обробляти сервер за 30 євро на місяць. Якщо ти прискориш, то зможеш заощадити зовсім небагато.

Програмісти прагнуть досконалості, але для бізнесу збільшення продуктивності кінцевого коду має невелику цінність. Набагато важливіша швидкість розробки. І Python у цьому сенсі є дуже продуктивною мовою.

Бізнес вибирає Python, тому що він показує результат в стислі терміни. Тому я не розглядаю швидкість Python як суттєвий недолік.

У світі досі використовують Ruby, який у 100 разів повільніший за Python. І він чомусь продовжує жити. А Python при правильному використанні можна порівняти за швидкістю з Go, яку вважають високопродуктивною мовою.

Серед недоліків Python виділяють те, що немає суворої типізації, і я частково погоджуся з цим. Також неможливо використовувати Python всередині браузера для побудови клієнтської частини. Весь проєкт зробити на Python, включаючи UI, не вдасться.

«Велика безкоштовна екосистема бібліотек і обмежена здатність до рефакторингу»

Сергій Зайченко, архітектор-консультант у Design and Test Lab, R&D Engineer у Sigasi, к. т. н.

Python добре вписується в проєкти, де домінує модель обчислень async/await, тобто одночасні запити з тривалими очікуваннями зовнішніх систем через мережу, очікування сховищ тощо. Навпаки, застосовувати його для завдань з інтенсивними обчисленнями на CPU безглуздо, хіба що йдеться про інтеграцію бібліотек з Python API, але нативною реалізацією на C/C++.

Сильні сторони:

  • Нема потреби застосовувати платні інструменти для розробки, платні фреймворки, application-сервери для деплою тощо. Є велика безкоштовна екосистема бібліотек, фреймворків, а також взаємозамінних альтернатив. Принаймні на початкових етапах проєкту можна обійтися мінімальними витратами на інструменти.
  • Багата екосистема для спеціалізованих ніш, таких як AI та Data Science. Мабуть, найкращий вибір навчальних ресурсів, які не потребують тривалої адаптації та занурення.

Слабкі сторони:

  • Обмежена здатність до рефакторингу. Навіть з анотаціями типів та щільним покриттям модульними тестами не завжди виходить рефакторити без регресій, особливо якщо в коді використано мовні засоби на кшталт **kwargs або нетипізовані словники, де вже безсилий лінтинг.
  • Немає стандартного засобу застосування залежностей out-of-the-box. Деякі бібліотеки або поєднуються з типізацією, або вимагають написати стільки ж boilerplate-коду, скільки організовувати використання залежностей самостійно.
  • Оскільки типізація поверхова і необов’язкова, Python критично залежить від покриття коду модульними тестами. Якщо код не активізовано, не факт, що він взагалі коректний навіть на рівні відповідності імен методів, які є в об’єкті. Високе покриття модульними тестами обов’язкове.

«Python дають вивчати дітям як вступ до програмування»

Оксана Лобко, Co-founder в achievki.io

Python — майже як псевдокод, має мінімалістичну чисту логіку. Зараз його дають вивчати дітям як вступ до програмування.

Натрапляла на пораду для підготовки до FAANG-інтерв’ю — вивчити Python лише для того, щоб швидко і правильно вирішувати алгоритмічні задачі, що є найскладнішим бар’єром для отримання оферу в FAANG. Чому саме Python? Бо буде менше коду і чиста логіка.

У Python є безліч бібліотек для будь-яких завдань. На ньому більшість проєктів вдасться будувати найшвидше.

Коли вперше побачила код djinni, то здивувалась, як там багато бізнес-логіки, автоматизації процесів та спеціальних кейсів і як просто це все описано. Збоку було видно лише вершину айсбергу. Якби хтось захотів «усе переписати» і зробити технічне завдання на djinni, то було б значно більше тексту, ніж просто взяти Python-код.

Цієї мови мені вистачає для всього на бекенді. Але люди кажуть, що на highload-частинах треба окремі шматки коду переписувати на чомусь швидшому — Cython, Golang, Rust, C.

«Python можуть використовувати не тільки програмісти»

Святослав Потєєнко, Team Lead, Senior Python Developer, DataArt

У 2015 році мій знайомий купив квартиру, а його відповідь на моє запитання «Як заробив?» була «Python». Так я збагнув, що час переходити з PHP на мову з більшим рейтом.

Одна українська компанія мала потребу в автоматизації обліку, тому я почав розбиратися з Django. Система трансформувалася в повноцінну ERP, пережила багато автоматизаторів, які хотіли її замінити, й працює досі.

Для мене Python — як швейцарський ніж. На ньому швидко можна розгорнути адмінку вебсайту, провести експеримент з даними або побудувати лінію обробки даних у хмарі.

Коли я розробляв ERP-систему 2015 року, я взагалі не знав, за що берусь і які кінцеві вимоги будуть до неї. Але Django дала змогу реалізувати всі побажання замовника у довгостроковій перспективі: SMS-розсилки, фінансові звіти, друк платіжок та облік відносин з клієнтами тощо.

Для іншої задачі потрібно було побудувати систему для збору біржових даних. При цьому вона мала стабільно працювати у нестабільних умовах. Прототип вдалося запустити за тиждень!

Загалом я рекомендую використовувати Python для обробки даних, бекенду вебсайтів та, звісно ж, data-аналітики.

За що я люблю Python? Хотів відповісти «стильно, модно, молодіжно», але подумав, що зараз є більш популярні мови. У 2015 році Python був не настільки широковживаним. Це була серйозна і структурована мова програмування, що давала впевненість у тривалому терміні життя написаних продуктів. Думаю, що того року мені пощастило потрапити в правильне місце у правильний час на початку цього тренду.

Люблю Python за привітне ком’юніті та базові речі: Django для швидкої підготовки CRUD, зручний пакетний менеджер і багато бібліотек на всі випадки життя.

Ще одна фішка полягає в тому, що Python можуть використовувати не тільки програмісти. Є багато інструментів, які дають змогу застосовувати його для аналітики та дослідження даних в інтерактивному режимі (Jupyter Notebook, pandas).

За що не люблю Python? Найперше — невелика швидкість обробки даних, якщо порівняти з іншими компільованими мовами. Але на моїх проєктах завжди можна налаштувати паралелізацію: розбивати задачі та масштабувати кількість одночасних процесів.

У 2021 році навколо Python виник хайп: всюди почала з’являтися реклама курсів, якість яких дуже сумнівна (всім обіцяють підозріло швидкий результат). Хоча насправді далеко не кожен може опанувати програмування або аналітику з нуля, маючи одне лише бажання заробити, а терпіння вчитися роками при цьому не вистачає.

Це призвело до того, що на ринку з’являється багато випускників, які не можуть виконати просту задачу на реальних проєктах. Це збільшує навантаження на команду, яка мусить дотягувати цю людину до потрібного рівня та одночасно робити все за неї.

Помічаю, що у початківців виникають складнощі з розумінням базових системних речей: як працює HTTP-протокол, безпека вебсайтів, процеси, потоки, що і де краще використовувати. А універсальна порада для всіх — намагайтеся писати свій код з думкою, що він буде написаний один раз, а прочитаний десять разів. Це стосується і коментарів, прийнятних назв змінних і загалом структури програми.

«Мене захоплює широкий вибір напрямів розробки, який дає Python»

Михайло Годісь, Software Engineer в N-iX

З Python я стикнувся наприкінці студентських років, коли потрібно було підготувати дипломну роботу. Оскільки проєктом була система з вебінтерфейсом, тоді на думку спав саме Python, який я вивчав під час поїздок у метро. Бажання рухатись саме в цьому напрямку підкріпили кілька переглянутих відеоуроків про Django.

Звісно ж, тепер кумедно згадувати ті фактори, якими керувався при виборі технологій, проте від того часу на комерційному рівні здебільшого стикався саме з Python. За понад чотири роки використання вдалось випробувати мову з різних сторін та у різних галузях (fintech, healthcare, cybersecurity, retail).

Python уже давно завоював прихильність розробників за свою простоту, швидкість роботи та чудовий синтаксис. Але мене найбільше захоплює широкий вибір напрямів розробки, який дає ця мова.

Ти початківець і хочеш розібратись? Без питань, веброзробка — чудовий напрям, де є проєкти будь-якої складності. Хочеш бути ближчим до науки або спробувати свої сили у чомусь новому? Data Science та Machine Learning до ваших послуг. А як щодо нижчих рівнів, можливо, роботи з приладами? Більше ані слова — хапай Raspberry Pi й твори. Якщо ж усе це поєднати, то можна тільки уявити, які цікаві проєкти отримаємо.

Варто відзначити Python-спільноту, завдяки якій доступна велика кількість бібліотек. Окрема подяка всім тим авторам, які підтримують документацію в стандартизованому та зрозумілому вигляді. Все це дає змогу зайнятися новими технологіями за лічені хвилини й робить поріг входження для новачків низьким, навіть якщо ви вперше бачите ту чи іншу бібліотеку.

Проте є й інша сторона Python — open-source мови. Неодноразово доводилось стикатися з тривалими кодовими детективами та зрештою розумінням, що 3rd party бібліотека, з якою працюєш, містить помилки й потрібно щось із цим робити. Не наважуюсь назвати це недоліком, тому радше скажу, що це особливість. Варто пам’ятати про це й частіше заглядати у код самих бібліотек або шукати відповідне issue в репозиторіях розробників, щоб не витрачати час на пошуки проблеми самостійно.

Також не забувайте, що Python — інтерпретована мова, і мізерні помилки у коді можуть призвести до серйозного головного болю. Думаю, багато хто потрапляв у ситуацію, коли пропущена кома в списку рядків призводила до годинного (хто більше?) пошуку проблеми та щирого нерозуміння, що відбувається. В такий момент розумієш важливість хорошого покриття коду тестами.

Наостанок зауважу, що через свої особливості Python не дає змоги зрозуміти деяких базових понять у світі програмування, як-от інші мови. Наприклад, не розкриває деталей структур даних і має своєрідне поняття про багатопотоковість процесів. Зрозуміло, що схоже мають пояснювати під час навчання в університеті або на відповідних курсах, проте ні для кого не секрет, що доволі багато людей починають свій шлях іншим способом.

Python — чудова мова, яка, як і будь-яка інша, при вмілому використанні стане надійним партнером у ваших цілях. Всім дзену!

Маєте важливу новину про українське ІТ? Розкажіть спільноті. Це анонімно.І підписуйтеся на Telegram-канал редакції DOU

👍ПодобаєтьсяСподобалось13
До обраногоВ обраному7
Підписатись на автора
LinkedIn



54 коментарі

Підписатись на коментаріВідписатись від коментарів Коментарі можуть залишати тільки користувачі з підтвердженими акаунтами.

Интересно, динамически типизированный код от «ускоренно вошедших» и проревьювленный такими же «ускоренными» там ничем не попахивает?
P.S. Кто-то считал стоимость саппорта этого чудо языка?

Якщо ви прийшли із певними патернами, які чужі для вас, та починаєти вимірювати якість по власних показниках, то звісно ж ваші «цифри» будуть смішними для вас, або пахнути чимось неприємним. Але, для деяких задач ваша статична типізація, кодрев’юви та все інше, буде самою неефективною реалізацію в світі. Там де ви пишете кілометр коду, пітоняшки пишуть один скрін, а решту часу грають на консольці.

После того как однажды отрефакторил проект на Скале, проникся уважением к статической типизации. После этого желание тратить время на динамически типизированные языки куда-то испарилось.

Краще вже Рубі з цієї опери брати. Він не повільніший, а синтаксис приємніший.

Ох...

> У Python сувора динамічна типізація

Краще казати не «сувора», а «сильна».

> Виходить, що ключового слова protected немає, а його функція виконується — ідеальне рішення за TRIZ. Я завжди відчуваю піднесення, коли про це розповідаю. Тобто можна просто домовитися і прибрати ціле ключове слово з мови? Це ж так круто, домовмося ще про щось!

Це «ідеальне рішення» швидко перестає бути ідеальним, коли треба змінити видимість члену обʼєкту. Ось тогда швидко помічаєш проблему... а коли засоби рефакторингу не розуміють всі випадки використання, а коли ще імʼя буде десь динамічно створюватись щоб потім якимось getattr знайти значення... біль, біль і біль.

> який побачить foo._bar(), почне посмикуватися око і з’явиться відчуття, що тут щось не те

А повинно помічатись не на код-ревʼю, а при компіляції.

> Python-розробник скаже, що продуктивність — не завжди вузьке місце, є інші інтерпретатори (PyPy, Jython тощо), і взагалі, проблемні місця можна переписати на Cython/C/C++ або Rust

1. До чого тут Rust, C і інші, коли FFI недешевий?
2. PyPy, Jython і інші несумісні з Cython. Або одне — або інше.

А повинно помічатись не на код-ревʼю, а при компіляції.

тут цікаво чому програміст того не бачить :)
коли звертається до foo._bar()

а коли бачить, і все одно звертається, то який варіант:
— він йолоп
— йому начхати
— спроектовано так, що якби не міг звернутися — то прийшлось би копіпастити той класс, щоб замінити на свій варіант, а потім інжектити його, і... зламати вже купу іншого коду своїм варіантом

я от щиро вдячний що в коді ліби знайшов:
function objectToDocumentXML ....  // If user supplies XML already, just use that.  XML Declaration should not be present.         if (params && params._xml)  return params._xml;

цього в документації немає
а як знайшов? та мені треба через купу слоїв абстракції пропхати свій варіант, шукав — що копіпастити. або дописувати свій патчер коду ліби, прив’язувати до пакетного менеджера, щоб при оновлені — патчив. робив і такє.
а от на «Java» — то був би капець скільки прийшлось би переписати отих слоїв, коректно заінжектити, бо
компілятор лаявся б

а через деякий час інший програміст дивився б на оте нахаращення, та й думав — «ну і індус понаписав, копіпастер, * * * »...

цього в документації немає

Тобто хакнув в обхід дозволеного інтерфейсом класу? Ну герой, чо.
А не намагався знайти, чому прямого доступу немає?

І чи буде після такого прямого доступу виконуватись контракт класу, на який спираються усякі аналізатори?

або дописувати свій патчер коду ліби, прив’язувати до пакетного менеджера, щоб при оновлені — патчив. робив і такє.

Взагалі в своєму пакеті можеш зробить будь-який патч. Саме так і треба робити, а не «привʼязувати до пакетного менеджера». (Якщо взагалі треба патчити...)

«ну і індус понаписав, копіпастер, * * * »...

Ага, а зараз інший індус просто лізе у нутрощі обʼєкту.

Тобто хакнув в обхід дозволеного інтерфейсом класу?

цей хак закладений у код ліби
кому треба — знайде.

мені треба — я й знайшов. і автори — коментом написали

А не намагався знайти, чому прямого доступу немає?

так і знайшов. дивлячись у код ліби

І чи буде після такого прямого доступу виконуватись контракт класу, на який спираються усякі аналізатори?

то проблеми аналізаторів, а не мої

Взагалі в своєму пакеті можеш зробить будь-який патч

я про — в чужому

бо не влізеш, там захардкожено.

Ага, а зараз інший індус просто лізе у нутрощі обʼєкту.

я сапортив код індусів на Java
індусу компілятор не завадить хні наробити

і зараз — маю оті самі проблеми з системою яка на православній Java — але веде себе не по документації та семантиці SOAP. причому ще й у різних випадках по різному хардкодили.

але ж — компілятор не лаявся, і тести зелені. все ок, премію індусам!

P.S.

спроектовано так, що якби не міг звернутися — то прийшлось би копіпастити той класс, щоб замінити на свій варіант, а потім інжектити його, і... зламати вже купу іншого коду своїм варіантом

і інжектами

оце й частенько називається з пихою
Великий Рефакторінг

бо
private function bar
треба на свій варіант замінити...

а було б
function _bar
на мові з дін типизацією
то в залежності від мови та сценарію створення об’єкту
трійко рядків, і тільки для того випадка, коли треба така заміна, так що інший код не зламається таким «хаком»

але так, не буде чим хвалитися, великого рефакторінгу не треба

Python-розробник скаже, що продуктивність — не завжди вузьке місце, є інші інтерпретатори (PyPy, Jython тощо), і взагалі, проблемні місця можна переписати на Cython/C/C++ або Rust

Так, після всього цього пайтона можна найняти с++ дева, який перепише все на с++, Це едина перевага пайтона.

Так, після всього цього пайтона можна найняти с++ дева, який перепише все на с++, Це едина перевага пайтона.

Ну тобто швидка прототипізація? Може, і так.
Але ось захотів написати маніпулятор сховищем YANG. Пітоновий модуль є, але для нього ще треба скомпілювати дві бібліотеки на C і подложити йому їх при встановленні. Поки що не осилив...

Ми так і робимо деколи. Прототип алгоритму на пітоні, в тестуванні і продакшині на С++.

Про такі речі мабуть не прийнято публічно зізнаватися, але — ≈ 10 років тому я, на посаді програміста, всерйоз задавався питанням щодо того, чи програмування — це взагалі «моє». А тоді я дізнався про Python, і життя налагодилося. :)

DOU, ви засранці. :) Мої контакти насправді зовсім нескладно знайти онлайн, щоби запитати мою думку щодо того, що скрін мого (OK, публічного) коментаря буде опублікований на ресурсі, що має 62k+ читачів. Без контексту.

Ігоре, написала вам на пошту!

Okay, значить, трохи контексту до мого дивного коментаря.

На той час я був зайнятий в основному підтримкою старих і вкрай криво написаних проєктів на PHP (починаючи з 4-ї версії) і Delphi. PHP-шні проєкти були пекельною мішаниною HTML, PHP і SQL коду, жодні фреймворки не використовувалися. Код деяких проєктів на Delphi виглядав як пачки процедур названих типу TForm17.Button49Click і т.п. — словом, все, як ми любимо. :)

Компанія активно оптимізувала витрати, тому наш відділ (відділ розробки програмного забезпечення) плавно відходив від програмування взагалі, натомість на нас скидали задачі по розгортанню і впровадженню програмних продуктів, розроблених іншими вендорами. І, зважаючи на те, що радості від роботи з кодом у мене на той час було, м’яко кажучи, мало, я не дуже з того приводу засмучувався.

Бо після 5+ років боротьби з Delphi і PHP вже почав думати, що:

1. Програмування це напевно завжди біль
2. Тримати складність під контролем напевно неможливо (якщо хтось мав досвід з PHP без фреймворків — 100% зрозуміє, про що я.. :) )

Про Python я дізнався від свого колеги (мабуть єдиного насправді класного програміста у тодішній команді). Купив книжку Лутца і «підсів» напевно вже з того моменту, коли взнав про виділення блоків відступами і PEP-0008.

За якийсь час в мене з’явилася нагода застосувати Python на практиці. У нас на обслуговуванні був один досить великий продукт, побудований на базі Oracle — програма, в котрій здійснювався облік всього, що стосувалося видобутку нафти — перелік свердловин, їх дебети, записи про планові/непланові ремонти і т.д. і т.п. Продукт був встановлений у 6 містах, кожне мало свою окрему базу. Майже щомісяця вендор випуска апдейти, котрі включали в себе оновлений клієнтський софт і оновлення структури бази даних, ми ці апдейти розгортали. Оновлення структури бази накочувалися просто виконанням наданих нам SQL-скриптів на базі, але окрім того нам треба було зробити відповідні зміни у спеціальній «в’юшечній» базі, котра через db-лінки дивилася на всі 6 баз кожного міста. Додатковою проблемою було те, що у в’юшках було трохи костилів — у тій спільній базі в деяких полях треба було підміняти одні коди іншими, через що більшість в’юшок виглядали сильно складніше ніж CREATE VIEW foo AS SELECT * FROM bar1 UNION ALL SELECT * FROM bar2 ..

Якщо зміни структури були не дуже великі — апдейт в’юшок хоч і був болем в дупі, але не займав дуже багато часу. Але одного разу нам прилетіли скрипти, де змін було дуже багато. Настільки багато, що ми мусили попередити клієнта, що побудувати звіт по всьому підприємству вчасно у нас не вийде — перестворення в’юх за приблизними розрахунками мало зайняти більше місяця, а скільки часу буде потрібно на виловлвання і виправлення багів — було взагалі складно передбачити.

Згадавши, наскільки в Python зручно працювати з текстами, я накидав скрипт, котрий зробив інтроспекцію всіх таблиць в базах (в Oracle це досить просто зробити), дописав логіку для особливих кейсів із замінами кодів, і десь через 3 дні мій скрипт згенерував ≈ 300kb SQL-коду для перестворення всіх в’юх. За тиждень тестування жодних проблем не було виявлено, звіт здали вчасно — це була переможна перемога. :) Не знаю, мабуть що те ж саме якось можна би було зробити і на PHP, а якщо сильно упоротися — то і на Pascal/Delphi. Але на Python це получилося швидко і навіть не дуже стрьомно виглядало, не зважаючи на мій на той майже відсутній досвід з цією мовою.

Потім було знайомство з Django. Ця історія також буде простинею на два екрани, можу її розказати, якщо це комусь цікаво (про що я дізнаюся, якщо попередній коментар, про знайомство з Python збере 10 вподобань). :)

Я поставив 10 лайк:). Тож цікаво було б почути... Особисто у мене негативні спогади про мої починання із Django. Я вчився сам кілька років тому, тож усі дії, навіть елементарні супроводжувались копанням у їх скудній документації і розбиранням методом тику(гугл видавав у кращому випадку один форум де люди пробували то розібрати). Проблемою було все від встановленням на Вінді до несумісності якихось файлів для роботи геоджанго. Потрібно було їх звідкісь завантажити та вгадати який використати бо було кілька версій. Пам’ятаю була якась проблема із доступом до даних із бази. Я не міг вирішити її десь місяць, жодної інфи ніде не було. Аж поки в один прекрасний день я сидів і прошивав паперовий документ і мене осяяло, що потрібно у файлі налаштувань внести зміни. Коротше у моєму розумінні до кращих бібліотек Python Django не належить.

OK, обіцяв — розповідаю. :)

Отже, після головняка з тими в’юшечними схемами, нам прилетів ще один, набагато більший головняк.

Клієнт захотів оптимізувати витрати на моніторинг буріння нафтових свердловин. В кожен момент часу у них відбувалося буріння на 10-15 об’єктах. На кожен об’єкт (а це переважно дуже віддалені місця в тайзі/тундрі) вони відправляли 2-х фахівців, котрі там кілька тижнів жили у вагончику з комп’ютером, на котрий передавалися дані телеметрії, і в дві зміни по 12 годин слідкували за даними — параметри типу глибини буріння, навантаження на бур, рівня радіації, тиску газів, хімічного складу газів і т.д. і т.п. Щоби не було ексцесів, там вимагалася досить висока кваліфікація спеціалістів, а кваліфіковані спеціалісти в тундрі хотіли багато грошей (думаю десь по ≈$5k/місяць кожен). Якщо помножити це на кількість об’єктів — виходила дуже немала сума.

Щоби це оптимізувати, клієнт звернувся до нас і ще одного підрядника. Моя компанія взяла на себе виготовлення автомобільних причепів, на котрих була 2-метрова антена для двостороннього супутникового зв’язку (супутник у компанії був свій) і контейнер, де був встановлений пристрій для апаратного шифрування, комп’ютер, блок безперебійного живлення, система обігріву/кондиціювання і т.п. А підрядник мав написати софт, котрий приймав би дані телеметрії, приводив їх до якогось «спільного знаменника» (бо на об’єктах працювали різні організації, котрі передавали дані у різних форматах), і передава це по супутниковому зв’язку в головний офіс. Де була встановлена стіна з моніторів, перед котрою сиділи 3-4 спеціалісти, в комфортних умовах і зі змінами по 8 годин.

В цілому ідея була непогана, але написаний підрядником софт — це була просто жесть. Нічого більш незручного, кривого і глючного я не бачив ні до, ні після того проєкту. Процес налаштування прийому даних при переїзді вагончика на новий об’єкт займав декілька годин, містив десятки місць де можна було щось провтикнути (бо одне і те ж саме треба було вводити багато разів, деколи в трошки різних форматах). Плюс воно глючило, висло, а типовим способом вирішення проблем було щось типу «о, в нас зависає цей сервіс? напишемо інший сервіс, котрий кожні 15 хвилин буде примусово прибивати/перезапускати сервіс, котрий висне». :) На додачу до проблем із софтом, було ще немало проблем на стороні організацій, що збирали і передавали дані. Міг глючити їхній софт, могло глючити їх обладнання, працівники могли забухати і т.п.

Ну і от. Задача по обслуговуванню всієї цієї радості прилетіла на відділ, у котрому я працював. Список обов’язків людини, що цією задачею займалася, в принципі був не дуже великий. Треба було переналаштовувати софт при переїзді вагончика на новий об’єкт, розбиратися з проблемою якщо якісь дані не приходили, і щодня до 10-ї ранку надсилати клієнту звіт про загальний стан речей по цій системі — який вагончик на якому об’єкті, яка там глибина буріння, які дані приходять а які не приходять, які є поточні проблеми і на чиїй вони стороні. При тому, що людина, котра займалася цією системою, могла була звільнена від будь-яких інших активностей, і за це платили в принципі немалі гроші ($1000+), з відділу протягом року пішло троє людей, кому це доручали. В менші організації, на менші зарплати і т.п.

Ефективно збирати і моніторити ситуацію по 20+ вагончиках, з котрих в середньому 15 були в роботі, було вкрай важко. Вранішній звіт, котрий від нас чекали в 10-й, часом відсилався на годину чи дві пізніше. Працівники на стороні клієнта були злі як чорти, і злість часто зривали на людині, котра готувала цей звіт (особливо коли було спізнення). Завжди треба було бути готовим до того, що в будь-який момент подзвонять з питанням «а шо там у нас на об’єкті N» і треба буде роз’яснити поточну ситуацію, надавши широкий контекст — як розвивалися події, які відбувалися комунікації, «на чиїй стороні м’яч» і т.п.

Одного зовсім нечудового дня, коли від нас пішов черговий працівник, та проблема стала моєю проблемою. Ми пробували різні способи трекінгу інформації (таблиці Excel, примітивний проєкт на PHP де це збиралося в одну таблицю), але жоден з них не був ні зручним, ні ефективним.

Було потрібно мати якусь структуровану БД, у котрій би була інформація про кожен вагончик (IP-адреси обладнання, версії софту, автомобільний номерний знак і т.п.), об’єкти, на котри вони знаходяться (в т.ч. історичні дані), куди можна вносити інформацію про всі зміни, із розбиттям на окремі потоки (проблеми що стосуються софту, заліза, підрядних організацій) і т.д. і т.п.

Я трохи подосліджував Drupal на предмет того, чи не можна щось подібне запиляти на ньому, але досить швидко цю ідею відкинув.

А потім згадав про Python. Думаю, з ним було в цілому прикольно працювати. Можливо там є щось цікаве для створення проєктів під веб?

Загуглив, знайшов слово «Django». Купив книжку (по версії 1.2, актуально тоді була 1.3). Почав досліджувати. Офігів, коли за перший день досліджень постворював половину моделей для запланованого додатку для «моніторингу системи моніторингу» (мало знаючи Python і взагалі не знаючи Django). І адмінку до цього всього, що дозволило відразу повносити частину даних і навіть вивести якийсь загальний список.

Звернувся до керівництва з тим, щоби мені виділили час на розробку додатку. Отримав категоричну відмову. Начвідділу сказала, типу «чувак, ну який новий додаток? це займе рік часу і швидше всього ніколи не буде дороблено до кінця... як половина інших проєктів, за котрі ми бралися».

Але без нормального інструменту працювати було боляче, а експериментами з Django займатися було цікаво і імплементація потрібного продукту просувалася на диво швидкими темпами. І от після 2 (двох) місяців роботи вечорами і на вихідних, я мав майже повнофункціональний продукт, котрий робив все, що мені було потрібно. Там відображалася вся необхідна інформація на 3-х рівнях деталізації, кожна зміна даних логувалася (можна було бачити, хто і коли вніс інформацію і яке було попереднє значення), можна було відфільтрувати логи по різних зонах відповідальності і т.д. і т.п.

Пам’ятаючи, як виглядала (і у що дуже швидко перетворювалася) розробка веб-проєктів на «голому» PHP, я був в шоці від того, як все вийшло з Python/Django. Колеги і керівництво тоді, пригадую, також прифігіли.

Після презентації першої версії мені офіційно виділили час на допилювання деяких додаткових фіч (але там не так багато довелося дописувати, більшість часу пішла на імплементацію красивого інформативного звіту в Excel-і, котрий ми щоранку засилали клієнту). Продукт реально забрав 80% всього болю по супроводжуванню системи. Якщо клієнт хотів на когось наволати — ми завжди могли чітко і аргументовано йому пояснити, на кого саме він має волати. :) Той звіт, котрий ми не встигали зробити за 3 години, легенько робився за годину, максимум.

Треба буде перепитати, але я в принципі не сильно здивуюся, якщо той мій перший проєкт на Django працює і по сьогоднішній день, ≈ 10 років після імплементації. Зараз я знаю, що там є немало провтиків (відсутність select/prefetch_related), але це напевно перший відносно складний і великий проєкт, за код котрого мені не соромно.

Коли почалася війна і я повернувся з Росії додому, той досвід, що я здобув на тому проєкті, був напевно єдиним релевантним досвідом, котрий допоміг мені при пошуку роботи.

Щодо вашого досвіду — думаю що значна частина проблем, з котрими ви стикнулися, була пов’язана з тим, що на Windows під веб писати в принципі не дуже зручно. Я в той час, до речі, також сидів на Windows, але проєкт жив всередині Ubuntu Server на VirtualBox (в PyCharm є можливість працювати з проєктом і інтерпретатором на віддаленому сервері).

Ну і ви згадуєте роботу з геоданими — можливо перший проєкт варто було починати із чогось трохи простішого.

Та моя перша задача на архітектуру і можливості Django лягла практично ідеально. Мабуть пощастило. :)

Я скажу ствердно основна частина проблем точно була пов’язана із Windows, додатково наклалось те, що на той час я працював у версії 2.0, а книжка було по 1.2... Плюс не будемо забувати я не іт-шник). Геоджанго я використовував лише для відображення геокоординат (точніше точок із імовірним розташовуванням об’єктів) на карті, там нічого складного, проблему вирішило встановлення нової версії бібліотеки. Я вирішив у той чи інший спосіб усі проблеми які переді мною виникали, проблемою було те скільки часу на це йшло у порівнянні із іншими не менш складними бібліотеками Python). Думаю станом на сьогодні ситуація змінилась в кращу сторону, але враження лишилось враженням. Дякую за розповідь!!!

Давным давно мода на небинарный код! На западе так точно!

Підкреслення як спосіб інкапсуляції. Якщо ім’я методу, функції або властивості Python починається з підкреслення «_foo», значить воно protected — його не можна використовувати за межами класу. Хіба що дуже хочеться: мова не викине помилку, якщо ви зробите foo._bar().

Мне одному кажется что лучше все же таки штуки предусматривать на уровне языка, а не контрактов и это скорее недостаток чем достоинство?

и это скорее недостаток чем достоинство?

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

Мне одному кажется что лучше все же таки штуки предусматривать на уровне языка,
...
foo._bar()

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

_bar декларирует что — не трогай!
а решил тронуть — ну, тебя предупреждали, автор кода за последствия — не отвечает!

другое дело что невменяемое написание кода — левой задней ногой, вобщем-то норма.
а потому еще и финализировать и запечатывать все нужно... на уровне языка :)

вот только — что будет с суммой недостатков и достоинств если устранить недостатки добавлением суровости Rust/C++/Haskell...

Месседж был не в том что из-за моего безумно важного мнения нужно переписать ЯП «правильно», а в том что я не понимаю восхищения автора по этому поводу. Не знаю, может питонисты работают только в больших продуктовых компаниях, где есть время писать тесты и рефакторить код, но я в свое время настрадался он отсутствия модификаторов доступа на js и что-то как-то _ не сильно кого-то останавливала когда менеджер буквально стоял над тобой и говорил что надо на 20 минут назад, хотя договор использовать его для инкапсуляции в команде был

больше всего тестов мне приходилось писать на Java
и модификаторы доступа там ничего не решали.
зато наворачивать костылища из-за них, да, приходилось
даже лезть в класслоадер, и на уровне байт кода, на лету патчить

так что из своего, то есть сугубо личного опыта — пользы в них не увидел.
для себя.

хотя договор использовать его для инкапсуляции в команде был

ну эт понятно, говнокоманда — вот и говнокод
опять же, «индусский код» на Java видел и фиксил лично, а не понаслышке
ничем он не лучше кода мальчика пыхера который научился копипастить с стековерфлов в плагины Wordpress (тоже видел, как такой, так и вполне годный код, даже в мире Wordpressа)

менеджер буквально стоял над тобой

работа у него такая :)
свойства ЯП от этого давления фигачить как ни попадя — не спасают

да, миллионы мух не могут ошибаться

они и не ошибаются. тьма видов вымерла — а мухи — живехеньки :)

снобы, пуристы, идеалисты пусть стенают
сами тоже — мухи же

доделываю вот SOAP сервис для работы с Volvo VIDA
сцуко, он же на Джаве. Это ж — у-у-у, SOAP

а сделано похоже индусами, и в итоге
вот же wsdl что предоставлен. по нем же генерятся и ответы в VIDA
ан нет, wsdl по боку, одна команда принимает вот в таком формате неймспейсы
а другая, ту же сущность — требует завернуть в другой формат
при этом — в доке написано по другому, а в примерах в проекте для SOAP UI — по третьему

а в логах, ах, хорошо то как:
Developer Message: Should be removed from the client! ..., ...,

и чё, спасли православные Java и SOAP от говнища этого?
от нарушения правила
пусть безобразно — но единообразно

думаю как быстрее-проще написать конфигуратор ответа... и чтобы быстрее — то в лог смотришь, аха, та команда сожрала это, а эта вот не хочет...

«типизация, типизация».
х.ячечная!

если болваны писали, и управления проектом не было — то до одного места типизация

я прям «вижу», как писалось, сдавалось, тесты все проходило, пиэмы радостно, с обеих сторон рапортовали...
и конечно — типизация, это ж Java, это серьезно, не то что какие там питоны с джсами

стектрейсов джавы на банкоматовском экране не доводилось видеть?
я видел — у топового укр банка :)

так может мухи — это джависты не? ;)

Частично согласен. Ну нет модификаторов в языке что поделать. С годами что было нормой становится Code Smell. В аналогию можно взять например С#, где довольно большое кол-во линтеров почему-то предлагает называть private property с underscore`ом в начале. Казалось бы всем очевидная вещь, но почему такой тренд? Почему не % или что-то еще. Да может пример не самый удачный, но я про то, что негласные правила всегда и везде присутсвтуют. Бизнес Логику мне в контроллер :)

Наприклад, візьмемо Djinni, де колись були проблеми з продуктивністю.

Ну так щоб користувачі помітили... тільки таке було:
— один раз індексів в базі не було, просто подивилася slowlog (тоді ще в mysql) і додала індекси
— а другий раз — в django ORM у вибірці з бази було кілька моделей і прив’язані моделі вибиралися окремими SQL-запитами, це пофіксилось додаванням prefetch_related() або select_related() в залежності від потреби.

Багато разів були 2x-10x оптимізації просто на рефакторингу кода, додаванні кешей, зміні бізнес-логіки. Але на невеликих непомітних шматках типу 300ms->30ms.
Дуже довго справлявся 1 сервер, і ріст доступних серверів випереджав потреби. Першу перебудову інфраструктури на «більше 1 сервера» зробила десь рік тому, але не тому що вперлися, а щоб дати ще 20х запас росту на майбутнє.

DOU Daily: переваги та недоліки Python та для чого IT-спеціалісту психотерапія

Совпадение? Не думаю... )

от всего сообщества питонистов, вот вам цветочек — 💩

от всего сообщества питонистов, вот вам цветочек — 💩

Кхм, т.е все сообщество питонистов думает, что так выглядит цветочек?
Братишка! Братишка, я тебе код принес на ревью...© :)

именно, цветочек достойный этих ваших взглядов о питоне.

Останні декілька місяців моніторю Python для початку, то якихось стажувань від компаній, курсів та трейні\джун позицій дуже мало. Доволі рідко з’являються. І в той же час на JS, Java та навіть C# хоч лопатою набирай

Багато сказано ... але забули про один, як на мене, критичний недолік: мова НЕ ide-friendly. Анотації типів допомагають, ала слабо.

Коли я роблю import xxx, перше, що я роблю — це пишу «xxx.» і дивлюсь що там. І так, в python, з цим все ок. Але з купою методів з **kwargs — не видно нічого ... і єдиний варіант — шукати документацію, що є дуже довго для 90% випадків.

Такая проблема есть. Кроме **kwargs есть еще C extensions, для которых совсем ничего не работает. Решить эту проблему можно на уровне библиотеки написав вот такой тайпинг стаб: github.com/...​cy_injector/providers.pyi

IDE и mypy смотрят на стаб для автокомплита и проверок. Стаб лежит рядом с основным модулем и не участвует в выполнении. Проблема в том, что такие стабы писать и поддерживать дорого. Для опенсорс библиотеки цена оправдана, а для коммерческого приложения может быть дорого.

У вашому випадку хоч stub ± нормальний, хоч і без доків.

Я більше про щось типу mongodb-шного
find_one(filter=None, *args, **kwargs)
І в доках «any additional keyword arguments are the same as the arguments to find()».
Що хоч і не зручно, але фіг з ним ... можна глянути що там у find.

Але якщо глягути
mysql.connector.connect(*args, **kwargs):
То тут ... хз ... тільки йти в гугл з «mysql.connector examples».

**kwargs іноді використовується по ділу, а іноді ... «а давайте два параметри обробимо тут, а решту передамо далі». Ланцюжок з 3-4х таких викликів і 10-15хв треба вичитувати як там що передати... в кращому випадку.

это хоть гуглится с первой страницы) а почему интересно сложно поддерживать нормальные аннотации, это какие-то особенности самого языка? Может очень много библиотек и по-этому не требуются от разработчиков детальные анотации

Така жиза. Довелось працювати з 400 рядками Пітон коду, тупо не можна без 50 грам розібратись з викликами через **kwargs в кожній функції. Поки код напам’ять не вивчиш, постійно треба стрибати і перевіряти які параметри куди йдуть.

Звісно, частково проблема в розробниках які таку кашу написали. Але, як підмічено, навіть в АПІ для баз даних така ж проблема.

У світі досі використовують Ruby, який у 100 разів повільніший за Python.

Ее, шо? Для яких задач рубі повільніший хоча б в 3-4 рази? Якщо порівнювати СPython та MRI Ruby.

Але люди кажуть, що на highload-частинах треба окремі шматки коду переписувати на чомусь швидшому — Cython, Golang, Rust, C.

На Go можна усе переписати, що зараз є у achievki.io

В самолёте летели программисты, да? Э... И один из программистов, э... с Украины, достал код на Python, и запах пошёл по всему самолёту, да. И к нему подошёл парень темнокожий, африканец, и увидел, как он присмоктывает. Смотрел, смотрел на него, слюну глотал и говорит... Ну что медленно, он грит медленно. Будешь переписывать на Go, он грит буду. Он грит: Я понимаю, что ты чтобы ты переписал всё, но я тебе не дам)))

youtu.be/4GNYOuHG-6U

Уже нет — сейчас на Западе тенденция использования небинарного...

:)

Колега по проєкту раніше розробляв на Python, зараз перейшов на Go й задоволений, тому в статтях про PHP, Python та Ruby нагадую про Go.

ось тут красномовна статистика :))
djinni.co/analytics/by-category
0.1 кандидатів на вакансію доступно на Go
0.1 на Ruby
0.3 на PHP
0.7 на Python

Спільнота гоферів в Україні росте, в GolangUA 100+ учасників за рік.

0.1 кандидатів на вакансію доступно на Go

Маю надію, що цього року вже буде хоча б 2 кандидата на 10 вакансій.

И какой вывод можно сделать из такой статистики ?

например такой:
кандидаты на Go дефицитнее по сравнению с Python
независимо от зарплаты и опыта, их физически страшно не хватает

кандидатів на вакансію доступно на Go

Как?! Разве их больше чем 2, которые тут обитают? )

Go — специализированный язык, чисто серверы и back end, а на python большая часть — работа с данными, ds, ai, по-этому они не совсем пересекаются.

Підписатись на коментарі