Пока мы не придумали что делать с остальными проблемами можно подумать на тему решить хотя бы проблемы с памятью. Тем более что по той стате от микрософта 80%+ проблем с безопасностью это ошибки памяти емнип.
Потому что все популярные на планете гуй либы построенны на оопшном принципе Button extends ButtonBase extends ControlBase
который в расте не работает. Альтернативные подходы вроде ECS не проработаны дальше сырых прототипов. а других сколько-нибудь известных способов организации контролов человечество пока не придумало.
Кроме того, что библиотек нет — их же, я так понимаю, ни для чего толком нет, и тогда получается, что на расте ничего писать не стоит, кроме совсем каких-то алгоритмов-алгоритмов, которые надо самому пилить с нуля? Речь о том, что какие-то языки, возможно, концептуальны, безопасны и с прекрасным синтаксисом, уберегающим от всех ошибок всегда везде и дающим гарантии всего. А начнёшь прикидывать, как бы на таком языке чего написать — того нету, этого нету, и не предвидится, похоже — либо пили свой кривой враппер сишных библиотек, покрывающий лично твои задачи, либо сам с нуля пиши (ага, ага), либо так и чахни над этими гарантиями безопасности, как пушкинский Кощей над златом.
Это не так — библиотек хватает, все зависит от ваших задач. Мне для моих задач (поднять веб-сервер, сервить опенапи доку, ходить по графам, считать генетику, взаимодействовать в телегой, ...) например есть все, если для ваших задач чего-то не хватает, то нужно оценить насколько это ценно и насколько больше раст дает по сравнению с необходимостью в него делать ФФИ из либ которые есть и прочий бойлер. Если выгоды меньше, ну значит раст не подходит, берите более подходящий стек, вопросов ровно ноль.
Насколько часто это возникает? На мой вкус нечасто, даже библиотека которая приводит адреса 0xaaaabbbccc в заборчик вида 0xaAAbbBCCc (эфировский hashsum-checked address) нашлась. Хотя это лефтпад по сути.
Гуй на расте писать не стоит, это правда. Впрочем уже лет 10 не приходится писать под десктоп, чему неимоверно рад. Изучаешь нормальные технологии и можно использовать то, что нужно, а не то, что на икспишных машинах клиента пойдет.
OpenCV — лет 5 назад писал враппер на расте, то что покрывало лично мои задачи я покрыл, но это заняло прилично времени, чтобы проработать паттерны и подходы: пришлсоь делать сначала врапперы плюсов на СИ, потом FFI unsafe Rust -> C, и потом безопасный интерфейс на расте. Если есть желание — поставьте плюси к и откомментите в ишшуе: https://github.com/opencv/opencv/issues/11666
Раст постарается сделать инлайны и аллокации по месту, но механизма гарантирующего такое поведение кроме box syntax нет. Т.е. в общем случае результат хороший, но гарантий никаких
На безопасности самолетов уж точно не экономят — так что пример плохой. Кроме того, самолеты безопаснее других видов транспорта (В 4 раза меньше смертность по сравнению с автомобилем, по статистике которую я смотрел в последний раз). Наконец, среди двух самолетов я предпочту тот, который безопаснее на 1% даже если это будет означать 10% подорожание билета.
Давайте формально: гарантии безопасности (и.е. статистического анализа по обнаружению) некоторых классов ошибок в различных языках отличаются. Есть языки, более приспособленные к анализу ошибок (хаскель, раст, идрис), менее приспособленные (джава, шарп), производящие только базовые проверки (С++, си) и не проверяющие практически ничего (жс, питон и иже с ними).
Учитывая ограниченность человеческого внимания (магическое число 7+-2) и рост производительности железа логично было бы переложить часть ментальных затрат на анализ кода с бедных разработчиков на компьютер. Что означает постепенный переход "вверх" от менее безопасных языков — к более.
Вы понимаете, что если в попытках "отстоять честь С++" (которую никто не трогает, в треде просто обсуждаются технологии и их трейдофы) вы начинаете говорить очевидные ложные утверждения, то это как раз ложится пятном на репутацию того, о чем вы говорите?
Найдите мне хотя бы 1 разработчика на скажем анриле или скажем Godot скажите ему в лицо, что на юнити разрабатывать по времени столько же. Мне интересно, что он вам ответит, и ответит ли вообще.
В принципе согласен, однако если есть пример где бокса в куче недостаточно то можно продемонстрировтать на практике? Я практически не припомню случаев где нужно было делать аллокаций обьекта не в боксе, как-либо ещё.
Очередное использование баек про то, что можно проверить только unsafe часть и гарантированно проблем нет. Это просто ложь, нужно проверять всё равно весь код даже чтобы избежать ошибок только с памятью, любое unsafe полагается на какой то инвариант, а его нарушение может произойти при просто вызове функции из safe кода.
Не может. Сейф функция гарантирует корректную работу на ЛЮБЫХ входных данных (В рамках даваемых языком гарантий офк). Функция которая требует особых условия на инпуте не может быть сейф (например, unwrap_unchecked)
если условие всегда выполняется, то бранч предиктор легко его проглотит без замедления времени работы. Если условие то туда, то сюда, то дешевый DU дешевле механизма исключений
Только у вас читаемость не ухудшается, а улучшается, потому что теперь вы явно видите точки где может произойти ошибка, и где её быть не может
То же самое: ошибки являются частью интерфейса. Хорошо когда оно в типах, а не только в документации (которую никто не читает пока все не сломается, а может и тогда)
Это вообще каким образом тут?
В общем то можно было сразу вернуться к корням — еррор кодам из С, суть та же самая.
Так у них единственная проблема была в том, чтоб удобно с этим работать — в сишке нет тегированных DU. В остальном одни плюсы. Например — я могу спокойно вызвать 10 функций и остановиться если в любой из них произошла ошибка. Просто трайкетч влепить? А теперь если в многопотоке делать — в расте я добавлю один par_iter() и теперь все то же самое делается параллельно, и соседние треды автоматически остановятся когда я в любом из них наткнусь на ошибку.
В общем, много преимуществ у такого подхода.
Итого имеем вместо A + B
И как читающему код человеку понять, может тут быть ошибка или нет? Или вы считаете что ему такими нюансами голову не нужно забивать? Я лучше увижу a.checked_add(b) и буду точно видеть что оказывается сложение может не сработать, и это ожидаемое поведение, чем скопирую подобный код будучи уверенным что он работает как я думаю, а оказывается челоек неявно полагался на эксепшоны. Фразу "не стройте логику на эксепшнах" придумали не в расте, а это именно что логика.
К чему это? Раст точно так же раскручен, но комментатора выше это не устраивает, он все ещё утверждает что тот на сишке написан (хотя первые версии были так-то на окамле хех).
Я не думаю, что это то, что имеется в виду. То что вы описываете в мелких масштабах называется SOLID и около того (сингл респонсабилити, и вот это все), в больших масштабах — юникс вей. К сожалению я уже не найду прямой речи на сайте самого саклесс, видимо этот пассаж был удален, но раньше там было написано буквально "эдж кейсы не нужны почти никому но почти весь код занимается ими, давайте просто не будем его писать". Это уже достаточно отличается от солид/юникс вей, но не бьется с тем, что вы пишете.
Пока мы не придумали что делать с остальными проблемами можно подумать на тему решить хотя бы проблемы с памятью. Тем более что по той стате от микрософта 80%+ проблем с безопасностью это ошибки памяти емнип.
Потому что все популярные на планете гуй либы построенны на оопшном принципе
Button extends ButtonBase extends ControlBaseкоторый в расте не работает. Альтернативные подходы вроде ECS не проработаны дальше сырых прототипов. а других сколько-нибудь известных способов организации контролов человечество пока не придумало.
Это не так — библиотек хватает, все зависит от ваших задач. Мне для моих задач (поднять веб-сервер, сервить опенапи доку, ходить по графам, считать генетику, взаимодействовать в телегой, ...) например есть все, если для ваших задач чего-то не хватает, то нужно оценить насколько это ценно и насколько больше раст дает по сравнению с необходимостью в него делать ФФИ из либ которые есть и прочий бойлер. Если выгоды меньше, ну значит раст не подходит, берите более подходящий стек, вопросов ровно ноль.
Насколько часто это возникает? На мой вкус нечасто, даже библиотека которая приводит адреса 0xaaaabbbccc в заборчик вида 0xaAAbbBCCc (эфировский hashsum-checked address) нашлась. Хотя это лефтпад по сути.
Гуй на расте писать не стоит, это правда. Впрочем уже лет 10 не приходится писать под десктоп, чему неимоверно рад. Изучаешь нормальные технологии и можно использовать то, что нужно, а не то, что на икспишных машинах клиента пойдет.
OpenCV — лет 5 назад писал враппер на расте, то что покрывало лично мои задачи я покрыл, но это заняло прилично времени, чтобы проработать паттерны и подходы: пришлсоь делать сначала врапперы плюсов на СИ, потом FFI unsafe Rust -> C, и потом безопасный интерфейс на расте. Если есть желание — поставьте плюси к и откомментите в ишшуе: https://github.com/opencv/opencv/issues/11666
Она работает не быстрее скорости света. Подробные разборы в интернете есть.
Можете поделиться пожалуйста что это за библиотеки такие?
Для них
Опшн не будет иметь оверхеда если у типа есть ниша, куда можно поместить бит отсутствия значения. Например у i32 такой ниши нет, а у NonZeroI32 — есть.
Раст постарается сделать инлайны и аллокации по месту, но механизма гарантирующего такое поведение кроме box syntax нет. Т.е. в общем случае результат хороший, но гарантий никаких
А вот сейчас обидно стало
Если вы обратите внимание, мой пост не вам написан а iig
:)
На безопасности самолетов уж точно не экономят — так что пример плохой. Кроме того, самолеты безопаснее других видов транспорта (В 4 раза меньше смертность по сравнению с автомобилем, по статистике которую я смотрел в последний раз). Наконец, среди двух самолетов я предпочту тот, который безопаснее на 1% даже если это будет означать 10% подорожание билета.
Давайте формально: гарантии безопасности (и.е. статистического анализа по обнаружению) некоторых классов ошибок в различных языках отличаются. Есть языки, более приспособленные к анализу ошибок (хаскель, раст, идрис), менее приспособленные (джава, шарп), производящие только базовые проверки (С++, си) и не проверяющие практически ничего (жс, питон и иже с ними).
Учитывая ограниченность человеческого внимания (магическое число 7+-2) и рост производительности железа логично было бы переложить часть ментальных затрат на анализ кода с бедных разработчиков на компьютер. Что означает постепенный переход "вверх" от менее безопасных языков — к более.
Это неправильные программисты. И они делают неправильный
медпродуктВы понимаете, что если в попытках "отстоять честь С++" (которую никто не трогает, в треде просто обсуждаются технологии и их трейдофы) вы начинаете говорить очевидные ложные утверждения, то это как раз ложится пятном на репутацию того, о чем вы говорите?
Найдите мне хотя бы 1 разработчика на скажем анриле или скажем Godot скажите ему в лицо, что на юнити разрабатывать по времени столько же. Мне интересно, что он вам ответит, и ответит ли вообще.
А, это да, известная багуля. Неприятная.
В принципе согласен, однако если есть пример где бокса в куче недостаточно то можно продемонстрировтать на практике? Я практически не припомню случаев где нужно было делать аллокаций обьекта не в боксе, как-либо ещё.
Не может. Сейф функция гарантирует корректную работу на ЛЮБЫХ входных данных (В рамках даваемых языком гарантий офк). Функция которая требует особых условия на инпуте не может быть сейф (например, unwrap_unchecked)
Так у них единственная проблема была в том, чтоб удобно с этим работать — в сишке нет тегированных DU. В остальном одни плюсы. Например — я могу спокойно вызвать 10 функций и остановиться если в любой из них произошла ошибка. Просто трайкетч влепить? А теперь если в многопотоке делать — в расте я добавлю один par_iter() и теперь все то же самое делается параллельно, и соседние треды автоматически остановятся когда я в любом из них наткнусь на ошибку.
В общем, много преимуществ у такого подхода.
И как читающему код человеку понять, может тут быть ошибка или нет? Или вы считаете что ему такими нюансами голову не нужно забивать? Я лучше увижу
a.checked_add(b)и буду точно видеть что оказывается сложение может не сработать, и это ожидаемое поведение, чем скопирую подобный код будучи уверенным что он работает как я думаю, а оказывается челоек неявно полагался на эксепшоны. Фразу "не стройте логику на эксепшнах" придумали не в расте, а это именно что логика.К чему это? Раст точно так же раскручен, но комментатора выше это не устраивает, он все ещё утверждает что тот на сишке написан (хотя первые версии были так-то на окамле хех).
Я не думаю, что это то, что имеется в виду. То что вы описываете в мелких масштабах называется SOLID и около того (сингл респонсабилити, и вот это все), в больших масштабах — юникс вей. К сожалению я уже не найду прямой речи на сайте самого саклесс, видимо этот пассаж был удален, но раньше там было написано буквально "эдж кейсы не нужны почти никому но почти весь код занимается ими, давайте просто не будем его писать". Это уже достаточно отличается от солид/юникс вей, но не бьется с тем, что вы пишете.
Не ну настоящий программист так не напишет же...