Хотелось бы обосновать свой выбор. Он исключительно субъективный, но у меня есть причины.
Зачем мне Golang если я знаю Си на котором могу написать буквально всё. Те же самые "буквально всё" на Golang, к сожалению, не напишешь. Люблю свободу без ограничений.
Если смотреть с точки зрения асимптотической сложности накладных расходов в больших проектах, то производительность программ на Си почти равна возможностям железа и, например, каждое новое клиентское подключение будет потреблять линейное количество ресурсов O(n) или близкое к тому. Накладные расходы любого другого языка программирования с теми же принципами, которые заложены в Golang (например гарбидж-коллектор) никогда не будет линейной, а с значительным коэффициентом.
Упрощу объяснение на выдуманном примере:
а) Программа на Си для одного клиентского подключения потребляет 1Mb и 1/1024 CPU. Для 1024 клиентов она потребит 1Gb и 1CPU. Это, конечно, очень грубое представление — в реальной жизни может быть как меньше ресурсов, так и больше — тут целое поле для оптимизаций.
b) Программа на Golang для одного клиентского подключения потребит 1Mb и 1/1024 CPU, но для 1024 клиентов она потребит 100Gb и 10CPU. Цифры взяты от потолка, прошу не придираться, цель их присутствия только для того, чтобы передать идею накладных расходов, а не принизить достоинства ЯП.
На самом деле изучение computer science подозревается по-умолчанию. Если ставится цель профессионально работать программистом, то без знания алгоритмов, работы памяти, параллелизма и других аспектов делать нечего не только в Сишке, но и в любом другом языке программирования. Однако computer science это такой пласт знаний, в который можно углубляться бесконечно не для практических задач, но ради академических знаний.
Прошу прощения. Меня к тому моменту забанили по политической статье и я уже ничего не смог ни добавить, ни изменить. Правильная ссылка должна была вести на публикацию https://habr.com/ru/articles/656677/. Спасибо @koreecза правильную ссылку.
Если Вы ищете удалённую работу в Google из Тагила, то по очевидным причинам Ваше оформленное не по стандартам принимающей стороны резюме даже не будет рассмотрено. Тогда остаётся вариант предложить изменить локацию. Там автоматически изменится уровень доверия, схемы налогообложения и прочие мелочи жизни, которые работодателю могут быть принципиально важны. А так же откроется возможность рассмотреть варианты hybrid и on-site.
С Вашим английским можно претендовать на очень крутые компании в случае переезда в зону их интересов. А ещё есть масса нюансов типа ATS и правил оформления резюме под конкретного работодателя или правил, относящихся к конкретной стране. Они есть и иногда очень жёсткие, и даже регулируются законом. Поищите комьюнити в социалках, задавайте вопросы именно по той локации, на которую рассчитываете и Вам подскажут как избежать ошибок при подаче резюме и прохождении интервью.
В моей локации у компаний богатый выбор аутсорсеров, но они предпочитают местных только потому, что их можно будет взять за жабры и трепать до конца жизни как того Буратину, в случае если сотрудник превращается в источник проблем.
Ещё вариант присоединиться к международным галерам, специализирующимся на аутсорсе. Но там, как правило, маленькие проекты с коротким сроком жизни... ну хоть руку набить и строчку в резюме добавить и то уже неплохо! Однако... как повезёт... У меня есть друг, который в галерах не первый год и на одном и том же проекте. При этом галеры помогли ему вместе с семьёй и тремя детьми релоцироваться в страну его мечты и он работает по 4 часа в день. При этом все довольны.
Теория Дарвина не всегда работает в IT. Иногда появляются такие уродливые монстры, которые, казалось бы, не имеют права на существование. Но за неимением альтернатив они не только живут и умудряются развиваться, но на их базе строят других монстров. Пример — Java, которая написана на Си, и Scala, которая написана на Java... Почему просто не писать на Си? ;)
P.S. Чувствую, за джаву мне сразу снесут карму, несмотря на смайлики. Надо было привести другой пример... Может котика приаттачить? :-D Не не поможет?
Использование структур для определения классов и их атрибутов достаточно распространённый приём в Сишке. И я согласен что очень удобный. Кроме ядра Linux такое используются в том числе для построения GUI (где-то было упоминание тут в комментариях).
Разница в уровне сложности между нативным OOP в том же C++ и трюками в Сишке. Чтобы не многословить просто укажу ссылку на одну из статей: "Десять вещей, которые я терпеть не могу в ООП" И одной такой заметкой список не ограничивается. Есть много хейта вокруг конкретно C++ и Java именно в ключе их усложнённости ради усложнения, когда программисты с 20 летним опытом просто не могут понять чужой код.
Суть цитируемого раздела заключается в том, чтобы передать мысль: DevOps — это одноразовый инструмент. Им пользуются и выбрасывают сразу же, как только запахло жареным. DevOps — это недешёвый ресурс, и от таких специалистов избавляются в первую очередь, особенно когда инфраструктура уже налажена, проект достиг пиковой стадии и дальнейшего развития не предвидится. Проект функционирует самостоятельно, принося прибыль, и для его поддержки требуется минимум усилий. Или, наоборот, если владелец бизнеса не увидел ожидаемой отдачи от своих инвестиций и начинает сокращать штат, то DevOps-инженеры улетают одними из первых, сразу после дизайнеров. Если в вашей компании начали сокращать дизайнеров — это уже первый звоночек, и пора обновить резюме. :-D Текст написан с долей юмора, но, как известно, в каждой шутке…
Вот и я к пришёл к тому же через такие же негативные эмоции и выгорание. Но при этом мне нравится сфера IT и поэтому хочу в ней оставаться дальше. Тем более платят ощутимо лучше, чем за всё остальное! ;-) Долго думал чем бы заниматься таким, что уже завтра не уйдёт в забвение и в результате нашёл для себя выход в Си.
Как вариант попробуйте найти такого нового работодателя, у которого есть две инфраструктуры: on-premise и в облаке. Или у него есть планы построить Disaster Recovery в облаке, продублировав инфраструктуру или её основные элементы. Там точно будет много практики и нового опыта с облаками. А чтобы расширить выбор работодателей улучшайте английский хотя бы до уровня Upper Intermediate. С таким английским вариантов выбора работодателей для работы в удалённом режиме возрастает на два порядка. В любом случае откажитесь от обслуживания конечных пользователей. Они сжирают всё время и не дают расти. Попросите у руководства для обслуживания пользователей отдельного эникейщика, который будет им помогать, чтобы Вы могли сосредоточиться на саморазвитии и поддержке серверных решений. В конце-концов предложите развернуть Disaster Recovery текущему работодателю. Хотя бы бэкапы хранить в облаке.
Абсолютно верное предположение! ;) Конечно есть идеи что делать дальше и очень скоро я их озвучу, потому что они могут быть интересны не только мне, но и другим программистам.
Позвольте предположить из контекста, что в оригинале фраза должна была иметь несколько иной смысл: "Работа системного администратора как была невероятно сложной, скучной и недооценённой, так и остаётся таковой, но уже в ключе DevOps и облачных инфраструктур". Всё точно @HellKaim? ;-)
Вынужден согласиться. Не раз пытался в прошлых локациях перейти в разработку, но повезло только сейчас и только тут. Раньше просто не мог найти работодателей, даже в удалёнке. Сейчас удалось зайти в интересный High Load проект. В нём такие ресурсы задействованы, что ничего кроме ассемблера и сишки не справится. Так же есть спрос на разработчиков модулей ядра операционок типа AIX, Linux, FreeBSD, разработчиков в сфере безопасности SELINUX/BPF, и, конечно, Embedded — это вообще большинство вакансий.
индустрия ест, за это платят деньги - значит это нужно
К сожалению у индустрии всегда есть своё мнение, и оно часто бывает деструктивным по отношению к людям ею нанятым. То швеи спиваются, то девопсы выгорают...
Не угадали. Все эти айтишники — жуткие зазнайки, хорошо разбирающиеся только в одном. Им как синоптикам — верить нельзя ни одному, Торвальдсу тем более. Надо делать свои ошибки и на них учиться. Потом делать самостоятельные выводы и описывать эти выводы в статьях, чтобы в результате тебе никто не верил — ведь ты же айтишник :-)
Спасибо, что поделились личным опытом. Было очень интересно прочесть.
Вот даже страшно было это читать, куда уж себе такое представить...
Ладно, добавлю смайлик. Дружелюбный. :o)
Хотелось бы обосновать свой выбор. Он исключительно субъективный, но у меня есть причины.
Зачем мне Golang если я знаю Си на котором могу написать буквально всё. Те же самые "буквально всё" на Golang, к сожалению, не напишешь. Люблю свободу без ограничений.
Если смотреть с точки зрения асимптотической сложности накладных расходов в больших проектах, то производительность программ на Си почти равна возможностям железа и, например, каждое новое клиентское подключение будет потреблять линейное количество ресурсов O(n) или близкое к тому. Накладные расходы любого другого языка программирования с теми же принципами, которые заложены в Golang (например гарбидж-коллектор) никогда не будет линейной, а с значительным коэффициентом.
Упрощу объяснение на выдуманном примере:
а) Программа на Си для одного клиентского подключения потребляет 1Mb и 1/1024 CPU. Для 1024 клиентов она потребит 1Gb и 1CPU. Это, конечно, очень грубое представление — в реальной жизни может быть как меньше ресурсов, так и больше — тут целое поле для оптимизаций.
b) Программа на Golang для одного клиентского подключения потребит 1Mb и 1/1024 CPU, но для 1024 клиентов она потребит 100Gb и 10CPU. Цифры взяты от потолка, прошу не придираться, цель их присутствия только для того, чтобы передать идею накладных расходов, а не принизить достоинства ЯП.
На самом деле изучение computer science подозревается по-умолчанию. Если ставится цель профессионально работать программистом, то без знания алгоритмов, работы памяти, параллелизма и других аспектов делать нечего не только в Сишке, но и в любом другом языке программирования. Однако computer science это такой пласт знаний, в который можно углубляться бесконечно не для практических задач, но ради академических знаний.
Прошу прощения. Меня к тому моменту забанили по политической статье и я уже ничего не смог ни добавить, ни изменить. Правильная ссылка должна была вести на публикацию https://habr.com/ru/articles/656677/. Спасибо @koreecза правильную ссылку.
Если Вы ищете удалённую работу в Google из Тагила, то по очевидным причинам Ваше оформленное не по стандартам принимающей стороны резюме даже не будет рассмотрено. Тогда остаётся вариант предложить изменить локацию. Там автоматически изменится уровень доверия, схемы налогообложения и прочие мелочи жизни, которые работодателю могут быть принципиально важны. А так же откроется возможность рассмотреть варианты hybrid и on-site.
С Вашим английским можно претендовать на очень крутые компании в случае переезда в зону их интересов. А ещё есть масса нюансов типа ATS и правил оформления резюме под конкретного работодателя или правил, относящихся к конкретной стране. Они есть и иногда очень жёсткие, и даже регулируются законом. Поищите комьюнити в социалках, задавайте вопросы именно по той локации, на которую рассчитываете и Вам подскажут как избежать ошибок при подаче резюме и прохождении интервью.
В моей локации у компаний богатый выбор аутсорсеров, но они предпочитают местных только потому, что их можно будет взять за жабры и трепать до конца жизни как того Буратину, в случае если сотрудник превращается в источник проблем.
Ещё вариант присоединиться к международным галерам, специализирующимся на аутсорсе. Но там, как правило, маленькие проекты с коротким сроком жизни... ну хоть руку набить и строчку в резюме добавить и то уже неплохо! Однако... как повезёт... У меня есть друг, который в галерах не первый год и на одном и том же проекте. При этом галеры помогли ему вместе с семьёй и тремя детьми релоцироваться в страну его мечты и он работает по 4 часа в день. При этом все довольны.
Теория Дарвина не всегда работает в IT. Иногда появляются такие уродливые монстры, которые, казалось бы, не имеют права на существование. Но за неимением альтернатив они не только живут и умудряются развиваться, но на их базе строят других монстров. Пример — Java, которая написана на Си, и Scala, которая написана на Java... Почему просто не писать на Си? ;)
P.S. Чувствую, за джаву мне сразу снесут карму, несмотря на смайлики. Надо было привести другой пример... Может котика приаттачить? :-D Не не поможет?
Использование структур для определения классов и их атрибутов достаточно распространённый приём в Сишке. И я согласен что очень удобный. Кроме ядра Linux такое используются в том числе для построения GUI (где-то было упоминание тут в комментариях).
Разница в уровне сложности между нативным OOP в том же C++ и трюками в Сишке. Чтобы не многословить просто укажу ссылку на одну из статей: "Десять вещей, которые я терпеть не могу в ООП" И одной такой заметкой список не ограничивается. Есть много хейта вокруг конкретно C++ и Java именно в ключе их усложнённости ради усложнения, когда программисты с 20 летним опытом просто не могут понять чужой код.
Суть цитируемого раздела заключается в том, чтобы передать мысль: DevOps — это одноразовый инструмент. Им пользуются и выбрасывают сразу же, как только запахло жареным. DevOps — это недешёвый ресурс, и от таких специалистов избавляются в первую очередь, особенно когда инфраструктура уже налажена, проект достиг пиковой стадии и дальнейшего развития не предвидится. Проект функционирует самостоятельно, принося прибыль, и для его поддержки требуется минимум усилий. Или, наоборот, если владелец бизнеса не увидел ожидаемой отдачи от своих инвестиций и начинает сокращать штат, то DevOps-инженеры улетают одними из первых, сразу после дизайнеров. Если в вашей компании начали сокращать дизайнеров — это уже первый звоночек, и пора обновить резюме. :-D Текст написан с долей юмора, но, как известно, в каждой шутке…
Благодарю, что разделяете моё мнение.
Вот и я к пришёл к тому же через такие же негативные эмоции и выгорание. Но при этом мне нравится сфера IT и поэтому хочу в ней оставаться дальше. Тем более платят ощутимо лучше, чем за всё остальное! ;-) Долго думал чем бы заниматься таким, что уже завтра не уйдёт в забвение и в результате нашёл для себя выход в Си.
Пруфы того, что всем нужен EKS? Легко:
https://www.linkedin.com/jobs/search/?keywords=devops eks&origin=JOBS_HOME_SEARCH_BUTTON&refresh=true
Или пруфы что он плохо интегрирован с остальными элементами AWS по сравнению с ECS и гораздо более глючный? Проще простого:
https://stackoverflow.com/questions/tagged/amazon-eks?tab=Unanswered
Как вариант попробуйте найти такого нового работодателя, у которого есть две инфраструктуры: on-premise и в облаке. Или у него есть планы построить Disaster Recovery в облаке, продублировав инфраструктуру или её основные элементы. Там точно будет много практики и нового опыта с облаками. А чтобы расширить выбор работодателей улучшайте английский хотя бы до уровня Upper Intermediate. С таким английским вариантов выбора работодателей для работы в удалённом режиме возрастает на два порядка. В любом случае откажитесь от обслуживания конечных пользователей. Они сжирают всё время и не дают расти. Попросите у руководства для обслуживания пользователей отдельного эникейщика, который будет им помогать, чтобы Вы могли сосредоточиться на саморазвитии и поддержке серверных решений. В конце-концов предложите развернуть Disaster Recovery текущему работодателю. Хотя бы бэкапы хранить в облаке.
Абсолютно верное предположение! ;)
Конечно есть идеи что делать дальше и очень скоро я их озвучу, потому что они могут быть интересны не только мне, но и другим программистам.
Оно само. ©AI
Позвольте предположить из контекста, что в оригинале фраза должна была иметь несколько иной смысл: "Работа системного администратора как была невероятно сложной, скучной и недооценённой, так и остаётся таковой, но уже в ключе DevOps и облачных инфраструктур". Всё точно @HellKaim? ;-)
Вынужден согласиться. Не раз пытался в прошлых локациях перейти в разработку, но повезло только сейчас и только тут. Раньше просто не мог найти работодателей, даже в удалёнке. Сейчас удалось зайти в интересный High Load проект. В нём такие ресурсы задействованы, что ничего кроме ассемблера и сишки не справится. Так же есть спрос на разработчиков модулей ядра операционок типа AIX, Linux, FreeBSD, разработчиков в сфере безопасности SELINUX/BPF, и, конечно, Embedded — это вообще большинство вакансий.
К сожалению у индустрии всегда есть своё мнение, и оно часто бывает деструктивным по отношению к людям ею нанятым. То швеи спиваются, то девопсы выгорают...
Не забудьте, пожалуйста, ещё через пять лет поделиться впечатлениями. А я со своей стороны обещаю поделиться впечатлениями о 5 годах в разработке :-)
Не угадали. Все эти айтишники — жуткие зазнайки, хорошо разбирающиеся только в одном. Им как синоптикам — верить нельзя ни одному, Торвальдсу тем более. Надо делать свои ошибки и на них учиться. Потом делать самостоятельные выводы и описывать эти выводы в статьях, чтобы в результате тебе никто не верил — ведь ты же айтишник :-)
Вам удалось гораздо лучше и без эмоций выразить все те мысли, которые я хотел донести. Благодарю.