В авионике — нет. Потому, что там нужна надежность. Mission critical solution. Это вам не браузер :-)
Пока у вас нет стандарта на язык, у вас нет четкой формальной неизменной спеки на язык, следовательно вы даже корректность компилятора проверить не можете.
Мозилла вполне себе зарабатывает. Гугл ей платил за то, что гугл был дефолтным поисковиком, яндекс вроде как платит скорее всего (яндекс дефолтен для русской сборки) и так далее. То есть у мозиллы есть схемы монетизации.
Да, многие языки — это языки одной корпорации. Rust, Go, Java, цейлон. И, что характерно, подобные языки все как один не имеют стандарта вменяемого :-) Ибо есть ровно одна реализация (да, я знаю, что у java были сторонние релизации, от той же IBM например), которая является эталонной и которую тащит одна корпорация (в основном).
Ярко отличается от этих языков язык С++. И, например, Ада (но путь её становления совсем другой конечно, не как у С++).
Да, в плане D тут скорее не парадокс Блаба играет ключевую роль, а парадокс Бабла :-) Чтобы было бабло на раскрутку языка нужно чтобы язык был уже раскручен.
Я Rust не знаю. Это просто первое что пришло в голову на тему «как и тут проигнорировать checked exceptions, не пробрасывая и без варнингов». Если что, напомню, что выше товарищ утверждал, что в Rust в отличие от java, проигнорировать не выйдет ну вообще никак.
Если внезапно Rust станет популярным, то вот подобное извращение будет наименьшим из того, что народ на нем будет выделывать :-)
Проблема с checked exceptions ровно в том, что народ начал массово их игнорировать именно вот таким образом, потому, что сигнатуру менять по всей иерархии на каждый чих — не удобно, конвертировать тоже лениво. Ну, максимум что какую-то малополезную обработку вставляли. А, ну и еще там были проблемы с тем, что несмотря на checked exceptions всё равно были рантайм-паники, которые могут летать как хотят и которые вроде как не поймать. Поэтому доверия к нижележащему коду, даже если ты обвязал все обработками ошибок, всё равно нет.
Насколько я понимаю, в Rust примерно те же грабли.
Спасибо. Кстати, надо посмотреть что в этом плане есть в Kotlin'e, если есть вообще. Ну и как они там с ошибками борются. Насколько я помню, они там пытались по крайней мере null dereference откусить.
На плюсах замыкания/лямбды также отлично инлайнятся. То есть на выходе ровно тот же код что был бы без них. Я например использовал лямбды на С++ в коде для микроконтроллера у которого 512 байт ОЗУ.
Вменяемого pattern-matching'a и нормальных алгебраических типов (не нормальные алг. типы с ненормальным матчингом сейчас уже можно сделать, это будет юзабельно, не сказать чтобы очень удобно) конечно не хватает.
Не обижайтесь, но мне кажется, что вы сейчас наглядно демонстрируете проявление парадокса, о котором говорится в статье. :) Вам зачем-то нужно обязательно убедится, что в Rust что-то сделано не так. Для этого вы берете опыт, который у вас есть на Java, и проецируете его на Rust, которого вы толком не знаете, и тут же выдаете вердикт: фигня, так работать не будет.
Технически, всё как раз будет работать. А опыта на Java у меня совсем не много, так что мимо кассы :-) В работе я использую другие языки.
Java тут выбрана просто как каноничный пример похожих грабель в мире языкостроения. На раннем этапе всем тоже казалось, что checked exceptions это офигенная идея (читай — пока языком пользовались его создатели и те самые сотни разработчиков, то есть пока почти никто не пользовался языком). Но как java пошла в народ, это все вскрылось. И увы, checked exceptions оказались ниочень.
То-то сотни разработчиков Rust, многие из которых MS и PhD по компиляторам такие тупые и не додумались предложить лучшего решения. :)
Ну, во первых это попытка манипуляторства вида argument from authority. Во-вторых чтобы сделать приличный ЯП мало быть PhD по компиляторостроению — компиляторщик сделает язык удобный для компиляции и сделает прекрасный компилятор. Но этот язык вполне вероятно будет не удобен прикладнику.
В общем, в том то и проблема, что они — PhD, как думаю, и в случае Java :-) Тут неплохо бы еще быть PhD по психологии и юзабилити хотя бы.
Пользователи же популярного языка — ну вот совсем не PhD, им надо фигак-фигак и в продакшн. Поэтому они будут искать лазейки как им это сделать быстрее, и если быстрее будет в обход языкового механизма (checked exception), то будут ходит в обход. Один из очевидных путей обхода я показал. Уверен что можно сделать еще удобней обход.
К компилятору Rust'a у меня пожалуй никаких притензий пока нет. К языку некоторые есть. Притензии в плане обработки ошибок — это довольно попсовые притензии. У меня есть и более экзотические :-)
пробросить ее наверх даже проще
На java пробросить наверх ошибку еще проще! Там вообще ничего не надо писать кроме как изменить сигнатуру функции!
void writeToFileIgnoreExceptions() throws IOException {
BufferedWriter writer = new BufferedWriter(new OutputStreamWriter(new FileOutputStream("filename.txt"), "utf-8"));
writer.write("This is a list of my best friends.");
System.out.println("I wrote to the file");
}
И никаких try! в теле функции. Но это, очевидно, checked exceptions не спасает. Посмотрите от чего страдают жабисты, и найдите хоть один аргумент почему этого не будет в Rust. Пока я вижу все предпосылки для ровно того же.
То есть если я захочу игнорировать ошибку — я изменю только сигнатуру и добавлю try… catch, если я захочу обрабатывать ошибку, то я напишу что-то в catch, если я захочу паниковать при ошибке, я напишу это в блоке catch. Видите насколько тут меньше писать чем в Rust, при эквивалентных трансформациях кода? И всё равно это не достаточно удобно, люди не любят менять сигнатуры функции. Это не прижилось.
Во-первых, вы сами как считаете, в API фукции должны входить возвращаемые ошибки или нет? Во-вторых, не вижу ничего странного в том, что функции с побочными эфектами и без должны иметь разные сигнатуры, ведь они не взаимозаменяемы. И в третьих, если вас действительно тревожит этот вопрос, можно привести все ошибки к Box.
Я сам не знаю как лучше. Долго думал и о вопросе обработки ошибок, смотрел разные ЯП (haskell, c++, go, ada, SPARK) решения не нашел (пока?). Поэтому и интересуюсь и делюсь мнением, потому, что некоторые знания по этому вопросу имеются. А у вас какой background?
Кроме того, если уж в API функции начали вытаскивать такие детали реализации, как ошибки которые могут возникнуть при работе, то можно вытащить и побольше, например информацию о том, как зависит результат функции от входных параметров (и зависит ли) (SPARK), есть ли побочные эффекты у функции (Haskell), и вообще, много чего еще можно придумать (вплоть до того, какую память функция может потреблять, в каких колличествах, сколько времени может исполняться и какая трудоемкость алгоритмов — это всё бывает нужно).
Потому, что это довольно редкое явление среди разнообразных ЯП :-) И очень хорошо, что Rust это исключение из правила.
PS. Да, я уже успел посмотреть на это. Это реализовано ровно так как я ожидал. Ведь в Rust всё (ок, не все, но многое) делается через одно место — через trait'ы. В том числе и closures например.
А штука с unwarp совершенно не эквивалентна тому, что написал я, и тому, что на java — это не игнорирование ошибок, а паника в случае если ошибка возникла. Также unwarp придется вставлять в 100500 строчках внутри блока из изменять их все, если я таки решу ошибку как-то обработать.
Нормальный проброс ошибок не проще из за того, что в этом случае спецификация функции зависит от её раализации. Именно поэтому checked exceptions в java считаются не самой лучшей идеей.
Если вы читали доку на стандартную либу по Rust, то должны знать откуда я взял этот пример и как его изменил :-) Поэтому ваши примеры я уже видел :-)
Если вы говорите про подход с обработкой ошибок с помощью Result, то накладные расходы здесь гораздо меньше, чем у исключений. Фактически, накладной расход — это дополнительное поле-дискриминатор enum'а в возвращаемом значении, и всё.
Гораздо меньше нуля? :-) Речь же шла про успешные вызовы функции. При успешном вызове исключения оверхеда не привносят.
Если я правильно понимаю, то в теле каждой функции будет ветвление которое будет выпоняться на всех уровнях при каждом успешном вызове функции и этим привносить оверхед в точности также как это в классической обработке ошибок в виде возвращаемых кодов ошибок. Это так?
В Rust невозможно проигнорировать ошибку а-ля catch (Exception e) в Java. Если функция, которую вы вызываете, может завершиться с ошибкой, то её возвращаемое значение будет типа Result<T, Error>, из которого собственно T можно достать только явно, через паттернматчинг
Проигнорировать ошибку можно всегда. А в языке с развитой системой макросов это можно сделать еще удобней, чем в языке без них.
Ну вот например даже без макросов:
use std::io;
use std::fs::File;
use std::io::prelude::*;
fn write_to_file_errors_ignored() {
let _ = || -> Result<(), io::Error> {
let mut file = try!(File::create("my_best_friends.txt"));
try!(file.write_all(b"This is a list of my best friends."));
println!("I wrote to the file");
Ok(())
}();
}
fn main() {
write_to_file_errors_ignored();
}
Тут абсолютно все равно что за типы ошибок были внутри последовательности операторов.
Это четкий аналог java'вского:
void writeToFileIgnoreExceptions() {
try {
BufferedWriter writer = new BufferedWriter(new OutputStreamWriter(new FileOutputStream("filename.txt"), "utf-8"));
writer.write("This is a list of my best friends.");
System.out.println("I wrote to the file");
} catch (IOException ex) {}
}
Только в отличии от java в Rust добавилось мусора внутри последовательности statement'ов — добавились макросы try! ну и добавилось оверхеда в случае если ошбок не было.
Вообще-то Rust гарантирует безопасность управления памятью.
Не гарантирует. Утечки памяти + невозможность поймать момент когда память таки закончилась и как-то отработать эту ситацию несколько противоречат этому заявлению.
Например, вы можете запросто получить трудноуловимые баги за мутабельные ссылки даже в простом однопоточном приложении.
Например? Нет, я понимаю, что мутабельность переменных (любых!) это уже сразу unsafe и крайне малопредсказуемый небезопасный код с т.з. например хаскелиста. Но с этой же точки зрения весь Rust также небезопасен и малопредсказуем.
/* скипнуто много философии и рекламы, дабы не заниматься cat /dev/zero > /dev/null */
Я не вижу никакой пользы в появлении «независимых» реализаций языка, учитывая демократичность разработки спецификаций и существующего компилятора.
А очень зря. Независимые реализации приводят например к появлению стандарта на язык. И, как следствие, значительному уточнению спецификации самого языка. А также обеспечивает значительно большую непотопляемость языка.
Если показателем для вас является то, что на нем начнут делать интернет-магазины, то скажу вам сразу – нет, на нем не будут делать интернет-магазины, скорее всего никогда.
Не нужно по гигабайту выделять каждому приложению. Просто попробуйте запустить свое тестовое приложение с этим вот ulimit -s unlimited и посмотрите что будет.
Операционка может выделять вам под стек динамически столько памяти, сколько вам нужно. Память будет выделяться по мере исчерпания стека.
Про «потокобезопасно» в вопросе нигде не было :-) Так что, вероятно, тут придется заплатить цену за то, что не используешь. (имеется ввиду время на изучение не нужного сейчас знания)
Если у меня программа однопоточная by design (а это в ряде задач таки лучше чем многопоточка в том числе и с т.з. производительности, и энергоэффективности, что сейчас стало вновь очень важно), то это будет не иллюзия. А полную безопасность в плане управления памятью Rust все равно не обеспечивает (даже без unsafe блоков).
Также Rust не решает всех проблем и с многопоточкой, поэтому даже потратив больше времени всё равно задача действительно решена не будет. Просто потому, что этих усилий не достаточно чтобы её решить, нужно потратить будет еще. Для многопоточки.
Я не говорю что Rust это что-то плохое или не нужное. Я говорю, что в данной статье наезд на С++ был не в тему. Пример плохой и посыл неправильный. Если я язык не знаю, и не понимаю как тут что работает, то я либо задам простой вопросы и получу непростой ответ, либо просто отстрелю себе ногу при программировании на данном ЯП. Тем или иным способом отстрелю. И на Rust тоже.
Важная характеристика для непростых языков — можно ли их учить постепенно, не всасывая сразу всю спеку языка себе в мозг. Если ты можешь написать что-то тебе полезное на данном непростом языке не читая всей тонны спеков, то язык будет потихоньку изучаться. Если нет, то большинство отправит такой язык в топку. И я боюсь именно это может серьезно ограничить распространение и применимость Rust. Мозилла не вечна, поэтому неплохо бы чтобы Rust вырос за пределы мозиллы (в т.ч. чтобы появились независимые реализации языка) до того, как она схлопнется. Самсунг не будет самостоятельно продвигать этот язык. IMHO
Эмм… А разве у них используется не допиленная версия вот этого LLC?
Пока у вас нет стандарта на язык, у вас нет четкой формальной неизменной спеки на язык, следовательно вы даже корректность компилятора проверить не можете.
Да, многие языки — это языки одной корпорации. Rust, Go, Java, цейлон. И, что характерно, подобные языки все как один не имеют стандарта вменяемого :-) Ибо есть ровно одна реализация (да, я знаю, что у java были сторонние релизации, от той же IBM например), которая является эталонной и которую тащит одна корпорация (в основном).
Ярко отличается от этих языков язык С++. И, например, Ада (но путь её становления совсем другой конечно, не как у С++).
Если внезапно Rust станет популярным, то вот подобное извращение будет наименьшим из того, что народ на нем будет выделывать :-)
Проблема с checked exceptions ровно в том, что народ начал массово их игнорировать именно вот таким образом, потому, что сигнатуру менять по всей иерархии на каждый чих — не удобно, конвертировать тоже лениво. Ну, максимум что какую-то малополезную обработку вставляли. А, ну и еще там были проблемы с тем, что несмотря на checked exceptions всё равно были рантайм-паники, которые могут летать как хотят и которые вроде как не поймать. Поэтому доверия к нижележащему коду, даже если ты обвязал все обработками ошибок, всё равно нет.
Насколько я понимаю, в Rust примерно те же грабли.
Вменяемого pattern-matching'a и нормальных алгебраических типов (не нормальные алг. типы с ненормальным матчингом сейчас уже можно сделать, это будет юзабельно, не сказать чтобы очень удобно) конечно не хватает.
К жабе алгебраические типы вполне прикручиваются: github.com/sviperll/adt4j
Впрочем, если хочется без прикручивания, то там давно есть scala.
Технически, всё как раз будет работать. А опыта на Java у меня совсем не много, так что мимо кассы :-) В работе я использую другие языки.
Java тут выбрана просто как каноничный пример похожих грабель в мире языкостроения. На раннем этапе всем тоже казалось, что checked exceptions это офигенная идея (читай — пока языком пользовались его создатели и те самые сотни разработчиков, то есть пока почти никто не пользовался языком). Но как java пошла в народ, это все вскрылось. И увы, checked exceptions оказались ниочень.
Ну, во первых это попытка манипуляторства вида argument from authority. Во-вторых чтобы сделать приличный ЯП мало быть PhD по компиляторостроению — компиляторщик сделает язык удобный для компиляции и сделает прекрасный компилятор. Но этот язык вполне вероятно будет не удобен прикладнику.
В общем, в том то и проблема, что они — PhD, как думаю, и в случае Java :-) Тут неплохо бы еще быть PhD по психологии и юзабилити хотя бы.
Пользователи же популярного языка — ну вот совсем не PhD, им надо фигак-фигак и в продакшн. Поэтому они будут искать лазейки как им это сделать быстрее, и если быстрее будет в обход языкового механизма (checked exception), то будут ходит в обход. Один из очевидных путей обхода я показал. Уверен что можно сделать еще удобней обход.
К компилятору Rust'a у меня пожалуй никаких притензий пока нет. К языку некоторые есть. Притензии в плане обработки ошибок — это довольно попсовые притензии. У меня есть и более экзотические :-)
На java пробросить наверх ошибку еще проще! Там вообще ничего не надо писать кроме как изменить сигнатуру функции!
И никаких try! в теле функции. Но это, очевидно, checked exceptions не спасает. Посмотрите от чего страдают жабисты, и найдите хоть один аргумент почему этого не будет в Rust. Пока я вижу все предпосылки для ровно того же.
То есть если я захочу игнорировать ошибку — я изменю только сигнатуру и добавлю try… catch, если я захочу обрабатывать ошибку, то я напишу что-то в catch, если я захочу паниковать при ошибке, я напишу это в блоке catch. Видите насколько тут меньше писать чем в Rust, при эквивалентных трансформациях кода? И всё равно это не достаточно удобно, люди не любят менять сигнатуры функции. Это не прижилось.
PS. Да, я уже успел посмотреть на это. Это реализовано ровно так как я ожидал. Ведь в Rust всё (ок, не все, но многое) делается через одно место — через trait'ы. В том числе и closures например.
А штука с unwarp совершенно не эквивалентна тому, что написал я, и тому, что на java — это не игнорирование ошибок, а паника в случае если ошибка возникла. Также unwarp придется вставлять в 100500 строчках внутри блока из изменять их все, если я таки решу ошибку как-то обработать.
Нормальный проброс ошибок не проще из за того, что в этом случае спецификация функции зависит от её раализации. Именно поэтому checked exceptions в java считаются не самой лучшей идеей.
Если вы читали доку на стандартную либу по Rust, то должны знать откуда я взял этот пример и как его изменил :-) Поэтому ваши примеры я уже видел :-)
Гораздо меньше нуля? :-) Речь же шла про успешные вызовы функции. При успешном вызове исключения оверхеда не привносят.
Если я правильно понимаю, то в теле каждой функции будет ветвление которое будет выпоняться на всех уровнях при каждом успешном вызове функции и этим привносить оверхед в точности также как это в классической обработке ошибок в виде возвращаемых кодов ошибок. Это так?
Проигнорировать ошибку можно всегда. А в языке с развитой системой макросов это можно сделать еще удобней, чем в языке без них.
Ну вот например даже без макросов:
Тут абсолютно все равно что за типы ошибок были внутри последовательности операторов.
Это четкий аналог java'вского:
Только в отличии от java в Rust добавилось мусора внутри последовательности statement'ов — добавились макросы try! ну и добавилось оверхеда в случае если ошбок не было.
Например? Нет, я понимаю, что мутабельность переменных (любых!) это уже сразу unsafe и крайне малопредсказуемый небезопасный код с т.з. например хаскелиста. Но с этой же точки зрения весь Rust также небезопасен и малопредсказуем.
/* скипнуто много философии и рекламы, дабы не заниматься cat /dev/zero > /dev/null */
А очень зря. Независимые реализации приводят например к появлению стандарта на язык. И, как следствие, значительному уточнению спецификации самого языка. А также обеспечивает значительно большую непотопляемость языка.
Вы за кого меня принимаете?
Операционка может выделять вам под стек динамически столько памяти, сколько вам нужно. Память будет выделяться по мере исчерпания стека.
И никаких костылей. :-)
Если у меня программа однопоточная by design (а это в ряде задач таки лучше чем многопоточка в том числе и с т.з. производительности, и энергоэффективности, что сейчас стало вновь очень важно), то это будет не иллюзия. А полную безопасность в плане управления памятью Rust все равно не обеспечивает (даже без unsafe блоков).
Также Rust не решает всех проблем и с многопоточкой, поэтому даже потратив больше времени всё равно задача действительно решена не будет. Просто потому, что этих усилий не достаточно чтобы её решить, нужно потратить будет еще. Для многопоточки.
Я не говорю что Rust это что-то плохое или не нужное. Я говорю, что в данной статье наезд на С++ был не в тему. Пример плохой и посыл неправильный. Если я язык не знаю, и не понимаю как тут что работает, то я либо задам простой вопросы и получу непростой ответ, либо просто отстрелю себе ногу при программировании на данном ЯП. Тем или иным способом отстрелю. И на Rust тоже.
Важная характеристика для непростых языков — можно ли их учить постепенно, не всасывая сразу всю спеку языка себе в мозг. Если ты можешь написать что-то тебе полезное на данном непростом языке не читая всей тонны спеков, то язык будет потихоньку изучаться. Если нет, то большинство отправит такой язык в топку. И я боюсь именно это может серьезно ограничить распространение и применимость Rust. Мозилла не вечна, поэтому неплохо бы чтобы Rust вырос за пределы мозиллы (в т.ч. чтобы появились независимые реализации языка) до того, как она схлопнется. Самсунг не будет самостоятельно продвигать этот язык. IMHO