Безопасность ЯП != безопасность ПО-решений

Спасибо, кэп, что Вы с нами!

LOR могут читать школьники и ПМ’ы, и для них это может быть откровением.

npm moment

поэтому нечего и пытаться?

«These multiple vulnerabilities in various Rust packages stem from the same root cause – forgetting to set proper limits on HTTP requests when using the Hyper library,»

Уязвимость: пользователи библиотеки не осилили прочесть документацию.

Сейчас это не модно же. Просто пихаешь как можно больше библиотек и всё.

Дык он безопасный только по части работы с памятью. От остального там защиты нет.

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

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

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

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

Дык он безопасный только по части работы с памятью. От остального там защиты нет.

Ага. Начинается с громкого заявления 16. Fearless Concurrency. А потом оказывается «не, защита от deadlock’ов - это сделай сам!»:

«… then research deadlock mitigation strategies for mutexes in any language and have a go at implementing them in Rust.»

https://doc.rust-lang.org/book/ch16-03-shared-state.html

Rust топит кодера в форме, мешая таким образом концентрироваться на логике. Это аргументируется zero-cost-ом, но производительность кода уже давно не является важным фактором для 95%+ задач. Бесшовное совмещение высокоуровневого и низкоуровневого языка не имеет перспектив, подход «где посрали — там поспали» не разделяли многие программисты прошлого, а плоды кратковременного приступ писания высокоуровневой гуйни в 90-х, включая Firefox, должны быть наконец закопаны — просто, индустрия уже лет 15 стагнирует и не способна произвести ничего нового. Так и живем.

А потом оказывается «не, защита от deadlock’ов - это сделай сам!»

Простите, а как ты хочешь защититься от дедлоков на 100%? Взять мютекс и зависнуть в цикле навсегда можно в любом тьюринг-полном языке.

Дык он безопасный только по части работы с памятью. От остального там защиты нет.

Ага. Начинается с громкого заявления 16. Fearless Concurrency. А потом оказывается «не, защита от deadlock’ов - это сделай сам!»:

«… then research deadlock mitigation strategies for mutexes in any language and have a go at implementing them in Rust.»

https://doc.rust-lang.org/book/ch16-03-shared-state.html

Бро, давно это пишу. Растовое memory safety — это крайне узкоспециализированная фича с сомнительной прикладной ценностью. Всё, что она дает — приложение падает вместо того, чтобы продолжать работу c UB. Забудьте вообще про потокобезопасность, в расте ее не больше, чем в любой крестовой библиотеки, заставляющей кодера передавать между потоками данные только строго заданной формы и через строго заданные функции.

продолжать работу c UB

Ты точно знаешь, что такое UB?

Вот в том-то и дело. Да и раст не изобрёл мьютексы для предотвращения гонок. И если раст какую-то небольшую часть параллелизации делает автоматически немного безопаснее, то это же далеко не «Fearless Concurrency».

Да и раст не изобрёл мьютексы для предотвращения гонок. И если раст какую-то небольшую часть параллелизации делает автоматически немного безопаснее, то это же далеко не «Fearless Concurrency».

Нет, но тем не менее, ограничение что все переменные могут быть либо mutable, либо shared – это довольно неплохая идея.

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

школьники и ПМ’ы

В голос!

Фанатики раста обижены?

Просто пихаешь как можно больше библиотек и всё.

Вот это прям до усрачки бесит кстати. Люди подключают сратые мегатонны кода ради какого-нибудь метода который «красиво строчку печатает». А потом удивляются куда вся память ушла

индустрия уже лет 15 стагнирует и не способна произвести ничего нового

Не может или не хочет?

Во-первых, для архитектуры x86 ничего нового и не будет, надо начинать с железа чтобы было что-то принципиально новое.

Во-вторых нового ради нового и не надо. Всё можно сделать на c(++) и js. Автоматизировать на шеловой скриптоте.

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

ну и вообще есть же божественны Rocket зачем что-то еще

Ну как бы если ты код либы прочёл хоть на 70% раз так 5, проверил зависимости, погонял в профайлере на проц-память, зарепортил пару багов по увиденному и получил ответ - вопросов нет. Но если существенная разница между таким подходом и «хуяк-жуяк сотня либ и в прод». Тем более что больше чем на 5-6 либ такой подход не особо работает, читать задерешься

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

Боже, опять «если ЯП не решает вообще все наши проблемы, то пользоваться им не надо» ?

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

Ошибки с памятью - значительная часть вообще всех в софте, написанным на С/С++. Так что нет - не узкоспециализированная. Вообще.

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

Ошибки с памятью - значительная часть вообще всех в софте, написанным на С/С++. Так что нет - не узкоспециализированная. Вообще

Еще раз: Rust никак не позволяет избежать ошибок работы с памятью, например, доступа к массиву за границами, разыменование нулевого указателя — он лишь роняет программу немедленно при обнаружении этих проблем, а не продолжает работу с UB. Для большинства применений разницы между этими исходами нет, оба они называются «у меня ваша программа не работает».

Что характерно, для устранения UB в языке не нужно было создавать такой переусложненный ЯП, как Rust.

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

Что характерно, для устранения UB в языке не нужно было создавать такой переусложненный ЯП, как Rust.

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

Ошибки с памятью - значительная часть вообще всех в софте, написанным на С/С++.

Одна бабка сказала, остальные повторяют эту ерунду. Про ASAN ничего не слышал? Корректность обращений в память спокойно проверяется уже второй десяток лет.

А самое смешное, что Rust и сам обзавёлся санитайзерами по самые уши. Т.е. чтобы растоадепт безопасно клепал хеллоу ворлды ему нужно обмазаться санитайзерами, да, это очень весело, это совсем не цпп ))

Люди подключают сратые мегатонны кода ради какого-нибудь метода который «красиво строчку печатает».

Да-да, так и есть.

Ошибки с памятью - значительная часть вообще всех в софте, написанным на С/С++.

То что молотком можно заехать себе по пальцу не означает, что молоток плохой инструмент. btw топор и всякие бензо[электро]пилы тоже инструменты опасные, но имхо не стоит на основании статистики больниц делать однозначный вывод, что инструменты плохие.

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

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

Ошибки с памятью - значительная часть вообще всех в софте, написанным на С/С++.

Корректность обращений в память спокойно проверяется уже второй десяток лет.

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

Rust никак не позволяет избежать ошибок работы с памятью, например, доступа к массиву за границами, разыменование нулевого указателя

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

Люди подключают сратые мегатонны кода ради какого-нибудь метода который «красиво строчку печатает».

Кстати, умеет ли раст делать билды так, чтобы в итоговый бинарник попадал только используемый код, а не весь хлам из библиотек?

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

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

ведро сегфолтилось

FACEPALM