Comments 17
С точки зрения инженера все языки программирования выглядят примерно одинаково: те же самые функции и т. д. При этом синтаксис — это обычно документация на 3-4 странички, чтобы понять, как работает язык. Поэтому для современного инженера хорошей практикой станет качать не просто знание одного языка, а понимание программирования как такового вместе с умением читать чужой код.
Способность читать чужой код дает 50% знания языка. Можно сколько угодно знать Python, но не суметь понять код, написанный другим разработчиком.
Умение прочесть разные языки программирования сделает из инженера по-настоящему универсального специалиста, который сможет оперативно разобраться в любом коде с использованием Википедии и двух страничек о синтаксисе.
Золотые слова и Python здесь ни при чём.
для этого в нормальных вузах на прогерских специальностях сначала читали теорию алгоритмов а уже потом языки.
Именно так у нас и БЫЛО:
А читал нам этот курс Лебедев Владлен Николаевич
. Я думаю на его бестселлере "Введение в системы программирования" выучилось не одно поколение программистов как с Советском Союзе, да и в России тоже:
Картинка нарисована, мягко говоря, далёкая от правды.
Те задачи, для которых предлагается в статье использовать Python (погрепать логи, по ssh походить, кроном список юзеров актуализировать), гораздо удобнее решать с помощью bash — есть на любом линуксе без дополнительных подпрыгиваний, библиотеки ставить не нужно, утилиты удобно вызывать опять же (а они таки очень быстрые).
Если говорить про web-сервисы, то на Python они получаются очень лаконичными, один инстанс при этом держит 2-3 тысячи rps без походов по сети, правда придётся освоить асинхронную парадигму программирования, но зато от data race язык защищает.
Golang силён в первую очередь своей моделью конкурентности и сборкой в бинарник без зависимостей — но если вы пишете действительно нагруженный web-сервис (в моей голове это 10k+ rps), то за это придётся заплатить необходимостью уметь писать многопоточный код, всё же несмотря на CSP горутины выполняются на нескольких потоках, а значит от data race программиста защищает только здравый смысл.
Вывод примерно такой: для начала стоит освоить bash, потом по мере нарастания сложности использовать python, а в случае необходимости таскать большие по объему кода бинарники или писать нагруженные web-сервисы, уже изучать Golang.
от data race язык защищает
Нет: https://verdagon.dev/blog/python-data-races
В однопоточном asyncio хоть и сложнее, но всё равно теоретически возможно получить data race если слишком перемудрить с тоннами await'ов в коде, поэтому даже для asyncio есть примитивы синхронизации
Пример по вашей ссылке это замаскированный синтаксисом языка race condition, об этом даже в шапке статьи написано "Note: I wrote this article with an unusual (and partially incorrect) definition of data race. To get the most out of this article, one could interpret "data race" as "race condition". "
Вывод примерно такой: для начала стоит освоить bash, потом по мере нарастания сложности использовать python, а в случае необходимости таскать большие по объему кода бинарники или писать нагруженные web-сервисы, уже изучать GoGolang.
В целом согласен. Но это для миддла. Сеньор должен знать шелл, один скриптовый и один компилируемый язык. И уметь читать ещё пару - тройку языков.
Часто бываю таски которые слишком просты для вызова интерпретатора. Но иногда попадаются задачи, где нужно обрабатывать громадные логи по хитрым правилам, и тогда без компилируемого языка не обойтись.
Вывод примерно такой: для начала стоит освоить bash, потом по мере нарастания сложности использовать python
Bash наверное будет посложнее, чем Python. По крайней мере в использовании: нужно знать, где в bash можно выстрелить себе в ногу.
Например, команды вроде ls * могут принять имена файлов, начинающиеся на «-» за опции командной строки, ну вот к примеру, допустим, у нас есть некий каталог, и мы в нём выполняем команду ls *, увидим, как и ожидали, список файлов. Теперь, если в нём создать файл '-l' (touch ./-l), то ls * в том же каталоге выдаст список файлов в другом формате. А какая-нибудь другая программа может и запустить что-нибудь неожиданное. То есть, нужно помнить, что вместо * в таких случаях нужно писать ./*.
Или, например, важно помнить то, что по умолчанию выполнение скрипта продолжится даже если запущенная в нём программа или команда оболочки вернула ошибку, то есть, возможны такие ситуации: перешли в каталог (но, как оказалось, неудачно), удалили всё в текущем каталоге, но, как потом выяснилось, совсем не там, где нужно... Игнорирования ошибок в процессе выполнения — это не совсем то, чего интуитивно ждёшь от языка программирования.
Или, например, представим нетипичную (возможно искусственно созданную...) ситуацию, когда имя файла содержит переводы строки. Если это не учесть, то скрипт может принять такое имя за несколько других имён (и не сделать что-то нужное с файлом или сделать что-то ненужное с другими файлами). Это, опять же, можно предусмотреть (-print0 в find, -0 в xargs), но и про эти грабли тоже надо знать.
Поэтому наверное всё-таки начинать нужно не с bash. А с Python — почему бы и нет?
Есть риск, что Go могут запретить, как гуглевское порождение. А питон я бы сам запретил за систему отступов, отсутствие строгой типизации и отсутствие компиляции
Согласен с автором. Кол-во доступных в Сети админ-скриптов для типовых админ-задач на Python vs Go соотносится, имхо, 50:1. Это хороший знак начать именно с Python. А дальше - Go. Языки Bash/CMD смотрится анахронизмом в наше время. Под Windows - админ-задач, пожалуй, до сих пор большинство, а там одни кодировки могут довести до красноглазия, не говоря про экранирование символов, работу с файлами и сетевыми пакетами итд. PowerShell под Windows не стал админ-тулом №1 (имхо).
Для грепа и построения внутренних web-сервисов у Python много "помогаек" в виде либ pandas, numpy, gradio, streamlit, их автор не упомянул. "Проблема скорости" Python с этими либами становится несущественной - многие из них написаны на быстрых и очень быстрых языках.
В принципе все сформулировано в народной мудрости: За комаром не с топором.
Хорошо идти от задач к выбору языка и знать их (языков) плюсы и минусы.
А не ваять все на одном, как например 1С ники пытаются.
Языков ведь много неспроста, питон берет массовостью, перл обработкой строк на порядок быстрее, баш он и в африке баш всегда под рукой, его надо знать
Очень забавно, когда в заголовке пишут явно, что админу надо программировать. Это же нонсенс! Я не встречал в своей жизни заголовков типа "Проктология для стоматолога: какой инструмент выбрать?", а в тексте реально расписывают потолще или потоньше и длиннее, при этом никто не написал, что стоматолог должен зубы лечить, а не одном месте ковыряться.
Я сам являюсь инженером с функциями админа и программиста (приходится тянуть те инструменты, которые писал будучи программистом), но в корне считаю это неверным подходом.
По языкам - Го и Питон интересные языки, но зачем они админу? Я много работал с питоном, перлом, с/с++, а даже ассемблером. Но для админа - BASH! Задача админа - администрировать!
Мне не раз приходилось срочно вылетать на какой-то объект, где что-то не сработало "как надо". По факту выяснялось, что автор программы на питон/с/perl пытался натянуть что-то на глобус и при каких-то условиях это что-то не сработало, в то время, как задача решалась двумя строчками bash с использованием проверенных инструментов. А зачастую "программисты" любят изобретать велосипед, напарываясь на те ошибки, которые уже пройдены другими десятилетиями назад.
Алё!!! Вы в своем уме там все?
Заголовок немного вводит в заблуждение, в статье имеется в виду инженер ближе к devops, чем к системному администрированию и сетям.
О в этом нет никакого смысла!
Занимался несколько лет DevOps деятельностью. Писал в основном на джаве, когда контрибьютил в продукт, на груви, когда настраивал пайплайн.
На другом месте появилось больше питона. Просто так было заведено. Ок, не проблема.
Перешёл снова на новое место и…тут все на тайпскрипте. И продукт, и все процессы вокруг него - cdk aws’а. Вот уже полгода как каждый день использую nodejs для своих sre задач.
кто бы мог подумать?)
Программирование для админа: какой язык выбрать?