Будущее WebAssembly в виде «дерева навыков»

Радует, что Rust — на передовой линии, в плане поддержки Wasm. Хороший современный системный язык, который все больше становится языком общего назначения. Может быть лучшие дни популярности FireFox уже и прошли, но мне нравится, как Mozilla борется за "место под солнцем", вкладываясь в такие фундаментальные технологии, как Wasm и Rust.

Будущее WebAssembly в виде «дерева навыков»

На Хабре, кстати, есть ее перевод: WebAssembly — это возвращение апплетов Java и Flash?

Будущее WebAssembly в виде «дерева навыков»

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

Будущее WebAssembly в виде «дерева навыков»

Поэтому существуют децентрализованные сети. В вашей схеме Чей-то сервис — им может быть и децентрализованный сервис, и машина самого пользователя, в том числе.

Выпуск Rust 1.30

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

Выпуск Rust 1.30

Обещанный блог-пост таки вышел, слегка с опозданием: Help test Rust 2018

Выпуск Rust 1.30

Ну и что с того? У вас же монтироваться они будут в одном месте — переходите к указанной функции-обработчику и все. Наоборот, удобно, что та часть запроса, которая должна соответствовать сигнатуре обработчика, указывается рядом с этой сигнатурой. Более того, так как она задается в процедурном макросе, мы можем проверять во время компиляции это соответствие.

Выпуск Rust 1.30

В unsafe Rust первая проблема решается:

let a = unsafe {
    let mut array: [i32; N] = std::mem::uninitialized();
    for i in 0..N {
        std::ptr::write(&mut array[i], i);
    }
    array
};

Выпуск Rust 1.30

Ну сейчас устаканивается Rust 2018, поэтому в основном завершается стабилизация уже разработанного ранее. Константы в обобщенных типах еще требуют серьезной разработки и широкого тестирования, так что в нынешнем году мы их точно не увидим в стабильном Rust.

Выпуск Rust 1.30

В Cell-ах и трехэтажных шаблонах все же лучше сразу разобраться, чтобы понимать, как реализовывать некоторые, привычные по другим языкам программирования вещи в Rust.

Допустим у вас есть некий объект и вы хотите хранить ссылки на него в нескольких местах одновременно. Но тут возникает сразу две проблемы:

1. Объект должен быть доступен из разных мест по ссылке, и удален только тогда, когда на него нет ссылок. Если есть по крайней мере одна ссылка, то объект должен жить.
2. Правила Rust позволяют иметь больше одной ссылки только на неизменяемый объект. Ссылка на изменяемый объект может быть только одна, без каких либо других ссылок на этот объект.

Первая проблема решается подсчетом ссылок (reference counting) и в других популярных прикладных ЯП она обычно скрыта от пользователя за реализацией. То есть любая "ссылка" на объект в таких ЯП всегда есть умный указатель со счетчиком ссылок. В Rust же такого типа ссылку нужно создавать вручную, если она вам нужна. Для этого используются типы Rc и Arc. Кроме того, нужно как-то решать вопрос образования циклических ссылок (Weak).

Вторая проблема решается введением совместно используемых изменяемых контейнеров — это типы Cell, RefCell, Mutex, RwLock.

Я рекомендую прочитать вот эту страницу официальной документации и разобрать приведенный там пример с гаджетами для того, чтобы понять, для чего и как использовать Rc, RefCell и Weak вместе. Также рекомендую ознакомиться с документацией по cell.

Выпуск Rust 1.30

Если вам не обязательно хранить ссылку на родителя в дочернем элементе, то реализация будет тривиальна. В противном случае вам придется:

• Использовать Rc, RefCell и прочие Weak; или
• Использовать сырые указатели и управлять освобождением памяти вручную; или
• Хранить узлы во внешнем контейнере и ссылаться на них по индексу; или
• Использовать готовые библиотеки, которые скрывают всю кухню за своим API.

Вообще, для лучшего понимания, рекомендую изучить реализацию rust-forest. Там представлено несколько подходов и они довольно неплохо прокомментированы.

Выпуск Rust 1.30

Ну вот посмотрите, как это делается в Rocket:

#[get("/<name>/<age>")]
fn hello(name: String, age: u8) -> String {
    format!("Hello, {} year old named {}!", age, name)
}

fn main() {
    rocket::ignite().mount("/hello", routes![hello]).launch();
}

То есть атрибуту на откуп отдается указание метода и параметров запроса, а к корневой части пути разные обработчики монтируются в одном месте.

Выпуск Rust 1.30

Несмотря на то, что Rust позиционируется как системный язык программирования, он также является языком программирования общего назначения. Что плохого в том, что как системный ЯП Rust имеет развитую систему типов и довольно высокоуровневые абстракции с нулевой стоимостью, а как прикладной ЯП — высокую производительность?

Выпуск Rust 1.30

А в чем, собственно, проблема? Атрибуты в Rust реализованы не через строки, как в Go, они вполне себе парсятся и проверяются во время компиляции.

Выпуск Rust 1.30

Похоже, что не отключается. Придется терпеть )
Хотя у меня нормально отображается и в узкой консоли:

Интервью c Аароном Паттерсоном, спикером конференции RubyRussia 2018

Когда я пишу на Си, я почти уверен, что не будет утечки памяти. С Rust ясно как белый день, что утечки памяти не будет.

Вообще-то Rust не избавляет от утечек памяти.

Yew — Rust&WebAssembly-фреймворк для фронтенда

Если речь про todomvc, то вот:

Обработка ошибок в Go 2

Из того, что мы "толком не знаем" не следует, что обработка ошибок не будет осуществлена также "здесь и сейчас", выражаясь вашей терминологией. Объявляется обработчик отдельно, но "определяется" он точно также в месте возникновения ошибки: просто связь устанавливается не по имени, а по порядку следования. Только в этом отличие.

Обработка ошибок в Go 2

В Rust'е, слава богу, такого поведения нет.

Так что вы изначально хотели получить от Rust'а? Возможность устанавливать обработчик положением в потоке кода? Так нельзя (без макросов). Я ваш исходный комментарий понял так, что вас интересует возможность определить обработку ошибки не в том же месте, где она возникает. Но вы как-то странно понимаете, что значит "определить обработку". В итоге у вас получается, что action().map_err(handle) — определяет обработчик handle в месте возникновения ошибки, а check action() + положение этой строки в потоке кода — не определяет обработчик ошибки в этом месте ее возникновения.