Ну да ладно... какое именно утверждение о Rust ты пытаешься доказать?

Что сахар не слишком нужен.

что тебе мешает сделать аналог Maybe тогда?

Начать делать аналог Maybe или еще чего-то хаскеляторского мне мешает отсутствие желания это делать. Я слишком плохо знаю Rust для этого.

Как я люблю такие обобщения. Достаточно одного, совершенно любого контрпримера, чтобы заклеймить собеседника мир-дверь-мячом

Я тоже люблю такие обобщения - на них отлично выявляются математики из анекдотов. Окей, ты меня заклеймил... теперь ответишь на вопрос? Я его даже повторю: какое именно утверждение о Rust ты пытаешься доказать?

Что если

мне мешает отсутствие желания это делать. Я слишком плохо знаю Rust для этого.

то do сахар тебе не поможет.

А... ну, не трудись это доказывать. Мне твое доказательство не нужно, да и тебе тоже.

Но можно и без монад - был proof-of-concept «монадического do».
proof-of-concept «монадического do»
без монад

Ну так мне интересно же, как это так.

Мне твое ... не нужно

Попробуй сказать это, скажем, апологетам reactos, может они перестанут сюда писать.

То же самое с bind продемонстрируй, пожалуйста. У меня тоже встречались мелкие поделки, где в main лишь один print, а всё остальное без монад вообще.

У меня тоже встречались мелкие поделки, где в main лишь один print, а всё остальное без монад вообще.

Что в качестве контрпримера тоже годится, кстати. ^__~

Из оберток над OpenGL мне более-менее понравился gfx-rs - он хоть как-то пытается адаптировать OpenGL к особенностям ржавчины.

Томаков glium попроще, но это просто небольшая обертка над OpenGL, что бы не возиться самому руками с unsafe вызовами.

А что с gl-rs?

А что с gl-rs?

Я об обертках и чем-то более высокоуровневом говорил. И kiss3d, и glium и gfx-rs используют gl-rs внутри. gl-rs - это само собой, я других нормальных привязок к OpenGL для ржавчины не знаю. Какие-то раньше были, но, вроде, все померли.

А движок piston пробовал?

А движок piston пробовал?

Поглядываю за развитием этого дела, там есть интересные штуки, но использовать его для своей поделки меня не тянет. Меня смущает в этом проекте то, что они на каждый чих стараются сделать максимально обобщенное решение, сразу пишут по целому фреймворку. И свистоперделок побольше прикрутить, что бы еще вот это можно было и вот то, а не просто решить конкретную задачу. Я не дикий сторонник минимализма, но такой подход кончается boost-оподобными библиотеками))

Разве что, я подумываю использовать их библиотеку работы с изображениями, благо она довольно автономна и не слишком раздута. Есть еще png-rs и rust-stb-image, но это обертки над сишными библиотеками, а я бы предпочел решение на ржавчине.

Не вижу, где я апеллировал к корректности

Вероятно, я неправильно интерпретировал «предсказуемые программы». Если речь о том, что из-за исключений выполнение может занимать разное время, то такой аргумент не кажется мне существенным. Если у нас такие требования, то и ограничений всё равно не избежать. И отсутствие исключений не самое плохо, да и раст мог бы любезно предоставлять что-то типа [no_exceptions] по аналогии с [no_std].

panic! - это аварийное завершение. Ошибка во входных данных не должна вызывать этого.

Это не более, чем рекомендация. Ну и «здравый смысл», да и то не во всех случаях - в простых утилитах вываливаться с паникой вполне может быть уместно.

Нет. В Rust нет исключений и оптимизации ничего не мешает.

Нет исключений? Вот это неожиданность! Тебе правда нравится повторять очевидные вещи?

Меня интересовали именно какие-то гарантии отсутствия паники. Хотя может они и не нужны, но интересно, что на эту тему думают разработчики.

Это не мусор, а равноправная часть программы. Скрывать его не нужно.

На этот счёт есть разные мнения. Твоё не является единственно правильным.

В Rust ты можешь абузить для этого вышеупомянутый panic!.

Не могу - перехватить нельзя. Как и «вернуть» что-то отличное от текста.

Кстати, что делает раст при неудачной аллокации? Раньше читал, что они ещё не определились и аллокатор просто возвращал нулевой указатель. Вот одно из мест, где исключения вполне уместны. Большинство программ устроит «падение», а кому надо - сможет обработать.

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

Некорректное сравнение. Забить на реализацию исключений будет как раз проще.

Скажите в этом Rust...

Скажите в этом Rust богомерзский gc или что-либо другое?

gc нет, но может подключатся как библиотека

http://doc.rust-lang.org/complement-design-faq.html#there-is-no-gc

Скажите в этом Rust богомерзский gc или что-либо другое?

Нет там GC. Из FAQ:

A language that requires a GC is a language that opts into a larger, more complex runtime than Rust cares for. Rust is usable on bare metal with no extra runtime. Additionally, garbage collection is frequently a source of non-deterministic behavior. Rust provides the tools to make using a GC possible and even pleasant, but it should not be a requirement for implementing the language.

Прямо сейчас, вроде, вообще нет реализаций GC. Есть аналоги unique_ptr и shared_ptr из С++. Основная фича (одна из) - регионы и передача владения. То есть компилятор не даст написать код, где мы сначала обращаемся к указателю, потом инициализируем или передаём владение, а потом используем.

Контроль памяти полуавтоматический с RAII и выводом lifetime. Для более сложный кейсов есть Rc<T> и Arc<T> (во втором A значит amomically). GC из коробки нет, но кому нужно могут без проблем прикрутить. Именно поэтому раст няшка, а вовсе не богомерзкий.

Спасибо...

Может быть и стоит тогда на него посмотреть...

... Меня интересовали именно какие-то гарантии отсутствия паники. Хотя может они и не нужны, но интересно, что на эту тему думают разработчики. ...

Я не представляю себе, как реализовать такие гаранти на вменяемом уровне. Тут, вроде, немного есть об этом: http://www.reddit.com/r/rust/comments/2ktw7t/dont_panic_the_hitchhikers_guide...

во втором A значит amomically

Нет, оно значит «atomically». И значит, что эта штука потоко-безопасна, в отличии от простого Rc.

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

За ссылку спасибо.

Ну речь скорее об оптимизациях, чем о гарантиях. А так компилятор может запрещать писать panic и вызывать функции, которые не отмечены как «не паникующие», если мы вешаем на нашу функцию такой аттрибут.

Хотя я так подумал, что оно вообще не надо. Это в С++ может быть надо генерить дополнительный код для исключений и если мы пишем nothrow, то сообщаем компилятору, что это не требуется. Если «обманули», то UB, а в расте после паники и так не предполагается продолжения работы.

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

А мне кажется. Я даже назвал предметную область, где это может быть проблемой - реальное время. Ну и утяжеление рантайма, усложнение интеграции с Си.

Даже в С++ nothrow есть. Что помогает оптимизировать, кстати. В расте ничего подобного нет и не планируется?

Нет. В Rust нет исключений и оптимизации ничего не мешает.

Нет исключений? Вот это неожиданность! Тебе правда нравится повторять очевидные вещи?

Ты задал очевидный вопрос, я на него ответил. Не вижу ничего неожиданного.

Меня интересовали именно какие-то гарантии отсутствия паники. Хотя может они и не нужны, но интересно, что на эту тему думают разработчики.

AFAIK, языковых гарантий нет и пока полагаются на конвенции.

Это не мусор, а равноправная часть программы. Скрывать его не нужно.

На этот счёт есть разные мнения. Твоё не является единственно правильным.

Я и не претендую. Но это мнение не только мое.

В Rust ты можешь абузить для этого вышеупомянутый panic!.

Не могу - перехватить нельзя.

Я пока не решил для себя, баг это или фича. В любом случае, запуск в отдельной задаче обходит это.

Как и «вернуть» что-то отличное от текста.

Строка передается в panic!. Возвращается некий тип Any - если тебе мало строки, придется написать свой макрос (возможно).

Кстати, что делает раст при неудачной аллокации?

ХЗ. Думаю, что паникует.

Меня интересовали именно какие-то гарантии отсутствия паники. Хотя может они и не нужны, но интересно, что на эту тему думают разработчики. ...

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

Эффектами. Были предложения по добавлению эфектов: http://smallcultfollowing.com/babysteps/blog/2012/05/29/simple-effect-system/

Ты же вроде из Sociomantic Labs?

Нет.

Эффектами. Были предложения по добавлению эфектов: http://smallcultfollowing.com/babysteps/blog/2012/05/29/simple-effect-system

Ух, 2012, сильно) Тогда ржавчина была совсем другим языком)

Как у меня отложилось в памяти, после беглого чтения обсуждений этого вопроса, одна из основных сложностей каких-то гарантий по поводу fail\panic это то, что паниковать при редких условиях может почти весь код. По ссылке говорится про паникующий println! - на что тогда вообще можно положиться? )

Я к тому что пример, когда исключения нужны, был весьма неудачный. С ними говнокодить удобнее, тут конечно не поспоришь.

Я даже назвал предметную область, где это может быть проблемой - реальное время.

Я догадался. Усложнение интеграции с С не будет.

Ты задал очевидный вопрос, я на него ответил. Не вижу ничего неожиданного.

А я вижу - нежелание задуматься над вопросом хотя бы пару секунду. Интересовали гарантии относительно паники.

Но это мнение не только мое.

Ну и я тоже не один такой с «любовью к исключениям».

В любом случае, запуск в отдельной задаче обходит это.

Ну нет. Раньше макрос try! (если не перепутал) как раз и создавал локальную «задачу» и можно были пользоваться как простыми исключениями. Сейчас это убого.

придется написать свой макрос (возможно).

Для «запуска» паники?

Усложнение интеграции с С не будет.

Нет? В коллбеке на Rust, вызванном из Си, можно будет бросить исключение?

А я вижу - нежелание задуматься над вопросом хотя бы пару секунду. Интересовали гарантии относительно паники.

Но спросил ты почему-то о nothrow и оптимизациях.

В любом случае, запуск в отдельной задаче обходит это.

Ну нет.

Что «ну нет» - не обходит? Ссылку, пожалуйста.

Раньше макрос try! (если не перепутал) как раз и создавал локальную «задачу» и можно были пользоваться как простыми исключениями.

ЕМНИП, try! всегда был early return по ошибке.

Кстати, что такое «локальная задача»?

Эх. Одна из вещей, которой мне довольно часто не хватает в ржавчине на данный момент - именованные аргументы у функций. Привык из-за проклятого питона)

Я бы предпочел вместо:

left = 0.0;
right = win_size.w as ZFloat;
bottom = 0.0;
top = win_size.h as ZFloat;
near = -1.0;
far = 1.0;
ortho(left, right, bottom, top, near, far)

писать (или вроде того):

ortho(
    left: 0.0,
    right: win_size.w as ZFloat,
    bottom: 0.0,
    top: win_size.w as ZFloat,
    near: -1.0,
    far: 1.0
);

Не фатально, но постоянно немного раздражает. Даже парочка RFC была, да все отложили на после-1.0.

Ух, 2012, сильно)

История решает (к вопросу об исключениях, кстати).

после беглого чтения обсуждений этого вопроса, одна из основных сложностей каких-то гарантий по поводу fail\panic это то, что паниковать при редких условиях может почти весь код

Это проблема, требующая решения.

Я к тому что пример, когда исключения нужны, был весьма неудачный.

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

С ними говнокодить удобнее, тут конечно не поспоришь.

Ну да, куда исключениям до красот

if(ERROR = f1(...))
{
  return ERROR;
}

И так много раз везде.

В коллбеке на Rust, вызванном из Си, можно будет бросить исключение?

А панику можно?

Но спросил ты почему-то о nothrow и оптимизациях.

Ну в С++ нет паники, в расте исключений. Мне показалось, что вопрос очевиден. Ладно, не поняли друг друга.

ЕМНИП, try! всегда был early return по ошибке.

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

Кстати, что такое «локальная задача»?

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

Эх. Одна из вещей, которой мне довольно часто не хватает в ржавчине на данный момент - именованные аргументы у функций.

Опциональных параметров, как и переменного количества аргументов тоже нет (если ничего не поменялось). Это хуже.

Опциональных параметров, как и переменного количества аргументов тоже нет

Зачем нужны функции с более чем одним аргументом?

В коллбеке на Rust, вызванном из Си, можно будет бросить исключение?

А панику можно?

Не знаю. Но паника - это аварийное завершение задачи, а не механизм обработки ошибок.

ЕМНИП, try! всегда был early return по ошибке.

Возможно, меня дезинформировали. Но это было давно

Когда-то в Rust была condition system, аналог лисповой. Не прижилась.

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

Ну, для крайних случаев «нужно выпутаться из кучи уровней вложенности» вполне подходит.

Зачем нужны функции с более чем одним аргументом?

Например, чтобы вещи типа vec! могли писаться проще (не макросами). Вон для инициализации хеш-таблиц такого макроса не завезли (вроде), не удобно.

ХЗ. Думаю, что паникует.

Судя по play.rust-lang.org падает.

не загромождая промежуточные функции (ненужной) обработкой

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

Ну да, куда исключениям до красот

Ну да, красоты ведь важнее логики. Пример с регулярками уже приводил. А чо, на регулярках же компактнее в несколько раз.

Зачем нужны функции с более чем одним аргументом?

Например, чтобы [...]

Ты говоришь с упоротым хаскелятором %)

Не знаю. Но паника - это аварийное завершение задачи, а не механизм обработки ошибок.

Не смотря на аварийность, паника возвращает описание (в курсе, про возможность вызвать без передачи строки). Подозреваю, что растовая паника в сишном коде ни к чему хорошему не приведёт. Подумаешь ещё одно ограничение.

Ну, для крайних случаев «нужно выпутаться из кучи уровней вложенности» вполне подходит.

Разве что, для очень крайних.

Ты говоришь с упоротым хаскелятором %)

У меня была такая мысль, но я решил, что человек серьезно спрашивает.

Это мягко говоря очень спорное утверждение.

В смысле? Ещё раз, если у нас есть много промежуточной обработки и могут случаться фейлы, которые можно обработать только где-то вверху, то исключения удобны. Даже при не самой компактной плюсовой обработке исключений.

Разумеется, если всё АПИ на исключениях, то ситуация меняется. Но я за это и не агитирую.

Ну да, красоты ведь важнее логики.

Слушай, у меня есть опыт написания кода и с исключениями и без. Как по объективным причинам, так и потому, что «так принято». На универсальность не претендую, но в С++ (и не только) исключения вполне «работают». Да, с ними можно «сделать хуже», но это касается многих частей языка. Исключения далеко не самые проблемные, имхо.

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

Одного аргумента хватит всем:

import Text.Printf

main = printf "%s is over %f times worse than haskell\n" "Rust" (26.5::Float)

А вот кстати вопрос - как дела с каррингом в rust?

Упоротый здесь не я, а некий изобретатель «монадического do» без монад.

Мы вроде как говорим о необходимости тащить эксепшены в новый язык, а не про абстрактные эксепшены в вакууме.

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

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

Мы вроде как говорим о необходимости тащить эксепшены в новый язык, а не про абстрактные эксепшены в вакууме.

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

Ну и у тейлганера хотя бы аргументы есть: усложнение рантайма (а лёгкий рантайм одна из их целей изначально) и «монадический сахар нас спасёт». С удовольствием послушаю твои. Только чур без «исключения это плохо, регулярки, говнокод».

есть уже куча наработок, которые без эксепшенов объезжать себе дороже

Есть примеры?

Ну а в расте сейчас плохо с синтаксическим сахаром для удобной обработки «кодов возврата» плюс отсутствие исключений.

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

У меня несколько другая «реальная жизнь», в таком случае.

Упоротый здесь не я, а некий изобретатель «монадического do» без монад.

Этот достойный человек не почтил нас своим присутствием, так что не вали с больной на здоровую.