Я думаю, не вернут. Вот мои соображения относительно того, почему:
Исключения могут усложнять понимание интерфейса, особенно в большом проекте. Любой пользователь должен знать, какие исключения бросает функция. Случай по-умолчанию — это не-обработка ошибок. Т.е. если идти по пути наименьшего сопротивления, ошибка вылетит наверх и завалит приложение. С возвращаемыми значениями программист либо обрабатывает, либо явно отказывается от обработки ошибки. Я полагаю, по этой причине в Google, Parallels и других компаниях исключения C++ не используют.
Исключения создают много сложностей в системном программировании и в программировании на голом железе. Не забывайте, что Rust — это системный язык программирования, причём системный «как Си», а не «как Go» (последний не проектировался для работы на голом железе). ABI с исключениями не стандартизован. Требуется немаленькая система поддержки исключений времени исполнения (для каждого кадра стека есть таблица с типами исключений, которые он ловит).
Нестабильные API в Rust будут всегда. Это часть версионной модели языка, как в браузерах — stable, beta, nightly. Нестабильные вещи появляются в nightly и доступны только там, чтобы люди с ними экспериментировали, но не тащили в проекты раньше времени.
Учитывая это, я всё же с вами соглашусь, что многие из базовых вещей почему-то нестабильны. Но чаще всего у этого есть понятная причина (которую ещё и компилятор в ошибке приводит!), и понятна цель авторов — хотят сделать не «как везде», а «как лучше», и да, не боятся из-за этого иногда лишний раз что-то переизобрести.
Господа из Iron (web-framework на базе http-сервера hyper) приводят вот такой тест производительности:
Iron averages 84,000+ requests per second for hello world and is mostly IO-bound, spending over 70% of its time in the kernel send-ing or recv-ing data.*
* Numbers from profiling on my OS X machine, your milage may vary.
Для понимания, какого порядка эти цифры, смотрите, например, этот тест: у них победил Haskell'ный warp с результатом 81701 запрос в секунду.
Это другое железо и это не совсем тест фрейворка, но понятно, что порядок результатов примерно одинаковый.
С цитированием тестов производительности надо быть осторожным. Нужно много контекста, чтобы делать выводы, более точные, чем «ну это цифры примерно одного порядка» — железо, остальная часть ПО, методология — всё сильно влияет.
Семантически код получается похожим на C++ (местами сильно проще из-за отсутствия исключений). Работает на оптимизаторе llvm. Тот же самый clang++ породит похожий код во многих случаях.
Дефолтный аллокатор (тот, что в libstd) сейчас паникует (или завершает программу, не помню точно — в любом случае, обработать его нельзя).
Завершает через `abort!()`
Если вы пишите что-то близкое к железу, то там вы можете реализовать свои способы аллокации памяти (отключив libstd) и самостоятельно обрабатывать такие ошибки.
Я бы сказал, не «можете», а «должны». Вы где-нибудь видели ОС или программы для голого железа, пользующиеся при этом стандартной библиотекой языка? :)
В Активном Обероне применяется автоматическое управление памятью, с использованием сборщика мусора реального времени. Это значит, что активности реального времени могут приостанавливать процесс сборки мусора. В участках кода реального времени запрещены операции выделения памяти за этим следит компилятор. Процедуры, методы и активности реального времени помечаются модификатором REALTIME. Не все реализации компилятора и среды выполнения поддерживают процессы реального времени.
Вот это действительно круто. Я время от времени думаю, почему в Rust не хотят сделать аннотаций «не выделяет память», чтобы как раз помечать функции, безопасные для использования в контексте какого-нибудь обработчика сигналов, например.
Ну и вообще, ради этого параграфа стоило прочитать публикацию. Только что узнал об Обероне больше, чем за последнюю неделю общения с его пользователями (не с вами).
Ещё: так работает любой Оберон, или именно Активный?
Правильно я понимаю, что язык по сути неотделим от среды исполнения, которая, можно сказать, является одновременно ОС и IDE? У меня сложилось впечатление, что Оберон-Система — это вот про это.
Можно ли использовать Активный Оберон (или любой Оберон) на Линуксе?
Да, на это время надо. Для Си тоже не сразу много компиляторов появилось. В целом, увидеть альтернативную реализацию было бы круто — известно, что компилятор у Раста внутри местами очень страшный, да и какие-то глобально нерешённые вопросы есть.
А про bare-metal — регулярно вижу в IRC и на Reddit людей, программирующих микроконтроллеры на Расте. zinc.rs-то это больше фреймворк, а в принципе libcore — это используемая без аллокатора часть стандартной библиотеки. Достаточно немаленькая часть, для голого железа подходящая. Если интересно, могу попробовать конкретные статьи найти.
Ну я попытался понять, о каких ОС на Обероне идёт речь, и нашёл в Википедии следующее:
В 1989 году в Швейцарской высшей технической школе Цюриха (ETH) была выпущена первая реализация Оберона для процессоров семейства NS32000. Он был создан в качестве компонента операционной среды Оберон.
Из вас же ничего, кроме оскорблений, не вытянешь.
Если вы из этого делаете вывод, процитированный выше, то вам надо всерьез задуматься о возможной дислексии.
Если вы по одной фразе диагностируете у собеседника болезнь, то вам надо всерьёз задуматься о чём-то похуже.
Ну вы же понимаете, что такой аргумент транзитивно применяется в любой ситуации по мере их возникновения. Получается, всё, что старое — хуже нового :)
Нестабильные API в Rust будут всегда. Это часть версионной модели языка, как в браузерах — stable, beta, nightly. Нестабильные вещи появляются в nightly и доступны только там, чтобы люди с ними экспериментировали, но не тащили в проекты раньше времени.
Учитывая это, я всё же с вами соглашусь, что многие из базовых вещей почему-то нестабильны. Но чаще всего у этого есть понятная причина (которую ещё и компилятор в ошибке приводит!), и понятна цель авторов — хотят сделать не «как везде», а «как лучше», и да, не боятся из-за этого иногда лишний раз что-то переизобрести.
Для понимания, какого порядка эти цифры, смотрите, например, этот тест: у них победил Haskell'ный warp с результатом 81701 запрос в секунду.
Это другое железо и это не совсем тест фрейворка, но понятно, что порядок результатов примерно одинаковый.
С цитированием тестов производительности надо быть осторожным. Нужно много контекста, чтобы делать выводы, более точные, чем «ну это цифры примерно одного порядка» — железо, остальная часть ПО, методология — всё сильно влияет.
Семантически код получается похожим на C++ (местами сильно проще из-за отсутствия исключений). Работает на оптимизаторе llvm. Тот же самый clang++ породит похожий код во многих случаях.
Завершает через `abort!()`
Я бы сказал, не «можете», а «должны». Вы где-нибудь видели ОС или программы для голого железа, пользующиеся при этом стандартной библиотекой языка? :)
Правда, результат надо всё равно выбросить наружу с помощью `try!` или сделать `unwrap()`.
Это шутка, конечно.
Вот это действительно круто. Я время от времени думаю, почему в Rust не хотят сделать аннотаций «не выделяет память», чтобы как раз помечать функции, безопасные для использования в контексте какого-нибудь обработчика сигналов, например.
Ну и вообще, ради этого параграфа стоило прочитать публикацию. Только что узнал об Обероне больше, чем за последнюю неделю общения с его пользователями (не с вами).
Ещё: так работает любой Оберон, или именно Активный?
Правильно я понимаю, что язык по сути неотделим от среды исполнения, которая, можно сказать, является одновременно ОС и IDE? У меня сложилось впечатление, что Оберон-Система — это вот про это.
Можно ли использовать Активный Оберон (или любой Оберон) на Линуксе?
Да, на это время надо. Для Си тоже не сразу много компиляторов появилось. В целом, увидеть альтернативную реализацию было бы круто — известно, что компилятор у Раста внутри местами очень страшный, да и какие-то глобально нерешённые вопросы есть.
А про bare-metal — регулярно вижу в IRC и на Reddit людей, программирующих микроконтроллеры на Расте. zinc.rs-то это больше фреймворк, а в принципе libcore — это используемая без аллокатора часть стандартной библиотеки. Достаточно немаленькая часть, для голого железа подходящая. Если интересно, могу попробовать конкретные статьи найти.
Из вас же ничего, кроме оскорблений, не вытянешь.
Если вы по одной фразе диагностируете у собеседника болезнь, то вам надо всерьёз задуматься о чём-то похуже.
По-моему, если для языка нужна своя ОС — это фигня какая-то, простите.
Вот хотя бы даже из детсадовских — обедающие философы, потоки, увеличивающие аккумулятор (http://carol-nichols.com/2014/07/14/ruby-rust-concurrency/), та же игра «угадайка», тот же hexdump, я не знаю.