Лучший способ найти работу - это создать её самому. Выкатываешь бизнес-идею (хотя бы в этот чат), находишь единомышленников, краудсорсишь средства на разработку, пишешь код -> профит.

Ну я понял, т.е., на текущий момент, это всё же инструмент для энтузиастов, которых не парит фактор автобуса)

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

Я думаю, что вопрос сеньеров не так сильно важен. Если конечный бизнес-продукт успешен, то всегда можно найти/научить людей.

Просто с точки зрения бизнеса язык вообще роль очень маленькую играет, потому что обычно считается, что это внутреннее дело отдела разработки. Ну а там обычно есть инерция.

Поэтому варианты - это либо в большой компании искать позицию, в которой есть относительная свобода действий (и там выбирать то, что считаешь правильным), либо искать стартап, который на начальном этапе готов использовать этот язык.

У меня такого сорта история в мейле была, когда я там airflow внедрял. Вначале тоже смотрели как на странную диковинку, но когда увидели, насколько успешное решение получилось, то смогли целую толпу инженеров найти, которые научились под него разрабатывать. Причём люди со всякого разного переучивались (и те кто на майкрософтовских тулах типа SSIS писали, и ещё там что-то было в багаже) и ничего, осилили и развили дальше.

Завершая мысль, айтишники не должны переживать из-за ситуации на рынке, так как искать людей - это задача HR, им за это деньги платят. Пытаться оптимизировать косты за счёт экономии на возможный поиск в возможном будущем - это не задача отдела разработки.

Говорю об этом, потому что наболевшее 😊 Слишком часто видел такое радение о бизнесе, которое не учитывает многих других факторов. В идеале разработчик должен приходить с заявлением типа "есть фреймворк/язык, в котором можно вот такую задачу сделать за пару месяцев, и мейнтейнить её смогут пара человек. Риски (которые я вижу) вот такие". И дальше уже человек, у которого есть бюджет, должен взвешивать риски, возможно принимать во внимание какие-то другие факторы о которых ты не знаешь и исходя из этого запускать или не запускать соответствующий пилот.

Плюс для питонистов неинтуитивно, только аннотации стали писать и бац - оказывается не надо )

😊

А в питоне они кстати что-нибудь делают?

Или только линтера?

Pydantic -- условно, датаклассы с проверкой типов в рантайме
И, я тут узнал, такую штуку

Есть multiple dispatch на типах

Ну и документация тоже
+ Ошибки ловить можно так

>Типы нужны только для multiple dispatch.
И все таки не соглашусь. Ограничение домена на котором работает функция через абстрактные типы тоже имеет смысл отдельно от multiple dispatch. Разбираться с сообщениями об ошибке где на вызове 10го уровня вложенности из функции внешего API пакета выясняется несовместимость типов то еще удовольствие...

#resources #meetup
Наши ресурсы:

Google doc: https://docs.google.com/spreadsheets/d/1-fcuVD6GbfK-_RrhLyzB7ENc-8MMSvN_0OMYSpdWDck/edit?usp=sharing

Calendar: https://calendar.google.com/calendar/u/0?cid=YjVhNmZjNzYxbzVjczJtNGFkOTJqMjJvdjRAZ3JvdXAuY2FsZW5kYXIuZ29vZ2xlLmNvbQ

Youtube: https://www.youtube.com/channel/UCnAz78fQXN4dDhP--XVPsFw

GitHub Organization: https://github.com/JuliaRussianCommunity

Может кто-нибудь закрепить ссылку на этот пост?

@kirtsar может добавить ссылку на этот пост в нынешний припиненный текст. Если сделать этот пост припиненным, то пропадёт общедоступный список литературы и останется только информация по митапам.

Не, теперь сохраняется история пинов

Ну как, проверяешь через mypy, он ругается если типы не стыкуются, можно в CI завести как проверку.

Ну, это я и назвал общим словом "линтер".