Здравствуйте, flаt, Вы писали:
F>Это они выпилили поддержку Windows 7 не так давно (против чего было много возмущений, но в расте сидят хиппи и им лень поддерживать старые ОС).
Не хиппи, а хипстеры, не путай.
Старадающие той же хернёй, что и хаскеллисты, только в мягкой форме — когда теоретическая чистота идеи, даже если она постоянно вставляет палки в колёса в реальном коде, важнее практичности.
Просто у функциональщиков это совсем упоротость за гранью, но у растаманов тоже есть.
Здравствуйте, johny5, Вы писали:
J>Кстате обнаружил для себя panic!, оказывается он не убивает приложение а только текущий поток (ну и приложение если поток был главным).
Ваш раст делали идиоты. И в итоге сделали говно с дичайшими и лютейшими граблями. Постараюсь обходить и раст, и что-либо на нём сделанное, и что-либо использовавшее библиотеки на расте, или что-либо зависящее от чего-нибудь написанного на расте.
Если от меня когда-либо будет зависеть выбор софта, то я постараюсь прошерстить использованные инструменты и либы и рекомендую отказаться от кривого выбора при обнаружении. Себе дороже будет такое пропустить.
Здравствуйте, DarkEld3r, Вы писали:
DE>Я так понимаю, что подробностей и примеров граблей не будет?..
Беззнаковые индексы и общий фанатизм по "типам, диапазон которых лучше всего представляет допустимые в данном контексте значения", что на деле только вынуждает пердолиться с кастами каждый раз когда нужно что-то сложить, или, боже упаси, вычесть.
Нет такой подлости и мерзости, на которую бы не пошёл gcc ради бессмысленных 5% скорости в никому не нужном синтетическом тесте
Re[5]: Почему в расте отсутствует выброс исключений?
Здравствуйте, DarkEld3r, Вы писали:
DE>Я так понимаю, что подробностей и примеров граблей не будет?..
А какие именно подробности тебе нужны? Незакрытых файлов, не освобождённых объектов синхронизации и инконсистентного состояния программы не достаточно? По-моему вполне. Потоки убивать нельзя!
Ф>>ЗЫ: точно такие же идиоты в шарпе https://learn.microsoft.com/ru-ru/dotnet/api/system.threading.thread.abort?view=net-7.0 DE>В чём суть претензии? В наличии этого метода в принципе или в том, что аборт можно перехватить?
Странно, что ты только про этот метод спросил, а вот про TerminateThread() умолчал. Претензия в том, что эта дрянь может кинуть исключение там, где его изначально в принципе не предполагалось, а то что оно может прервать статический конструктор и прервать инициализацию статических полей класса — это дикий трэш. Просто представь себе, что у тебя инициализируется глобальный экземпляр какой-нибудь сложной хрени, и в этот момент прилетает ThreadAbort — всё, приплыли: ты потом в жизни не разберёшься почему программа погоду на Марсе добывает вместо того чтобы работать.
Там кроме того что ты можешь написать на эту тему в самой BCL попадается, например:
Здравствуйте, T4r4sB, Вы писали:
TB>Беззнаковые индексы и общий фанатизм по "типам, диапазон которых лучше всего представляет допустимые в данном контексте значения", что на деле только вынуждает пердолиться с кастами каждый раз когда нужно что-то сложить, или, боже упаси, вычесть.
Я бы не сказал, что эти "грабли" исключительно растовая проблема. Да в целом тема достаточно спорная.
Re[7]: Почему в расте отсутствует выброс исключений?
Здравствуйте, Философ, Вы писали:
Ф>А какие именно подробности тебе нужны? Незакрытых файлов, не освобождённых объектов синхронизации и инконсистентного состояния программы не достаточно? По-моему вполне. Потоки убивать нельзя!
У меня складывается впечатление, что ты не разобрался, но уже начал громко орать. В расте нельзя "убить поток". Ну кроме как получив нативный хендл и сделав это средствами системного апи, но это можно сделать везде, где можно получить этот самый хендл и к языку оно отношения не имеет.
Паника, о которой говорилось выше — это просто "исключение", которое разматывает стек (есть альтернативный режим в котором паника — это немедленное завершение приложения). Никаких проблем при этом не возникает. Можно, конечно, писать код небезопасный к исключениям, но это везде так. И я бы сказал, что в расте это немного сложнее: повсеместно используется RAII и глобальное состояние не поощряется.
Когда-то давно панику можно было перехватить исключительно на границе потоков, а не в произвольный момент. Из-за этого периодически всплывает связь паники с потоками.
Ф>Странно, что ты только про этот метод спросил, а вот про TerminateThread() умолчал.
Честно говоря, я вообще не понял на что по ссылке надо обращать внимание, поэтому и переспросил. С .NET дела практически не имел. Спорить с тем, что прибить поток в произвольный момент ни к чему хорошему не приведёт я не буду.
Re[7]: Почему в расте отсутствует выброс исключений?
Здравствуйте, DarkEld3r, Вы писали:
DE>У меня складывается впечатление, что ты не разобрался, но уже начал громко орать.
Я не разбирался — не пишу на расте, просто прочитал то что написал johny5. Написал он вот так:
Кстате обнаружил для себя panic!, оказывается он не убивает приложение а только текущий поток ...
DE>Паника, о которой говорилось выше — это просто "исключение", которое разматывает стек (есть альтернативный режим в котором паника — это немедленное завершение приложения).
Ах разматывает!!
DE>Когда-то давно панику можно было перехватить исключительно на границе потоков, а не в произвольный момент. Из-за этого периодически всплывает связь паники с потоками.
Ах можно перехватить!
DE>Честно говоря, я вообще не понял на что по ссылке надо обращать внимание, поэтому и переспросил. С .NET дела практически не имел. Спорить с тем, что прибить поток в произвольный момент ни к чему хорошему не приведёт я не буду.
По ссылке написано, что сейчас оно исключение кидает и больше ничего не делает.
Caution
Thread.Abort is not supported and throws PlatformNotSupportedException.
По-моему его вообще изначально не надо было добавлять — кроме вреда от него ничего больше не было.
Всё сказанное выше — личное мнение, если не указано обратное.
Здравствуйте, Философ, Вы писали:
Ф>А какие именно подробности тебе нужны? Незакрытых файлов, не освобождённых объектов синхронизации и инконсистентного состояния программы не достаточно? По-моему вполне. Потоки убивать нельзя!
Объекты при этом освобождаются, файлы закрываются, объекты синхронизации "отравляются", инконсистентного состояния не наблюдается
Здравствуйте, DarkEld3r, Вы писали:
DE>Ну а так в интернете чего только не пишут, не всё из этого правда.
Ф>>Ах разматывает!! Ф>>Ах можно перехватить!
DE>Не пойму к чему этот сарказм. Всё ещё видишь какие-то проблемы с паникой и/или потоками в расте?
Я вот даже не знаю чему тут теперь верить:
Объекты при этом освобождаются, файлы закрываются, объекты синхронизации "отравляются", инконсистентного состояния не наблюдается
Здравствуйте, vsb, Вы писали:
_>>Ну, то что ты описал — это как раз случай не исключительной ситуации, а обычной обработки ошибок и соответственно удобнее это обрабатывать не исключениями, а через Result. vsb>Нет, удобней это обрабатывать именно исключениями. Т.к. при этом мне не нужно писать никакого кода.
Твоя фраза подразумевает, что при обработке с исключениями не надо писать какой-то код, который надо писать при обработке ошибок через Result в Rust'e. И т.к. это очевидно не код самой реакции на ошибку (который естественно надо писать в любом подходе и языке), то тогда о чём собственно речь? Или ты считаешь "дополнительным кодом" несколько знаков вопроса?
vsb>OOM в жаве это отдельная иерархия, но в целом — да, если отвечать на вопрос — пытается. И у него скорей всего получится, т.к. на нижнем уровне там всё используется в пулах преаллоцированных. Хотя, конечно, в условиях OOM всё будет плохо. У меня такой ситуации практически не бывает, но если про это задумываться, я при OOM предпочёл бы просто завершить процесс.
Именно! И как раз для таких ситуаций исключения (или паники) подходят идеально.
_>>А что именно неудобно в работе с Result? vsb>Ну в го неудобно то, что там под каждым вызовом функции еще 3 строки на обработку err. В расте сахарок сделали, но всё равно везде Result-ы мусорят же. Зачем мне это видеть.
Ну тут есть довольно простой ответ, через встречный вопрос. ))) Вот допустим ты используешь механизм исключений для обработки обычных ошибок. Можешь ли ты взяв произвольную функцию в коде точно перечислить список ошибок, который она может вернуть?
Re[6]: Почему в расте отсутствует выброс исключений?
Здравствуйте, Marty, Вы писали:
_>>Всё вышеописанное касается приложений написанных на любых языках. Но в большинстве языков есть один встроенный механизм обработки, который разработчики из-за незнания/неумения/безысходности используют для всех ситуаций. От этого и возникают все подобные неоднозначности и холивары. _>>Rust же здесь выгодного отличается наличием двух отдельных механизмов, каждый под свою ситуацию. Паники для обработки исключительных ситуаций и Result для обычных ошибок. M>Чем это отличается? Что мешает в C++? У меня для плюсов, кстати, написан свой Result. Иногда использую. Иногда нет. Иногда использую исключения, когда ошибку не исправить, но можно отловить на каком-то уровне и вывести пользователю или записать в лог и похромать дальше — что-то типа assert'а, только более контролируемого
В принципе я уже не раз говорил, что C++ и Rust почти что эквивалентные. Есть микронюансы, которые можно сделать на одном языке и нельзя на другом, а 99% возможностей пересекаются. Но это если говорить именно о возможности. Если же говорить об удобстве или традициях (существует ли общепринятая для языка практика под данному вопросу или же каждый делает как хочет), то тут уже возможна большая разница.
Если вернуться конкретно к вопросу работы с Result, то тут всё в точности как я описал выше. Создать подобный тип можно в обоих языках, но в Rust с ним будет удобнее работать из-за наличия двух синтаксических сахаров: развитого сопоставления с образцом и встроенного оператора "?". И плюс данный подход является общепринятым в сообществе, так что во всех библиотеках ты можешь видеть именно его и есть способы бесшовного автоматического склеивания их всех в единую стройную систему.