Как стать автором
Обновить

Комментарии 16

Ну почему, написано хорошо и с юмором. Я вот с удовольствием почитал :)

Мне не понравилось, даже в оригинале. Одна натужная шутка растянута на целую статью, при этом автор явно не понимает, какие проблемы решает borrow checker.

О, я первый… Хорошая статья — веселая :-) Сам пару дней как пробую Rust — и пока чувствую себя одичалым, шагающим по владениям Ланистеров...

Если вам в хватит упорства, то в конце прогулки будете чувствовать себя Королем Ночи. :)
Ну что я могу на это сказать… Терпите и настойчиво двигайтесь вперёд. Язык очень достойный. Сам занимаюсь им совсем недавно, хотя написал кое-что практически полезного. Подумываю сейчас не уйти ли на него вообще с привычного С/C++. Единственный его серьезный недостаток — пока маловато вакансий.
С C++ (особенно с так называемого “современного” C++) переход вообще лёгок и приятен.
Потому что почти все особенности Rust в “современном” C++ (с его rvalue references и std::move) тоже есть, только в программе они не прописаны, компилятором не проверяются и зачастую даже тестами не всегда выявляются.
Бороться с ними приходится уже тогда, когда всё упало упало у заказчика (ну или с помощью кучки санитайзеров).
Бороться с правилами Rust — тоже та ещё разлекуха, но по сравнению с C++ это просто сказка: если компилятор вы убедили, то дело на 90% (если не на 99%) сделано, скорее всего будет работать.
Аналогично продвигался сам. Пришел с Javа, без универского образования программиста и получил камнем по голове этими временами жизни, ссылками и т.п. Многопоточку до сих пор с трудом понимаю, благо есть много библиотек фунциональных и понятных.
Для пробы сделал простой веб бэкэнд для учета расходов с базой в Postgres. В процессе работы я получил много положительных эмоций и опыта. Actix web в простых задачах прост и понятен, Serde можно подключать не полностью, а только необходимые части, есть возможность использовать nanoserde если нужен только json и дорожите размером библиотек.

На самом деле надо просто понимать, когда требования слишком сильные и их можно ослабить В примере со строкой это просто:


let a = String::from("foo");
{
   dbg!(&a);
}
dbg!(&a);
dbg!(&a);

для вывода отладочной печати объект уничтожать не обязательно.


Альтернативно (для любителей заюзать линейность):


let a = String::from("foo");
let a = {
   dbg!(a);
}
let a = dbg!(a);
let a = dbg!(a);



Статья (оригинальная) оставила смешанное впечатленеи. С одной стороны забавно, а с другой — за ёлками потеряли лес. Ощущения как от статьи объясняющую монады через буритто и коробки.

Интересная статья!
Сам являюсь (в какой-то степени) Java Script энтузиастом, так что после прочтения аж самому руки зачесались пробовать всякие непотребства с Rust'ом :)
От нескольких дней, до пары недель будете плакать, бороться с компилятором, — потом привыкните и будете получать удовольствие, периодически налетая на подводные камни. И очень внимательно изучайте doc.rust-lang.org/book и начинать лучше, с 4 главы
Трюки с владением в Rust помогают решать проблемы конкурентного доступа к общим ресурсам из разных потоков. С перспективы однопоточного JavaScript такой проблемы вообще не должно существовать.

Не только из разных потоков, а в общем случае из разных контекстов. Раст расширяет защиту через четкое владение и на асинхронные приложения, типа тех, что пишут на JS.

То есть я хочу сказать, что не смотря на полную многослойную защиту памяти виртуальной машиной внутри и снаружи, в JS меньше конструкций помогающих избегать неконсистентных состояний.

let a = String::from("foo");
{
    dbg!(a);
}

Скоуп здесь ни при чем, a перемещается в dbg!, а не внутрь блока. То есть, такой код будет аналогичен:


let a = String::from("foo");
dbg!(a);

Да, тоже ждал, когда автор уберет скоуп и скажет «не все так просто, я вас обманул потому, что…», но нет. Видимо сам автор запутался в линейных типах.

Пример с владением в разных областях описан неверно. В вашем случае inner scope вообще не нужен и по сути это и будет dbg! — так как этот макрос завладевает переданной переменной.

```
let a = String::from(«foo»);
dbg!(a); // это inner scope по отношению к main
dbg!(a); // это тоже inner scope по отношению к main
```
Данный код вызовет ошибку, потому что inner scope вернул память системе
```
let a = String::from(«foo»);
a = dbg!(a);
dbg!(a);
```
Этот код не выозвет ошибку, т.к. inner scope вернул память main scope.

```
let a = String::from(«foo»);
{ // inner scope
let b = String::from(«bar»);
println!(«Я не владею {}», a);
println!(«Зато владею {}», b);
}
dbg!(a);
dbg!(b);
```
Этот код приведет к ошибке владения b, но не как не a. Т.к. inner scope не владеет а. А b как раз создана во владениях inner scope и буде тудалена когда inner scope закончится (на символе })
Зарегистрируйтесь на Хабре , чтобы оставить комментарий