Comments 28
Выглядит вполне ничего, за исключением постоянного unwrap(). Впрочем, в go есть такое же в виде if err != nil. Ещё обидно, что стек-трейсы можно увидеть только в отладочной версии программы (в go они будут видны всегда).
Насчёт .unwrap() — в этом-то и разница. В go ошибку можно не обрабатывать и это будет невидимо в исходном коде — так же, как и в Си. В Rust не проверенная ошибка (т.е. например Result, который не используется) вызывает предупреждение компилятора, а простейший способ её не обрабатывать — .unwrap() — помечает данное место как явно не обрабатывающее ошибки.
Представьте себе, что вам нужно в проекте на go из 10000 строк найти все места, где ошибки не обрабатываются, и оценить, сколько временеи нужно будет на приделывание правильной обработки. Вам придётся делать это, вручную вычитывая код. В Rust достаточно текстового поиска.
Представьте себе, что вам нужно в проекте на go из 10000 строк найти все места, где ошибки не обрабатываются, и оценить, сколько временеи нужно будет на приделывание правильной обработки. Вам придётся делать это, вручную вычитывая код. В Rust достаточно текстового поиска.
В го можно искать по коду "_".
Go линтеры, вроде errcheck отлично справляются с этой задачей
А как они работают?
Анализирует код проекта и выдает список проблем с указанием файлов, номеров строк. В моем случае подсвечивает строки в редакторе (sublime), в которых есть необработанные ошибки.
Я имею ввиду, как анализируют. Знают, какие функции ошибки возвращают, или действительно, достаточно искать _ как выше предлагают?
Ну не я разработчик линтера.
Вообще выявляет как при использовании методов из пакетов, подключенных с гитхаба, так и собственных методов в проекте и стандартных. А по _ можно искать только маскированные ошибки, ведь по сути можно значение даже не получать.
Вообще выявляет как при использовании методов из пакетов, подключенных с гитхаба, так и собственных методов в проекте и стандартных. А по _ можно искать только маскированные ошибки, ведь по сути можно значение даже не получать.
Они парсят весь код на Go согласно синтаксису и проверяют.
Я не совсем понял: Rust сумеет при этом коде защитить от SQL injection или выполнит все что придет из запросов?
Вы про законченную версию из репозитория? Потому что здесь-то запросы к базе статические и защищать не от чего.
Да, вы пробовали отправлять sql injection в запросах законченной версии? Они нормально отсекались?
Это делает не Rust как таковой, а библиотека postgres, но да, он типобезопасен:
Заголовок спойлера
$ 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>
Спасибо, посмотрел на код на github'е: iron выглядит очень неплохо, тем более для низкоуровнего языка.
С нетерпением жду следующих статей.
С нетерпением жду следующих статей.
let me = Person {
id: 0,
name: "Михаил".to_string(),
data: None
};
для id нельзя задать None?
А «Михаил» не строка?!
А «Михаил» не строка?!
Строковые константы имеют тип &'static str, т.е. являются string slice, а в структуре у поля тип String — heap-allocated string, изменяемая строка. Почему выбран именно он — отдельный вопрос, потому как для &'a str тоже есть трейт ToSql и в execute можно напрямую передавать &'static str.
Строковые константы имеют тип &'static str, т.е. являются string slice, а в структуре у поля тип String — heap-allocated string, изменяемая строка. Почему выбран именно он — отдельный вопрос, потому как для &'a str тоже есть трейт ToSql и в execute можно напрямую передавать &'static str.
UFO just landed and posted this here
Уже написали несколько объяснений, но я попробую ещё раз, потому что про строки любят спрашивать :)
«Михаил» — это строковый литерал, это не «объект». Его нельзя изменять, например. Это «unboxed» значение, и to_string превращает его в boxed значение на куче.
«Михаил» — это строковый литерал, это не «объект». Его нельзя изменять, например. Это «unboxed» значение, и to_string превращает его в boxed значение на куче.
А «Михаил» не строка?!
pub struct Person<'a> {
pub name: &'a str,
}
fn main() {
let me = Person {
name: "Михаил",
};
}
Хабру пора добавить подсветку для Rust.
Sign up to leave a comment.
Создаём REST-сервис на PostgreSQL и Rust. Часть 1: прототип