Rust 1.9

Сделать там много чего можно, кроме нормального паттерн-матчинга. Но стандартных средств нет, соответственно повторение ситуации с std::string, QString, CString, MyString и прочими.

«Нормальный» матчинг для Result и не нужен. Да и в других случаях switch по тегу типа не так плох.

Плох. Компилятор не знает какому тэгу какое поле юниона соответствует (хотя в MSVC можно SAL-атрибуты использовать). Статические анализаторы тоже вряд ли что смогут в этой ситуации сделать.

То есть ещё один источник ошибок, каких в С++ и так хватает.

Ну можно ещё на лямбдах, макросах и темплейтной магии. Но опять-же проблема отсутствия стандартного решения.

Ну тут как посмотреть. В си да, хватит switch-а из-за наличия анонимных структур (С11), но в крестах будут уродливые суффиксы аля `t.res.foo` и `t.err.msg` вместо `t.foo` и `t.msg` соответственно.

Будет t.as<foo>().x

Или t.unwrap().x - как в Rust

Компилятор не знает какому тэгу какое поле юниона соответствует

Компилятор не знает, класс - знает. Ошибочный код скомпилируется, но бросит ошибку в рантайме.

опять-же проблема отсутствия стандартного решения.

Ну да, лучше бросать исключения и возвращать -1 в случае ошибки.

И чем оно лучше лиспа?

Да ЛЮБОЙ язык лучше ЛИСПа! Как и лучше брэйнфаков, рефалов и прочей ереси.
ЛИСП - это смешной язык из скобочек, позволяющий в краткой форме завинтить алгоритм так, что потом без косяка не разобраться. И нужно такое гуано в продакшене??

Между тем, писать на C++ не отстреливая себе ног можно уже давно

А в rust отстрелить их не выйдет в принципе. 90% ошибок C++ ловятся компилятором rust.

Да ЛЮБОЙ язык лучше ЛИСПа!

Malbolge видел?

Особенно в Rust-е, где кроме кодов возврата есть еще и паники.

Паника - частный случай. Достаточно посмотреть либы на расте - их все пишут panic-free. А если в либе есть паника или unsafe - быстро создаётся багрепорт, что бы автор ее убрал или в описании либы черным по белому пишут что она может «паниковать».

То есть panic в раст - это фича, которая нужна, но использовать ее нужно только в очень критических ситуациях, и зачастую не рекомендуется.

ЛИСП - это смешной язык из скобочек, позволяющий в краткой форме завинтить алгоритм так, что потом без косяка не разобраться.

Этот язык позволяет определять идиотов. Они обычно говорят что это смешной язык из скобочек. А в «продакшн», да, не всегда подойдёт.

А в «продакшн», да, не всегда подойдёт

В продакшене с 1960-х

Возможно

Отлично. BareMetal, ARM926EJ-S. Да вообще все прочие ARM, MIPS и так далее. Есть компиляторы? Когда появятся? Есть ли надежды? Как я понял, через unsafe вполне можно сказать: эта структура (Foo) отражает замапленные данные по адресу 0xEEEEEEE, т.е. что-то вроде:

volatile Foo* usb_configuration_regs = reiterpret_cast<volatile Foo*>(0xEEEEEEEE);

Имхо, данную возможность регламентируют, но будет ли она востребована, будет ли разработчик языка продвигать его в этом направлении?

RTTI в нормальном ООП не нужен, а за неиспользование exceptions пороть розгами. Да, и обрабатывать задекларированные эксепшны надо заставлять еще на этапе компиляции.

Тривиальный приемер когда надо различать виды исключительных ситуаций: тебе надо отправить запрос на сервер. Если косяк со связью - отложить на повторить в следующий сеанс, если сервер сказал еррор 500 - кинуть тикет в поддержку, если 403 - спросить валидные реквизиты.

Исключение нельзя забыть обработать если компилятор требует его обработки если оно задекларированно в нижележащем вызове, и всех делов

Между тем, писать на C++ не отстреливая себе ног можно уже давно
А в rust отстрелить их не выйдет в принципе. 90% ошибок C++ ловятся компилятором rust.

Никлаус Вирт читает этот текст, и усмехается: «Они не слышали об Обероне и Компонентном Паскале?»

Увы, оба мертвы.

А вот и любители checked exceptions подтянулись.

BareMetal, ARM926EJ-S. Да вообще все прочие ARM, MIPS и так далее.

В этом случае советуют смотреть zinc.rs: https://zinc.rs/

zinc.rs: https://zinc.rs/

О, спасибо, погляжу.

Лучше сказать, у них ОЧЕНЬ маленькое сообщество, но Компонентный Паскаль все еще жив (развивающейся проект OpenBUGS)

Ну, и еще в идеологии: разделение возвращаемых значений на нормальные и исключительные - это одна из самых больших ошибок в истории языков программирования

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

И если это происходит на низком уровне, то ожидаемо, что создатели языков не отказываются повторять эту «ошибку».

будет ли разработчик языка продвигать его в этом направлении?

Вот я не вижу пока особого стремления. Возможно если раст станет достаточно популярным, то может быть будет. И то вполне вероятно что нет. Я думаю что нет. Ниша BareMetal очень консервативна, С там будет править ещё очень долго.

Не думаю. Наряду с сигнализацией прерыванием у железа есть сигнальные флаги - чем не тег результата.

будет ли разработчик языка продвигать его в этом направлении?

Вот я не вижу пока особого стремления.

А какое стремление должно быть? Rust с самого начала заявлялся как язык системного программирования, в том числе написания ОС - самый настоящий bare metal.

Стремление его там применять.

в том числе написания ОС - самый настоящий bare metal.

Вот именно что в том числе.

Стремление его там применять.

У core team? Потому что желания применять Rust для написания ОС - просто через край.

Rust-ишка.

В этом случае советуют смотреть zinc.rs: https://zinc.rs/

фуфло это все

      pll {
        m = 50;
        n = 3;
        divisor = 4;
      }

чем это безопасней чем аналогичный код на С ? и как руст спасет от аппаратных ошибок - а это для SoC и ядер ARM очень актуально ?

фуфло это все

okay.jpg

имхо конечно, но руст не заменит C в низкоуровневом программировании, а для middleware неплохой кандидат

https://coaxion.net/blog/2016/05/writing-gstreamer-plugins-and-elements-in-rust/

Кто скажет опытный, это годно? На что похож синтаксис, насколько часто всё ломать будут, вообще, заслуживает внимания?

Годно для чего и по сравнению с чем?

Синтаксис как в плюсах.

За год с релиза ничего не сломали. За обратной совместимостью строго следят.

Но зачем? Свой тип ошибок определяет, условно говоря, крейт, и он же определяет функции отображения своих ошибок в стандартные.

Затем, что наверху нужны типизированные ошибки, иначе нельзя будет передавать детали. Хотя не совсем понятно что ты имеешь в виду, по твоей ссылке функции отображения всего лишь подсахаривают код преобразования между enum-ами с набором ошибок.

Заявить одно, а иметь инструмент для конкретной платформы, сложности портирования на новые - это другое. Вы дали один пример выше, это весомый аргумент.

Заявить одно, а иметь инструмент для конкретной платформы

Ты раньше не был в темах о Rust? На нем написано несколько ОС разной степени серьезности, так что заявления вполне подкреплены фактами.

сложности портирования на новые

Core team, конечно, не будет заниматься поддержкой конкретных платформ, но архитектуры поддерживаются, а дальше уже дело наличия заинтересованных людей.

Вопрос был в том, зачем функциям определять по 2-3 типа ошибок. Зачем нужны типизированные ошибки, и так понятно.

Поясните в чём смысл прыгать в этот ржавый бэндвагон, если на нём нет и никогда не будет проектов, кроме экспериментального движка какого-то недобраузера, который никогда не взлетит?

Вопрос был в том, зачем функциям определять по 2-3 типа ошибок.

Странный вопрос, нужны чтобы сигнализировать об ошибках. Многие приложения с кучей кода примерно сводятся к такой упрощённой древовидной модели в которой каждый слой может захотеть завершиться с фатальной для него ошибкой.

Одолжите машину времени.

То есть в 2016 году бэндвагон таки загремел под откос?

Мне она нужна для будущего, а не прошлого. Вы же предвещаете будущее. Мне тоже хочется.

Вопрос был в том, зачем функциям определять по 2-3 типа ошибок.

Странный вопрос, нужны чтобы сигнализировать об ошибках

2-3 типа ошибок. Тип ошибок - это один sum type на крейт.

Поясните в чём смысл прыгать в этот ржавый бэндвагон

Каждый решит для себя. Ты, например, решил, что смысла нет.

И то и другое - наколеночная поделка.

И что предпочтёшь ты?

стандартными фичами языка, без всякого синтаксического мусора типа try-catch.

Ага, только вместо try/catch-мусора есть всякие try! и .?.

Большинство современных, популярных языков (rust, swift, go) не поддерживают исключения

Про «большинство» и «популярных» - спорно. Кстати, swift «не поддерживает» достаточно оригинально.

Большинство современных, популярных языков (rust, swift, go) не поддерживают исключения

Swift 2.0

enum AwfulError: ErrorType {
    case Bad
    case Worse
    case Terrible
}

func doDangerousStuff() throws -> SomeObject {
    // If something bad happens throw the error:
    throw AwfulError.Bad

    // If something worse happens, throw another error: 
    throw AwfulError.Worse

    // If something terrible happens, you know what to do: 
    throw AwfulError.Terrible

    // If you made it here, you can return:
    return SomeObject()
}

do {
    let theResult = try obj.doDangerousStuff()
}
catch AwfulError.Bad {
    // Deal with badness.
}
catch AwfulError.Worse {
    // Deal with worseness.
}
catch AwfulError.Terrible {
    // Deal with terribleness.
}
catch ErrorType {
    // Unexpected error!
}