Вариант для распечатки		Пред. тема | След. тема
Форум Разговоры, обсуждение новостей
Изначальное сообщение		[ Отслеживать ]

"Выпуск uutils 0.3, варианта GNU Coreutils на языке Rust "	+/–
Сообщение от opennews (ok), 25-Окт-25, 08:01
Опубликован выпуск проекта uutils coreutils 0.3.0 (Rust Coreutils), развивающего аналог пакета GNU Coreutils, написанный на языке Rust. В состав coreutils входит более ста утилит, включая sort, cat, chmod, chown, chroot, cp, date, dd, echo, hostname, id, ln и ls. Целью проекта является создание кроссплатформенной альтернативной реализации Coreutils, среди прочего способной работать на платформах Windows, Redox и Fuchsia... Подробнее: https://www.opennet.me/opennews/art.shtml?num=64114
Ответить | Правка | Cообщить модератору

Сообщения

[Сортировка по ответам | RSS]

1. Сообщение от Медведь (ok), 25-Окт-25, 08:01	+9 +/–
> Заявлен уровень совместимости 83.91% (было 87.06%) То есть добавление тестов выявило новые проблемы? Кто бы мог подумать... Пилите, Шура, пилите, они золотые.
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #3, #24, #85

3. Сообщение от Аноним (3), 25-Окт-25, 08:09	+6 +/–
Казалось бы более просто управление памятью должно было помочь растикам быстрее разрабатывать софт. В итоге они разрабатывают софт в 10 ращ медленнее. Оказалось все дело не в языке, а в голове.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #1 Ответы: #4, #54, #127

4. Сообщение от Медведь (ok), 25-Окт-25, 08:18	+3 +/–
На самом деле rust не так уж прост в управлении памятью: например, утечки памяти из-за циклических связей в структурах с объектами со счетчиками ссылок (Rc) в нем вполне себе имеют место быть, и borrow checker от этого не спасает. Но т-с-с-с-с, я этого не говорил, а то сейчас набигут растеры и побьют меня.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #3 Ответы: #5, #16, #50, #78

5. Сообщение от Аноним (5), 25-Окт-25, 08:44	+3 +/–
но ведь утечки памяти безопасны, oom киллер перегрузит приложение, станок/автопилот/робот перезапустятся полностью и все.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #4 Ответы: #6, #14, #25

6. Сообщение от Медведь (ok), 25-Окт-25, 08:46	+4 +/–
> но ведь утечки памяти безопасны, oom киллер перегрузит приложение, станок/автопилот/робот перезапустятся полностью и все. Какая прелесть! В цитатник! Не забудьте, пожалуйста, донести эту ценную мысль до разработчиков .net, скажем -- а то они ерундой маются, разруливают циклические ссылки, освобождают зачем-то память... Стоп, а зачем ее вообще освобождать? Ну свалится софтина в OOM -- но безопасно же свалится, вот что главное! Эврика!
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #5 Ответы: #9, #15

7. Сообщение от 12yoexpert (ok), 25-Окт-25, 09:00	+/–
> по сравнению с GNU Coreutils утилита sort теперь быстрее в 3.72 раза конечно, если в половине кода вставлять успешно завершающиеся загрушки инвалиды умственного труда
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #21, #52, #142

9. Сообщение от 12yoexpert (ok), 25-Окт-25, 09:18	+1 +/–
так .net/c# это не язык, просто NIH-пародия на джаву. да и течь, как джава, оно не может, даже киллер-фичу языка толком не осилили
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #6 Ответы: #74

10. Сообщение от Аноним (17), 25-Окт-25, 09:23	+/–
>Заявлен уровень совместимости 83.91% (было 87.06%). Снижение уровня совместимости объясняется добавлением в тестовый набор 16 новых тестов. Никто не измерял насколько они тесты переписали? В свете последних новостей возникают сомнения в их правдивости. Также встаёт вопрос, исходя из цели переписать 1 в 1 GNU Coreutils почему у них стабильно ломается то одно, то другое, если им достаточно просто повторить код? Неужели Rust оказался настолько сложным для восприятия человеком, что даже ИИ не может помочь?
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #11, #18

11. Сообщение от Аноним (11), 25-Окт-25, 09:36	+4 +/–
А зачем им повторять CVE из gnu? Тут стараются сразу писать корректно.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #10 Ответы: #12, #13, #22

12. Сообщение от Медведь (ok), 25-Окт-25, 09:39	+/–
> Тут стараются сразу писать корректно. 10/10 за чувство юмора!
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #11

13. Сообщение от Аноним (17), 25-Окт-25, 09:44	+/–
>Тут стараются сразу писать корректно. А когда это у них начнёт получаться?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #11 Ответы: #90

14. Сообщение от Аноним (14), 25-Окт-25, 09:55	+2 +/–
станок/автопилот/робот перезапустятся полностью и все. да, и самолёт и ядерный реактор :-)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #5 Ответы: #48, #53

15. Сообщение от laindono (ok), 25-Окт-25, 09:58	+3 +/–
https://doc.rust-lang.org/reference/unsafety.html Что именно является unsafe в контексте rust достаточно недвусмысленно определено. Утёкшая память никак не относится к безопасному доступу к памяти (memory-safety). Rust даёт гарантии по части доступа к памяти, а не гарантии безопасности в общем смысле. Протёкшая память может максимум привести к атаке denial-of-service. Может быть критическим багом, но на полноценную уязвимость не тянет. Безусловно неприятно, но не тоже самое, что use after free или прочие сишечные забавы. Кроме того DoS наверняка проще провести над .net приложухой, чем над аналогичной rust приложухой. Всёж таки у шарпов рантайм жирненький. Да и не только на исчерпание памяти такие атаки проводятся.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #6 Ответы: #17, #20, #46

16. Сообщение от Аноним (-), 25-Окт-25, 10:05	+2 +/–
> утечки памяти из-за циклических связей в структурах с объектами > со счетчиками ссылок (Rc) в нем вполне себе имеют место быть А не подскажите, в каком языке без garbage collection эту проблему решили? И решаема ли она в принципе?)) > и borrow checker от этого не спасает Вообще в доке раста расписано от чего borrow спасает, а от чего нет. И даже черным по белому написано "Preventing memory leaks entirely is not one of Rust’s guarantees" doc.rust-lang.org/book/ch15-06-reference-cycles.html Но кто же читает доку... > а то сейчас набигут растеры и побьют меня. Фууу, конечно нет! Это было бы сравнимо с пинанием щеночков-дayнов! Мерзко с одной стороны, и абсолютно бесполезно с другой.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #4

17. Сообщение от Аноним (17), 25-Окт-25, 10:06	–3 +/–
>Может быть критическим багом, но на полноценную уязвимость не тянет. Описание большинства ошибок работы с указателями в Си.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #15 Ответы: #19

18. Сообщение от нах. (?), 25-Окт-25, 10:21	–2 +/–
Ну наоборот жыж - в свете последних новостей выяснилось, что если ты тестируешь что ключик -r обрабатывается - какой-то умный вася может взять и заткнуть тест, поставив заглушку, и ачивмент анлокт! Поэтому теперь приходится переделывать тесты, чтобы убедиться что -r не текущую дату вернул, еще и файл ему создать особым образом, а то свежесозданым не проверишь. Не то что эти диды, которым в голову не пришло что тут может быть диверсия на ровном месте. > если им достаточно просто повторить код? повторить != скопипастить. А бегать от борова да, труднее чем просто абы как решить задачу, а обрабатывать corner cases когда-нибудь в следующей версии - как оно было при разработке gnu. (потому что таки да, надо проверять untrusted input на входе, а не совать в date форматную строку из внешнего источника, и надеяться что как-нибудь обработается) опыт руффлятины не даст соврать - пять лет на голый парсер. С все еще "79%" api. (Причем по сути кроме парсера своего там почти ничего не было, от ффмпега до совсем ужасных лефтпадов неведомых васянов взято готовыми. Макромедии пришлось почти все писать с нуля, ничего готового не было. Да еще под три несовместимых даже в мелочах компилятора.)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #10 Ответы: #65

19. Сообщение от Аноним (-), 25-Окт-25, 10:30	+1 +/–
> Описание большинства ошибок работы с указателями в Си. Особенно когда это remote code execution)) Загляни в соседнюю тему, так десятки взломов "c использованием уязвимости, связанной с переполнением буфера".
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #17

20. Сообщение от Медведь (ok), 25-Окт-25, 10:40	–1 +/–
Вы опять привычно свернули в сторону гарантий раста по работе с памятью. Это замечательно, что он защищает от (сравнительно узкого) класса ошибок работы с памятью, но, во-первых, даже в случае памяти -- не от всех, а во-вторых -- какой ценой? Давайте для каждого класса критических ошибок придумаем по языку, и будем яростно спорить, какой из них наиболее критически защищен. Я полагаю, что защита от критических ошибок доступа к памяти должна быть аппаратной и от языка зависеть не должна, и похоже, что разработчики ChkTag в этом тоже уверены. Кстати, в какой-то мере необходимость защиты от утечек понимали даже сами растеры: в начальных версиях раста был опциональный GC, который потом был вышвырнут на мороз во имя пуризма и чтобы zero-cost'у раста больше доверяли. Но зато позже наплодили библиотечных реализаций GC, неудобных и лишенных языковой поддержки... Песня!
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #15 Ответы: #26, #28, #29, #51

21. Сообщение от Аноним (25), 25-Окт-25, 10:53	+3 +/–
Дак это же те самые uutils, которые сломали обновления в Убунте!
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #7 Ответы: #40, #49

22. Сообщение от Аноним (25), 25-Окт-25, 10:55	+/–
opennet.ru/opennews/art.shtml?num=64108
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #11 Ответы: #64

24. Сообщение от Я (??), 25-Окт-25, 11:04	+/–
Это, как раз, нормально.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #1

25. Сообщение от Аноним (25), 25-Окт-25, 11:15	+/–
Дак вот почему боинги падают... Программисты на расте переполняют память при работе с закрылками...
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #5

26. Сообщение от Аноним (17), 25-Окт-25, 11:18	+/–
>в начальных версиях раста был опциональный GC, который потом был вышвырнут на мороз Т.е. они пожертвовали безопасностью работы с памятью ради производительности? Кого-то это мне напоминает...
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #20 Ответы: #27

27. Сообщение от Медведь (ok), 25-Окт-25, 11:29	+/–
> Т.е. они пожертвовали безопасностью работы с памятью ради производительности? Учитывая, что GC был опционален и производительности особо-то и не мешал, очень странное решение. Ну ввели бы что-то типа #![no_gc], есть же у них #![no_std] -- и гарантировали бы предсказуемость времени жизни объектов и всё такое там, где оно надо.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #26

28. Сообщение от laindono (ok), 25-Окт-25, 11:29	+/–
> Это замечательно, что он защищает от (сравнительно узкого) класса ошибок работы с памятью А больше ничего и не предполагалось. Rust в первую очередь язык для системного уровня и ниже. Сборка мусора не бесплатна, виртуальные машины не бесплатны. Есть некоторый набор задач, где это критично. > защита от критических ошибок доступа к памяти должна быть аппаратной Она есть в различных видах. Начиная с виртуальной памяти и заканчивая всякими тегами. Не панацея, куча нюансов. Опять же, чтоб некоторые из этих штук работали, нужна поддержка со стороны языка в том или ином виде. Внезапно, да? > Давайте придумаем Давайте вы лучше научитесь читать (документацию), а не заниматься придумыванием и развенчиванием собственных же мифов.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #20 Ответы: #30

29. Сообщение от Аноним (29), 25-Окт-25, 11:41	+/–
> Это замечательно, что он защищает от (сравнительно узкого) класса ошибок работы с памятью, Насколько узкого? Можно посмотреть на кол-во CVE в ядре и узреть, что этот узкий класс составется примерно большинство. > но, во-первых, даже в случае памяти -- не от всех, Но от тех, которые могут принести существенный вред. > а во-вторых -- какой ценой? Сколько там процентов насчитали вулнов из-за "ошибки памяти"? 70%? Мало? > Давайте для каждого класса критических ошибок придумаем по языку, и будем яростно спорить, какой из них наиболее критически защищен. Если вы представите руст2.0 который покроет еще один класс широко распространенных ошибок, то я вам пожму руку и поблагодарю. > Я полагаю, что защита от критических ошибок доступа к памяти должна быть аппаратной и от языка зависеть не должна, и похоже, что разработчики ChkTag в этом тоже уверены. А АРМ такая защита уже давно... но что-то это не сильно помогает. Интересно почему?) Гуглу приходится то MiraclePTR добавлять, то фаззингом обамзываться, то ультиматично выкидывать код на с/с++ и заменять. А всё вышеперечисленное стоит денег. ChkTag еще и будет стоить памяти. Уверен админы серверов обрадуются) > Кстати, в какой-то мере необходимость защиты от утечек понимали даже сами растеры: в начальных версиях раста был опциональный GC, который потом был вышвырнут на мороз во имя пуризма и чтобы zero-cost'у раста больше доверяли. И много вы знаете системных ЯП со сборщиком мусора? Смогли бы совместить одновременно развитие GC и borrow? И да, вы лукавите. GC из раста убрали еще в 2014 году, в версиях 0.11-0.12 Т.е просто сменилась парадигма развития. > Но зато позже наплодили библиотечных реализаций GC, неудобных и лишенных языковой  поддержки... Песня! Пф, слышать такую критику от адепта языка, где даже строк нормальных нету в std... Как там было в пословице про бревно в глазу))?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #20 Ответы: #31

30. Сообщение от Аноним (17), 25-Окт-25, 11:45	+/–
>Сборка мусора не бесплатна, виртуальные машины не бесплатны. Есть некоторый набор задач, где это критично. Ну так ввели бы директиву no_gc, как предложили выше, но делать этого не стали, потому что сложнее было бы рекламироваться.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #28

31. Сообщение от Медведь (ok), 25-Окт-25, 11:57	–3 +/–
> Если вы представите руст2.0 который покроет еще один класс широко распространенных ошибок, то я вам пожму руку и поблагодарю. Нет уж, увольте, с меня хватает дичи и в rust 1.0 ))) > ChkTag еще и будет стоить памяти. Уверен админы серверов обрадуются) Стоимость памяти ничтожна по сравнению с последствиями простоя для большинства бизнес-процессов. > А АРМ такая защита уже давно... но что-то это не сильно помогает Возможно, потому, что из-за очень недавнего появления стандарта на это дело пока что поддержка в компиляторах хромает? Я вообще не очень в курсе, насколько широко MTE используется в софте на ARM прямо сейчас. Поделитесь статистикой, насколько используется и насколько не помогает? > И много вы знаете системных ЯП со сборщиком мусора? Я выше писал, что для системного ПО его было бы правильнее отключать в коде, а не выбрасывать вообще. > Смогли бы совместить одновременно развитие GC и borrow? А вот это -- правильный вопрос. Borrow вообще трудно совместить со многими концепциями, которые из-за этого никогда не будут реализованы в rust. Но вам не кажется, что это обрекает его на стагнацию как ЯП? > И да, вы лукавите. GC из раста убрали еще в 2014 году, в версиях 0.11-0.12 Я где-то утверждал что-то другое, кроме того, что он изначально был в rust? > Пф, слышать такую критику от адепта языка, где даже строк нормальных нету в std... Пф, std::string в моем любимом C++ меня вполне устраивают...
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #29 Ответы: #36

32. Сообщение от Аноним (32), 25-Окт-25, 12:06	+/–
>Улучшена совместимость с эталонным тестовым набором GNU Coreutils Т.е. проходить стала меньше тестов - 532 (было 538) неудач стало больше - 68 (было 52) и полностью пропускать приходится больше - 33 (было 27) Но это улучшение... тут скорее продолжена работа над улучшением или типа того
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #33, #38, #47

33. Сообщение от Аноним (25), 25-Окт-25, 12:26	+1 +/–
Только программисты на расте умеют безопасно разрабатывать программы обратно во времени!
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #32

34. Сообщение от Аноним (34), 25-Окт-25, 12:29	+/–
Если даже coreutils заржавеют и сгниют, останутся busybox и toybox.
Ответить | Правка | Наверх | Cообщить модератору

36. Сообщение от Аноним (-), 25-Окт-25, 13:03	+2 +/–
> Нет уж, увольте, с меня хватает дичи и в rust 1.0 ))) Раз добровольцев нет - будем использовать то, что есть) > Стоимость памяти ничтожна по сравнению с последствиями простоя для большинства бизнес-процессов. Так ChkTag просто убьет процесс. На серваке. Например БД в процессе транзакции. Вот админы обрадуются! >> А АРМ такая защита уже давно... но что-то это не сильно помогает > Возможно, потому, что из-за очень недавнего появления стандарта на это дело пока  что поддержка в компиляторах хромает? Я бы не назвал технологию представленную в 2018, а выкаченную в 2019 новой. community.arm.com/arm-community-blogs/b/architectures-and-processors-blog/posts/enhancing-memory-safety > Я вообще не очень в курсе, насколько широко MTE используется в софте на ARM прямо сейчас. source.android.com/docs/security/test/memory-safety/arm-mte Есть мааааленькая загвоздка Caution: Apps that enable MTE should be thoroughly tested on an MTE-compatible device before being shipped to the Play Store. Failure to do so may lead to critical bugs being discovered only on MTE-capable devices, which may harm usability of the app Сколько у нас на данный момент выпущено процессоров без ChkTag? Сколько лет у них будет поддержка? > Поделитесь статистикой, насколько используется и насколько не помогает? Могу поделиться насколько не помогает) 2021 год - всё еще не помогло 🤷🏻‍♂️ security.googleblog.com/2021/04/rust-in-android-platform.html Жалуются на Limitations of detection и что выполнить "The Rule Of 2" очень сложно. А тут уже какой-то прогресс, правда не связанный с MTE security.googleblog.com/2022/12/memory-safe-languages-in-android-13.html To date, there have been zero memory safety vulnerabilities discovered in Android’s Rust code. > Я выше писал, что для системного ПО его было бы правильнее отключать в коде, а не выбрасывать вообще. Вон D так умеет. Но по какой-то причине никому не нужен. >> Смогли бы совместить одновременно развитие GC и borrow? > А вот это -- правильный вопрос. Borrow вообще трудно совместить со многими  концепциями, которые из-за этого никогда не будут реализованы в rust. Не уверен что это плохо. > Но вам не кажется, что это обрекает его на стагнацию как ЯП? Нет. Большая часть языков это "или GС, или ручное управление" без выбора. И они работают и выполняют свои функции (как могут))). Делать из ЯП мегакомаbн типа NeroBurning с редактором этикеток, ну такой себе. Могут позволить далеко не многие. > Я где-то утверждал что-то другое, кроме того, что он изначально был в rust? А был ли тот раст, растом? > Пф, std::string в моем любимом C++ меня вполне устраивают... Добавили, но не в первой версии. Примерно как в расте убрали GC. Был ли С++ без string С++ или это был какой-то другой язык? А а utf без костылей уже может)?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #31 Ответы: #37

37. Сообщение от Медведь (ok), 25-Окт-25, 13:26	+/–
> Добавили, но не в первой версии. Примерно как в расте убрали GC. Был ли С++ без string С++ или это был какой-то другой язык? Есть некоторая разница -- строки в C++ добавили и они есть, а сборщик мусора из rust выкинули -- и его нет. Остальное у вас -- переливание из пустого в порожнее насчет того, что действительность такова и больше никакова. Но действительность меняется, подождем...
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #36

38. Сообщение от Медведь (ok), 25-Окт-25, 13:30	+/–
Что ж тут непонятного. Отрицательное улучшение, в лучших традициях.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #32

39. Сообщение от Аноним (39), 25-Окт-25, 13:36	+1 +/–
>производительность некоторых утилит, например, по сравнению Осталось выяснить, за чей счёт банкет. Если ускорение не за счёт simd для каких-то угловых случаев, очевидно, новый вариант менее оптимален (впрочем, для когда на ржавчине довольно классически).
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #57, #60

40. Сообщение от Аноним (40), 25-Окт-25, 13:49	+/–
Ну к слову это не их вина, что убунтовцы взяли пакет, который на 80% совместим со старым и при этом не удосужились проверить что все используемые функции работают как надо
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #21 Ответы: #75, #79

43. Сообщение от warlock (??), 25-Окт-25, 14:13	–1 +/–
Круть!
Ответить | Правка | Наверх | Cообщить модератору

45. Сообщение от Аноним (45), 25-Окт-25, 15:55	–1 +/–
Ерундой люди занимаются, что доказала недавняя новость про убунту.
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #94

46. Сообщение от Аноним (46), 25-Окт-25, 16:22	–1 +/–
> Rust даёт гарантии по части доступа к памяти, а не гарантии безопасности в общем смысле. Гарантии безопасного доступа к памяти может дать только корректность логики приложения и подлежащих слоёв, обеспечивающих выполнение. Может ли Раст проверять корректность логики в вопросе доступа к неопределённо-вероятностным блокам памяти, исчисляемых во время выполнения и зависимых от окружения и входных данных?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #15 Ответы: #88

47. Сообщение от Аноним (46), 25-Окт-25, 16:25    Скрыто ботом-модератором	+/–
"Отрицательный рост"... Хотя нет, правильно так: "отрицательный Раст"!
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #32

48. Сообщение от Аноним (48), 25-Окт-25, 16:26	+/–
>самолёт и ядерный реактор Ядерный реактор на расте с кореутилс. кхд)кхд)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #14

49. Сообщение от Аноним (48), 25-Окт-25, 16:28	+/–
>Дак это же те самые uutils, которые сломали обновления в Убунте! Ну все прям можно убунту даже ставить. Нет спасибо, я после убунт 21.10 еще до релиза разочаровался. Все  понятно куда они линию гнут.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #21

50. Сообщение от Аноним (51), 25-Окт-25, 16:47	+1 +/–
> утечки памяти из-за циклических связей в структурах с объектами со счетчиками ссылок (Rc) в нем вполне себе имеют место быть, и borrow checker от этого не спасает А как работающий во время компиляции borrow checker должен спасать от ошибок во времени выполнения? Иди проспись.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #4

51. Сообщение от Аноним (51), 25-Окт-25, 16:51	+/–
> Это замечательно, что он защищает от (сравнительно узкого) класса ошибок работы с памятьи Не узкого, а более 70% тех, что приводят к уязвимостям. Гугл с МС приводили статистику.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #20

52. Сообщение от Аноним (51), 25-Окт-25, 16:57	+1 +/–
>> по сравнению с GNU Coreutils утилита sort теперь быстрее в 3.72 раза > конечно, если в половине кода вставлять успешно завершающиеся загрушки В смысле, растовый sort бысрее сишного потому что как-то частично/неполноценно сортирует, или что ты хотел сказать?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #7 Ответы: #58

53. Сообщение от Аноним (51), 25-Окт-25, 17:12	+/–
> перезапустятся полностью и все. > да, и самолёт и ядерный реактор :-) А что, предлагаешь писать ПО для самолетов и ядерных реакторов на языках с GC? Эксперт выше ведь именно о GC вещал.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #14 Ответы: #56

54. Сообщение от Аноним (54), 25-Окт-25, 17:18	+/–
> разрабатывают софт в 10 ращ медленнее Сколько времени у GNU/coreutils заняло развиться до этого уровня? Лет тридцать? Ок…
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #3 Ответы: #55, #76

55. Сообщение от Аноним (17), 25-Окт-25, 17:42	+1 +/–
Предлагаете подождать 30 лет до работоспособного состояния uutils?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #54 Ответы: #67, #84

56. Сообщение от Аноним (48), 25-Окт-25, 18:29	+/–
Короч спросил у гжпт, Rust используется в вспомогательных системах ядерных реакторов и самолетов, но не массово, пока что C++, Основными системами управляет (RTOS), такие как VxWorks, QNX, INTEGRITY, RTLinux. Но не в критических модулях, в критических модулях управляют специальные встроенные системы.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #53 Ответы: #69

57. Сообщение от Аноним (57), 25-Окт-25, 18:43	+/–
Гнутый софт, честно говоря, кривой и медленный. Grep тормознее хипстерских аналогов заметно.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #39 Ответы: #59, #80

58. Сообщение от 12yoexpert (ok), 25-Окт-25, 18:47	+/–
чувак, для начала тебе нужно понять, что слова маркетологов о том, что их товар быстрее свободного ПО, могут быть неправдой
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #52 Ответы: #61

59. Сообщение от Аноним (39), 25-Окт-25, 18:56	–1 +/–
Греп хоть не падает рандомно. Рипгреп одна из худших представителей поделок, по умолчанию на медленных носителях ощутимо тормознее и больше долбит диск впустую. Что есть у гнутого софта (во всяком случае, когда касается компонентов ОС, вроде coreutils) -- это стабильность и предсказуемая работоспособность.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #57 Ответы: #91

60. Сообщение от freehck (ok), 25-Окт-25, 19:05	+/–
>>производительность некоторых утилит, например, по сравнению > Осталось выяснить, за чей счёт банкет. Если ускорение не за счёт simd > для каких-то угловых случаев, очевидно, новый вариант менее оптимален (впрочем, для > когда на ржавчине довольно классически). С учётом того, что у них задача -- сделать сравнение в свою пользу, бьюсь об заклад, что они сравнивали (условно) стоковый coreutils из какого-нибудь Debian, скомпилированного под amd64 для древнючих архитектур, и uutils, скомпилированный со всеми возможными и невозможными оптимизациями спецом под тестовую тачку.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #39 Ответы: #92

61. Сообщение от Аноним (51), 25-Окт-25, 19:36	+/–
> слова маркетологов о том, что их товар быстрее свободного ПО, могут быть неправдой Хочешь сказать, растовый sort сортирует так же или медленнее сишного?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #58 Ответы: #63

63. Сообщение от Аноним (40), 25-Окт-25, 20:55	+/–
А если наработки по сортировке перенесут на С.... Вообще взлетит
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #61

64. Сообщение от Аноним (11), 25-Окт-25, 21:15	–1 +/–
И где тут CVE?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #22 Ответы: #71

65. Сообщение от Аноним (11), 25-Окт-25, 21:17	+/–
> Не то что эти диды, которым в голову не пришло что тут может быть диверсия на ровном месте. Это те диды, которые писали оригинал? https://github.com/advisories/GHSA-vg73-g8m4-q62r
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #18

67. Сообщение от Аноним (67), 25-Окт-25, 22:01	+/–
> Предлагаете подождать 30 лет до работоспособного состояния uutils? Так уже используют. Да, вылезли первые ошибки. И еще не одна вылезет. Но паровоз уже тронулся (не умом). И через 30 лет (если оба доживут) разница в списках CVE за этот период у растовского варианта будет в разы ниже чем у сишного.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #55

69. Сообщение от Аноним (69), 25-Окт-25, 22:15	+/–
> спросил у гжпт Странно, что он тебе не рассказал, как космические корабли на расте бороздят просторы большого театра.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #56 Ответы: #77

71. Сообщение от Аноним (69), 25-Окт-25, 22:21	+/–
Ты сказал "Тут стараются сразу писать корректно", что является враньём.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #64 Ответы: #72, #82

72. Сообщение от Аноним (69), 25-Окт-25, 22:22	–1 +/–
P.S. Ах, да... "стараются". Но кроме старания нужна ещё и квалификация, которой у них нету.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #71

74. Сообщение от morphe (?), 25-Окт-25, 22:32	+/–
> так .net/c# это не язык, просто NIH-пародия на джаву. Когда через 25 лет в жаве осилят project valhalla - тогда может быть, но сейчас VM и GC шарпов намного лучше спроектирована для большинства задач. В жаве слишком долго полагались на оптимизацию gc вместо того чтобы просто хранить вещи на стеке/inline в других объектах, escape analysis не считается потому что кроме простых случаев не работает.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #9

75. Сообщение от Аноним (75), 25-Окт-25, 22:36	+/–
А фальш-заглушка в эти 80%, прошедших тесты, входит? Если да, то их вина. К тому же, какие ещё "они" и "убунтовцы"? Разраб с самым большим количеством коммитов в uutils - подписался как Ubuntu Developer. Это, плюс-минус, те же люди.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #40

76. Сообщение от Аноним (76), 25-Окт-25, 22:36	+1 +/–
В 1990-м в целом уже готово было
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #54 Ответы: #121, #157

77. Сообщение от НеАноним (?), 25-Окт-25, 22:38	+/–
Да двигатель м драйв который, кажется в 2017 сделали. Бороздит просторы) Люди во всю колонизируют другие планеты. И занимаются терраформингом других планет. Там кстати щас набирают экспедицию на марс, но долгтй полет. Правда пока набирают. Года так с 2018, любой может. Короч где то видел на сайте, серьезно. Вообщем только) Только ты с Linux) хд)хд)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #69

78. Сообщение от morphe (?), 25-Окт-25, 22:39	+/–
>  На самом деле rust не так уж прост в управлении памятью: например, утечки памяти из-за циклических связей в структурах с объектами со счетчиками ссылок (Rc) в нем вполне себе имеют место быть, и borrow checker от этого не спасает. Но т-с-с-с-с, я этого не говорил, а то сейчас набигут растеры и побьют меня. Циклические ссылки нужно создавать либо явно (Rc::new_cyclic), либо у тебя внутри Rc должно быть interior mutable значение, потому что по дефолту содержимое Rc immutable И в обоих случаях у человека есть возможность задуматься, а то ли он вообще делает, и не нужна ли ему арена/хранилище объектов с передачей хендлов (индексов)/какая-то графовая структура/gc. И все эти способы решения в Rust имеются, и использовать их удобнее чем другие. Посмотри как сложный софт на Rust пишется, например Bevy ECS для игр, и увидишь что за счёт выразительности языка даже такая стрельба по ногам является опциональной, и проблема скорее для тех кто недостаточно в Rust погружен и пытается решать проблемы методами из других языков.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #4 Ответы: #93

79. Сообщение от morphe (?), 25-Окт-25, 22:42	+/–
> Ну к слову это не их вина, что убунтовцы взяли пакет, который на 80% совместим со старым и при этом не удосужились проверить что все используемые функции работают как надо Убунта даже не удосужилась обновить пакет, несмотря на то что в uutils каждый день что-то дорабатывают и фиксят, и фикс проблемы был уже давно, просто по привычке убунта взяла версию трёхмесячной давности
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #40

80. Сообщение от Аноним (48), 25-Окт-25, 22:45	+/–
>Гнутый софт Да.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #57

82. Сообщение от Аноним (11), 25-Окт-25, 22:55	+/–
Ты вырвал фразу из текста, корректность была про CVE.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #71

84. Сообщение от Аноним (54), 26-Окт-25, 00:08	+/–
Если в 10 раз медленнее, то 300 лет надо ждать.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #55

85. Сообщение от morphe (?), 26-Окт-25, 01:05	+/–
> То есть добавление тестов выявило новые проблемы? Кто бы мог подумать... Пилите, Шура, пилите, они золотые. Там исправили проблему от которой неподдерживаемые аргументы игнорировались Вопрос скорее в том, что это за тесты, которым без разницы обрабатываются аргументы или нет
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #1

88. Сообщение от Чтото знающий (?), 26-Окт-25, 01:48	+/–
>Гарантии безопасного доступа к памяти может дать только корректность логики приложения и подлежащих слоёв, обеспечивающих выполнение. Не могли бы вы привести пример на безопасном Rust, который подтверждал бы ваше утверждение? Типа, вот здесь на корректность доступа к памяти влияет исключительно логика приложения, а не компилятор, который в вашем примере просто пропустит некорректное обращение к памяти.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #46

90. Сообщение от Чтото знающий (?), 26-Окт-25, 02:02	+/–
Уже получается. Просмотрите на количество пройденных тестов, что ли.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #13 Ответы: #97

91. Сообщение от Чтото знающий (?), 26-Окт-25, 02:06	–2 +/–
>по умолчанию на медленных носителях ощутимо тормознее и больше долбит диск впустую Ссылки будут на результаты тестирования или очередное "экспертное мнение"?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #59 Ответы: #106

92. Сообщение от Чтото знающий (?), 26-Окт-25, 02:08	+/–
>С учётом того, что у них задача -- сделать сравнение в свою пользу Зачем бы им заниматься подтасовками? Или вы по себе судите?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #60 Ответы: #107, #110

93. Сообщение от Медведь (ok), 26-Окт-25, 02:10	–2 +/–
Это все замечательно, но вот только циклические взаимосвязи в реальных предметных областях встречаются очень часто, и раст со своим боровчекером в таких задачах неуклюж, как бегемот в посудной лавке. Стандартный ответ растера: "ты просто не понял раст!". Но если для того, чтобы выразить тривиальную взаимосвязь из реального мира, нужно навертеть тонны откровенно ненужных сущностей, возможно, не я "недостаточно погружён", а просто rust недостаточно выразителен или слишком ограничен? Скажем, биться с боровчекером, растыкивая Rc::new_cyclic просто из-за ограничений модели владения, как по мне, удовольствие сильно ниже среднего, не находишь?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #78 Ответы: #96, #99, #115

94. Сообщение от Чтото знающий (?), 26-Окт-25, 02:12	–2 +/–
1. Чем хотят, тем и занимаются. Вам какое дело до этого? 2. А что она доказала? Авторы утилит ведь показывают, что все тесты они пока не проходят. На это и номер версии намекает. Почему же вы считаете их виноватыми в том, что дистрособиратели Убунты решили взять в свой продукт сырое ПО?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #45 Ответы: #98

95. Сообщение от Чтото знающий (?), 26-Окт-25, 02:14	–5 +/–
Ух, сколько борцунов с Rust набежало. Чуют недоброе, ох чуют, что скоро только легаси и останется им поддерживать.
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #105, #109

96. Сообщение от Чтото знающий (?), 26-Окт-25, 02:32	+/–
>раст со своим боровчекером в таких задачах неуклюж, как бегемот в посудной лавке. >чтобы выразить тривиальную взаимосвязь из реального мира, нужно навертеть тонны откровенно ненужных сущностей Если вам нужны циклические зависимости, вы или используете unsafe, либо вам неважна утечка памяти, о возможности которой честно сообщают в доке. >просто rust недостаточно выразителен или слишком ограничен? Ограничен? Да,безусловно. Не даёт протекать в код примерно 70% типовых ошибок. Недостаточно выразителен? Глядя на то, сколько кода уже написано на этом языке в разных предметных областях, закрадывается сомнение в вашей объективности.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #93 Ответы: #100

97. Сообщение от Аноним (17), 26-Окт-25, 02:36	+/–
Результат пока не впечатляющий и правдивость тестов вызывает вопросы.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #90 Ответы: #132

98. Сообщение от Аноним (17), 26-Окт-25, 02:40	+/–
Авторы утилит и дистрособиратели Убунты - это одни и те же люди.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #94 Ответы: #135

99. Сообщение от morphe (?), 26-Окт-25, 02:47	+/–
> Это все замечательно, но вот только циклические взаимосвязи в реальных предметных областях > встречаются очень часто, и раст со своим боровчекером в таких задачах > неуклюж, как бегемот в посудной лавке. Я и не сказал что таких не существует, я сказал что большинство таких случаев решаются способами более удобными чем через Rc<RefCell<T>>: арены, графы, хендлы, опять же сборщик мусора/cборщик циклов
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #93 Ответы: #101

100. Сообщение от Медведь (ok), 26-Окт-25, 02:48	–2 +/–
> Если вам нужны циклические зависимости, вы или используете unsafe, либо вам неважна утечка памяти, о возможности которой честно сообщают в доке. А-а-а, погодите, так "честная дока" оправдывает все косяки дизайна языка, про которые она "честно сообщает"? Упс, а ведь доки по C совершенно честно говорят, что ответственность за косяки с памятью лежит на программисте. Всё, никаких претензий, ведь так?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #96 Ответы: #130

101. Сообщение от Медведь (ok), 26-Окт-25, 02:59	+/–
> арены, графы, хендлы, опять же сборщик мусора/cборщик циклов Про тонны ненужных сущностей я уже писал...
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #99 Ответы: #102, #103

102. Сообщение от morphe (?), 26-Окт-25, 03:02	+1 +/–
> Про тонны ненужных сущностей я уже писал... Т.е в условных сях ты можешь использовать счётчик ссылок для циклических структур и при этом не получать утечки/use after free? Нука покажи свою магию
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #101 Ответы: #112

103. Сообщение от morphe (?), 26-Окт-25, 03:03	+/–
> Про тонны ненужных сущностей я уже писал... Гвозди надо забивать микроскопом, стены сверлить им же...
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #101 Ответы: #113

105. Сообщение от Аноним (105), 26-Окт-25, 07:11	+/–
> Ух, сколько борцунов с Rust набежало. Чуют недоброе, ох чуют, что скоро только легаси и останется им поддерживать. Когда примерно 15-ть лет назад выходили новости про пермиссивные аналоги GNU утилит, были единичные посты о том, что корпорасты собираются заменить всю системную часть GNU/Linux. Многие говорили: "это же Open Source, форки же всегда бывают, может у кого-то из разрабов своё видение, о том каким должна быть программа. Посмотри на ядро, кто бросит "вызов" Линусу?". Ну, не верили. Кстати, сам Р. Столлман тоже был насторожен такой тенденцией. На 2025 год уже нет, ни у никого нет сомнений в том, что корпорасты хотят максимально избавится копилефтного кода. Получится ли это у Red Hat, Canonical, Oracle? Да, получится. А те компании, которые собирают собственные дистры на основе их дистрибутивов будут вынуждены подстроится. Смогут ли корпорасты частично или полностью вытеснить GNU? Нет, не получится. GNU - это самостоятельный игрок, который создан с нуля Свободным Сообществом. Программисты всего мира! Мой вам совет, не принимайте участие в разработке и тестировании корпорастических дистрибутивов. Не тратьте на это своё время. Так вы делаете корпорастов сильнее. И не забывайте, что пермиссивщик легко превращается в проприетарщика.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #95 Ответы: #108, #138

106. Сообщение от Аноним (39), 26-Окт-25, 09:15	+/–
На какие тестирования, у тебя всё хорошо? По умолчанию он в несколько потоков долбит и это значительно медленнее 1 потока.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #91 Ответы: #122, #133

107. Сообщение от Аноним (39), 26-Окт-25, 09:20	–1 +/–
>>С учётом того, что у них задача -- сделать сравнение в свою пользу > Зачем бы им заниматься подтасовками? Или вы по себе судите? Ну, вот, автор мусл заявляет, что его либц значительно лучше и производительнее глибц примерно во всём, смотри брошюрки на сайте. Есть те, кто в это верят. А на практике, все мы знаем.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #92

108. Сообщение от Аноним (108), 26-Окт-25, 10:30	+/–
> И не забывайте, что пермиссивщик легко превращается в проприетарщика. Проприетарщик проприетарщику рознь. Одно дело когда это мегамонополисты, и совсем другое дело когда мелкий ремесленник Васян пытается заработать на хлеб закрытой тулзой. Вся эта очередная классовая "борьба" - как раз и выгодна корпорастам, чтоб рабы даже не вздумали пойти в свободное плавание. Только харкор, только на галерах у воротил, которые заказывает музыку. Я об этом уже много раз писал лет 20 назад. Но воз и ныне там. Смысл в том, что не нужно кидаться в крайности.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #105 Ответы: #111

109. Сообщение от Аноним (158), 26-Окт-25, 11:55	+2 +/–
> Чуют недоброе, ох чуют А что тут чуять то если это недоброе в новостях. То там отвалится, то там не обновляется. А опыт начинания переписывания других проектов говорит о том, что они никогда НЕ МОГУТ полностью повторить оригинал из-за кривизны, которая ограничивает возможности разработки. А кривизна вызвана заточенностью на безопасной работе с памятью, а не удобстве поддерживания одного кода для множества архитектур с использованием множества разных библиотек и их версий.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #95 Ответы: #137

110. Сообщение от freehck (ok), 26-Окт-25, 12:02	+1 +/–
> Зачем бы им заниматься подтасовками? А я их в этом не обвиняю. Подтасовка предполагает, что действие произведено с таковым умыслом. В данном же случае, причины могут быть куда более прозаичны. Так, например, перед разработчиком стоит задача произвести сравнительный анализ своего софта и софта копируемого. Разработчик прекрасно знает свой софт, и как его выгоднее собрать, чтобы добиться лучшей производительности. Но при этом сравнительно слабо знает, как сделать аналогичное для копируемого софта: и главное -- у него нет никакого желания глубоко разбираться в этом. Вот так неосознанно и получаются такие результаты безо всяких подтасовок. В большинстве подобных тестов впечатляющие результаты именно этим и обусловлены, так что пока не будет убедительно доказано обратного, это -- рабочая гипотеза, которую лично я буду считать истинной. PS: Или вот ещё пример. Буквально в этом году прямо тут на опеннете в новости про Redis (или мб Valkey) был человек, который приводил результаты произведённых им бенчмарков, из которых следовало, что он якобы может выжать из Postgresql более 10k qps для запросов update-а одной и той же строки. Не смотря на то, что это невозможно в принципе, он искренне верил в то, что писал. Он на самом деле произвёл бенчмарки, он совершенно точно не совершал подтасовок. Просто он банально ошибся и закидывал базу update-ами рандомных строк, а не одной конкретной. Так что тесты -- штука такая: очень сильно зависят от того, кто их производит.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #92 Ответы: #134

111. Сообщение от Аноним (-), 26-Окт-25, 13:59	+/–
Почему-то я вспомнил фильм 1998 года, "Честная куртизанка". Извини. Понимаешь в чём дело когда возникает "борьба", не бывает оттенков серого, промежуточных состояний. Ты должен сделать чёткий выбор, на какой ты стороне. Когда травили Столлмана люди сделали чёткий выбор. И сделав чёткий выбор они спасли Столлмана. Я не говорю о том, что "если ты не за нас, то ты против нас" - это аморальное высказывание. Я лишь говорю о том, что во время "борьбы" надо сделать чёткий выбор на какой ты стороне. И это правильно.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #108 Ответы: #114

112. Сообщение от Медведь (ok), 26-Окт-25, 15:25	–4 +/–
В условных сях двусвязный циклический список, например, элементарно делается без счетчиков ссылок вообще, и прекрасно освобождается соответствующей функцией. А в C++ это все еще и чудесно работает в деструкторе списка, что вкупе со смарт-поинтерами сводит риск неправильного использования к неразличимому минимуму.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #102 Ответы: #116, #117

113. Сообщение от Медведь (ok), 26-Окт-25, 15:42	+/–
Ты сейчас про модель владения в расте? Полностью согласен, она здорово мешает, когда ее приходится терпеть во всех 100% кода.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #103 Ответы: #129, #131

114. Сообщение от Аноним (108), 26-Окт-25, 16:11	+/–
Выбор простой. Нечего терять кроме собственных цепей. Хотя кому-то рабство нравится. Многие даже здесь нахваливают своих рабовладельцев.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #111

115. Сообщение от Аноним (51), 26-Окт-25, 16:39	+1 +/–
> Но если для того, чтобы выразить тривиальную взаимосвязь из реального мира, нужно навертеть тонны откровенно ненужных сущностей В каком языке без GC задача циклических зависимостей решаема без "откровенно ненужных сущностей" в виде подсчета ссылок? Может, C++? > Скажем, биться с боровчекером, растыкивая Rc::new_cyclic просто из-за ограничений модели владения, как по мне, удовольствие сильно ниже среднего, не находишь? Господи, что за бред ты снова несёшь? Rc работает в рантайме и не имеет НИКАКОГО отношения к borrow checker-у, работающего во время компиляции. > возможно, не я "недостаточно погружён" Ты не просто "недостаточно погружён" - ты фантастически некомпетентен в темах, на которые пытаешься умничать, и потому закономерно несешь несусветную чушь.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #93 Ответы: #118

116. Сообщение от Аноним (51), 26-Окт-25, 16:46	+/–
> А в C++ это все еще и чудесно работает в деструкторе списка, что вкупе со смарт-поинтерами Лол. "Ненужные" Rc из Раста против "чудесных" смарт-поинтеров из C++. Воин даже не в курсе, что концептуально это одно и то же. 🤦
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #112 Ответы: #119

117. Сообщение от Аноним (51), 26-Окт-25, 16:50	–1 +/–
>> Т.е в условных сях ты можешь использовать счётчик ссылок для циклических структур и при этом не получать утечки/use after free? > В условных сях двусвязный циклический список, например, элементарно делается без счетчиков ссылок вообще, и прекрасно освобождается соответствующей функцией. О как! Вместо счетчика ссылок для решения use-after-free сишочник предлагает проверенное десятилетиями "написал правильно - мамой клянусь"! И на полном серьезе же пишет...
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #112 Ответы: #120

118. Сообщение от Медведь (ok), 26-Окт-25, 16:59	–2 +/–
Ты разберись, зачем в вашем расте вообще существует этот самый Rc::new_cyclic, а там посмотрим, кто некопенгаген.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #115

119. Сообщение от Медведь (ok), 26-Окт-25, 17:02	–2 +/–
Строго говоря, все объекты в том же python концептуально -- примерно то же самое, и что? Ни в плюсах, ни в пайтоне никто не навязывает откровенно дебильного беганья от боровчекера. Дьявол в деталях, как говорится.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #116

120. Сообщение от Медведь (ok), 26-Окт-25, 17:05	–2 +/–
>>> Т.е в условных сях ты можешь использовать счётчик ссылок для циклических структур и при этом не получать утечки/use after free? >> В условных сях двусвязный циклический список, например, элементарно делается без счетчиков ссылок вообще, и прекрасно освобождается соответствующей функцией. > О как! Вместо счетчика ссылок для решения use-after-free сишочник предлагает проверенное > десятилетиями "написал правильно - мамой клянусь"! И на полном серьезе же > пишет... Растеры же полагаются на автопроверки, накручивают тонны бойлерплейта, по итогу имеем что имеем, пламенный привет багам в Ubuntu...
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #117

121. Сообщение от Аноним (121), 26-Окт-25, 18:55	+/–
Так готово, что те баги до сих пор фиксят.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #76

122. Сообщение от Аноним (121), 26-Окт-25, 19:00	+/–
Так рипгреп писался для современных компьютеров с SSD, а не для твой древности с MFM контроллером. Для людей с ограниченными возможностями рекомендуется grep и Debian potato.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #106 Ответы: #126

126. Сообщение от Аноним (39), 26-Окт-25, 19:58	+/–
Ну разве что для дебиичей, которые холодные данные хранят на ссд, может быть полезно такое поведение. Но к чему им быстрее, ведь, очевидно, ничем полезным они не занимаются?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #122

127. Сообщение от эксперт по всему (?), 26-Окт-25, 20:22	–1 +/–
представь что rust это C++ со всеми возможными статическими анализаторами. писать на C++ когда надо полностью удовлетворять анализаторы будет примерно также по скорости
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #3

128. Сообщение от Аноним (128), 26-Окт-25, 21:29	+1 +/–
Из описания языка Vale про Rust: https://vale.dev/comparisons "Rust is also very difficult. It's as complex as C++, and throws it all at the programmer at once. Unless you're brilliant (or come from certain backgrounds which fit well with Rust's restrictions), it's going to take you many months to learn what patterns the borrow checker likes, what kinds of tricks to use to work around it, and when to give up and re-architect your program. It's safe by default, except: It has unsafe code which allow unsafe operations. It allows bugs in unsafe code (and FFI 4) to trigger memory unsafety in safe Rust code. A Rust program will bring a lot of unsafe code in via dependencies "
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #139, #140

129. Сообщение от morphe (?), 26-Окт-25, 22:15	+/–
> Ты сейчас про модель владения в расте? Полностью согласен, она здорово мешает, > когда ее приходится терпеть во всех 100% кода. Я её вообще не замечаю, потому что весь нормально написанный код (включая код на C) этой модели и так соответствует
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #113

130. Сообщение от Чтото знающий (?), 27-Окт-25, 00:04	+/–
>оправдывает Не оправдывает, а сообщает. >косяки дизайна языка Вполне возможно, что другого решения в природе не существует. Или безопасная работа с памятью (включая возможную утечку) или сам себе злобный Буратино. Сродни законам физики. Они не позволяют... они много чего не позволяют. Но благодаря им мир становится детерменированным. >Всё, никаких претензий, ведь так? Объективно Rust намного лучше C. Разве ж это претензия? Просто констатация факта.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #100

131. Сообщение от Чтото знающий (?), 27-Окт-25, 00:15	+/–
>когда ее приходится терпеть во всех 100% кода Вам её приходится терпеть, потому что, предположу, вы её плохо понимаете (при условии, что вы действительно пытаетесь программировать на этом языке). Попробуйте начать с чего-нибудь простого, чтобы привыкнуть. А там, уверен, и понимание появится. Хорошим помощником в понимании может стать какой-нибудь чат ИИ.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #113 Ответы: #158

132. Сообщение от Чтото знающий (?), 27-Окт-25, 00:21	+/–
>Результат пока не впечатляющий Это субъективная оценка. Как по мне, для альфа-версии - вполне себе впечатляющий, учитывая то, сколько утилит в работе находится, и как быстро разработчики вышли на такой результат. >и правдивость тестов вызывает вопросы. Для альфа-версий вполне обычное явление. Но вы всегда можете помочь проекту, если действительно в нём заинтересованы.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #97 Ответы: #159

133. Сообщение от Чтото знающий (?), 27-Окт-25, 00:26	+/–
На реальное тестирование, а не умозрительное, которым вы или ваш единомышленник пытаетесь здесь заниматься. Потому что медленный диск вполне может работать быстрее при нескольких потоках по сравнению с одним. Как это возможно? Буферизация. Обычно ОС кеширует обращение к диску.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #106 Ответы: #136

134. Сообщение от Чтото знающий (?), 27-Окт-25, 00:33	+/–
Ваша аналогия некорректна. Потому что какая-нибудь cut в реализации и использовании на несколько порядков проще, чем MySQL или PostgreSQL. Следовательно, возможностей накрутить тест в свою пользу гораздо меньше. Далее. Это ведь открытый проект. Если кто-то сомневается в результатах, вполне может провести аналогичные тесты и прийти уже с конкретными цифрами, а не умозрительными подозрениями, как это делаете вы или ваши единомышленники.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #110 Ответы: #150

135. Сообщение от Чтото знающий (?), 27-Окт-25, 00:35	+/–
Ок. В какой LTS версии Ubuntu вы столкнулись с проблемами из-за сырости этих утилит?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #98 Ответы: #155

136. Сообщение от Аноним (39), 27-Окт-25, 00:42	+/–
То, что тебя интересует, называется упреждающее чтение (диск читает большими блоками и релевантные данные чудом могут оказаться в буфере), этим занимается прошивка диска и ОС тут никаким боком. На практике не поможет. Нет, ну, конечно, ситуация грепнуть несколько раз одни и те же данные (вместо того, чтобы правильно написать команду), вполне может случиться, тогда мультипоточный греп по кэшу может оказаться пропорционально быстрее. Во всех остальных случаях, операции медленнее. Между прочим, случайный доступ и на ссд весьма посредственную производительность демонстрирует, поэтому очень значительное ускорение просто невозможно.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #133 Ответы: #141

137. Сообщение от Чтото знающий (?), 27-Окт-25, 00:45	+/–
они никогда НЕ МОГУТ полностью повторить оригинал из-за кривизны этого самого оригинала Поправил. Так, пожалуй, точнее будет. Есть продукты на Rust, которые существенно превосходят оригинал. Например, ripgrep. Или pingora. Или zed. Просто подобные проекты ведут не корпорации, как правило (pingora - исключение), а энтузиасты. Поэтому быстрого результата ожидать не приходится. Люди, ведь, в своё свободное время этим занимаются, ради удовольствия, а не чтобы конкретно вам угодить.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #109 Ответы: #160

138. Сообщение от Чтото знающий (?), 27-Окт-25, 00:50	–1 +/–
>На 2025 год уже нет, ни у никого нет сомнений в том, что корпорасты хотят максимально избавится копилефтного кода. Реальность такова, что сколь-либо сложное ПО могут вытягивать только корпорации. Что ярко демонстрирует то же ядро Линукса,в котором около 88% кода пришло от корпораций. Поэтому их желание вполне понятно - кто девушку платит, тот её и танцует. Но почему вы о корпорациях вспомнили? Речь же о языке программирования, а не типах лицензий.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #105 Ответы: #146, #147, #154

139. Сообщение от Чтото знающий (?), 27-Окт-25, 01:05	–1 +/–
Половина из написанного - попытка натянуть сову на глобус. Нет, Rust гораздо проще C++, чья спецификация занимает около полутора тысяч страниц. Лично я не считаю себя шением в программировании. Кроме того, мне за 50. Но мне хватило примерно 40 часов, чтобы освоить какие-то основы, чтобы начать писать софт. Согласен, что Rust - не самый простой язык программирования. Но до C++ ему в этом плане очень далеко. >it's going to take you many months to learn what patterns the borrow checker likes Часто хватает 5 минут, чтобы спросить у чата. В особо сложных случаях может растянуться на несколько дней. Но уж точно ни о каких месяцах речь не идёт. >It has unsafe code which allow unsafe operations Это так. Но этот код всегда отмечен специальным образом. Поэтому проблемы искать проще, чем в том же коде на Плюсах, где весь код - сплошной unsafe. >A Rust program will bring a lot of unsafe code in via dependencies Зависит от конкретного проекта. То есть, это необязательно всегда так.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #128 Ответы: #176, #177

140. Сообщение от Чтото знающий (?), 27-Окт-25, 01:20	+/–
Продолжение. Автор статьи говорит о том, что Rust не является полностью безопасным из-за FFI. А как можно обеспечить безопасность в чужом коде? Ещё перлы "C++ is the fastest; it lets you do anything you want, with zero overhead" Правда-правда все абстракции в Плюсах без дополнительных издержек? "while no language can be faster than C++'s speed in theory" Автор не знает о существовании Си, Ассемблера? Резюмирую. Я бы не стал доверять статьям с подобными оценками, потому что или автор некомпетентен, или очень предвзят.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #128 Ответы: #149

141. Сообщение от Прохожий (??), 27-Окт-25, 01:46	+/–
Меня это не интересует. Я об этом прекрасно осведомлён (в ИТ-отрасли уже более 25 лет). Это во-первых. Во-вторых, ведь никто не запрещает использовать 1-поточный режим, если по какой-то причине многопоточный кажется медленным. То есть, у вас есть ВЫБОР в случае ripgrep, в отличие от grep, где его нет.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #136 Ответы: #148

142. Сообщение от Чтото знающий (?), 27-Окт-25, 01:53	+/–
>конечно, если в половине кода вставлять успешно завершающиеся загрушки У вас, конечно, и доказательства есть? Или как обычно?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #7

146. Сообщение от Аноним (108), 27-Окт-25, 05:46	+/–
> Реальность такова, что сколь-либо сложное ПО могут вытягивать только корпорации. Что ярко демонстрирует то же ядро Линукса,в котором около 88% кода пришло от корпораций. Поэтому их желание вполне понятно - кто девушку платит, тот её и танцует. Просто некоторые товарищи до сих пор совершенно не подозревают в какую позу их поставили и уже которое десятилетие мнят себя пламенными идейными борцами под знаменем Столлмана (на смех корпорастам). Это выглядит комично со стороны. И как раз такое клоунское положение вещей и выглядит как нечто пограничное между вышеупомянутой "честной куртизанкой" и полу-сектантским психическим заболеванием. Когда им заикаешься про мелкую (но по-настоящему независимую) проприетарщину от пролетария Васяна, который пытается (не факт что получится) заработать себе на бомж-пакет, то в ответ раздаются только предсказуемые, бессмысленные и тенденциозные лозунги. Хотя сами же, в отличии от независимого Васяна - часто в открытую проституируют на галерах у корпорастов или же за их деньги им пританцовывают (ну это про то что вы и писали - "кто девушку платит, тот её и танцует", "любой каприз за ваши деньги" и так далее).
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #138

147. Сообщение от Аноним (108), 27-Окт-25, 06:25	+1 +/–
> Но почему вы о корпорациях вспомнили? Я заметил употребление термина "проприетарщина" с негативным оттенком. > Речь же о языке программирования, а не типах лицензий. Кстати да, и лицензия LGPL - не просто так создавалась. Она заточена под проприетарщину (при чём самим Столлманом). В том, что кто-то пробует заработать даже путём закрытия части кода - нет ничего плохого. Это, конечно, сообществом FSF не поощряется, но и не стоит забывать и то, что среднестатистический человек питается не только святым духом. По поводу Растокостылей. Всё. Не о чем говорить. Баталии уже не актуальны после ChkTag. Если у фирмы (или отдельного кодера) годами складывались наработки на Си и Си++, то ты не переубедишь что-то менять, это архисложная и контр-продуктивная задача.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #138 Ответы: #151, #152

148. Сообщение от Аноним (39), 27-Окт-25, 09:50	+/–
Тогда не понимаю, почему такие вещи приходится объяснять. Ripgrep совершенно непредсказуем, в скрипт не добавишь, а это основное применение. Падает, если ему файл не понравился. К тому же, разница в производительности там не столь значительна, чтобы отказываться от привычных регулярок.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #141

149. Сообщение от Аноним (39), 27-Окт-25, 10:04	+1 +/–
Той сарказм неуместен, плюсы действительно позволяют и simd и zero-copy, и с куда меньшими затратами. К примеру, даже чтение данных в плюсах можно сделать значительно быстрее, чем в си, посредством пары небольших трюков с libc++. А ассемблер непонятно каким боком приплетаешь, он может быть максимально быстрым, но вручную ты не оптимизируешь под каждый процессор (они каждый год новые со своими особенностями). Единственное, для чего он полезен, это simd. Про затраты на написание кода даже не будем.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #140

150. Сообщение от freehck (ok), 27-Окт-25, 10:45	+1 +/–
> Если кто-то сомневается в результатах, вполне может провести аналогичные тесты и прийти уже с конкретными цифрами Вот и сделайте, пожалуйста. Чужим-то временем, чай, легко распоряжаться, да?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #134

151. Сообщение от Медведь (ok), 27-Окт-25, 12:57	+/–
> Баталии уже не актуальны после ChkTag. Совершенно верно. Предвижу реакцию оппонентов: "Но у нас же гарантии compile time! А ChkTag просто убьет программу в рантайме!" Это так, но при этом все ошибки работы с памятью, от которых гарантирует раст, из критических, чреватых дырами в безопасности, внезапно становятся просто себе логическими ошибками, одними из многих возможных, в одном ряду с любыми другими ошибками, могущими кинуть панику в растовом рантайме. Ждем выхода процессоров с ChkTag, но уже сейчас компетентные граждане сильно задумаются, стоит ли связываться с растом или просто подождать.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #147 Ответы: #153

152. Сообщение от Аноним (-), 27-Окт-25, 13:24	+/–
> Кстати да, и лицензия LGPL - не просто так создавалась. Она заточена под проприетарщину (при чём самим Столлманом). В том, что кто-то пробует заработать даже путём закрытия части кода - нет ничего плохого. Но сам Столлман писал в Манифесте ГНУ, что люди программируют не ради денег, зарплаты нужно ограничивать, и вообще тех кто пишет проприетарь - нужно наказывать. > Это, конечно, сообществом FSF не поощряется, но и не стоит забывать и то, что среднестатистический человек питается не только святым духом. Он может получать дары от благодарных пользователей)) Или танцевать в фyppu-сьюте. > По поводу Растокостылей. Всё. Не о чем говорить. Ну так не говори) > Баталии уже не актуальны после ChkTag. Напомню что а АРМ аналогичный механизм с 18-19 года. Поддержка уже давно добавлена в андроид. Но, по какой-то странной причине в, практически, 2026 году гугл продолжает уменьшать использование дырявых языков. Возможно серебрянная пуля в виде MTE, оказалась не настолько хорошей, как мне ты пытаешься  втирать)? Сколько лет будут выпускаться процессоры по старой технологии? Когда закончится для них End of Servicing Lifetime? Напомню, что для 7th Gen Core Kaby Lake это дата была 2024 год. А сейчас актуальные - 11-12 поколение. > Если у фирмы (или отдельного кодера) годами складывались наработки на Си и Си++, то ты не переубедишь что-то менять, А его не надо переубеждать. Можно просто для госконтрактов прописать условия "не дырявые ЯП". И он сам побежит переписывать хоть на Аду, хоть на раст, хоть вспомнит что есть Сишный CompCert (но для него нужно мозги иметь). > это архисложная и контр-продуктивная задача. Ага. То-то макрософты, амазоны, гуглы и клоудфлари сами начали переходить.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #147 Ответы: #162

153. Сообщение от Аноним (-), 27-Окт-25, 13:29	+/–
> Совершенно верно. Это ты сам с собой соглашаешься?)) > Предвижу реакцию оппонентов: "Но у нас же гарантии compile time! А ChkTag просто убьет программу в рантайме!" Я у тебя уже спрашивал в другой теме, почему если в АРМ эта штука уже 7 лет, то проблемы не исчезли. Ты как-то не заметил вопроса или слился 🤷🏻‍♂️ > Это так, И этого уже достаточно) > но при этом все ошибки работы с памятью, от которых гарантирует раст, из критических, чреватых дырами в безопасности, внезапно становятся просто себе логическими ошибками, С чего вдруг? Если у тебя внезапно время от времени падает сервак, то тебе будет не очень весело искать кто попортил память. > Ждем выхода процессоров с ChkTag, но уже сейчас компетентные граждане сильно задумаются,  стоит ли связываться с растом или просто подождать. А еще выкинуть все старые серваки и купить новые.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #151 Ответы: #156

154. Сообщение от Аноним (154), 27-Окт-25, 13:50	+/–
> ядро Линукса,в котором около 88% кода пришло от корпораций. Забыл упомянуть, 88% лишнего кода. Линух застыл в нулевых, уже давно ничего фундаментального в ядро не добавляется. Идёт только бесконечное переписывание кроватей с языка на язык и их перестановка между кернел и юзер-спейсами.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #138

155. Сообщение от anonymous (??), 27-Окт-25, 14:02	+/–
А что, эту кривую поделку уже в какой-то LTS затянули? Соболезную пострадавшим.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #135

156. Сообщение от Медведь (ok), 27-Окт-25, 14:04	+/–
> Это ты сам с собой соглашаешься?)) Да, специально для тебя выхожу и захожу, выхожу и захожу. > Я у тебя уже спрашивал в другой теме, почему если в АРМ > эта штука уже 7 лет, то проблемы не исчезли. > Ты как-то не заметил вопроса или слился 🤷🏻‍♂️ Если у тебя есть статистика по проблемам в софте собранном под ARM с поддержкой MTE, в студию! > С чего вдруг? Если у тебя внезапно время от времени падает сервак, > то тебе будет не очень весело искать кто попортил память. Если сервак падает от паники в коде на раст, меня вряд ли утешит мысль, что зато это же паника на самом раст, практически святая паника! Да и просто ошибки в логике софта меня мало порадуют, скажу честно. Раст от них защищает? > А еще выкинуть все старые серваки и купить новые. Чего уж там, перестроить все серверные и проложить новые дороги к ним.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #153 Ответы: #164

157. Сообщение от User (??), 27-Окт-25, 14:20	+/–
Смотреть, в каком году гнутики добавили в свою поделку ключ -r я, конечно же, не буду...
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #76

158. Сообщение от Аноним (158), 27-Окт-25, 14:52	+/–
> Попробуйте начать с чего-нибудь простого, чтобы привыкнуть. А там, уверен, и понимание появится. На простом те самые нюансы не всплывут.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #131

159. Сообщение от Аноним (158), 27-Окт-25, 14:55	+/–
> Как по мне, для альфа-версии - вполне себе впечатляющий Одна проблема. Что он делает в Ubuntu. > Для альфа-версий вполне обычное явление. Но вы всегда можете помочь проекту, если действительно в нём заинтересованы. То заинтересованность только одна. Что бы эти альфа-версии никуда не пихали. Или пихали куда-нибудь где "заинтересованных" нет.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #132

160. Сообщение от Аноним (158), 27-Окт-25, 15:01	+1 +/–
> они никогда НЕ МОГУТ полностью повторить оригинал из-за кривизны этого самого оригинала Вот совершенно не важно. Главное - что они принципиально НЕ МОГУТ. > Есть продукты на Rust, которые существенно превосходят оригинал. Например, ripgrep. Или pingora. Или zed. Два последних не видел. ripgrep видел. Явно сырая недоделка. Периодически валящаяся. Плохой пример. > Просто подобные проекты ведут не корпорации, как правило (pingora - исключение), а энтузиасты. > Поэтому быстрого результата ожидать не приходится. Люди, ведь, в своё свободное время этим занимаются, ради удовольствия, а не чтобы конкретно вам угодить. Дело совершенно не в этом, а в том что это на порядки сложнее, и лечит это не собираются.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #137

162. Сообщение от Аноним (162), 27-Окт-25, 15:51	+/–
> Напомню что а АРМ аналогичный механизм с 18-19 года. Поддержка уже давно добавлена в андроид. Но, по какой-то странной причине в, практически, 2026 году гугл продолжает... Мыши плакали, кололись, но продолжали жрать кактус. Гугл может себе позволить подобные эксперименты, к тому же месье́ знают толк в извращениях. Первый раз что ли? https://gcemetery.co
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #152 Ответы: #163, #165

163. Сообщение от Аноним (162), 27-Окт-25, 15:57	+/–
И вдогонку: https://killedbygoogle.com Или может скажете принудительное внедрение Kotlin в андроиде было очень "умной" затеей? Когда традиционной Джавы хватало выше крыши. Все эти бессмысленные нагромождения, метания, погоня за хайпом и баззвордами по прихоти менеджеров-гуманитариев, беспорядок как дань моде - ни к чему хорошему не приведут в конечном итоге.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #162

164. Сообщение от Аноним (-), 27-Окт-25, 16:28	+/–
> Если у тебя есть статистика по проблемам в софте собранном под ARM с поддержкой MTE, в студию! Пффф, какие у тебя запросы) Я ж спросил простой вопрос "если МТЕ так крут, то зачем гугл использует раст?") И да, поддержка МТЕ не во всех процессорах, да еще нужен особый чипсет. Посмотри на то как его используют и расскажи что это просто. developer.arm.com/documentation/108035/0100 > Если сервак падает от паники в коде на раст, меня вряд ли утешит мысль, что зато это же паника на самом раст, практически святая паника! А если он не упадет, а скажет при компиляции "дружище, ты тут ошибся"? Любая предотвращенная ошибка, которая не попала к пользователям, обходится гораздо дешевле. > Да и просто ошибки в логике софта меня мало порадуют, скажу честно. Раст от них защищает? А должен? Хочешь гарантий для логики - тогда Ада-спарк тебе в помощь. Или хаскель с математической верификацией. Но будет очень дорого. >> А еще выкинуть все старые серваки и купить новые. > Чего уж там, перестроить все серверные и проложить новые дороги к ним. Cpaказм это конечно хорошо, но получилось глупо. Вот у тебя есть список компов за тонны баксов opennet.ru/opennews/art.shtml?num=62256 Например "11 миллионов процессорных ядер CPU AMD EPYC", которые однозначно не поддерживают  новые фичи. И там крутится линукс. Предлагаешь выкинуть?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #156 Ответы: #166

165. Сообщение от Аноним (-), 27-Окт-25, 16:32	+/–
> Мыши плакали, кололись, но продолжали жрать кактус. Да-да, какой глупый гугл) Мелкомягкие, амазон и прочие тоже? > Гугл может себе позволить подобные эксперименты, к тому же месье́ знают толк в извращениях. Первый раз что ли? https://gcemetery.co О, люблю эту ссылку. Думаю половина проектов были объеденены или поглощены гугловскими творениями. А тут речь про миллионы строк уже работающих в андроиде. Ну и вишенка на торт - биндер в ядро линукс, который заменяет старый СИшный.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #162 Ответы: #167

166. Сообщение от Медведь (ok), 27-Окт-25, 16:58	+/–
> если МТЕ так крут, то зачем гугл использует раст? Может потому, что хочет здесь и сейчас, а ChkTag вот только-только стандартизировали? Вот что ответила нейросетка: Google видит в MTE технологию, способную на порядок повысить безопасность миллиардов устройств и положить конец эре уязвимостей памяти. Компания инвестирует значительные ресурсы, чтобы сделать MTE стандартом де-факто в мобильной индустрии, сотрудничая с производителями чипов и устройств. > А если он не упадет, а скажет при компиляции "дружище, ты тут ошибся"? Любая предотвращенная ошибка, которая не попала к пользователям, обходится гораздо дешевле. Соглашусь. > Хочешь гарантий для логики - тогда Ада-спарк тебе в помощь. Или хаскель с математической верификацией. Вот это - имхо правильный подход, не тыкать раст всюду, где он нужен и не нужен, а использовать правильные инструменты. > Предлагаешь выкинуть? А что, с появлением раста они все внезапно упали и больше не работают? Вроде бы еще накануне вполне себе выполняли свои задачи. Понятно, что новые технологии защиты внедрятся постепенно, по мере обновления парка железа. Или ты хочешь сказать, что сервероводы, покупая новый сервер, гордо скажут -- нет, мне не нужен процессор с ChkTag|MTE|..., у меня же раст, дайте мне вооон тот серверок из кладовочки?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #164 Ответы: #168

167. Сообщение от Аноним (162), 27-Окт-25, 17:15	+/–
> Да-да, какой глупый гугл) > Мелкомягкие, амазон и прочие тоже? А что они когда-то были эталоном безошибочности? Обычные корпорастические манагеры подверженные бесполезному распылению усилий. Корпорасты как раз и славятся тем, что повсеместно городят франкенштейнов и очень далеки от академически строгих подходов в инженерном деле. > А тут речь про миллионы строк уже работающих в андроиде. Ну это только начало эксперимента. Потом это болото ещё придётся поддерживать. А оно может внезапно перестать быть модно-молодёжным.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #165 Ответы: #169

168. Сообщение от Аноним (-), 27-Окт-25, 17:29	+/–
> Может потому, что хочет здесь и сейчас, О, вот это здравая мыcль. У тебя есть выбор или твой код станет менее дырявым вот прям сейчас и степень этого менее будет увеличиваться с каждой замененной строкой. Или ждать N лет пока вымрет всё железо без поддержки такой фичи. > а ChkTag вот только-только стандартизировали? Т.е если посмотреть на развитие MTE developer.android.com/ndk/guides/arm-mte то поддержка даже гугловых девайсов - это Pixel 8 и Pixel 9. Не густо не так ли? > Google видит в MTE технологию, способную на порядок повысить безопасность миллиардов устройств и положить конец эре уязвимостей памяти. Красиво сказано. А вот что они пишут в своем блоге security.googleblog.com/2023/11/mte-promising-path-forward-for-memory.html Бла-бла Shifting to memory safe languages such as Rust as a proactive solution to prevent the new memory safety bugs from being introduced in the first place.   >> Хочешь гарантий для логики - тогда Ада-спарк тебе в помощь. Или хаскель с математической верификацией. > Вот это - имхо правильный подход, не тыкать раст всюду, где он нужен и не нужен, а использовать правильные инструменты. А где он нужен и не нужен? Кто это решает? Может у вас есть деньги на разработку Ada-spark? Кстати последние по какой-то непонятной причине решили "AdaCore Joins Rust Foundation as Silver Member" adacore.com/press/adacore-joins-rust-foundation-as-silver-member По поводу математической верификации. Ты знаешь сколько это стоит? sigops.org/s/conferences/sosp/2009/papers/klein-sosp09.pdf The overall size of the proof, including framework, libraries, and generated proofs (not shown in the table) is 200,000 lines of Isabelle script. .... total cost of 2.2 py including the Haskell effort. А речь про "8,700 lines of C code and 600 lines of assembler" И да, между формальной верификацией, спарком и обычный сишным кодом (дpыстня с переполнениями и прочими use-after-free) по свойству "корректность-безопасность" пропасть. И ее может заполнить раст. > А что, с появлением раста они все внезапно упали и больше не работают? Вроде бы еще накануне вполне себе выполняли свои задачи. Не, они просто остались дырявыми) > Понятно, что новые технологии защиты внедрятся постепенно, по мере обновления парка железа. Т.е, если брать пример ARM, то лет 10 ждать? Ну, тогда из ядра раст уже не выколупаете)) > Или ты хочешь сказать, что сервероводы, покупая новый сервер, гордо скажут -- нет, мне не нужен процессор с ChkTag|MTE|..., у меня же раст, дайте мне вооон тот серверок из кладовочки? Не, они спросят поставщика либы и ядра "у меня есть парк старых верваков и датацентров, оно будет работать?", а следущий вопрос будет "оно еще не окупилось, может как-то сделать чтобы и старые были побезопаснее". А учитывая что такие фирмы (амазон, гугл, майки) по совместительству еще и спонсоры LF и разработчики опенсорса...
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #166 Ответы: #171

169. Сообщение от Аноним (-), 27-Окт-25, 17:38	+/–
> А что они когда-то были эталоном безошибочности? А кто говорит про безошибочность? Тут речь про то, что если корпы что-то внедряют, то это обычно надолго. > Обычные корпорастические манагеры подверженные бесполезному распылению усилий. То ли дело васяны лепящие 100500й дистрибутив с нескучными обоями)) > Корпорасты как раз и славятся тем, что повсеместно городят франкенштейнов и очень далеки от академически строгих подходов в инженерном деле. Напомнить на кого обычно работают эти академики? Например создатель Minix. >> А тут речь про миллионы строк уже работающих в андроиде. > Ну это только начало эксперимента. Которому уже сколько лет? И который уже признан успешным. > Потом это болото ещё придётся поддерживать. А оно может внезапно перестать быть модно-молодёжным. И? Ну будет какой-то хруст-2.0, разработка будет в расте. Это не является проблемой.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #167 Ответы: #170

170. Сообщение от Аноним (162), 27-Окт-25, 17:59	+/–
> Тут речь про то, что если корпы что-то внедряют, то это обычно надолго. Вот с этого надо было начинать. Но сути дела это не меняет. Сколько раз не назови чёрное - белым. > Напомнить на кого обычно работают эти академики? На управленцев. И что по итогу? Вынуждены пользоваться наследием 80-х, потому что теоретические фундаментальные разработки если не застопорились, то ОЧЕНЬ сильно замедлились. > Которому уже сколько лет? И который уже признан успешным. Ну, про "успешность" можешь кому-нибудь другому втирать. Я в курсе всех плюсов и минусов Раста, и толочь воду в ступе на опеннете в 100500 раз нет никакого желания. > И? Ну будет какой-то хруст-2.0, разработка будет в расте. > Это не является проблемой. Слушай, вот когда подгонят хруст 2.0 с блэкджеком - тогда и поговорим. И я рад что для корпов в который раз это якобы "не проблема" )))
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #169 Ответы: #172

171. Сообщение от Медведь (ok), 27-Окт-25, 18:02	+/–
Кто из нас прав, покажет только время, и за ним точно не заржавеет ))) Предлагаю закончить бесконечный спор.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #168

172. Сообщение от Аноним (-), 27-Окт-25, 18:10	+/–
> Вот с этого надо было начинать. Но сути дела это не меняет. Суть дела была "раз появится аналог МТЕ, то раст не нужен". Это и обсуждается. > На управленцев. И что по итогу? Вынуждены пользоваться наследием 80-х, потому что теоретические фундаментальные разработки если не застопорились, то ОЧЕНЬ сильно замедлились. Так это скрепа не только управленцев. Сколько народу пользовалось копролитным С89, когда уже был С11? "Работает - не трогай" как символ нынешнего computer science > Ну, про "успешность" можешь кому-нибудь другому втирать. Пф, типа твое мнение будет волновать гугл. По их стандартам и требованиям - действительно успешный. > Слушай, вот когда подгонят хруст 2.0 с блэкджеком - тогда и поговорим. А пока у нас будет раст в ядре, в дровах типа MESA и в телефонах. Нравится нам это или нет.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #170 Ответы: #173

173. Сообщение от Аноним (162), 27-Окт-25, 18:22	+1 +/–
>> Вот с этого надо было начинать. Но сути дела это не меняет. > Суть дела была "раз появится аналог МТЕ, то раст не нужен". > Это и обсуждается. Кем обсуждается? Основные проблемы с памятью устранены на аппаратном уровне. Я сразу написал, что для меня эта тема закрыта. А кому лень кодить вдумчиво, хочется экзотики и экстремального секса с боровом - никто не запрещает.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #172

176. Сообщение от Кошкажена (?), 27-Окт-25, 23:06	+/–
> Нет, Rust гораздо проще C++, чья спецификация занимает около полутора тысяч страниц. А сколько занимает спецификация раста? А точно, ее же нет.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #139

177. Сообщение от Кошкажена (?), 27-Окт-25, 23:08	+/–
> Часто хватает 5 минут, чтобы спросить у чата. В особо сложных случаях может растянуться на несколько дней. Но уж точно ни о каких месяцах речь не идёт. А потом задаются вопросом откуда "уровень совместимости 83.91%".
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #139

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема