Comments 82
Это все, конечно, мое субъективное мнение.
отсутствие явно напрашивающихся библиотек(например для работы с потоками)
Эм… В гоу есть goroutines, каналы и пакет sync. Что еще нужно?
крайне странная работа с модулями и версиями
В чем странность? Мое мнение, что, конечно, системе зависимостей далеко до, например, того, что мы имеем в PHP (composer), но что же в go mod странного?
На счет GOPATH — это не совсем так. Причём давненько ;)
поразительная многословность
По сравнению с Java, например?
отсутствие явно напрашивающихся библиотек(например для работы с потоками)
Вы действительно знакомы с Go?
Зачем там библиотеки если это ядро самого языка.
необходимость в GOROOT и GOPATH…
Вы действительно знакомы с Go?
Упомянутые переменные используются только при разработке. При исполнении ничего не нужно, ни библиотек, ни переменных.
Упомянутые переменные не необходимы, соответствующие значения определяются автоматически. Но вы можете их переопределить, если нужно.
И это не еще считая альтернативного способа go mod (который уже пару версий как основной)
плохой подход к обработке ошибок
Или напротив — хороший.
tendium
Отлично, но в реальном мире (если мы не пишем библиотеку для общего назначения) одного слова часто недостаточно. Да и емкое слово еще надо придумать. Ну, либо, придется лепить слова в одно, без подчеркиваний и кемелкейса
Авторы языка имели ввиду, что сложные названия вы можете организовывать через иерархический импорт.
а так — замечательный язык(хотя и со странностями)
Гоу — язык, как язык. Я бы не назвал его плохим, однако есть ряд особенностей, которые мне лично не нравятся, а недостаток это или нет — не хочу судить.
Вот примеры того, что мне не нравится:
- пакеты в go определяются именем каталога, причем документация говорит о том, что
Good package names are short and clear. They are lower case, with no under_scores or mixedCaps. They are often simple nouns [...]
Отлично, но в реальном мире (если мы не пишем библиотеку для общего назначения) одного слова часто недостаточно. Да и емкое слово еще надо придумать. Ну, либо, придется лепить слова в одно, без подчеркиваний и кемелкейса. С учетом того, что всё приложение состоит из пакетов (особенно, если оно хоть как-то более-менее сложное), это превращается в проблему для описания бизнес-логики в go (каждый раз, когда мне это нужно сделать, я убиваю в себе перфекциониста). Вот пример названия пакета из реальной жизни: validatingwebhookconfiguration (kubernetes, если что).
то, что я давно считал антипаттерном, в go — на удивление — часто нормальная практика. В частности использование глобальных переменных, с возможностью их модификации откуда бы то ни было. Например, настройки стандартного глобального логгера можно в любой момент поменять из любого места приложения.
более того, разработчик часто вынужден лезть в инстанс глобального логгера, потому что иногда нужно выводить логи из сторонних библиотек. Понятное дело, что адекватные программисты делают это в самом начале инициализации приложения и больше этого не делают, но выстрелить себе в ногу очень легко. В мире здорового человека для логов в библиотеку можно было бы передать имплементацию некоего интерфейса, но в мире курильщика так почти никто не делает. Вообще, в целом в go — в моем восприятии — почему-то крайне редко используется методология dependency injection.
система structure tags, имхо, достаточно крива в плане синтаксиса. В частности меня добивает тот факт, что разбить длинный тег структуры на несколько строк просто нельзя. Если структура имеет достаточно сложное описание тэгов, то без вариантов — у вас будет длинный рояль в кустах.
решение использовать регистр в качестве признака экспортируемого и не экспортируемого символа, имхо, было не до конца продуманным.
для новичка, наверное, будет удивлением, но в функцию, описанную как
func name([]interface{})нельзя передать переменную типа[]string, например (вместоstringлюбой конкретный тип). На это, понятное дело, есть свои причины, но тем не менее, это порой вынуждает писать полотна boilerplate кода.
текст ошибки рекомендуют писать с маленькой буквы и без знака препинания в конце, но многие крупные проекты на это забили, ибо текст ошибки часто нужно показать пользователю. Чтобы этого избежать, можно, конечно, сделать коды ошибок, а на их основе выводить что-то осмысленное, но часто это просто лишняя трата времени.
стандартов по неймингу методов, имхо, тоже недостаточно наработано. Например, если у вас есть геттер, который возвращает, скажем
entity, то часто у вас метод будет назван какEntity()(безGet). Но если у вас есть экспортируемое поле с этим же именем, то вы уже не можете использовать геттер безGet.
вообще, с геттерами/сеттерами всё не однозначно — у меня сложилось впечатление, что авторы по возможности дают напрямую работать с полями объекта. Но тут есть проблема — возможно, вы хотите дать прочитать, но от изменения объект не защищен. И тут уже как бы ответственность лежит на программисте. И ладно, если вы используете стороннюю библиотеку — всегда можно сказать "используй строго в соответствии с документацией", но если у вас есть свой внутренний проект, то рано или поздно кто-то создаст неявные зависимости там, где вы их не ожидали увидеть.
использование импорта пакета для получения сайд-эффекта а-ля
import _ "somepkg"за счет вызова функции "init" можно, имхо, смело считать bad practice, но в мире go это достаточно распространенная практика.
если вам надо разобрать в go json с заранее неизвестной структурой (или же с динамической структурой), то вы обречены на кучу бойлерплейта и врапперов. При этом встроенная библиотека для декодирования json эффективностью работы не впечатляет.
Вопрос на засыпку: сколько потеряешь в зарплате, переключившись с PHP на Java, если на PHP уже практически достиг потолка зарплат и уже получаешь больше чем половина Java разработчиков с опытом 10+ лет?
По нормальному кодер джун на яве без реалього опыта получает больше чем топ кодер на пхп с 20+ годами опыта.
Да, до джуна на яве расти дольше чем до миддла на пхп, но тем не менее.
До Джуна расти? С чего это? Джава это же не Аси или брейнфак, там ничего сверхсложного нет.
Последнее время слышим определение джуна как «я прочитал туториал по языку, порешал задачки, если вдруг затруднюсь — посмотрю функции в мануале или погуглю.». Формированию подобного мнения способствует дикое количество курсов «ява за 30 часов».
По нам определение джуна это программист с профильным (хотя не обязательно универсистетским, может самоучка) образованием, который изучил язык (не по туториалу, а по полноценному мануалу) так что бы все базовые функции знать не лазя в мануал, знает на том же уровне все нужные либы и иде и системы версий, но имеет небольшой опыт применения языка на практике (при этом сам завершил хотя бы 3 полноценных проекта).
В нашем определении даже джун пхп это минимум полгода изучения вопроса на фуллтайме, для явы в меру сложности и объема этот срок скорее ближе к 2 годам.
Ни в коем случае не настаиваем на своей правоте — мы просто объясняем о каких джунах мы говорили.
Джунство у вас зависит от языка? Если человек, полжизни писал на JS или Java, потом прошёёл курсы TypeScript/Kotlin за 30 часов — он джун в последних?
Джунство у вас зависит от языка?Время до джунства. Если пхп на порядок проще явы, то представляется самоочевидным, что джуном на нем можно стать быстрее.
Если человек, полжизни писал на JS или Java, потом прошёёл курсы TypeScript/Kotlin за 30 часов — он джун в последних?Затрудняемся ответить.
Учитывая условно-совместимый бакграунд — расти до сеньера он будет на порядок быстрее человека только пришедшего в профессию.
Если вопрос в том джун ли он — то скорее всего да, т.к. тут идет не изучение нового языка (о чем говорили мы), а переобучение на новую (хотя и сильно отличающуюся) версию.
Он однозначно не миддл, если вопрос в этом. Т.к. кроме базы в котлине\тайпскрипте за 30 часов ничеге не изучить. Однако с учетом бакграунда по сути в этой же области — за год вполне может стать сеньером, что для новичка в котлине просто фантастика.
так что бы все базовые функции знать не лазя в мануал, знает на том же уровне все нужные либы и иде и системы версий
Что есть базовые функции и либы?) Я до сих пор зачастую лезу по синтаксису в гугл, если конструкциями/функциями пользуюсь не часто.
На мой взгляд джунство это не просто знание технологии, а знание+уровень умения учиться и разбираться.
Что есть базовые функции и либы?)В случае с php это всё отсюда www.php.net/manual/en
Базовые знания — значит что необязательно знать все флаги или запоминать порядок аргументов, но о наличии функций с нужным функционалом и их поведении знать надо.
Что бы не было шедевров вида sleep(0.5), тогда как sleep принимает аргументом только целые секунды (в одном из тестовых заданий было у кандидата) или что бы не велосипедить перевод 2011-09-13 в unixtime (опять же в одном из тестовых заданий и кандидат гордился этим).
На мой взгляд джунство это не просто знание технологии, а знание+уровень умения учиться и разбираться.Умение учиться и разбираться нужно для любой работы.
Хороший пример, да. Противоречащий сам себе. sleep(0.5) — типичный пример, как люди уповают на своё знание. Если не пользуешься чем-то, что такие ляпы не даст совершать (нормальная IDE, отдельный статанализатор и т. п.), то гуглить (поиск гугла по php.net лучше поиска самого сайта) сигнатуры "базовых функций и либ" обязательно, чуть ли не при каждом использовании.
Я бы вообще к базовым PHP относил только основную работу со строками и массивами, ну и базовую с датами. Я вот за 20+ лет разработки на PHP не знаю даже полного списка поддерживаемых из коробоки баз данных. А когда открываю его, как сейчас, то о трети баз данных и не слышал никогда. Вы реально считаете, что джуну нужно знать, что PHP поддерживает DB++?
Хороший пример, да. Противоречащий сам себе. sleep(0.5) — типичный пример, как люди уповают на своё знание. Если не пользуешься чем-то, что такие ляпы не даст совершать (нормальная IDE то гуглить (Не противоречащий, т.к. мы сказали «надо знать», а не «уповать на знание»:) Вы же не гуглите оператор инкримента что бы не ошибиться «уповая на знание»?
Вы реально считаете, что джуну нужно знать, что PHP поддерживает DB++?Ща словим минусцов:)
Сам факт что поддерживает? Да, иначе это «английский со словарем», все равно как в английском не знать о существовании Future Perfect Continuous скажем или не знать как включается 6 передача на авто, т.к. «все равно первые два года выше 70км/ч нельзя ездить».
Учитывая что расширение экспериментальное — можно не знать деталей функций, но хотя бы что в принципе функции могут делать — знать надо. Что бы просто читая чужой код и внезапно встретив dbplus_find не думать «что это вообще за на фиг».
Из примеров — нас брали на аудит проекта и мы там увидели решение кэширования на файлах на диске в памяти. Само по себе неплохое решение, но для него нужны причины. Спросили — отчего так? Почему не мемкэшед например? Ответ — так пхп же не поддерживает мемкэшед. Вы понимаете? Человек зарезал один из хороших вариантов только потому, что он просто не знал о наличии в пхп его поддержки.
Если подходить к знанию языка по другому, то что дальше? Не надо знать sleep, потому что есть более универсальный time_nanosleep? Не надо знать родные функции mysqli потому что есть более универсальный pdo? Не надо знать зачем нужно экранирование кавычек потому что во всех нормальных фреймворках оно сделано на автомате? Можно забить на знание функций работы хмл, т.к. они редко встречаются в проектах и всегда можно нагуглить?
Ответ — так пхп же не поддерживает мемкэшедБерешь и гуглишь «PHP Memcache», очень легко.
Ответ на ваш последний абзац почти везде — «да». Для любого ЯП. Сильные разработчики, по моему опыту, выделялись совсем другими характеристиками.Для сильных разработчиков это всегда было обязательной базой.
Какой это разработчик на php если он php не знает? Чё за бред вообще?
Берешь и гуглишь «PHP Memcache», очень легко.С такой логикой можно взять школьника с 9 классами образования. Он тоже может нагуглить «php memcache», равно как и ООП подучить.
По Вашему в вакансиях пишут требования — знания php, знание yii, знание zend с целью узнать может ли разработчик нагуглить информацию по ним? Или с целью нанять разработчика знающего их?
Вы когда отдаете документы, допустим, на перевод, Вы ожидаете кого там увидеть в работниках? Человека знающего «английский со словарем»?
Какой это разработчик на php если он php не знает? Чё за бред вообще?PHP знает, библиотечные функции не все знает (=не может о конкретных поговорить, хотя в прошлом мог работать и с mysqli, и с XML, а мог и не работать). Поговорить о знании ЯП можно спросив про работу со ссылками, о сборке мусора, о типах, о классах. Дать несложное задание на кодинг и посмотреть результат (а гугл в помощь). Знание ЯП — само по себе лишь маленькая часть профессиональных навыков разработчика, так что странно на этом заостряться. Мы спрашивали больше о принципах дизайна, архитектуры кода и проекта, о их реальных проектах (это даже важнее остального). Кстати, у разработчиков с опытом преимущественно в других ЯП тоже был хороший шанс.
знание yii, знание zendПо моим впечатлениям конкретно на фреймворках на собеседованиях никто не заостряется. Желательно только иметь опыт хоть с каким-то в данной области.
Вы когда отдаете документы, допустим, на перевод, Вы ожидаете кого там увидеть в работниках? Человека знающего «английский со словарем»?Я в основном ожидаю увидеть перевод. Сильный лингвист может и только со словарём, да. Дальше аналогия ломается, т.к. перевод сильно отличается от разработки.
знание ЯП — само по себе лишь маленькая часть профессиональных навыков разработчика, так что странно на этом заострятьсяЭто обязательная часть навыков. Это как колеса у автомобиля. Часть маленькая, но если хотя бы одного нет — далеко не уедешь.
PHP знает, библиотечные функции не все знаетТогда он не знает php. В чем его знание состоит? В том что он знает что после функций надо точку с запятой ставить? Офигеть нормы знания.
А потом садятся в убер и удивляются что водители не все дорожные знаки знают, не ну а че, не все же встречаются каждый день, да и можно посмотреть как остальные водители едут, ага.
Вот здесь habr.com/en/news/t/495968/#comment_21470146 abar и F0iL неплохо написали на эту тему.
Вот главное оттуда
Люди просто путают «освоить синтаксис языка» и «освоить язык».
но лучше прочитайте полностью, т.к. изложено лучше чем мы сможем, да и повторятся смысла нет.
Знание ЯП — само по себе лишь маленькая часть профессиональных навыков разработчика, так что странно на этом заостряться.Речь не о разработчике. Речь о разработчике на конкретном языке программирования. Который, внезапно, оказывается даже не знает библиотечных функций этого языка. Но заявляет себя профессионалом в этом языке.
Я в основном ожидаю увидеть перевод.Перевод и гугл транслейт может сделать.
Но речь-то черт побери шла о джунах.
Директор-сеньер таксопарка может и прав не иметь, но когда прав не имеет водитель-джун это уже трэш.
PHP знает, библиотечные функции не все знаетТогда он не знает php. В чем его знание состоит
Не стоит судить так категорично. Невозможно знать всю стандартную библиотеку языка, т.к. языки развиваются, если только они не мертвые. Также невозможно знать все особенности всех библиотек и фреймворков для этого языка. Везде нужна своя мера, в этом суть.
В конечном счете значение имеет то, как, имея какое-то знание средств языка, ты сможешь решить ту или иную задачу и как сделаешь это эффективно… или условно эффективно, лишь бы заказчик был доволен.
Невозможно знать всю стандартную библиотеку языкаВы, вероятно, пропустили часть дискуссии выше. Речь не шла о знании вплоть до всех флагов, и даже порядок аргументов можно не везде помнить.
А вот знать какие функции есть в языке и какое их назначение — особой проблемы нет и это база знания языка, как таблица умножения.
Также невозможно знать все особенности всех фреймворков для этого языка.Про фреймворки речь не шла. Фреймворков понятно может быть целый зоопарк.
лишь бы заказчик был доволен.Заказчик бывает доволен сайтом который грузится 10 секунд и имеет целый набор уязвимостей. Так себе критерий.
Речь не шла о знании вплоть до всех флагов
А вот знать какие функции есть в языке и какое их назначение — особой проблемы нет
Что тогда вы подразумеваете под словами знать функции?
В том же php банально для массивов и строк порядка сотен функций. Помнить их все поименно не имеет практического смысла. Больший смысл имеет знать, что есть те или иные группы функций для определенного случая.
Заказчик бывает доволен сайтом который грузится 10 секунд и имеет целый набор уязвимостей.
Все должно быть регламентировано, иначе можно бесконечно долго доводить до «идеала».
Допустим, время отклика приложения было 10сек, вас это не устроило, вы оптимизировали работу и добились отклика в 1сек… а почему не 0,1сек… почему не 0,01сек? Где грань?
Что тогда вы подразумеваете под словами знать функции?Название, что делает, что принимает, особенности поведения если есть, возможные возвращаемые результаты.
Помнить их все поименно не имеет практического смысла.Выезжая на дорогу надо знать все пункты ПДД.
Все должно быть регламентировано, иначе можно бесконечно долго доводить до «идеала».Количество функций в ЯП не бесконечное.
Допустим, время отклика приложения было 10сек, вас это не устроило, вы оптимизировали работу и добились отклика в 1сек… а почему не 0,1сек… почему не 0,01сек? Где грань?А это опять критерий вида «заказчик доволен», к знанию языка он неприменим.
Грань очень простая: не должно быть недостатков/ошибок и/или избыточных затрат времени произошедших из-за незнания штатных функций ЯП.
Это не значит что надо брать д-еба который не знает программирования.
Суть в том, что если Вы нанимаете а) программиста б) на ЯП… то он должен уметь а) программировать б) знать ЯП.
Количество функций в ЯП не бесконечное.
Оно конечно, как и все в реальном мире. Но оно (количество) изменчиво.
Я привел вам простой пример о функциях массивов и строк в php. Их более двух сотен. Нужно ли помнить их все? Используются ли они все в реальной жизни? Помните ли и используете ли вы их сами?
Принцип Парето никто не отменял: в разработке в 80% случаев используется 20% функционала ЯП / фреймворка.
Это не значит что надо брать д-еба который не знает программирования.
Не надо в крайности бросаться. Я лишь акцентирую внимание на необходимой достаточности знаний.
Суть в том, что если Вы нанимаете а) программиста б) на ЯП… то он должен уметь а) программировать б) знать ЯП.
Не согласен с "б". Должен он знать ЯП на достаточном для вас как для работодателя уровне. Собственно и программирование так же.
Сейчас на PHP уже не так много специалистов.
В картинке к статье зарплата пхп спецов 100к — вторая снизу — ниже только дельфи.
При этом по количеству спецов пхп опять же на втором месте, только уже сверху, на первом яваскрипт.
Таким образом имеем — большая конкуренция за небольшую зарплату, каким образом это «не так много спецов на пхп».
Сам переход был обусловлен мыслями о будущем. В пхп я провел около 10-ти лет. Ушел когда мне было 36. В целом хотел тихой гавани в большой компании, где цикл разработки большой, а ты один из множества старперов. Мои ожидания полностью оправдались — большая компания, куча «возрастных» специалистов, где я со своими почти 40-ка выгляжу достаточно молодо. :)
А сами задачи интересней и сложней тех, с чем приходилось сталкиваться в PHP мире. Не берусь утверждать что так везде.
А меняли область разработки? Стали писать под mobile или desktop или, грубо говоря, "лишь" сменили PHP на Java, Symfony на Spring, Doctrine на Hibernate, а так продолжали решать те же бизнес-задачи, что и раньше?
Переход на самом деле занял время и усилий. На первых порах было сложно отказаться от многих PHP-привычек — сложно жилось без «магических» методов, очень много сервисов, dto, репозиториев (куда больше чем в PHP), в работе с базой пришлось значительно чаще использовать разные возможности БД. Преодалеть привычки помогло общение с коллегами и code review.
Звучит так, что мне перейти будет проще. :)
сложно жилось без «магических» методов, очень много сервисов, dto, репозиториевЗвучит как переход от более ситуативной разработки (aka г-код) к более систематической. Вред implicit кода и разделение ответственности описан еще в книжках 90-х (это самые старые, попадавшиеся мне). От ЯП вообще не зависит.
Может она атипичная для России, но вот Киеве смотрю аналогичную статистику (медианы, доллары в месяц, чистыми):
Junior Java — 900
Junior PHP — 900
Senor Java (10+ лет опыта) — 4400
Senior PHP (10+ лет опыта) — 4000
В питере скорее так (по знакомым, не по статистике)
Junior Java — 1500
Junior PHP — 600
Senor Java (10+ лет опыта) — 8000
Senior PHP (10+ лет опыта) — 2500
По москве на 20-50% больше, но пропорция сохраняется.
Но — java только в крупных компаниях, где только оффлайн, офис, диплом, NDA и все корпоративные вещи.
Не прямо 5, но 4,5+ тут, например
А 5 не просто рассматривают, а иногда кажется, что продешевил :)
По Java с теми же пераметрами предложений раз в 6 больше, а если зп/ожидания уменьшать, то сближаются числа, что косвенно подтверждает статистику.
Или банальная редкость технологий: если несколько крупных компаний связались с какой-то технологией, а она так и не «взлетела», то из-за острого желания найти нормальных работников — зарплаты предлагаются большие, но объем трудового рынка для этих технологий — мизерный, и скорее всего таким и останется.
Смотреть только на зарплаты — занятие сомнительное.
Оно плохо коррелирует с заявленной темой статьи
Если верить графикам в статье, то при медианной зряплате менее 8$/час как в РФ, и среднемировых около 30$ за вами будут охотиться HR любых компаний, какой бы язык вы не выбрали. При таком прайсе даже индусам сложно конкурировать.
объемы легаси быстро сократились (но как такое могло произойти?)
Варианты из личного опыта:
- фирмы, использующие заказной софт на Delphi, загнулись
- фирмы, использующие заказной софт на Delphi, перешли в веб. Сам несколько раз инициировал и принимал участие в подобных проектах в 2000-х, основной аргумент был: "у вас всё пиратское, а за это начинают сажать. или платите за windows, firebase (или как там его), сам delphi, или переписывайте на FOSS, желательно веб. Я, кстати, могу недорого переписать на LAMP"
- фирмы, использующие заказной софт на Delphi, перешли на заказной .Net (на Java ни разу не видел)
- фирмы, использующие заказной софт на Delphi, перешли на коробочный софт или SaaS
И да, аргумент про пиратское — тоже был крайне весомым, проблем с законом из-за софта мало кто хотел, а при легализации (венду купи, базу, если она не игрушечная борландовская — тоже купи, и так далее) делфи быстро переставала быть дешевой.
Ну да, "заказной" в моём комменте часто означало по факту "сын НОК на программиста учится же? Пускай нам склад сделает, а мы даже заплатим ему две стипендии его. Всё равно каждый день играть приходит"
Аргумент про пиратское стал весовым, когда реально начали за пиратство привлекать, до этого, как говорится, строгость законов компенсировались их неприменением. УК РФ вроде в 96-м приняли новый, да и до этого уже какие-то статьи были, а кампанию врде как раз в 2000-м и начали.
Ну вот про базу не нужно, мало кто использовал interbase от Борланд я видел в основном firebird (который полностью открытый и бесплатный продукт) а вот среда разработки да мало кто платил за лицензию, не говоря уже о компонентах. Тут скорее сыграл фактор резкого разового увеличения затрат, и многие пошли по пути раз уж всё равно платить то переделаем на более модном (при этом от вэб автоматизации многие страдали, т.к. более менее удобный для повседневных задач интерфейс стало возможно делать не так давно, а те кто умеет в них появились ещё позже) но да где работа заключалась в нажатии 2х кнопок и 3х полей ввода там веб был отличным вариантом.
www.businessinsider.com/the-top-coding-languages-with-the-highest-salary-2020-4#pascal-is-associated-with-an-average-global-salary-of-6277390-9
Например это легко проверяется по выборке его упоминания в проектах на Github
P.S. Стоит ли он изучения каждый может решить сам, но понимание принципов его экосистемы может оказаться полезным для расширения кругозора возможностей инструментальных средств применяемых с этим языком.
И, да, Вы не найдёте вакансий по нему в кадровых агенствах и заинтересованности Теам лидеров в нём :)
Можно ли называть языки аппаратного описания языками программирования? На мой взгляд, их стоит отделить.
По тем вакансиям, что видел я, у меня сложилось впечатление, что на том же Java, например, стартовать проще. Зарплаты тех, кто пишет под ПЛИС, выглядят в большинстве ниже. Правда, смотрел я предложения российского рынка труда. Может, в международной выборке ситуация иная. Также мне показалось, что в случае IP под специализированные микросхемы (ASIC), ситуация лучше. Правда и хлопот там побольше, чем в случае с ПЛИС.
Плюс очень хорошие зп были у тех, кто для амеров под заказ делал сайты на Wordpress/Magento.
У остальных да — все достаточно печально на пхп. И самое, что печальное — нет практического опыта, чтобы перейти на другой язык в более серьезную сферу.
Ну и фразу: «Хочешь деньги, учи Java» — никто еще не отменял.
Очень хорошая статья, лично я учу питон из за его плюшек и очень лёгкого синтаксиса
Даже не стал читать. Заголовок неправильный. Чтобы за вами охотились HR любой компании надо мозги иметь а не язык знать.
Я думаю пункты 3 и 5 должны быть на самом верху. Я долгое время работал Java и PHP разработчиком, но заинтересовался Rust'ом (когда-то давно у меня был и плюсовый опыт). Года полтора я просто изучал язык, писал на нем хобби-проекты в свободное время, старался активно участвовать в сообществе. Главными тут были — интерес к самому языку, вера в его перспективность и понимание того, зачем он нужен мне в моих личных проектах. Со временем стал неплохо разбираться в нем, и устроиться на работу не составило большого труда. Сейчас работаю Rust-разработчиком и в общем-то всем доволен. Хотя моя зарплата слегка уменьшилась с переходом на Rust, но она все равно осталась выше приведенных тут медианных значений и я получил возможность больше времени уделять тому, что мне нравится.
На основании моего скромного опыта могу сказать, что HR охотится на обладателей знания технологий, а не языков. Или в общем случае, на обладателей фундаментального знания, например, статистического анализа или линейной алгебры.
И я не согласен с Анной Мелеховой: с моей точки зрения мышление определяет язык. Параноик и педант не будет эффективно писать на динамическом языке со слабой типизацией, в то время как противоположный психотип не будет писать на С++/Rust.
www.businessinsider.com/the-top-coding-languages-with-the-highest-salary-2020-4#pascal-is-associated-with-an-average-global-salary-of-6277390-9
Какой язык программирования учить, чтобы за вами охотились HR крупных компаний