Под равносильностью я имел в виду, то что писать заключения вроде «программисты на Rust злоупотребляют unwrap», равносильно тому что «программисты на Go злоупотребляют пропуском обработки ошибок», механизм работы, конечно же, отличается.
работа программы будет молча продолжена
Будет молча продолжена до первого обращения к результату и выскочит какой-нибудь NPE. Вряд ли программа написана так, что с результатом никакой последующей работы не ведётся.
Что тоже не очень комплимент "практическому опыту" авторов — писать сложнейший проект на языке, который ещё несколько лет как не достиг стабильного релиза.
Языка для такого проекта не было (с проблемами С++ не захотели связываться) и именно с языка и начался проект.
Справедливости ради, хочу добавить, что после Rust на Go программировать приятнее благодаря простоте этого языка и экосистема Go на порядок лучше развита (специально здесь использую данное словосочетание).
Мне нравится простота и развитость Go и нравится безопасность и функциональные возможность Rust.
Нет я хочу сказать, что когда в совершенно новый язык добавлятся новая фича и объявляется как "на порядок лучше" — это всегда наивно и преждевременно. Настоящее испытание "фич" происходит годами, по мере того, как программисты массово начинают её использовать и на практике становится понятно, насколько это работает так.
Вас похоже задело фраза «на порядок лучше».
Давайте я перефразирую.
В Rust, так же как и в Go, нет исключений. После написания программ на Go и Rust, я считаю (это ключевой момент, это моё мнение), что обработка ошибок в Rust сделана на порядок лучше.
Фича обработки ошибок в Rust уже испытана более чем двумя годами прошедшими со дня релиза первой версии и программисты массово её используют, т.к. программа без обработки ошибок не скомпилируется.
При этом unwrap не рекомендуется для использования в продакшене, т.к. необработанная ошибка упадёт в рантайме с паникой. Использовать unwrap в Rust, равносильно пропуску обработки ошибки в Go.
На личном опыте написания программ на языках Rust и Go.
Как раз "практичность и эмпиричность" означает проверенность временем и обкатанность реальными программистами на реальных проектах, а не теоретические размышления, что будет лучше.
Вы хотите сказать, что программы на Rust не обкатаны на реальных проектах?
Я не сильно слежу за миром Rust, но из нескольких свежих статей сложилось впечатление, что Rust-программисты злоупотребляют .unwrap()
Если судить по статьям, то Go-программисты злоупотребляют пропуском обработки ошибок. Вы же понимаете, что статьи пишутся не для того, чтобы досконально все ошибки описывать. Лучше судить по коду на гитхабе. И не любительских проектов, а тех что работают на продакшене.
В каждый тред где человек пишет, что перешёл на Go, ему советуют попробовать D. Если человек пишет что перешёл на Rust, то у него спрашивают: «Почему не на D»?
Похоже у D слишком плохо с PR-ом, раз на него не переходят :)
Под равносильностью я имел в виду, то что писать заключения вроде «программисты на Rust злоупотребляют unwrap», равносильно тому что «программисты на Go злоупотребляют пропуском обработки ошибок», механизм работы, конечно же, отличается.
Будет молча продолжена до первого обращения к результату и выскочит какой-нибудь NPE. Вряд ли программа написана так, что с результатом никакой последующей работы не ведётся.
Языка для такого проекта не было (с проблемами С++ не захотели связываться) и именно с языка и начался проект.
Справедливости ради стоит упомянуть, что от стабильного релиза языка прошло чуть больше двух лет.
Складывается ощущение, что вы думаете, что на Rust написан только servo и что пишут на нём только авторы языка.
Не знаю, насколько проект удался, но Firefox Quantum основанный на servo уже в бете и в ноябре планируется релиз.
https://blog.mozilla.org/blog/2017/09/26/firefox-quantum-beta-developer-edition/
Я специально сделал упор что фраза «на порядок лучше» — это моё личное мнение, основанное на опыте.
Нет, ну если хотите, называйте panic-recover-defer исключениями :)
Но используется этот механизм не так как в других языках.
Например, в других языках, библиотеки пишут так, что отсутсвие записи в базе выбрасывает исключение.
Или библиотеки валидации пользовательского ввода выбрасывают исключения на ошибки валидации.
Или, например, чтобы отдать пользователю по HTTP вместо 200 статуса, какой-нибудь 400-тый выбрасывают исключение.
И у меня отвращение от такого использования исключений.
В Go для таких случаев не будут применять panic-recover-defer.
Теоретический ;)
Справедливости ради, хочу добавить, что после Rust на Go программировать приятнее благодаря простоте этого языка и экосистема Go на порядок лучше развита (специально здесь использую данное словосочетание).
Мне нравится простота и развитость Go и нравится безопасность и функциональные возможность Rust.
Вас похоже задело фраза «на порядок лучше».
Давайте я перефразирую.
В Rust, так же как и в Go, нет исключений. После написания программ на Go и Rust, я считаю (это ключевой момент, это моё мнение), что обработка ошибок в Rust сделана на порядок лучше.
Фича обработки ошибок в Rust уже испытана более чем двумя годами прошедшими со дня релиза первой версии и программисты массово её используют, т.к. программа без обработки ошибок не скомпилируется.
При этом unwrap не рекомендуется для использования в продакшене, т.к. необработанная ошибка упадёт в рантайме с паникой. Использовать unwrap в Rust, равносильно пропуску обработки ошибки в Go.
divan0 дайте, пожалуйста, ссылки на эти статьи, где «все просто используют unwrap». Я бы с удовольствием почитал.
На личном опыте написания программ на языках Rust и Go.
Вы хотите сказать, что программы на Rust не обкатаны на реальных проектах?
Если судить по статьям, то Go-программисты злоупотребляют пропуском обработки ошибок. Вы же понимаете, что статьи пишутся не для того, чтобы досконально все ошибки описывать. Лучше судить по коду на гитхабе. И не любительских проектов, а тех что работают на продакшене.
Перед тем как написать комментарий прочитал всю статью и устроенный вами срач :) Просто забавное наблюдение.
Не только в одном. В Rust-е так же нет исключений, но обработка ошибок там на порядок лучше реализованы чем в Go.
В каждый тред где человек пишет, что перешёл на Go, ему советуют попробовать D. Если человек пишет что перешёл на Rust, то у него спрашивают: «Почему не на D»?
Похоже у D слишком плохо с PR-ом, раз на него не переходят :)
В 2015 отмечали Шесть лет Go
В 2017 отмечаем Go: 10 лет и растём дальше
Быстро, однако, Гофер стареет :)
У раста ещё есть хороший подход убирать конкретизацию типа под выражение where:
Тогда само определение функции становится более лаконичным.
Интересно, а GlusterFS не пробовали? Может она бы подошла.