В первую очередь специфичная, реалтаймовость снижает производительность ОС в среднем. Для выполнение той же задачи реалтайм оси нужно более мощное железо.
Просто вы в тесте своем сравнили грубо говоря интерпретируемую версию java с компилируемой в нативный машкод.
Ну и кроме всего прочего, было бы просто интересно посмотреть на этот же бенчмарк, где и на интелах java запускалась бы в режиме интерпретации. Там же есть ключик для этого, чтобы jit отключить.
В авионике — нет. Потому, что там нужна надежность. 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, то должны знать откуда я взял этот пример и как его изменил :-) Поэтому ваши примеры я уже видел :-)
Надо будет посмотреть, как из России удобней будет такую штуку заказать.
Ну и кроме всего прочего, было бы просто интересно посмотреть на этот же бенчмарк, где и на интелах java запускалась бы в режиме интерпретации. Там же есть ключик для этого, чтобы jit отключить.
Эмм… А разве у них используется не допиленная версия вот этого 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, то должны знать откуда я взял этот пример и как его изменил :-) Поэтому ваши примеры я уже видел :-)