Комментарии 49
Ни main, ни типизация, ни методы у структур не вызывает вопросов, если до этого писали на любом другом Си-подобном языке, к коим относится и Go. Явная точка входа и строгая статическая типизация — скорее привычное требование, нежели неожиданность. Да что уж там говорить, даже в Python принято точку входа называть main, и вызывать ее из if-блока.
Но больше всего мне непонятен посыл статьи.
В Python пишешь
a = 5, потомa = "текст"— и всё нормально.
Нет, не нормально, на любом нормальном ревью за такое бьют по рукам будут ругать.
foriinrange(len(arr)):
и это не нормально, for i in arr:. Не говоря, что называть переменные i и arr — тоже плохой тон.
Судя по приведенным примерам, вам и в питоне пока многое не понятно.
Ничего против вкатунов не имею, но 3 года работать и не знать разницы между статической и динамической типизацией - это сильно.
рекомендую автору посмотреть это
может скажем ему?
Мне кажется, это какой то стёб, написанный нейросетью.
Также напрягла пара фраз - 'видел вакансии выше 100к' и 'работаю уже третий год'. Такое ощущение, что работа не то, что большие требования к специалисту предъявляет и соответствующим образом оплачивает, раз на 100к вакансии засматриваться начал.
Все-таки, мне кажется это прикол, а не реальное мнение🤔
Это шутка такая? То есть я что мог не читать Лутца ( что уничтожило мое самолюбие и заставило идти в CS) а устраиваться на работу?
А ЧЕ ТАК МОЖНО БЫЛО???
"Я писал на петухоне, но чёт за него не платят. Начал писать на нормальном языке, блин, как же сложно"
По факту го почти идеальный язык (идеальный это плюсы естесно), в питоне потоки не настоящие, динамическая типизация и тд
"Закончил онлайн-школу, работаю уже третий год " а вы все профильное образование, профильное образование, а человек молодец прошел трех месячные курсы и сразу вкатился и кому-то что-то уже наверняка написал в прод))
Качественный наброс :)
У нас есть и го, и пистон в стеке. Хз, пистон удобнее, но тормознее и если использовать asyncio то приходится часто рыть либы. Го быстрый, но странный. Имхо жаба лучше, а котлин ещё лучше
Лучше в чем? Языки выбирают не по удобности а по надобности и под определенные задачи...
Большинство языков может, каждый из них, могут закрыть большинство задач. И ты, либо вынужден тратить массу времени на изучение нового языка, где задача решается быстрее (реализация, а не производительность) и будешь вынужден содержать ещё один стек технологий, либо потратишь чуть больше времени на "текущем" языке для решения этой задачи, чем на другом языке.
Так что "язык выбирают по надобности" не всегда хорошая философия. Не говоря уже о том, что в конечном итоге всё сводится лишь в наличие или отсутствие уже кем-то написанной библиотеки. Но ведь её кто-то когда-то написал. Так почему не помочь в создании библиотеки на вашем "основном" языке?
Лучше субъективно для меня. Я в основном веб бэк пишу, и его в целом можно на чем угодно сделать, даже на сишке (но надо быть особым "затейником"). Соответственно все что дальше написано - чисто моё мнение, на истину не претендую.
Жаба со шпрингом имхо даёт наилучшее сочетание скорости разработки, скорости приложения и количества багов "по невнимательности" на квадратный байт: checked exception, strong typing, depinjection из спринга. На пистоне разработка быстрее но можно легко сделать шапито если вместо числа придёт строка (условно), а если все обмазать pydantic - будет невероятно медленно. Го быстрый, но какой-то странный, хз, вроде норм и вдруг какая-нибудь фигня (для меня, опять же)
А ещё у жабы божественный мавен и чуть менее божественный гредл. Что у го, что у питона вместо системы сборки и управления зависимостями кривые затычки
Что такое компиляция и точка входа в программу вы конечно же не знаете, да?
Те кто говорит что го лёгкий - ничего не знает о го. Простые вещи бывает сделать не так просто или слишком дотошно
Иногда скучаю по временам где я писал на руби, и жаль что тогда crystal ещё не создали (хоть я его и не пробовал но восхищаюсь).
А, хотя вспомнил, я терпеть не могу исключения, и потому всё ещё на го с его примитивной логикой ошибок
Но ведь исключения прекрасны. Если нужно пробросить ошибку на 10 уровней вверх вручную, это же ад, нет? Или на Go пишут без рефракторинга на небольшие функции?
Чаще бывает что никто не проверяет исключения и весь код падает, чем случаи когда нужно пробросить ошибку. Даже профессиональные разработчики с многолетним опытом банально забывают обработать исключение, недавно случай был на проде
А если ещё дойти до правильности обработки, а не просто всё словить и залоггировать... Хотя и на го ошибки не менее сложно обрабатывать корректно
У исключений печи одно преимущество: если ты его не обработал, ты увидел трейс. Если ты не обработал err, не добавил к ней метаданные, то сиди ищи источник
Куда именно падает весь код? В бакенде, когда мы предоставляем какой-то API кому-угодно, исключения очень эффективны. Пишется один единственный обработчик верхнего уровня в который прозрачно движком обернуты все хендлеры API. В результате если при вызове любого метода API что-то там кинуло исключение, обработчик его корректно обработает, залоггирует и API вернет соответствующую ошибку, в зависимости от типа исключения. Так что внутри, в бизнес-логике как правило вообще ловить исключения не надо, надо только их бросать, если есть необходимость. Ну и ловить только какие-нибудь экзотические случаи, типа, надо делать retry при optimistic lock exception, хотя, на мой взгляд, даже тут надо думать как их избегать, а не ретраи делать.
Код сильно чище чем на go и это, наверное, единственная причина, почему я с него ушел и не использую в бакенде.
Ну и где-то читал статью, что исключения очень дороги по производительности
Если нужно пробросить ошибку на 10 уровней вверх вручную
В rust это выглядит достаточно удобно. Если возвращаемый тип Result с одинаковым типом Error как у вызывающей функции, так и у вызываемой - то достаточно знак вопроса добавить и автоматом если ошибка - будет сделан возврат. При этом нет той самой неявности что в исключениях мешается.
Ручная проверка ошибок полезна при написании критического софтра, когда нужно точно знать где возникла ошибка. Исключения могут вылезти из глубоких недр стека - вот и сиди и гадай какой эксепшн ловить. При написании корпоративных приложений это удобно, а вот для низкоуровневых вещей ловить исключения - страшно
Такого уровня зарплату и на питоне найти не проблема. Go выигрывает по зарплате на старших грейдах, а до них вам ещё пилить и пилить.
Ну и да, вот и выросло поколение, не видевшее c/c++, как говорится. )
Скорее не изучавшее базу CS, впрочем, все же склоняюсь к тому что это стеб. Сложно представить мне живого человека, что 3 года в профессии, но не знает ни про разницу между статической и динамической типизацией, ни про то как запуск программ происходит. Да что уж, сложно представить даже просто получившего работу человека который этого не знает. У меня коллеги 1сники с первой работы то это все знали даже, хотя они принципиально почти никуда кроме 1с не смотрели.
Яркий пример почему не стоит учить и не стоит изучать Питон первым языком
Эх, тоже когда-то начинал с python, потом перешёл на go - поначалу был очень неудобно и непривычно, потом освоился и python стал казаться каким-то не таким...
Сейчас в свободное время почитываю книги по rust - некоторые главы отлично заполняют пробелы в понимании, а некоторые вещи кажутся настолько логичными и удобными, что хочется забросить go:) Но пока сложно.
Тяжело читать, я как питонист могу сказать надо было тебе на rust переходить там бы ни каких проблем не возникло у тебя.
представьте, а еслиб он на сях решил пописать....
Я ни дня не работал в it, но оказывается, знаю в разы больше. Пишу для себя)
Переход с Python на Go: мысли человека, которому иногда сложно