Правда, тут есть другие проблемы:) Например, эти проверки начинают заражать ваш код. Да, для этого есть сахар, что упрощает жизнь. Но, в любом случае, вам придётся писать много преобразований из одного типа ошибки в другой или агрегировать их в discriminated unions (или, что ещё ужаснее, вызывать панику), чтобы хоть как-то разрулить многообразие ситуаций в работе программы.
let cool_result = match cool_function() {
Ok(result) => result,
Err(error) => return Err(error),
}; // длинный вариант
let cool_result = cool_function()?; // короткий вариант.
К тому же, тем, кто фапает на сверхскорость Rust, подобное не нравится из-за высокой вероятности оверхеда из-за ошибки предсказания перехода процессором. Но другого выхода особо не видно, поэтому получилось то, что получилось.
None — частный случай типа Option. Он похож на Result<R, E>.
Собственно, чтобы значение могло было None, вы должны явно сказать об этом в типах. И тогда нет, не будет такой гарантии, потому, что это валидный результат, который задекларировали вы же (или другой разработчик).
А вообще, по умолчанию, всей вот этой чехарды с повсеместными nil/null/None в Rust нет (опять же, из-за явного указания Option там, где оно возможно).
На примерах:
fn do_it() -> Result<Option<MyResult>, MyError>
// Если результат Ok(_), то внутри него может быть None.
// Например, Ok(Some(result)) и Ok(None).
// Ну и Err(error).
fn do_it_force() -> Result<MyResult, MyError>
// А вот тут None невозможен, только Ok(result) или Err(error).
Пытались как-то реализовать бота подобным способом и умудриться решить проблемы перезапуска и масштабирования. Решение в итоге нашли, но реализовывать не стали, т.к. в рамках наших задач особой нагрузки не было, да и взаимодействий много было и пришлось бы прилично так потратить времени на доработку.
Суть была в том, что, по хорошему, все входящие и исходящие сигналы бота должны быть (де-)сериализуемы для хранения где-то (например, в БД или кэше). Так диалог мог бы быть поднят/восстановлен в любом из нодов, на которых работал бот. Беда, как раз, в том, что даже вызовы методов сервисов и отправку их результатов пришлось бы оборачивать в сообщения.
Аналогично, в своё время, возвращал доступы к устройствам нерадивых пользователей — заменял файл, отвечающий за залипание клавиш на cmd.exe. Схема дальшейших действий эквивалентна.
В противопоставление этому есть другое мнение. Оно говорит о том, что паттерны выделяют для будущего использования. Причина тому ясна: использование проверенных временем механизмов абстрагирования помогает избежать ошибок, решение которых привело к появлению того или иного паттерна.
С транзакциями всё в порядке. Существует специальная очередь, из которой и берут записи для формирования блоков. Поэтому, из откинутых блоков записи снова помещаются в эту очередь.
Я уже описывал, что хэш должен быть больше, либо равен определенному числу (не постулат, но bitcoin использует именно эту схему).
Это искусственно ограничивает скорость создания блоков. Так что же мешает по определенным правилам регулировать это число?
Майнеры нужны из-за искусственного завышения вычислительной сложности для составления блока. Помним, что хэш-функция в идеале непредсказуема, а узлы, которые эти блоки хранят и проверяют, не принимают блоки с хэшем, значение которого меньше фиксированного числа. Из-за этого приходится множество раз менять вышеупомянутый counter для получения нового результата хэширования до тех пор, пока хэш не станет удовлетворять условиям принятия блока в цепь.
Простите за снобство, но это плохой пример. Если async f() возвращает обещание, то зачем оператор await после return? Не достаточно ли будет "вернуть" обещание? Механизм Promise'ов ждёт обещания любой глубины. Даже если обещание resolve'ит другое обещание.
Именно.
Правда, тут есть другие проблемы:) Например, эти проверки начинают заражать ваш код. Да, для этого есть сахар, что упрощает жизнь. Но, в любом случае, вам придётся писать много преобразований из одного типа ошибки в другой или агрегировать их в discriminated unions (или, что ещё ужаснее, вызывать панику), чтобы хоть как-то разрулить многообразие ситуаций в работе программы.
К тому же, тем, кто фапает на сверхскорость Rust, подобное не нравится из-за высокой вероятности оверхеда из-за ошибки предсказания перехода процессором. Но другого выхода особо не видно, поэтому получилось то, что получилось.
None — частный случай типа Option. Он похож на Result<R, E>.
Собственно, чтобы значение могло было None, вы должны явно сказать об этом в типах. И тогда нет, не будет такой гарантии, потому, что это валидный результат, который задекларировали вы же (или другой разработчик).
А вообще, по умолчанию, всей вот этой чехарды с повсеместными nil/null/None в Rust нет (опять же, из-за явного указания Option там, где оно возможно).
На примерах:
Есть. Но увы, как и всё, относящееся к Rust, разрабатывается крайне медленно.
Я вот всё, облизываясь, поглядываю на Azul.
Нет, не совсем так. Забили на восстановление диалога из истории.
Сами диалоги до сих пор на асинхронных корутинах работают:)
Согласен, потому и забили.
Потому, что при восстановлении код будет исполнен второй раз и запрос/вызов также будет вызван второй раз.
Пытались как-то реализовать бота подобным способом и умудриться решить проблемы перезапуска и масштабирования. Решение в итоге нашли, но реализовывать не стали, т.к. в рамках наших задач особой нагрузки не было, да и взаимодействий много было и пришлось бы прилично так потратить времени на доработку.
Суть была в том, что, по хорошему, все входящие и исходящие сигналы бота должны быть (де-)сериализуемы для хранения где-то (например, в БД или кэше). Так диалог мог бы быть поднят/восстановлен в любом из нодов, на которых работал бот. Беда, как раз, в том, что даже вызовы методов сервисов и отправку их результатов пришлось бы оборачивать в сообщения.
Аналогично, в своё время, возвращал доступы к устройствам нерадивых пользователей — заменял файл, отвечающий за залипание клавиш на cmd.exe. Схема дальшейших действий эквивалентна.
Шёл 2019 год. В PHP добавили короткие лямбды.
Ни в коем случае не умаляю работы над языком, но запоздание фичи довольно-таки велико.
Вы сами задали вопрос и, тут же, сами же и начали критиковать язык за свой же вопрос?
В противопоставление этому есть другое мнение. Оно говорит о том, что паттерны выделяют для будущего использования. Причина тому ясна: использование проверенных временем механизмов абстрагирования помогает избежать ошибок, решение которых привело к появлению того или иного паттерна.
На самом деле, нет. При правильном построении грамматики запроса последовательный разбор становится достаточно несложной задачей.
С транзакциями всё в порядке. Существует специальная очередь, из которой и берут записи для формирования блоков. Поэтому, из откинутых блоков записи снова помещаются в эту очередь.
И ещё кое-что. Майнеры не "майнят" оставшиеся биткоины. Они "майнят" награду за принятый в цепь блок.
Я уже описывал, что хэш должен быть больше, либо равен определенному числу (не постулат, но bitcoin использует именно эту схему).
Это искусственно ограничивает скорость создания блоков. Так что же мешает по определенным правилам регулировать это число?
Ни насколько. Сложность вычисления хеша одного блока не зависит от длины цепи.
Майнеры нужны из-за искусственного завышения вычислительной сложности для составления блока. Помним, что хэш-функция в идеале непредсказуема, а узлы, которые эти блоки хранят и проверяют, не принимают блоки с хэшем, значение которого меньше фиксированного числа. Из-за этого приходится множество раз менять вышеупомянутый counter для получения нового результата хэширования до тех пор, пока хэш не станет удовлетворять условиям принятия блока в цепь.
Откуда вам знать, что это не имя? Имена всегда с "большой" буквы начинаются, вне зависимости от контекста.
Поддержу тему анимации. "Гифки" доставили больше, чем сама статья:D
Простите за снобство, но это плохой пример. Если
async f()возвращает обещание, то зачем операторawaitпослеreturn? Не достаточно ли будет "вернуть" обещание? Механизм Promise'ов ждёт обещания любой глубины. Даже если обещание resolve'ит другое обещание.