Здравствуйте, BlackEric, Вы писали:
N>>Круто, что сказать. С++ потихоньку уходит и из системного программирования? BE>Ничего удивительного. Новый, безопасный язык. C++ очень сложен и следовательно позволяет допускать множество ошибок при написании кода. ТО что было хорошо в 90е-10е, сейчас уже не годится.
Не годится, потому что плюшевые ламеры освоить не могут, а не потому, что что-то хорошо или плохо.
В настоящее время в Android на Rust написано около 5 млн строк кода, в которых выявлена лишь одна потенциальная уязвимость, вызванная проблемами при работе с памятью. Таким образом плотность подобных уязвимостей в коде на Rust составила 0.2 уязвимости на миллион строк кода. Для сравнения в коде на языках C и C++ данный показатель составляет около 1000 уязвимостей на миллион строк кода. Ключевым источником проблем в Rust является код, находящийся в unsafe-блоках. Доля подобного кода оценивается в 4% от всего кода, написанного на Rust.
Круто, что сказать. С++ потихоньку уходит и из системного программирования?
Здравствуйте, Nuzhny, Вы писали:
N>Круто, что сказать. С++ потихоньку уходит и из системного программирования?
Ничего удивительного. Новый, безопасный язык. C++ очень сложен и следовательно позволяет допускать множество ошибок при написании кода. ТО что было хорошо в 90е-10е, сейчас уже не годится.
Здравствуйте, B0FEE664, Вы писали:
BFE>Не годится, потому что плюшевые ламеры освоить не могут, а не потому, что что-то хорошо или плохо.
Беда в том что Rust как раз на порядок сложнее в освоении, нежели C++ С++ бери и пиши — никто по рукам не бьет. То что прога дырявая или падает — уже проблемы пользователей. А Rust же бьет по голове за каждую потенциальную ошибку.
Здравствуйте, Shmj, Вы писали:
S>Здравствуйте, B0FEE664, Вы писали:
BFE>>Не годится, потому что плюшевые ламеры освоить не могут, а не потому, что что-то хорошо или плохо.
S>Беда в том что Rust как раз на порядок сложнее в освоении, нежели C++ С++ бери и пиши — никто по рукам не бьет. То что прога дырявая или падает — уже проблемы пользователей. А Rust же бьет по голове за каждую потенциальную ошибку.
поэтому растоманы скоро останутся без еды
их заменит ИИ
потому что натренить модель которая по ошибке может выдавать исправление — проще
N>В настоящее время в Android на Rust написано около 5 млн строк кода, в которых выявлена лишь одна потенциальная уязвимость, вызванная проблемами при работе с памятью. Таким образом плотность подобных уязвимостей в коде на Rust составила 0.2 уязвимости на миллион строк кода. Для сравнения в коде на языках C и C++ данный показатель составляет около 1000 уязвимостей на миллион строк кода. Ключевым источником проблем в Rust является код, находящийся в unsafe-блоках. Доля подобного кода оценивается в 4% от всего кода, написанного на Rust.
А не может быть так, что это очень молодой код, в котором просто еще не успели найти уязвимости?
N>Круто, что сказать. С++ потихоньку уходит и из системного программирования?
Мне кажется, в долгосрочной перспективе C++ вообще уходит. Но это может занять еще очень много времени.
Здравствуйте, SkyDance, Вы писали:
Pzz>>Почему он сложнее?
SD>Потому что заставляет тебя заранее исправить всю кривизну (ту самую, что ведет к уязвимостям). Заставляет разобраться до того, как все будет работать в проде. Еще на этапе компиляции. Понятное дело, что первоначальные затраты заметно выше. И так же понятно, что потом это поддерживать проще.
SD>Примерно как с тестами. Если их не написать с самого начала, то зачастую можно быстрее отправить какой-то код в прод. Зато потом...
у меня вообще никаких тестов нет в коде, тестеры вручную тестируют. ПМИ будет в понедельник, боюсь будет эпик фэйл.
ладно, надеюсь, потом дадут время на рефакторинг, чтобы привести код к такому виду, чтобы тестовый фреймворк в целом к этому легаси можно было бы прикрутить
Здравствуйте, SkyDance, Вы писали:
Pzz>>Почему он сложнее?
SD>Потому что заставляет тебя заранее исправить всю кривизну (ту самую, что ведет к уязвимостям). Заставляет разобраться до того, как все будет работать в проде. Еще на этапе компиляции. Понятное дело, что первоначальные затраты заметно выше. И так же понятно, что потом это поддерживать проще.
Про поддержку вообще не факт. Допиливать мелочи — может быть. А вот рефекторинг может оказаться фатальным.
Нет такой подлости и мерзости, на которую бы не пошёл gcc ради бессмысленных 5% скорости в никому не нужном синтетическом тесте
Здравствуйте, Pzz, Вы писали:
Pzz>А не может быть так, что это очень молодой код, в котором просто еще не успели найти уязвимости?
В тексте прямо говорится, что для молодого кода они всё и считают:
Накопленная статистика подтверждает ранее высказанное предположение, что основным источником проблем с безопасностью является новый код, а для старого кода наблюдается экспоненциальная зависимость безопасности от времени — со временем в старом коде ошибки выявляются всё реже и реже. В конечном счёте в Google решили не пытаться переписать старый код на языках безопасно работающих с памятью, а сосредоточиться на использовании подобных языков для нового кода.
Здравствуйте, Skorodum, Вы писали:
S>А как меняется количество строк при переписывании с С++ на С++? ИМХО, если взять какой-нибудь большой проект на С++98 и переписать на С++20, то он тоже легко в 4 раза меньше может стать по количеству строк.
Есть подозрение, что тамошний код при переписывании с C++98 на C++98 можно было бы раза в полтора-два уменьшить.
Здравствуйте, YuriV, Вы писали:
YV>Тем более из ансейф блоков раст никогда не вылезал Как только какая-нибудь сложность в архитектуре и оппа ансейф-блок.
Это очень сильное преувеличение. Мне за пять лет unsafe понадобился ровно один раз, и еще пару раз видел его когда читал код зависимостей.
YV>Весь растохайп, в принципе, начался именно из-за утверждений растоманов, что "всё проверяет компилятор", не нужно заморачиваться на мелочах, можно сосредоточиться на логике.
Ну так unwrap() и есть логика. Если язык в принципе позволяет сделать panic! в произвольном месте (а unwrap() это, по сути, синоним if + panic!), компилятор тут ничего не сделает, только линтер или ревьюер может по рукам дать. Даже в супербезопасном питоне можно написать exit(0) в произвольном месте, и программа вылетит.
Дам совет для будущих холиваров — если хочется придираться к паникам в Расте, можно обсуждать неочевидные паники (например, при арифметических операциях), которые даже линтер не ловит.
YV>Результат — растоманы пишут, лишь бы скомпилилось и в прод. Т.е. раньше были скриптокидди, теперь растокидди.
Бред. Взрослому человеку должно быть стыдно такое писать.
YV>Так-то можно и в С++ писать прямыми руками, тем более это несложно, включить всякие линтеры и санитайзеры, перейти на современную версию С++, изучить гайд для новичков, хотябы и т.д. Речь о том, что полузнайке всё равно что у него в руках — как ударить себя по лбу он найдёт способ. Поэтому раст абсолютно ни отчего не спасает.
С++ — это как Раст когда весь код завернут в большой unsafe блок. В принципе, можно, конечно, но зачем? Разница тут не качественная, а количественная. Ударить себя по лбу можно в любом языке, но в Расте способов гораздо меньше, и заметить их легче.
Здравствуйте, CRT, Вы писали:
CRT>Здравствуйте, mrTwister, Вы писали:
CRT>>>в долгосрочной перспективе ИИ будет сразу фигачить в машинных кодах
T>>Не будет. Только если придумают какой-то принципиально новый тип ИИ.
CRT>В долгосрочной перспективе будет такой тип ИИ который будет сразу фигачить в машинных кодах. Это тоже самое что я написал в моем прошлом комментарии, только другими словами.
а с чего такие выводы? на github-е вряд ли гигантское количество проектов, написанных на ассемблере, на основе чего он будет учиться?
ну и тем более, естественный интеллект же не занимается тем, чтобы сокращать мышцы сердца по таймеру, чтобы не умереть.
плохая аналогия конечно, но смысл того, что я хочу донести, надеюсь, понятен?
Здравствуйте, BlackEric, Вы писали:
BE>Ничего удивительного. Новый, безопасный язык. C++ очень сложен и следовательно позволяет допускать множество ошибок при написании кода. ТО что было хорошо в 90е-10е, сейчас уже не годится.
N>В настоящее время в Android на Rust написано около 5 млн строк кода, в которых выявлена лишь одна потенциальная уязвимость, вызванная проблемами при работе с памятью. Таким образом плотность подобных уязвимостей в коде на Rust составила 0.2 уязвимости на миллион строк кода. Для сравнения в коде на языках C и C++ данный показатель составляет около 1000 уязвимостей на миллион строк кода. Ключевым источником проблем в Rust является код, находящийся в unsafe-блоках. Доля подобного кода оценивается в 4% от всего кода, написанного на Rust.
N>Круто, что сказать. С++ потихоньку уходит и из системного программирования?
Для C и C++ это суммарный, средний, какой показатель? Не может быть такого, что 999.8 уязвимостей — это сишные, а 0.2 — плюсовые?
И ещё вопрос — как там C++ используется? Как сишечка с синтаксическим сахаром, или нормально?
Здравствуйте, Великий Мессия, Вы писали:
ВМ>поэтому растоманы скоро останутся без еды ВМ>их заменит ИИ
Та кто его знает. Вот C++ выдает ошибку на 3 экрана, мне лень читать все это. Копирую простыну ИИ — а ему эти 3 экрана — 1 секунда его внимания — сразу говорит в чем дело.
Тут как раз может быть обратный эффект — то что сложно человеку (как то запомнить 2 Гб. документации) — легко для ИИ. И наоборот — то что сложно ИИ (часть из) — человеку может быть легко и очевидно.
В любом случае пока работы непочатый край и вряд ли кто-то останется прямо уж без еды...
Здравствуйте, B0FEE664, Вы писали:
N>>>Круто, что сказать. С++ потихоньку уходит и из системного программирования? BE>>Ничего удивительного. Новый, безопасный язык. C++ очень сложен и следовательно позволяет допускать множество ошибок при написании кода. ТО что было хорошо в 90е-10е, сейчас уже не годится. BFE>Не годится, потому что плюшевые ламеры освоить не могут, а не потому, что что-то хорошо или плохо.
да, похоже на то. Главное, что я увидел в статье:
При включении в состав Android изменений сопоставимого размера, изменения на Rust требуют примерно на 20% меньше ревизий, чем их эквиваленты на C++.
Данные показатели объясняются упрощением тестирования и смещением выявления ошибок на ранние стадии разработки, на которых ошибки становятся заметны ещё до того, как разработчик приступает к проверке кода. Кроме того, за счёт исключения накладных расходов на sandbox-изоляцию в коде на Rust удалось добиться повышения производительности.
Язык Rust загоняет разрабов в некое стойло, не дающее делать вещи подобные:
- const auto interface = static_cast<libusb_interface*>(calloc(1, sizeof(libusb_interface*)));
+ const auto interface = static_cast<libusb_interface*>(calloc(1, sizeof(libusb_interface)));
wl.>При включении в состав Android изменений сопоставимого размера, изменения на Rust требуют примерно на 20% меньше ревизий, чем их эквиваленты на C++.
Всего на 20%? А топик начинался так, словно в расте вообще ошибок не делают.
wl.>
Кроме того, за счёт исключения накладных расходов на sandbox-изоляцию в коде на Rust удалось добиться повышения производительности.
Хм. А обещали нативную скорострельность, как у Си. А не за счет исключения sandbox-га.
wl.>Язык Rust загоняет разрабов в некое стойло, не дающее делать вещи подобные: wl.>
wl.>- const auto interface = static_cast<libusb_interface*>(calloc(1, sizeof(libusb_interface*)));
wl.>+ const auto interface = static_cast<libusb_interface*>(calloc(1, sizeof(libusb_interface)));
wl.>
А зачем делать подобные вещи? В Rust-е нет способа зааллоцировать типизованный кусок памяти?
Здравствуйте, Shmj, Вы писали:
S>В Rust можно в небезопасном (unsafe) коде:
S>
S>let layout = Layout::new::<*mut MyStruct>(); // выделяем размер указателя
S>let ptr = alloc_zeroed(layout) as *mut MyStruct;
S>
А что опасного в том, чтобы выделить память под сишную структуру?
S>В Rust-команде можно договориться что unsafe пишет только тимлид, а всем остальным это слово запрещено использовать.
И как же все остальные достигнут нормальной квалификации, если им запрещено программировать?
Потому что заставляет тебя заранее исправить всю кривизну (ту самую, что ведет к уязвимостям). Заставляет разобраться до того, как все будет работать в проде. Еще на этапе компиляции. Понятное дело, что первоначальные затраты заметно выше. И так же понятно, что потом это поддерживать проще.
Примерно как с тестами. Если их не написать с самого начала, то зачастую можно быстрее отправить какой-то код в прод. Зато потом...
wl.>у меня вообще никаких тестов нет в коде, тестеры вручную тестируют. ПМИ будет в понедельник, боюсь будет эпик фэйл. wl.>ладно, надеюсь, потом дадут время на рефакторинг, чтобы привести код к такому виду, чтобы тестовый фреймворк в целом к этому легаси можно было бы прикрутить
Rust по сути представляет набор определенных тестов, которые код должен пройти на этапе компиляции (тот самый borrow checker, ага). Поэтому на нем сложнее писать, но зато меньше ошибок.
В этом плане также интересен OCAml, его система типизации тоже заставляет программиста более серьезно подойти к проблеме. В итоге заметно меньше багов на строку кода.
Но сам этот параметр (багов на строку кода) неверный, т.к. некоторые языки уж очень многословные. Есть известное исследование от Ericsson, когда они свою С/С++ систему переписали на Erlang, и там стало в 4 раза меньше строк кода (при той же плотности багов на строку, то есть общее количество багов снизилось в 4 раза). То самое подтверждение формулы Эйнштейна, E=m*C^2.
Errors = More * Code ^ 2.
S>>let layout = Layout::new::<*mut MyStruct>(); // выделяем размер указателя
S>>let ptr = alloc_zeroed(layout) as *mut MyStruct;
S>>
Pzz>А что опасного в том, чтобы выделить память под сишную структуру?
Так тут вы выделяете память под один указатель, то есть 8 байт. А в голове у вас как будто под структуру. И потом будете писать в размер структуры, которая более 8 байт, а там уже совсем другие данные
Но в Rust такое возможно только в unsafe, а это очень важно данная концепция.
S>>В Rust-команде можно договориться что unsafe пишет только тимлид, а всем остальным это слово запрещено использовать. Pzz>И как же все остальные достигнут нормальной квалификации, если им запрещено программировать?
Им разрешено в песочнице — без unsafe. Там особого вреда причинить не смогут, так что норм. И такого кода как раз 80% а то и более.
Здравствуйте, Pzz, Вы писали:
S>>Беда в том что Rust как раз на порядок сложнее в освоении, нежели C++ Pzz>Почему он сложнее?
Выше ответили. Вообще на нем писать не комфортно как-то, по этому за десятилетия не особо стал популярным. Возможно даже победят расширения для безопасности памяти C++ или Carbon-lang.
Здравствуйте, Nuzhny, Вы писали:
Pzz>>Всего на 20%? А топик начинался так, словно в расте вообще ошибок не делают.
N>Это же разные штуки: ревизии в коде и число уязвимостей.
Здравствуйте, Shmj, Вы писали:
Pzz>>А что опасного в том, чтобы выделить память под сишную структуру?
S>Так тут вы выделяете память под один указатель, то есть 8 байт. А в голове у вас как будто под структуру. И потом будете писать в размер структуры, которая более 8 байт, а там уже совсем другие данные
Я уже понял, да. Сам на это несколько раз попадался.
В принципе, в C++ есть new, а в C это лечится простым макросом-обёрткой:
#define NEW(T) ((T*) calloc(1, sizeof(T)))
В целом, фишечка неприятная, но не прям ужас-ужас-ужас.
S>>>В Rust-команде можно договориться что unsafe пишет только тимлид, а всем остальным это слово запрещено использовать. Pzz>>И как же все остальные достигнут нормальной квалификации, если им запрещено программировать?
S>Им разрешено в песочнице — без unsafe. Там особого вреда причинить не смогут, так что норм. И такого кода как раз 80% а то и более.
У меня джуны участвовали в написании ядерных драйверов. Задачи им, ставились, конечно, попроще, чем не джунам, но они писали настоящий код, без наручников на своих руках. Я потом просматривал, чего они понаписали.
А как еще научиться, если "вы сначала плавать научитись, а воду в бассеин потом нальём"?
Здравствуйте, SkyDance, Вы писали:
Pzz>>Почему он сложнее?
SD>Потому что заставляет тебя заранее исправить всю кривизну (ту самую, что ведет к уязвимостям). Заставляет разобраться до того, как все будет работать в проде. Еще на этапе компиляции. Понятное дело, что первоначальные затраты заметно выше. И так же понятно, что потом это поддерживать проще.
Ну т.е., заставляет быть очень эксплицитным в отношении своих намерений.
Ну, не знаю, кто как, а я всегда так делаю. С самого начала, как программировать начал. А тут еще и синтаксис есть прям в языке.
Меня в расте смущает скорее не требование явно выражать свои намерения (из которых следует необходимость их наперёд для себя сформулировать), а синтаксис евонный, который кажется мне слишком уж вычурным и барочным, без нужды.
SD>Примерно как с тестами. Если их не написать с самого начала, то зачастую можно быстрее отправить какой-то код в прод. Зато потом...
Сейчас скажу крамольное. Если быть предельно откровенным, у меня сложное отношение к тестам.
Да, я понимаю, код с тестами воспринимается с большим доверием, чем код без тестов, и всячески изгибать его потом комфортнее, потому что тесты ловят за руку, когда случайно сломал (и поощряют экспериментировать, толком не разобравшись).
Но тесты минимум в два раза увеличивают цену написания, при том нет ощущения, что это компенсируется соответствующим уменьшением цены развития и поддержки.
Заметим, код условного ядра UNIX, как Linux так и BSD, особо-то тестами не покрыт. Что не мешает быть ему вполне качественным и надёжным.
Здравствуйте, Pzz, Вы писали:
Pzz>Заметим, код условного ядра UNIX, как Linux так и BSD, особо-то тестами не покрыт. Что не мешает быть ему вполне качественным и надёжным.
Есть такое. Тут чисто вопрос экономики — написание авто-тестов стоит дорого и все-равно можно пропустить важные проверки. Чаще всего лучше проверить вручную тот код, который был изменен.
Здравствуйте, Pzz, Вы писали:
Pzz>У меня джуны участвовали в написании ядерных драйверов. Задачи им, ставились, конечно, попроще, чем не джунам, но они писали настоящий код, без наручников на своих руках. Я потом просматривал, чего они понаписали.
Pzz>А как еще научиться, если "вы сначала плавать научитись, а воду в бассеин потом нальём"?
Бизнес об этом не думает. Пусть пишут свои опенсорсные проекты, доказывают что умеют — и уже потом бизнес их возьмет и доверит — а обучать сейчас не будут.
Здравствуйте, Shmj, Вы писали:
Pzz>>А как еще научиться, если "вы сначала плавать научитись, а воду в бассеин потом нальём"?
S>Бизнес об этом не думает. Пусть пишут свои опенсорсные проекты, доказывают что умеют — и уже потом бизнес их возьмет и доверит — а обучать сейчас не будут.
А где этот бизнес собирается брать готовых сеньёров, если он не хочет обучать джунов?
Здравствуйте, Shmj, Вы писали:
S>Так тут вы выделяете память под один указатель, то есть 8 байт. А в голове у вас как будто под структуру. И потом будете писать в размер структуры, которая более 8 байт, а там уже совсем другие данные
S>Но в Rust такое возможно только в unsafe, а это очень важно данная концепция.
Pzz>Ну т.е., заставляет быть очень эксплицитным в отношении своих намерений.
Именно! Заставляет разобраться (!!!) в том, что ты делаешь. У нас, старичья, желание разобраться в том, как что работает, было ключевым — мы поэтому и стали заниматься компьютерной техникой. Сначала, конечно, разобрав все в доме будильники, чайники и что еще под руку могло попасться.
Но современные железяки просто так не разберешь. А порой так и вовсе не разберешь. Они слишком сложные, и слишком не-обслуживаемые. Поэтому уже нет стремления разобраться, как и что работает, и что ты хочешь сделать. Напротив, все ушло в некоторые слабо формализованные вероятности — "хочу вот как-то так".
Pzz>Меня в расте смущает скорее не требование явно выражать свои намерения (из которых следует необходимость их наперёд для себя сформулировать), а синтаксис евонный, который кажется мне слишком уж вычурным и барочным, без нужды.
Не, ну это придирки, или вопрос вкусовщины. Выглядит чутка непривычно, но, в целом, вполне разумно. А главное — не так многословно, как это в managed языках типа жабы и аналогов.
Pzz>Да, я понимаю, код с тестами воспринимается с большим доверием, чем код без тестов, и всячески изгибать его потом комфортнее, потому что тесты ловят за руку, когда случайно сломал (и поощряют экспериментировать, толком не разобравшись).
Так это по определению и есть "поддержка старого кода". Более того, если приучить себя начинать с тестов, то и новый код пишется намного более прямой и понятный. Это всего лишь следующий шаг по лестнице грамотности программиста. Он редко случается сам собой. Как правило, нужно активно об этом думать — не о том, чтобы "пофиксить баг", а о том, чтобы написать тест, который баг воспроизводит. Через какое-то время начинаешь прозревать, насколько это меняет даже само восприятие программирования.
Pzz>Но тесты минимум в два раза увеличивают цену написания, при том нет ощущения, что это компенсируется соответствующим уменьшением цены развития и поддержки.
Поэтому и стараются перенести тривиальные тесты прямо в сам язык. И Rust как раз в этом хорош — система типов и подход к менеджменту памяти позволяют обойтись без (порой нетривиальных) тестов. Это все часть подхода "shift left" — когда обнаружение проблемы происходит на как более раннем этапе. Сначала это было в проде. Потом уже в стейдже. Потом на этапе е2е тестов, потом — интеграционных, потом — юнит. Сдвигай на еще один шаг — и вот тебе уже компилятор скажет "атата". Дальнейший сдвиг (еще до этапа написания кода, уже во время обсуждения "а надо ли вообще такой код писать") куда более сложный и пока не очень автоматизирован.
TB>Про поддержку вообще не факт. Допиливать мелочи — может быть. А вот рефекторинг может оказаться фатальным.
Конечно! Тут уже верно указали — количество дефектов напрямую зависит от новизны кода. Если был сделан большой рефакторинг, то есть много нового кода, при прочих равных (*) поначалу будет намного больше ошибок. На С/С++ эти ошибки будешь ловить уже после ухода в прод, а на Rust — еще на этапе компиляции (что, конечно же, поначалу замедлит рефакторинг).
(*) под прочими равными понимается неизменность общей архитектуры и тулинга. Если этот рефакторинг, например, перенес весь код из unsafe в safe, или вовсе на какой-то более высокоуровневый язык, подобные сравнения могут быть неприменимы.
Здравствуйте, SkyDance, Вы писали:
SD>Но сам этот параметр (багов на строку кода) неверный, т.к. некоторые языки уж очень многословные. Есть известное исследование от Ericsson, когда они свою С/С++ систему переписали на Erlang, и там стало в 4 раза меньше строк кода (при той же плотности багов на строку, то есть общее количество багов снизилось в 4 раза). То самое подтверждение формулы Эйнштейна, E=m*C^2. SD>Errors = More * Code ^ 2.
А как меняется количество строк при переписывании с С++ на С++? ИМХО, если взять какой-нибудь большой проект на С++98 и переписать на С++20, то он тоже легко в 4 раза меньше может стать по количеству строк.
Вообще C++ на так уж и сложен и небезопасен. Просто значительно выросло количество естетов, стремящихся с помощью его всевозможных примочек усложнить код и порой как следствие сделать его и небеопасным и непонятным и неподдерживаемым. Так языки, где возможности для извращений ограничены или вовсе отсутствуют, становятся безопасными и эффективными.
S>А как меняется количество строк при переписывании с С++ на С++? ИМХО, если взять какой-нибудь большой проект на С++98 и переписать на С++20, то он тоже легко в 4 раза меньше может стать по количеству строк.
Нет, не может. Будет примерно так же. И не спрашивай, откуда я знаю
с примерами. И мой опыт это полностью подтверждает.
У вас кроме "не спрашивай" аргументы есть, чтобы утверждать, что среднестатистический проект на С++98 не будет значительно меньше, если его переписать на С++11/14/17/20?
Здравствуйте, SkyDance, Вы писали:
SD>... На С/С++ эти ошибки будешь ловить уже после ухода в прод, а на Rust — еще на этапе компиляции
Вчера Cloudflare лежал 3 часа из-за того, что в ботфильтре на расте unwrap разворачивал ошибочное значение безо всяких проверок и весь сервис постоянно падал и не пропускал ни своих, ни чужих. Вот и все гарантии в компайл-тайм.
Здравствуйте, YuriV, Вы писали:
YV>Вчера Cloudflare лежал 3 часа из-за того, что в ботфильтре на расте unwrap разворачивал ошибочное значение безо всяких проверок и весь сервис постоянно падал и не пропускал ни своих, ни чужих. Вот и все гарантии в компайл-тайм.
Так ты не путай их отсталый сегфолт и нашу продвинутую панику. Это другое, это понимать надо!
Нет такой подлости и мерзости, на которую бы не пошёл gcc ради бессмысленных 5% скорости в никому не нужном синтетическом тесте
Здравствуйте, YuriV, Вы писали:
YV>Вчера Cloudflare лежал 3 часа из-за того, что в ботфильтре на расте unwrap разворачивал ошибочное значение безо всяких проверок и весь сервис постоянно падал и не пропускал ни своих, ни чужих. Вот и все гарантии в компайл-тайм.
clippy ругается на это по умолчанию, если специально не отключить. Если они отключили — то это не проблема раста. Так-то можно и тупо в unsafe блоке в нулевой указатель чего-нибудь записать.
Здравствуйте, Manticore, Вы писали:
M>Здравствуйте, YuriV, Вы писали:
YV>>Вчера Cloudflare лежал 3 часа из-за того, что в ботфильтре на расте unwrap разворачивал ошибочное значение безо всяких проверок и весь сервис постоянно падал и не пропускал ни своих, ни чужих. Вот и все гарантии в компайл-тайм.
M>clippy ругается на это по умолчанию, если специально не отключить. Если они отключили — то это не проблема раста. Так-то можно и тупо в unsafe блоке в нулевой указатель чего-нибудь записать.
Тем более из ансейф блоков раст никогда не вылезал Как только какая-нибудь сложность в архитектуре и оппа ансейф-блок. Но растоманы надрываются: "это же в одном месте — всё прозрачно". Но на практике оказывается, что одного места абсолютно достаточно, чтобы положить пол-инета.
Весь растохайп, в принципе, начался именно из-за утверждений растоманов, что "всё проверяет компилятор", не нужно заморачиваться на мелочах, можно сосредоточиться на логике. Результат — растоманы пишут, лишь бы скомпилилось и в прод. Т.е. раньше были скриптокидди, теперь растокидди.
Так-то можно и в С++ писать прямыми руками, тем более это несложно, включить всякие линтеры и санитайзеры, перейти на современную версию С++, изучить гайд для новичков, хотябы и т.д. Речь о том, что полузнайке всё равно что у него в руках — как ударить себя по лбу он найдёт способ. Поэтому раст абсолютно ни отчего не спасает.
Здравствуйте, mrTwister, Вы писали:
CRT>>в долгосрочной перспективе ИИ будет сразу фигачить в машинных кодах
T>Не будет. Только если придумают какой-то принципиально новый тип ИИ.
В долгосрочной перспективе будет такой тип ИИ который будет сразу фигачить в машинных кодах. Это тоже самое что я написал в моем прошлом комментарии, только другими словами.
Здравствуйте, Manticore, Вы писали:
M>clippy ругается на это по умолчанию, если специально не отключить. Если они отключили — то это не проблема раста.
Если clippy ругается на всякую ерунду, без которой писать невозможно — то это таки проблема раста.
Нет такой подлости и мерзости, на которую бы не пошёл gcc ради бессмысленных 5% скорости в никому не нужном синтетическом тесте
Здравствуйте, Manticore, Вы писали:
YV>>Тем более из ансейф блоков раст никогда не вылезал Как только какая-нибудь сложность в архитектуре и оппа ансейф-блок.
M>Это очень сильное преувеличение. Мне за пять лет unsafe понадобился ровно один раз, и еще пару раз видел его когда читал код зависимостей.
Я на плюсах лет 15 наверное не работал уже с сырой памятью
Но, могу представить, что кто-то её до сих пор весьма активно использует
Здравствуйте, Marty, Вы писали:
M>Я на плюсах лет 15 наверное не работал уже с сырой памятью
На плюсах необязательно работать с сырой памятью чтобы поиметь проблемы.
const auto & m = std::min(
"123456789_123456789_123456789_123456789_123456789_"s,
"123456789_123456789_123456789_123456789_123456789_123456789_"s);
std::cout << m << std::endl;
Здравствуйте, CRT, Вы писали:
CRT>В долгосрочной перспективе будет такой тип ИИ который будет сразу фигачить в машинных кодах. Это тоже самое что я написал в моем прошлом комментарии, только другими словами.
Хз, не могу будущее предсказывать. Может, конечно, позитронный мозг изобретут, но это уже будет не LLM
Здравствуйте, Manticore, Вы писали:
M>С++ — это как Раст когда весь код завернут в большой unsafe блок. В принципе, можно, конечно, но зачем? Разница тут не качественная, а количественная. Ударить себя по лбу можно в любом языке, но в Расте способов гораздо меньше, и заметить их легче.
Вот, классика, пришёл растоман и рассказал какой плохой С++. А почему вы не рассказали откуда взялся анврап в неположенном месте в этом конкретном случае? И почему, раз в расте это легко заметить, это не заметили в ф-ции из 10 строк и чудо-компилятор ничего не сказал?
С++ бери и пиши — никто по рукам не бьет. То что прога дырявая или падает — уже проблемы пользователей. А Rust же бьет по голове за каждую потенциальную ошибку.
