В целом, ваш ответ скатывается в "мне тяжело изучать что-то новое, что хоть чуть сложнее того, что я уже знаю". Это не проблема языка или технологии. Это ваша проблема.
Это уже какие-то переходы на личности начались.
Это не моя проблема, это особенность языка Rust в нем очевидно порог вхождения больше чем в Go. Это не делает язык плохим, но отрицать это бессмысленно.
ну неужели нельзя было сделать так, чтобы вчерашний питонист, прошедший курсы, за один день въехал в раст.
Это кому вопрос? Разработчикам раста?
Неужели без дешевых манипуляций нельзя показать сильные стороны го?
Читаемость и порог вхождения. Ваши примеры тоже можно обвинить в манипулятивности. Давайте попробуем вести диалог без глупых наездов.
Что за хрень тут происходит для человек не знающего rust понять довольно сложно, а в go просто возвращается два значения, что должно быть понятно любого.
Можно сравнить еще работу со строками, в go есть просто один тип string, и с ними легко работать, в rust же есть два &str и String и можно голову сломать. В го чтобы сделать конкатенацию строк, просто пишешь s1 + s2, в расте же надо использовать макросы и там тоже есть определенные непонятные места.
В целом на rust действительно код получается лаконичнее, но это не значит, что его легче читать, особенно для начинающих.
Я начинал изучать го и раст одновременно и могу сказать, что понять как писать код на го намного проще. Когда пишешь код на раст возникает больше вопросов, чем ответов, в работу со строками и обработку ошибок не так просто вникнуть. В го же такого вопроса не возникает, если человек знает конструкцию if, значит он ужа знает как обрабатывать ошибки.
Они уже появились специальной сборке языка, которая называется Rust)
У go же другая идея - минималистичный синтаксис, чтобы на него мог легко переключится разработчик с любого языка. Дополнительные языковые конструкции идут в противоречие с этой задачей.
Разработчики в возрасте 40+ менее гибки и готовы к изменениям (читай — менее терпимы к хаосу и возможному бардаку в процессах, который в той или иной мере присутствует почти во всех компаниях).
Автор не может организовать процессы. Или терпит бардак в процессах, потому что "ну мы же команда", тимбилдинги и прочая ерунда, на которую чаще ведутся молодые. Старшие уже через это прошли и смотрят с усмешкой.
Таким людям сложно взаимодействовать с более молодыми членами команды, причем речь идет как о разнице в системе ценностей и интересов, так и в готовности подчиняться молодым руководителям.
Автору сложно взаимодействовать со старшими. Видимо отказываются поработать на выходных за спасибо.
Люди такого возраста обычно уже обзавелись семьей и у них куча других забот помимо работы. Они не готовы кодить днями и ночами «по кайфу», и по ночам разбираться с критичными инцидентами.
Опытные разработчики знают себе цену и не хотят овертаймить за спасибо. Если такое часто нужно в вашей компании, то опять же у вас просто бардак с процессами.
Возраст снижает способность к обучению и замедляет процесс (да и желание) изучения новых технологий.
Видимо у автора в его 25 или сколько там, этот процесс уже замедлился раз он сделал, такой вывод) Ладно шутки в сторону. Где ваши доказательства?
У нас мало разработчиков старше 40, не потому что они тупеют и уходят работать охранниками, а потому, что отрасль молодая, большинство еще не успели состариться. Некоторые конечно успели, но в те годы было мало программистов, а сейчас в кого не плюнь, все программисты, либо хотят ими стать. В процентом соотношении молодых больше (до 35).
В США эта отрасль развивается дольше и там средний возраст разработчика выше. По некоторым данным это 39 лет.
Возраст снижает способность к обучению и замедляет процесс (да и желание) изучения новых технологий.
Возможно 70-90 лет да, но говорить такое про 40 просто смешно.
Когда я вижу примеры паттерн матчинг в питоне, то у меня возникает множество вопросов.
Т.е. берут некий говнокод, который написан, мягко говоря не питон стиле, и пытаются облагородить этот говнокод не существующими средствами языка, а модификацией самого языка.
Использовать везде isinstance это не очень хорошая идея, в питоне же duck typing. Да иногда это может понадобиться, но скорее как исключение, а не общая практика.
Возьмем пример 1.
def main(value):
if isinstance(value, str) and value == "load":
load()
elif isinstance(value, str) and value == "save":
save()
else:
default()
Зачем тут проверять isinstance(value, str) остается загадкой. Скорее всего незачем, просто чтобы оправдать добавление паттерн матчинга.
Можно обойтись без паттерн матчинга.
def main(value):
if value == "load":
load()
elif value == "save":
save()
else:
default()
Возьмем другой пример:
def main(data_string):
values = data_string.split("~")
if isinstance(values, (list, tuple)) and len(values) == 2 and values[0] == "load":
load(values[1])
elif isinstance(values, (list, tuple)) and len(values) == 3 and values[0] == "save":
save(values[1], values[2])
else:
default(values)
Нужна ли нам тут проверка isinstance(values, (list, tuple)) ? В данном примере точно нет, т.к. метод split возвращает list. Но что есть values это аргумент функции, и неизвестно что туда прилетает. Если у вас в одну функцию прилетает совсем непонятно что, ну list и tuple то ладно, но если там совсем рандомные объекты прилетают, то проблема в вашем коде, а не отсутствии паттерн матичнга.
Можно переписать его так:
def main(data_string):
action, *data = data_string.split("~")
if action == "load":
load(*data)
if action == "save":
save(*data)
default(action, *data)
Да, мы не проверили длину. Но действительно ли это нам тут нужно? Из условий задачи это не ясно. Ну ладно, давайте проверим.
def main(data_string):
action, *data = data_string.split("~")
if action == "load" and len(data) == 1:
load(*data)
if action == "save" and len(data) == 2:
save(*data)
default(action, *data)
Может чуть менее красиво чем с паттерн матчингом, но уж точно не так ужасно как в изначальном примере.
Т.е. из того что я увидел паттерн матчинг не помогает в реальных задачах (во всяком случае из примеров я этого не увидел), а лишь позволяет замаскировать говнокод. Ведь от того что код стал лаконичнее, он не перестал быть говнокодом.
Все переврали, ладно хоть ссылку на исследования оставили.
Кажется вот о чем идет речь.
"Consistent with our hypothesis, language aptitude, as assessed by the Modern Language Aptitude Test (MLAT)22, was a robust predictor of all of the Python learning outcomes."
Речь не идет не о каких языковых способностях. Никто не понимает, что это такое и тем более как это измерить.
Но взяли некий тест Modern Language Aptitude Test (MLAT) из 1950х годов, и сравнили результаты прохождения этого теста с результатами в обучении Python.
С тех пор методики преподавания языка довольно существенно поменялись, даже если тогда этот тест для чего-то работал (конечно же не для определения неких мифических языковых способностей, а скажем, что человек может успешно учиться по некой программе из 1950х), то в настоящее время очень сомневаюсь. Нашли новое применение старому тесту, который возможно работает для метода обучения, который они тестировали. Но сейчас же миллион методов - есть книги, статьи, youtube, онлайн курсы, офлайн курсы, университеты и т.п. Очень сомнительное исследование.
Про anyhow не знал. С этой библиотекой действительно выгладит лаконичнее.
Потому что вы определили свой тип Error, а я использовал трейт std::error::Error.
Определять свой набор ошибок для каждой функции выглядит не слишком лаконично и довольно утомительно. В go этого не требуется.
Это уже какие-то переходы на личности начались.
Это не моя проблема, это особенность языка Rust в нем очевидно порог вхождения больше чем в Go. Это не делает язык плохим, но отрицать это бессмысленно.
Это кому вопрос? Разработчикам раста?
Читаемость и порог вхождения. Ваши примеры тоже можно обвинить в манипулятивности. Давайте попробуем вести диалог без глупых наездов.
Могу обратный пример привести.
vs
Что за хрень тут происходит для человек не знающего rust понять довольно сложно, а в go просто возвращается два значения, что должно быть понятно любого.
Можно сравнить еще работу со строками, в go есть просто один тип string, и с ними легко работать, в rust же есть два &str и String и можно голову сломать. В го чтобы сделать конкатенацию строк, просто пишешь s1 + s2, в расте же надо использовать макросы и там тоже есть определенные непонятные места.
В целом на rust действительно код получается лаконичнее, но это не значит, что его легче читать, особенно для начинающих.
Я начинал изучать го и раст одновременно и могу сказать, что понять как писать код на го намного проще. Когда пишешь код на раст возникает больше вопросов, чем ответов, в работу со строками и обработку ошибок не так просто вникнуть. В го же такого вопроса не возникает, если человек знает конструкцию if, значит он ужа знает как обрабатывать ошибки.
Они уже появились специальной сборке языка, которая называется Rust)
У go же другая идея - минималистичный синтаксис, чтобы на него мог легко переключится разработчик с любого языка. Дополнительные языковые конструкции идут в противоречие с этой задачей.
С нетерпением ждем от автора продолжения, почему они не нанимают женщин, негров, и азиатов. (Сарказм)
А может все наоборот? Читаю между строк:
Автор не может организовать процессы. Или терпит бардак в процессах, потому что "ну мы же команда", тимбилдинги и прочая ерунда, на которую чаще ведутся молодые. Старшие уже через это прошли и смотрят с усмешкой.
Автору сложно взаимодействовать со старшими. Видимо отказываются поработать на выходных за спасибо.
Опытные разработчики знают себе цену и не хотят овертаймить за спасибо. Если такое часто нужно в вашей компании, то опять же у вас просто бардак с процессами.
Видимо у автора в его 25 или сколько там, этот процесс уже замедлился раз он сделал, такой вывод) Ладно шутки в сторону. Где ваши доказательства?
Какой возраст у автора? 20?
У нас мало разработчиков старше 40, не потому что они тупеют и уходят работать охранниками, а потому, что отрасль молодая, большинство еще не успели состариться. Некоторые конечно успели, но в те годы было мало программистов, а сейчас в кого не плюнь, все программисты, либо хотят ими стать. В процентом соотношении молодых больше (до 35).
В США эта отрасль развивается дольше и там средний возраст разработчика выше. По некоторым данным это 39 лет.
Возможно 70-90 лет да, но говорить такое про 40 просто смешно.
Посмотри например на возраст создателей языка Go.
Статья - сборник каких-то глупых мифов.
System Design это интересная тема.
А вот как насчет задачек с leetcode? Научились чему-то полезному применимому в работе? Или эти знания нигде кроме собесов не пригодятся?
Почему? Там вроде самые большие зарплаты. Какие аргументы приводят?
У меня 3 банка, я менял симку. Никуда в офис приходить не приходилось. Даже если теоретически такое можно сделать, фактически банки это не делают.
Охваты будут ниже, денег меньше. Возможно они все-таки задумаются, о том чтобы производить что-то полезное, а не просто мусор.
Соглашусь
Да, спасибо. Сейчас уже не исправить, конечно же там должно быть elif и else
С точки зрения красоты вроде ничего не поменялось.
Когда я вижу примеры паттерн матчинг в питоне, то у меня возникает множество вопросов.
Т.е. берут некий говнокод, который написан, мягко говоря не питон стиле, и пытаются облагородить этот говнокод не существующими средствами языка, а модификацией самого языка.
Использовать везде isinstance это не очень хорошая идея, в питоне же duck typing. Да иногда это может понадобиться, но скорее как исключение, а не общая практика.
Возьмем пример 1.
Зачем тут проверять isinstance(value, str) остается загадкой. Скорее всего незачем, просто чтобы оправдать добавление паттерн матчинга.
Можно обойтись без паттерн матчинга.
Возьмем другой пример:
Нужна ли нам тут проверка isinstance(values, (list, tuple)) ? В данном примере точно нет, т.к. метод split возвращает list. Но что есть values это аргумент функции, и неизвестно что туда прилетает. Если у вас в одну функцию прилетает совсем непонятно что, ну list и tuple то ладно, но если там совсем рандомные объекты прилетают, то проблема в вашем коде, а не отсутствии паттерн матичнга.
Можно переписать его так:
Да, мы не проверили длину. Но действительно ли это нам тут нужно? Из условий задачи это не ясно. Ну ладно, давайте проверим.
Может чуть менее красиво чем с паттерн матчингом, но уж точно не так ужасно как в изначальном примере.
Т.е. из того что я увидел паттерн матчинг не помогает в реальных задачах (во всяком случае из примеров я этого не увидел), а лишь позволяет замаскировать говнокод. Ведь от того что код стал лаконичнее, он не перестал быть говнокодом.
А точнее? Вместо капчи теперь показывается реклама?
Если так сделают, то никто не мешает переключится на других подобных ботов и аудитория в миг уменьшится до нуля.
Сделал два бесплатных продукта. Круто, но деньги то где?
То что одного бота купили, какая-то странная история, мне не понятен экономический смысл.
А второй тоже как-то деньги приносит?
Все переврали, ладно хоть ссылку на исследования оставили.
Кажется вот о чем идет речь.
"Consistent with our hypothesis, language aptitude, as assessed by the Modern Language Aptitude Test (MLAT)22, was a robust predictor of all of the Python learning outcomes."
Речь не идет не о каких языковых способностях. Никто не понимает, что это такое и тем более как это измерить.
Но взяли некий тест Modern Language Aptitude Test (MLAT) из 1950х годов, и сравнили результаты прохождения этого теста с результатами в обучении Python.
С тех пор методики преподавания языка довольно существенно поменялись, даже если тогда этот тест для чего-то работал (конечно же не для определения неких мифических языковых способностей, а скажем, что человек может успешно учиться по некой программе из 1950х), то в настоящее время очень сомневаюсь. Нашли новое применение старому тесту, который возможно работает для метода обучения, который они тестировали. Но сейчас же миллион методов - есть книги, статьи, youtube, онлайн курсы, офлайн курсы, университеты и т.п. Очень сомнительное исследование.
Даже не в деньгах дело. Когда уже работаешь просто нет на это время, особенно если собеседуешься не в одну контору.