З нетерпінням чекатиму продовження про дужки, бо мене на тій схемі також в Rust занесло.

Класно зробили. Такий собі низькорівневий хаскель

Вирішив цьогорічний Advent of code написати на rust. Враження дуже цікаві. Поки що написав тільки перше завдання (добре, із його продовженням) і маленьку бібліотечку для завантаження вводу з сайту. Довелося трохи покопирсатися в стандартних бібліотеках (ini для налаштувань і hyper для завантаження даних), але впорався, код працює.
Що дуже сподобалося: в файлі проекту (.toml) дописуєш вимоги до бібліотеки, на кшталт

ini=">=0.6"

тобто бібліотека ini версії не нижче за 0.6, і компілятор при збірці сам(!) її завантажує. Можна навіть прописувати посилання на GitHub.
Що приємно: невикористані змінні не викликають нарікань компілятора, якщо починаються на _. Наприклад, цикл в 10 повторень виглядає як

for _ in 0..10 {print!("*")}

Якщо замість _ написати i, компілятор лається на невикористану змінну. Так само останній варіант match-ів зазвичай позначають _.
Із чим довелося позависати:
1. Обробка помилок. В Rust немає виключних ситуацій і вважається дурним тоном використовувати unwrap-и. Функція, що може повернути помилку, має повертати тип Result<T,E>, зі значеннями Ok(T), якщо все гаразд і Err(E), якщо щось пішло не так. unwrap, насправді, працює так:

match result {
  Ok(value) => value,
  Err(error) => panic!(error),
}

Але панікувати - це не наш метод. Замість панікувати використовується така схема:
- створюємо власний тип помилки із переліком можливих проблем, проблеми, що йдуть "транзитом" з інших функцій, при цьому обгортаються в наш тип:

enum Error {
  MyError, //це наша помилка
  IoError(io::Error), //а це помилка введення даних, яка виникає в іншій функції, викликаній з нашої
}

- визначаємо кілька функцій для виведення повідомлень про наші помилки та перетворення з чужих типів помилок (як от io::Error) на наш; гадаю, тут скоро виникне (а швидше за все, вже виник, я просто поки не знайшов) типовий макрос для визначення таких функцій в типових випадках, а як ні, то мені варто його написати;
- замість методу .unwrap() використовуємо макрос try!, який робить замість panic! звичайний return. У версії 1.13 - наразі останній - цей макрос можна замінити знаком ? (читається "Carrier", це звично для rust, ! в макросах читається як "Bang"), для спрощення ось таких виразів:

let x=try!(try!(try!(a().b()).c()).d().e());

якщо не зрозуміли (а це реально важко), тут відбувається ланцюжок викликів a().b().c().d().e() (це типово для rust), але функції b(), c() та e() повертають не простий тип, а result. Із керіером це виглядає так:

let x=a().b()?.c()?.d().e()?;

2. Rust бореться із Q&D code (програмуванням на тяп-ляп). Звісно, повністю його не перебореш, он ті ж unwrap-и є якраз прикладом такого Q&D; але деякі речі дуже правильні, хоча звикати до цього важко. Отже, ситуація: я написав функцію для завантаження мого input-у з сайту Advent of code

fn get_input(url:&str, session:&str)

Відлагодив (мої поневіряння із Hyper поки що описувати не буду), запрацювало. Але трохи нецікаво писати ці речі в кожному файлі, тому я вирішив підвантажувати їх із .ini. Ну і перша думка:

fn get_input(url:&str, session:&str){
  if str.is_empty() || session.is_empty() {
    //завантажити ini, замінити url чи session на значення з ini
  }
  //завантажуємо дані, як зазвичай
}

А от не виходить. Треба додатково проголошувати змінні перед перевіркою і копіювати у них значення з ini - бо інакше ini припинить існувати при виході з блоку if. А це вже зовсім некрасиво. Тому я проголосив додаткову функцію

fn get_input_from_ini(){
  //завантажити ini, взяти з нього url та session
  get_input(url, session);
}

Тепер, якщо викликати нову функцію, ini живе достатньо довго для того, щоб брати посилання на рядки з нього. А якщо ini не потрібен - треба брати стару.

А ще маю відзначити роботу оптимізатора. Якщо в test/debug-збірці перебір md5 тягнувся по 100000 за пару секунд, то в release - пара мільйонів на секунду.

А в результаті обійшлося взагалі без match.

Дякую, встиг.

Навіть не знаю.. бо не знаю навіщо мені Rust..

Написання типової програми на Rust для мене складається з таких етапів:
- написати функціональний код;
- скомпілювати, переконатися, що не працює;
- довго і нудно розбирати на імперативний, виправляючи помилки, знайдені компілятором;
- довести до компіляції, переконатися, що працює, як слід (у Rust якщо скомпілювалося - 90%, що запрацює як слід);
- зібрати назад у функціональний.

Функція, що робить з "abc" рядок "A-Bb-Ccc", на Python:

def accum(s):
    return '-'.join((c*(i+1)).title() for i,c in enumerate(s))

і на Rust (тільки зі стандартною бібліотекою):

use std::iter::*;

fn accum(s:&str)->String {
    s.chars()
     .enumerate()
     .map(|(i,c)|{
          let mut word = String::new();        
          word.extend(c.to_uppercase());
          for _ in 0..i {
              word.extend(c.to_lowercase());
          }
          word
       })
     .collect::<Vec<_>>()
     .join("-")
}

Книга: https://doc.rust-lang.org/book/
Поточний стан перекладу: https://github.com/pavloslav/rust-book- … dition/src