D, Go и Rust, взлетит ли что-нибудь?

.. А потом жалуются, что исключения тормозят ...

Ты точно мне отвечал? Я специально написал «И не из-за производительности».

Блин, здесь вообще кто-то читает сообщения собеседника или идет аналог «угадай мелодию» - «Я затроллю этого чувака с трех слов! - А я с двух, лололо»?

ну OCaml занял свою нишу (в науке, например). А не пишут десктопный софт (хотя может быть и есть, обычно не задумываешься на чем что-то написано, если оно не тормозит) на нем потому что осилить окамл сложнее, чем C++, например (или питоны всякие). Просто потому что Доков/примеров десктопного софта на С++ в разы больше. Вот садится Вася и хочет очередной чятик запилить, что он возьмет? Qt конечно (GTK/Fltk, не важно), просто потому что примеров чятиков нарыл. А потом Вася вырос и пошел работать. С чем он работать будет?

Вроде специально даже обратное написал, для особо умных. Чего ты наезжаешь?

Это из-за утверждения «в задницу исключения», которое не имело должного обоснования :)

Тут разговор упирается в религию

Так вот мне не понятно, откуда здесь религия берется. Если мы рассматриваем языки группы C, C++, Go (не могу говорить за Rust, т.к. не знаю его, да он еще и не зарелизен), то объективно, исключения — это единственный механизм, который:

- не дает «проглотить» ошибку и проигнорировать ее из-за невнимательности/забывчивости;

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

- позволяет лаконично записывать прикладной код (что особенно важно в случае с перегрузкой операторов, например, для нужд вычислений или DSL-естроения).

При этом, опять же, объективных контраргументов по поводу исключений, не так уж и много:

- связанные с исключениями накладные расходы. Хотя это очень спорный вопрос, но допустим, что так и есть;

- необходимость верификации кода или доказательства каких-то свойств/параметров кода (например, что такая-то функция гарантированно укладывается в такое-то количество тактов процессора). В этих случаях прерывание обычного хода исполнения посредством исключений добавлять забот.

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

А вот неконтролируемые исключения скорее всего вредны, потому что мешают асинхронности.

а многочисленные возвраты помогают что-ли? и вообще что значит «мешают асинхронности»?

я хоть и не тот аноним, но вот пример D, Go и Rust, взлетит ли что-нибудь? (комментарий)

ну OCaml занял свою нишу (в науке, например)

да что-то как-то в науке не очень, скорее уж Python, Fortran, C, иногда даже Perl

Мыж не про «только Россию» говорим, верно? С лету могу называть http://www.ebi.ac.uk и helcom.fi

Пусть значение + что-то возвращается в виде тупла.

Вот у тебя и получилось полмонады :)

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

полмонады

Звучит как грязное ругательство.

И почему она не может вернуть результат, помеченный warn_unused?

Можно подробнее?

Ты так говоришь, будто они были, а потом их выкинули. Но их просто не было, совсем.

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

Я вот предположу, что и в Go с возвратом нескольких, и в Rust с Maybe/Just от них отказываются вынужденно. Потому что скрестить исключения с асинхронностью и сопрограммами довольно сложно.

Как раз одно из достоинств сопрограмм для асинхронного кода и заключается в том, что исключения сохраняют свою работоспособность(в отличии от случая с callback'ами или какими-нибудь сигналами/слотами).

Нет. Исключения, если их кидать - имеют стоимость.

Все имеет стоимость. Даже виртуальные вызовы.

И почему она не может вернуть результат, помеченный warn_unused?

Можно подробнее?

https://doc.rust-lang.org/std/result/#results-must-be-used

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

Ну, они наверняка рассматривались. Но есть вещи определенно поважнее исключений, и на раннем этапе дизайна языка исключения уж точно усложняли модель рантайма.

А ради чего заниматься этими вопросами, если наличие GC в этой задаче вообще не нужно и ручной/полуавтоматческой работы с памятью вполне достаточно?

Так это моя просьба была - привести пример, когда наличие ГЦ очень сильно осложняет дело. Оказывается, в этом случае не осложняет. Ну так и запишем - можно решить на яве.

Вот по-этому их в Rust и нет ))) Зато там есть трейты со статическим связыванием. Опять же не то же самое, но позволяет решать бОльшую часть задач, и реально zero cost.

У go тоже рантайм.

Вот по-этому их в Rust и нет ))) Зато там есть трейты со статическим связыванием.

Там есть и динамическое связывания. Работает так же быстро, как виртуальные методы в крестах.

Опять же не то же самое, но позволяет решать бОльшую часть задач, и реально zero cost.

Статический полиморфизм в плюсах еще более наворочен. Так что не надо.

Вы что-то свое понимаете под zero cost, о чем вам уже давно тут говорят. Ничего не бывает нулевой стоимости в прямом смысле слова. В C++ есть такой принцип, но он говорит о том, что мы не платим за то, что не используем. Так же в C++ не добавляли фичу, если не могли представить достаточно эффективную реализацию. Те же исключения довольно эффективны. Автоматический проброс выше по стэку вызовов - это правильное поведение в большинстве случаев исключительных ситуаций. Для других есть optional-типы и пр. вещи, которые есть в C++ в том или ином виде. Rust тут только сахар добавляет.

динамическое связывание*

Так это моя просьба была - привести пример, когда наличие ГЦ очень сильно осложняет дело. Оказывается, в этом случае не осложняет. Ну так и запишем - можно решить на яве.

Так зачем это делать на яве и заниматься вопросами, не нагадит ли нам виртуальная машина и сборщик в данной задаче, когда можно решить задачу без привлечения этих мощных(но совершенно ненужных нам тут) средств?

Кстати, я писал и на C++ и на Java. Могу сказать, что Java не экономит время разработки, по крайней мере не существенно. Вот питон, скала, руби - экономят. И существенно.

Вот по-этому их в Rust и нет ))) Зато там есть трейты со статическим связыванием.

http://doc.rust-lang.org/book/static-and-dynamic-dispatch.html

Конечно же swift

Ничего не бывает нулевой стоимости в прямом смысле слова.

Бывает, если это работает только в компайл-тайме.

В C++ есть такой принцип, но он говорит о том, что мы не платим за

то, что не используем.

Я смотрю вы упопролись на своем С++ и не видите дальше него. В Rust «zero cost abstraction» - это другой принцип, и он реально означает zero cost без всякого маркетинг-стайл мухлежа, типа мелким шрифтом *если вы это не используете.

«Rust has a focus on safety and speed. It accomplishes these goals through many zero-cost abstractions, which means that in Rust, abstractions cost as little as possible in order to make them work. The ownership system is a prime example of a zero cost abstraction. All of the analysis we'll talk about in this guide is done at compile time. You do not pay any run-time cost for any of these features.»

Спасибо, не знал. Вообще выглядит не как Rust-стайл. Наверное прагматизм победил.

Наверное прагматизм победил.

Если что, фича старая. Года 2, не меньше (а может, с самого начала).

Сдох он давно уже. Де-факто. Доживающие свой век носители продолжают насиловать труп FIV/ F77, а те, кто знает, что такое сильная типизация, прототипы функций, перегрузка имён, вычисления во время компиляции, модульность, и другие полезные средства языка - те предпочитают более современные и адекватные ЯП.

4.2, довольно много народу пишет научный софт на F95 и выше

Бывает, если это работает только в компайл-тайме.

В компайл-тайм ничего не работает. Оно генерирует код.

«Rust has a focus on safety and speed. It accomplishes these goals through many zero-cost abstractions, which means that in Rust, abstractions cost as little as possible in order to make them work.»

Этому определению вполне соответствуют исключения в C++.

Из-за библиотек, я полагаю?

УПРЛСЯ?

Давай теперь я из контекста выдеру: «All of the analysis we'll talk about in this guide is done at compile time. You do not pay any run-time cost for any of these features».

Твоя цитата об анализе. Моя цитата о том, что понимается под zero cost abstraction.

В общем, иди потыкай раст, измерь скорость его работы, сравни с C++(вместе с исключениями) и подумай над результатами.

Ну ты еще и дизайн от имплементации не отличаешь... Чего там мерить, первой версии еще нет.

Ну ты еще и дизайн от имплементации не отличаешь...

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

Чего там мерить, первой версии еще нет.

Уже есть.

Вообще выглядит не как Rust-стайл. Наверное прагматизм победил.

Победил здравый смысл. Без полиморфизма мало что можно сделать.

Я уже показал. Макрос try! позволяет пробрасывать ошибки. И этот механизм практически халявный.

Живут же в хаскеле и go как-то, хз.

В хаскеле же полиморфизм типов огого, не? Да и расширение с темплейтами есть.

Это параметрический и ad hoc полиморфизм, он и в Rust есть. А вот динамической диспетчерезации нет.

Живут же в хаскеле и go как-то, хз.

Там есть Ad-hoc полиморфизм.

В go вообще без динамического полиморфизма никуда, т.к. нет полиморфных типов/дженериков/шаблонов.

А вот динамической диспетчерезации нет.

В go есть.

Да, действительно.

Не много. И это те же самые, кто всю жизнь насиловал Ф66-Ф77, а от Ф95 в их поделках - максимум что - это свободная форма записи.

конечно, C++ много, где не нужен, но выбора то не было, а теперь есть.

Если возможности/особенности C++(которых в Go нет от слова совсем) не нужны, то можно было взять практически любой язык от Java(или там Scala) до Python/Ruby. Появление go тут мало что поменяло.

Сразу скажу - скорее mono взлетит, чем D, Go и Rust. А честно - ничего из этого не взлетит.

А вот динамической диспетчерезации нет.

Вообще-то и в хаскеле её предостаточно. Например, экзистенциальные типы.

Пфф, Go уже взлетел, выйди из криокамеры.

Да, за разработку на Расте уже платят http://www.reddit.com/r/rust/comments/2yackc/rustrelated_job_openings_at_mozi...

из-за утверждения «в задницу исключения», которое не имело должного обоснования :)

Обоснование ж было по ссылке (в бложике битсквида).

Так вот мне не понятно, откуда здесь религия берется.

У людей различный жизненный опыт, откуда ж еще)

мы рассматриваем языки группы C, C++, Go

Эээм, не понял, к чему ты перечислил эти языки - из них исключения есть только в плюсах же.

не дает «проглотить» ошибку и проигнорировать ее из-за невнимательности/забывчивости

В ржавчине есть атрибут #[must_use]. А в плюсах должны быть включены придирчивые предупреждения.

Автоматическое протаскивание ошибок через много вызовов и лаконичность кода - это, само по себе, хорошо. Только вот при написании кода теперь надо учитывать, что из любой строчки может вылететь исключение, а это чертовски сложное дело. И отличить хороший код с исключениями от плохого намного сложнее, чем аналогичное для кодов ошибок/Reslut'ов всяких.

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

Обоснование ж было по ссылке (в бложике битсквида).

Там была написана какая-то, мягко говоря, ерунда.

В комментарии, на который я сейчас вынужден отвечать, так же написана ерунда.