Насчёт .unwrap() — в этом-то и разница. В go ошибку можно не обрабатывать и это будет невидимо в исходном коде — так же, как и в Си. В Rust не проверенная ошибка (т.е. например Result, который не используется) вызывает предупреждение компилятора, а простейший способ её не обрабатывать — .unwrap() — помечает данное место как явно не обрабатывающее ошибки.
Представьте себе, что вам нужно в проекте на go из 10000 строк найти все места, где ошибки не обрабатываются, и оценить, сколько временеи нужно будет на приделывание правильной обработки. Вам придётся делать это, вручную вычитывая код. В Rust достаточно текстового поиска.
Команда как-то «сама» собралась в репозитории. Возможно, некоторая социальность GitHub'а помогает. Кажется, я сам изначально нашёл проект, потому что кто-то в ленте его отметил.
Никакой официальной поддержки от кого-либо у нас не было. До конца довести было непросто — поначалу было больше маленьких вливаний от многих людей, ближе к концу все почти все изменения делали одни и те же люди.
К сожалению, с переводами ситуация пока не самая лучшая. Авторы знают о нашем переводе и о нескольких других, но избегают придания им статуса «официальных». Наш перевод упомянут на странице документации оригинала, но интегрировать его к себе они пока не хотят — так сказал steveklabnik, который занимается документацией проекта.
Я пока знаю, что версии для читалок для оригинала сделал другой человек сс помощью pandoc (вместо нашего calibre). К сожалению, я не видел результат и не знаю, можно ли избежать там наших проблем с EPUB.
$ RUST_BACKTRACE=1 cargo run -- del '-1 OR 1=1' Running `target/debug/rust-phonebook del -1\ OR\ 1=1` thread '<main>' panicked at 'called `Result::unwrap()` on an `Err` value: ParseIntError { kind: InvalidDigit }', ../src/libcore/result.rs:736 stack backtrace: 1: 0x555c75a62f49 - sys::backtrace::tracing::imp::write::ha2610c4d9f39e7d20qt 2: 0x555c75a62128 - panicking::on_panic::h0137eb721b989e66zqx 3: 0x555c75a551fe - sys_common::unwind::begin_unwind_inner::h9323ab6063ed22d03es 4: 0x555c75a55998 - sys_common::unwind::begin_unwind_fmt::hd6d1e3432b74d1dc9ds 5: 0x555c75a619a1 - rust_begin_unwind 6: 0x555c75a91aff - panicking::panic_fmt::h3b414ef7ca9e7ec0wZK 7: 0x555c7586bff6 - result::Result<T, E>::unwrap::h17631234665356226696 at ../src/libcore/macros.rs:28 8: 0x555c7586ae97 - main::closure.11714 at src/main.rs:85 9: 0x555c7586ae3c - ops::impls::_&'a mut F.FnOnce<A>::call_once::h16646540071590734845 at ../src/libcore/ops.rs:1795 10: 0x555c7586ade2 - option::Option<T>::map::h18348351940653665552 at ../src/libcore/option.rs:425 11: 0x555c7586ad9c - iter::Map<I, F>.Iterator::next::h6843473521919548427 at ../src/libcore/iter.rs:1686 12: 0x555c7586aadc - vec::Vec<T>.FromIterator<T>::from_iter::h16476383075473108179 at ../src/libcollections/vec.rs:1160 13: 0x555c7586aa79 - iter::Iterator::collect::h14488226810590600205 at ../src/libcore/iter.rs:567 14: 0x555c758627f7 - main::h89fbfb3db45c0143MAa at src/main.rs:84 15: 0x555c75a64b94 - sys_common::unwind::try::try_fn::h5089277237340746579 16: 0x555c75a61808 - __rust_try 17: 0x555c75a6482d - rt::lang_start::h377d03c3ab92e2f1kox 18: 0x555c758b9609 - main 19: 0x7ffb915336ff - __libc_start_main 20: 0x555c7581eaf8 - _start 21: 0x0 - <unknown>Представьте себе, что вам нужно в проекте на go из 10000 строк найти все места, где ошибки не обрабатываются, и оценить, сколько временеи нужно будет на приделывание правильной обработки. Вам придётся делать это, вручную вычитывая код. В Rust достаточно текстового поиска.
Команда как-то «сама» собралась в репозитории. Возможно, некоторая социальность GitHub'а помогает. Кажется, я сам изначально нашёл проект, потому что кто-то в ленте его отметил.
Никакой официальной поддержки от кого-либо у нас не было. До конца довести было непросто — поначалу было больше маленьких вливаний от многих людей, ближе к концу все почти все изменения делали одни и те же люди.
К сожалению, с переводами ситуация пока не самая лучшая. Авторы знают о нашем переводе и о нескольких других, но избегают придания им статуса «официальных». Наш перевод упомянут на странице документации оригинала, но интегрировать его к себе они пока не хотят — так сказал steveklabnik, который занимается документацией проекта.
Я пока знаю, что версии для читалок для оригинала сделал другой человек сс помощью pandoc (вместо нашего calibre). К сожалению, я не видел результат и не знаю, можно ли избежать там наших проблем с EPUB.