| 1.1, Медведь (ok), 08:01, 25/10/2025 [ответить] [﹢﹢﹢] [ · · · ]
| +9 +/– |
 > Заявлен уровень совместимости 83.91% (было 87.06%)
То есть добавление тестов выявило новые проблемы? Кто бы мог подумать... Пилите, Шура, пилите, они золотые.
| | |
| |
| 2.3, Аноним (3), 08:09, 25/10/2025 [^] [^^] [^^^] [ответить]
| +6 +/– |
Казалось бы более просто управление памятью должно было помочь растикам быстрее разрабатывать софт. В итоге они разрабатывают софт в 10 ращ медленнее. Оказалось все дело не в языке, а в голове.
| | |
| |
| 3.4, Медведь (ok), 08:18, 25/10/2025 [^] [^^] [^^^] [ответить]
| +3 +/– |
На самом деле rust не так уж прост в управлении памятью: например, утечки памяти из-за циклических связей в структурах с объектами со счетчиками ссылок (Rc) в нем вполне себе имеют место быть, и borrow checker от этого не спасает. Но т-с-с-с-с, я этого не говорил, а то сейчас набигут растеры и побьют меня.
| | |
| |
| 4.5, Аноним (5), 08:44, 25/10/2025 [^] [^^] [^^^] [ответить]
| +3 +/– |
но ведь утечки памяти безопасны, oom киллер перегрузит приложение, станок/автопилот/робот перезапустятся полностью и все.
| | |
| |
| 5.6, Медведь (ok), 08:46, 25/10/2025 [^] [^^] [^^^] [ответить]
| +4 +/– | |
> но ведь утечки памяти безопасны, oom киллер перегрузит приложение, станок/автопилот/робот перезапустятся полностью и все.
Какая прелесть! В цитатник! Не забудьте, пожалуйста, донести эту ценную мысль до разработчиков .net, скажем -- а то они ерундой маются, разруливают циклические ссылки, освобождают зачем-то память...
Стоп, а зачем ее вообще освобождать? Ну свалится софтина в OOM -- но безопасно же свалится, вот что главное! Эврика!
| | |
| |
| 6.9, 12yoexpert (ok), 09:18, 25/10/2025 [^] [^^] [^^^] [ответить]
| +1 +/– |
 так .net/c# это не язык, просто NIH-пародия на джаву.
да и течь, как джава, оно не может, даже киллер-фичу языка толком не осилили
| | |
| |
| 7.74, morphe (?), 22:32, 25/10/2025 [^] [^^] [^^^] [ответить]
| +/– | |
> так .net/c# это не язык, просто NIH-пародия на джаву.
Когда через 25 лет в жаве осилят project valhalla - тогда может быть, но сейчас VM и GC шарпов намного лучше спроектирована для большинства задач. В жаве слишком долго полагались на оптимизацию gc вместо того чтобы просто хранить вещи на стеке/inline в других объектах, escape analysis не считается потому что кроме простых случаев не работает.
| | |
|
| 6.15, laindono (ok), 09:58, 25/10/2025 [^] [^^] [^^^] [ответить]
| +3 +/– |
 https://doc.rust-lang.org/reference/unsafety.html
Что именно является unsafe в контексте rust достаточно недвусмысленно определено. Утёкшая память никак не относится к безопасному доступу к памяти (memory-safety). Rust даёт гарантии по части доступа к памяти, а не гарантии безопасности в общем смысле.
Протёкшая память может максимум привести к атаке denial-of-service. Может быть критическим багом, но на полноценную уязвимость не тянет. Безусловно неприятно, но не тоже самое, что use after free или прочие сишечные забавы.
Кроме того DoS наверняка проще провести над .net приложухой, чем над аналогичной rust приложухой. Всёж таки у шарпов рантайм жирненький. Да и не только на исчерпание памяти такие атаки проводятся.
| | |
| |
| 7.17, Аноним (17), 10:06, 25/10/2025 [^] [^^] [^^^] [ответить]
| –3 +/– | |
>Может быть критическим багом, но на полноценную уязвимость не тянет.
Описание большинства ошибок работы с указателями в Си.
| | |
| |
| 8.19, Аноним (-), 10:30, 25/10/2025 [^] [^^] [^^^] [ответить] | +1 +/– | Особенно когда это remote code execution Загляни в соседнюю тему, так десятки ... текст свёрнут, показать | | |
|
| 7.20, Медведь (ok), 10:40, 25/10/2025 [^] [^^] [^^^] [ответить] | –1 +/– | Вы опять привычно свернули в сторону гарантий раста по работе с памятью Это зам... большой текст свёрнут, показать | | |
| |
| 8.26, Аноним (17), 11:18, 25/10/2025 [^] [^^] [^^^] [ответить] | +/– | Т е они пожертвовали безопасностью работы с памятью ради производительности Ко... текст свёрнут, показать | | |
| |
| 9.30, Аноним (17), 11:45, 25/10/2025 [^] [^^] [^^^] [ответить] | +/– | Ну так ввели бы директиву no_gc, как предложили выше, но делать этого не стали, ... текст свёрнут, показать | | |
|
| 8.29, Аноним (29), 11:41, 25/10/2025 [^] [^^] [^^^] [ответить] | +/– | Насколько узкого Можно посмотреть на кол-во CVE в ядре и узреть, что этот узкий... большой текст свёрнут, показать | | |
| |
| 9.31, Медведь (ok), 11:57, 25/10/2025 [^] [^^] [^^^] [ответить] | –3 +/– | Нет уж, увольте, с меня хватает дичи и в rust 1 0 Стоимость памяти ничтожна ... большой текст свёрнут, показать | | |
| |
| 10.36, Аноним (-), 13:03, 25/10/2025 [^] [^^] [^^^] [ответить] | +2 +/– | Раз добровольцев нет - будем использовать то, что есть Так ChkTag просто убьет ... большой текст свёрнут, показать | | |
|
|
| 8.51, Аноним (51), 16:51, 25/10/2025 [^] [^^] [^^^] [ответить] | +/– | Не узкого, а более 70 тех, что приводят к уязвимостям Гугл с МС приводили стат... текст свёрнут, показать | | |
|
| 7.46, Аноним (46), 16:22, 25/10/2025 [^] [^^] [^^^] [ответить]
| –1 +/– | |
> Rust даёт гарантии по части доступа к памяти, а не гарантии безопасности в общем смысле.
Гарантии безопасного доступа к памяти может дать только корректность логики приложения и подлежащих слоёв, обеспечивающих выполнение.
Может ли Раст проверять корректность логики в вопросе доступа к неопределённо-вероятностным блокам памяти, исчисляемых во время выполнения и зависимых от окружения и входных данных?
| | |
|
|
| 5.14, Аноним (14), 09:55, 25/10/2025 [^] [^^] [^^^] [ответить]
| +2 +/– | |
станок/автопилот/робот перезапустятся полностью и все.
да, и самолёт и ядерный реактор :-)
| | |
| |
| 6.48, Аноним (48), 16:26, 25/10/2025 [^] [^^] [^^^] [ответить]
| +/– | |
>самолёт и ядерный реактор
Ядерный реактор на расте с кореутилс.
кхд)кхд)
| | |
| 6.53, Аноним (51), 17:12, 25/10/2025 [^] [^^] [^^^] [ответить]
| +/– |
> перезапустятся полностью и все.
> да, и самолёт и ядерный реактор :-)
А что, предлагаешь писать ПО для самолетов и ядерных реакторов на языках с GC? Эксперт выше ведь именно о GC вещал.
| | |
| |
| 7.56, Аноним (48), 18:29, 25/10/2025 [^] [^^] [^^^] [ответить]
| +/– |
Короч спросил у гжпт, Rust используется в вспомогательных системах ядерных реакторов и самолетов, но не массово, пока что C++,
Основными системами управляет (RTOS), такие как VxWorks, QNX, INTEGRITY, RTLinux.
Но не в критических модулях, в критических модулях управляют специальные встроенные системы.
| | |
| |
| 8.69, Аноним (69), 22:15, 25/10/2025 [^] [^^] [^^^] [ответить] | +/– | Странно, что он тебе не рассказал, как космические корабли на расте бороздят про... текст свёрнут, показать | | |
|
|
|
| 5.25, Аноним (25), 11:15, 25/10/2025 [^] [^^] [^^^] [ответить]
| +/– |
Дак вот почему боинги падают... Программисты на расте переполняют память при работе с закрылками...
| | |
|
| 4.16, Аноним (-), 10:05, 25/10/2025 [^] [^^] [^^^] [ответить]
| +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нов!
Мерзко с одной стороны, и абсолютно бесполезно с другой.
| | |
| 4.50, Аноним (51), 16:47, 25/10/2025 [^] [^^] [^^^] [ответить]
| +1 +/– | |
> утечки памяти из-за циклических связей в структурах с объектами со счетчиками ссылок (Rc) в нем вполне себе имеют место быть, и borrow checker от этого не спасает
А как работающий во время компиляции borrow checker должен спасать от ошибок во времени выполнения? Иди проспись.
| | |
| 4.78, morphe (?), 22:39, 25/10/2025 [^] [^^] [^^^] [ответить] | +/– | Циклические ссылки нужно создавать либо явно Rc new_cyclic , либо у тебя внутр... большой текст свёрнут, показать | | |
| |
| 5.93, Медведь (ok), 02:10, 26/10/2025 [^] [^^] [^^^] [ответить]
| –2 +/– | |
Это все замечательно, но вот только циклические взаимосвязи в реальных предметных областях встречаются очень часто, и раст со своим боровчекером в таких задачах неуклюж, как бегемот в посудной лавке.
Стандартный ответ растера: "ты просто не понял раст!". Но если для того, чтобы выразить тривиальную взаимосвязь из реального мира, нужно навертеть тонны откровенно ненужных сущностей, возможно, не я "недостаточно погружён", а просто rust недостаточно выразителен или слишком ограничен? Скажем, биться с боровчекером, растыкивая Rc::new_cyclic просто из-за ограничений модели владения, как по мне, удовольствие сильно ниже среднего, не находишь?
| | |
| |
| 6.96, Чтото знающий (?), 02:32, 26/10/2025 [^] [^^] [^^^] [ответить]
| +/– |
>раст со своим боровчекером в таких задачах неуклюж, как бегемот в посудной лавке.
>чтобы выразить тривиальную взаимосвязь из реального мира, нужно навертеть тонны откровенно ненужных сущностей
Если вам нужны циклические зависимости, вы или используете unsafe, либо вам неважна утечка памяти, о возможности которой честно сообщают в доке.
>просто rust недостаточно выразителен или слишком ограничен?
Ограничен? Да,безусловно. Не даёт протекать в код примерно 70% типовых ошибок.
Недостаточно выразителен? Глядя на то, сколько кода уже написано на этом языке в разных предметных областях, закрадывается сомнение в вашей объективности.
| | |
| |
| 7.100, Медведь (ok), 02:48, 26/10/2025 [^] [^^] [^^^] [ответить]
| –2 +/– | |
> Если вам нужны циклические зависимости, вы или используете unsafe, либо вам неважна утечка памяти, о возможности которой честно сообщают в доке.
А-а-а, погодите, так "честная дока" оправдывает все косяки дизайна языка, про которые она "честно сообщает"? Упс, а ведь доки по C совершенно честно говорят, что ответственность за косяки с памятью лежит на программисте. Всё, никаких претензий, ведь так?
| | |
|
| 6.99, morphe (?), 02:47, 26/10/2025 [^] [^^] [^^^] [ответить]
| +/– |
> Это все замечательно, но вот только циклические взаимосвязи в реальных предметных областях
> встречаются очень часто, и раст со своим боровчекером в таких задачах
> неуклюж, как бегемот в посудной лавке.
Я и не сказал что таких не существует, я сказал что большинство таких случаев решаются способами более удобными чем через Rc<RefCell<T>>: арены, графы, хендлы, опять же сборщик мусора/cборщик циклов
| | |
| |
| 7.101, Медведь (ok), 02:59, 26/10/2025 [^] [^^] [^^^] [ответить]
| +/– | |
> арены, графы, хендлы, опять же сборщик мусора/cборщик циклов
Про тонны ненужных сущностей я уже писал...
| | |
| |
| 8.102, morphe (?), 03:02, 26/10/2025 [^] [^^] [^^^] [ответить] | +1 +/– | Т е в условных сях ты можешь использовать счётчик ссылок для циклических структу... текст свёрнут, показать | | |
|
|
| 6.115, Аноним (51), 16:39, 26/10/2025 [^] [^^] [^^^] [ответить]
| +1 +/– | |
> Но если для того, чтобы выразить тривиальную взаимосвязь из реального мира, нужно навертеть тонны откровенно ненужных сущностей
В каком языке без GC задача циклических зависимостей решаема без "откровенно ненужных сущностей" в виде подсчета ссылок? Может, C++?
> Скажем, биться с боровчекером, растыкивая Rc::new_cyclic просто из-за ограничений модели владения, как по мне, удовольствие сильно ниже среднего, не находишь?
Господи, что за бред ты снова несёшь? Rc работает в рантайме и не имеет НИКАКОГО отношения к borrow checker-у, работающего во время компиляции.
> возможно, не я "недостаточно погружён"
Ты не просто "недостаточно погружён" - ты фантастически некомпетентен в темах, на которые пытаешься умничать, и потому закономерно несешь несусветную чушь.
| | |
| |
| 7.118, Медведь (ok), 16:59, 26/10/2025 [^] [^^] [^^^] [ответить]
| –2 +/– |
Ты разберись, зачем в вашем расте вообще существует этот самый Rc::new_cyclic, а там посмотрим, кто некопенгаген.
| | |
|
|
|
|
| 3.54, Аноним (54), 17:18, 25/10/2025 [^] [^^] [^^^] [ответить]
| +/– | |
> разрабатывают софт в 10 ращ медленнее
Сколько времени у GNU/coreutils заняло развиться до этого уровня? Лет тридцать? Ок…
| | |
| |
| 4.55, Аноним (17), 17:42, 25/10/2025 [^] [^^] [^^^] [ответить]
| +1 +/– |
Предлагаете подождать 30 лет до работоспособного состояния uutils?
| | |
| |
| 5.67, Аноним (67), 22:01, 25/10/2025 [^] [^^] [^^^] [ответить]
| +/– | |
> Предлагаете подождать 30 лет до работоспособного состояния uutils?
Так уже используют. Да, вылезли первые ошибки. И еще не одна вылезет. Но паровоз уже тронулся (не умом). И через 30 лет (если оба доживут) разница в списках CVE за этот период у растовского варианта будет в разы ниже чем у сишного.
| | |
|
| |
| 5.157, User (??), 14:20, 27/10/2025 [^] [^^] [^^^] [ответить]
| +/– |
Смотреть, в каком году гнутики добавили в свою поделку ключ -r я, конечно же, не буду...
| | |
|
|
| 3.127, эксперт по всему (?), 20:22, 26/10/2025 [^] [^^] [^^^] [ответить]
| –1 +/– |
представь что rust это C++ со всеми возможными статическими анализаторами. писать на C++ когда надо полностью удовлетворять анализаторы будет примерно также по скорости
| | |
|
| 2.85, morphe (?), 01:05, 26/10/2025 [^] [^^] [^^^] [ответить]
| +/– | |
> То есть добавление тестов выявило новые проблемы? Кто бы мог подумать... Пилите, Шура, пилите, они золотые.
Там исправили проблему от которой неподдерживаемые аргументы игнорировались
Вопрос скорее в том, что это за тесты, которым без разницы обрабатываются аргументы или нет
| | |
|
| 1.7, 12yoexpert (ok), 09:00, 25/10/2025 [ответить] [﹢﹢﹢] [ · · · ]
| +/– | |
> по сравнению с GNU Coreutils утилита sort теперь быстрее в 3.72 раза
конечно, если в половине кода вставлять успешно завершающиеся загрушки
инвалиды умственного труда
| | |
| |
| 2.21, Аноним (25), 10:53, 25/10/2025 [^] [^^] [^^^] [ответить]
| +3 +/– |
Дак это же те самые uutils, которые сломали обновления в Убунте!
| | |
| |
| 3.40, Аноним (40), 13:49, 25/10/2025 [^] [^^] [^^^] [ответить]
| +/– |
Ну к слову это не их вина, что убунтовцы взяли пакет, который на 80% совместим со старым и при этом не удосужились проверить что все используемые функции работают как надо
| | |
| |
| 4.75, Аноним (75), 22:36, 25/10/2025 [^] [^^] [^^^] [ответить]
| +/– | |
А фальш-заглушка в эти 80%, прошедших тесты, входит? Если да, то их вина.
К тому же, какие ещё "они" и "убунтовцы"? Разраб с самым большим количеством коммитов в uutils - подписался как Ubuntu Developer. Это, плюс-минус, те же люди.
| | |
| 4.79, morphe (?), 22:42, 25/10/2025 [^] [^^] [^^^] [ответить]
| +/– | |
> Ну к слову это не их вина, что убунтовцы взяли пакет, который на 80% совместим со старым и при этом не удосужились проверить что все используемые функции работают как надо
Убунта даже не удосужилась обновить пакет, несмотря на то что в uutils каждый день что-то дорабатывают и фиксят, и фикс проблемы был уже давно, просто по привычке убунта взяла версию трёхмесячной давности
| | |
|
| 3.49, Аноним (48), 16:28, 25/10/2025 [^] [^^] [^^^] [ответить]
| +/– | |
>Дак это же те самые uutils, которые сломали обновления в Убунте!
Ну все прям можно убунту даже ставить.
Нет спасибо, я после убунт 21.10 еще до релиза разочаровался.
Все понятно куда они линию гнут.
| | |
|
| 2.52, Аноним (51), 16:57, 25/10/2025 [^] [^^] [^^^] [ответить]
| +1 +/– |
>> по сравнению с GNU Coreutils утилита sort теперь быстрее в 3.72 раза
> конечно, если в половине кода вставлять успешно завершающиеся загрушки
В смысле, растовый sort бысрее сишного потому что как-то частично/неполноценно сортирует, или что ты хотел сказать?
| | |
| |
| 3.58, 12yoexpert (ok), 18:47, 25/10/2025 [^] [^^] [^^^] [ответить]
| +/– |
чувак, для начала тебе нужно понять, что слова маркетологов о том, что их товар быстрее свободного ПО, могут быть неправдой
| | |
| |
| 4.61, Аноним (51), 19:36, 25/10/2025 [^] [^^] [^^^] [ответить]
| +/– | |
> слова маркетологов о том, что их товар быстрее свободного ПО, могут быть неправдой
Хочешь сказать, растовый sort сортирует так же или медленнее сишного?
| | |
| |
| 5.63, Аноним (40), 20:55, 25/10/2025 [^] [^^] [^^^] [ответить]
| +/– |
А если наработки по сортировке перенесут на С.... Вообще взлетит
| | |
|
|
|
| 2.142, Чтото знающий (?), 01:53, 27/10/2025 [^] [^^] [^^^] [ответить]
| +/– | |
>конечно, если в половине кода вставлять успешно завершающиеся загрушки
У вас, конечно, и доказательства есть? Или как обычно?
| | |
|
| 1.10, Аноним (17), 09:23, 25/10/2025 [ответить] [﹢﹢﹢] [ · · · ]
| +/– | |
>Заявлен уровень совместимости 83.91% (было 87.06%). Снижение уровня совместимости объясняется добавлением в тестовый набор 16 новых тестов.
Никто не измерял насколько они тесты переписали? В свете последних новостей возникают сомнения в их правдивости.
Также встаёт вопрос, исходя из цели переписать 1 в 1 GNU Coreutils почему у них стабильно ломается то одно, то другое, если им достаточно просто повторить код? Неужели Rust оказался настолько сложным для восприятия человеком, что даже ИИ не может помочь?
| | |
| |
| 2.11, Аноним (11), 09:36, 25/10/2025 [^] [^^] [^^^] [ответить]
| +4 +/– |
А зачем им повторять CVE из gnu? Тут стараются сразу писать корректно.
| | |
| |
| 3.13, Аноним (17), 09:44, 25/10/2025 [^] [^^] [^^^] [ответить]
| +/– | |
>Тут стараются сразу писать корректно.
А когда это у них начнёт получаться?
| | |
| |
| |
| 5.97, Аноним (17), 02:36, 26/10/2025 [^] [^^] [^^^] [ответить]
| +/– |
Результат пока не впечатляющий и правдивость тестов вызывает вопросы.
| | |
| |
| 6.132, Чтото знающий (?), 00:21, 27/10/2025 [^] [^^] [^^^] [ответить]
| +/– | |
>Результат пока не впечатляющий
Это субъективная оценка. Как по мне, для альфа-версии - вполне себе впечатляющий, учитывая то, сколько утилит в работе находится, и как быстро разработчики вышли на такой результат.
>и правдивость тестов вызывает вопросы.
Для альфа-версий вполне обычное явление. Но вы всегда можете помочь проекту, если действительно в нём заинтересованы.
| | |
| |
| 7.159, Аноним (158), 14:55, 27/10/2025 [^] [^^] [^^^] [ответить]
| +/– | |
> Как по мне, для альфа-версии - вполне себе впечатляющий
Одна проблема. Что он делает в Ubuntu.
> Для альфа-версий вполне обычное явление. Но вы всегда можете помочь проекту, если действительно в нём заинтересованы.
То заинтересованность только одна. Что бы эти альфа-версии никуда не пихали. Или пихали куда-нибудь где "заинтересованных" нет.
| | |
|
|
|
|
| |
| |
| 5.71, Аноним (69), 22:21, 25/10/2025 [^] [^^] [^^^] [ответить]
| +/– |
Ты сказал "Тут стараются сразу писать корректно", что является враньём.
| | |
| |
| 6.72, Аноним (69), 22:22, 25/10/2025 [^] [^^] [^^^] [ответить]
| –1 +/– |
P.S. Ах, да... "стараются". Но кроме старания нужна ещё и квалификация, которой у них нету.
| | |
|
|
|
|
| 2.18, нах. (?), 10:21, 25/10/2025 [^] [^^] [^^^] [ответить] | –2 +/– | Ну наоборот жыж - в свете последних новостей выяснилось, что если ты тестируешь ... большой текст свёрнут, показать | | |
|
| 1.32, Аноним (32), 12:06, 25/10/2025 [ответить] [﹢﹢﹢] [ · · · ]
| +/– | |
>Улучшена совместимость с эталонным тестовым набором GNU Coreutils
Т.е. проходить стала меньше тестов - 532 (было 538)
неудач стало больше - 68 (было 52)
и полностью пропускать приходится больше - 33 (было 27)
Но это улучшение... тут скорее продолжена работа над улучшением или типа того
| | |
| |
| 2.33, Аноним (25), 12:26, 25/10/2025 [^] [^^] [^^^] [ответить]
| +1 +/– |
Только программисты на расте умеют безопасно разрабатывать программы обратно во времени!
| | |
| 2.38, Медведь (ok), 13:30, 25/10/2025 [^] [^^] [^^^] [ответить]
| +/– |
Что ж тут непонятного. Отрицательное улучшение, в лучших традициях.
| | |
|
| 1.39, Аноним (39), 13:36, 25/10/2025 [ответить] [﹢﹢﹢] [ · · · ]
| +1 +/– | |
>производительность некоторых утилит, например, по сравнению
Осталось выяснить, за чей счёт банкет. Если ускорение не за счёт simd для каких-то угловых случаев, очевидно, новый вариант менее оптимален (впрочем, для когда на ржавчине довольно классически).
| | |
| |
| 2.57, Аноним (57), 18:43, 25/10/2025 [^] [^^] [^^^] [ответить]
| +/– | |
Гнутый софт, честно говоря, кривой и медленный.
Grep тормознее хипстерских аналогов заметно.
| | |
| |
| 3.59, Аноним (39), 18:56, 25/10/2025 [^] [^^] [^^^] [ответить]
| –1 +/– |
Греп хоть не падает рандомно. Рипгреп одна из худших представителей поделок, по умолчанию на медленных носителях ощутимо тормознее и больше долбит диск впустую. Что есть у гнутого софта (во всяком случае, когда касается компонентов ОС, вроде coreutils) -- это стабильность и предсказуемая работоспособность.
| | |
| |
| 4.91, Чтото знающий (?), 02:06, 26/10/2025 [^] [^^] [^^^] [ответить]
| –2 +/– | |
>по умолчанию на медленных носителях ощутимо тормознее и больше долбит диск впустую
Ссылки будут на результаты тестирования или очередное "экспертное мнение"?
| | |
| |
| 5.106, Аноним (39), 09:15, 26/10/2025 [^] [^^] [^^^] [ответить]
| +/– |
На какие тестирования, у тебя всё хорошо? По умолчанию он в несколько потоков долбит и это значительно медленнее 1 потока.
| | |
| |
| 6.122, Аноним (121), 19:00, 26/10/2025 [^] [^^] [^^^] [ответить]
| +/– |
Так рипгреп писался для современных компьютеров с SSD, а не для твой древности с MFM контроллером. Для людей с ограниченными возможностями рекомендуется grep и Debian potato.
| | |
| |
| 7.126, Аноним (39), 19:58, 26/10/2025 [^] [^^] [^^^] [ответить]
| +/– |
Ну разве что для дебиичей, которые холодные данные хранят на ссд, может быть полезно такое поведение. Но к чему им быстрее, ведь, очевидно, ничем полезным они не занимаются?
| | |
|
| 6.133, Чтото знающий (?), 00:26, 27/10/2025 [^] [^^] [^^^] [ответить]
| +/– |
На реальное тестирование, а не умозрительное, которым вы или ваш единомышленник пытаетесь здесь заниматься. Потому что медленный диск вполне может работать быстрее при нескольких потоках по сравнению с одним. Как это возможно? Буферизация. Обычно ОС кеширует обращение к диску.
| | |
| |
| 7.136, Аноним (39), 00:42, 27/10/2025 [^] [^^] [^^^] [ответить]
| +/– |
То, что тебя интересует, называется упреждающее чтение (диск читает большими блоками и релевантные данные чудом могут оказаться в буфере), этим занимается прошивка диска и ОС тут никаким боком. На практике не поможет. Нет, ну, конечно, ситуация грепнуть несколько раз одни и те же данные (вместо того, чтобы правильно написать команду), вполне может случиться, тогда мультипоточный греп по кэшу может оказаться пропорционально быстрее. Во всех остальных случаях, операции медленнее. Между прочим, случайный доступ и на ссд весьма посредственную производительность демонстрирует, поэтому очень значительное ускорение просто невозможно.
| | |
|
|
|
|
|
| 2.60, freehck (ok), 19:05, 25/10/2025 [^] [^^] [^^^] [ответить]
| +/– |
 >>производительность некоторых утилит, например, по сравнению
> Осталось выяснить, за чей счёт банкет. Если ускорение не за счёт simd
> для каких-то угловых случаев, очевидно, новый вариант менее оптимален (впрочем, для
> когда на ржавчине довольно классически).
С учётом того, что у них задача -- сделать сравнение в свою пользу, бьюсь об заклад, что они сравнивали (условно) стоковый coreutils из какого-нибудь Debian, скомпилированного под amd64 для древнючих архитектур, и uutils, скомпилированный со всеми возможными и невозможными оптимизациями спецом под тестовую тачку.
| | |
| |
| 3.92, Чтото знающий (?), 02:08, 26/10/2025 [^] [^^] [^^^] [ответить]
| +/– | |
>С учётом того, что у них задача -- сделать сравнение в свою пользу
Зачем бы им заниматься подтасовками? Или вы по себе судите?
| | |
| |
| 4.107, Аноним (39), 09:20, 26/10/2025 [^] [^^] [^^^] [ответить]
| –1 +/– |
>>С учётом того, что у них задача -- сделать сравнение в свою пользу
> Зачем бы им заниматься подтасовками? Или вы по себе судите?
Ну, вот, автор мусл заявляет, что его либц значительно лучше и производительнее глибц примерно во всём, смотри брошюрки на сайте. Есть те, кто в это верят. А на практике, все мы знаем.
| | |
| 4.110, freehck (ok), 12:02, 26/10/2025 [^] [^^] [^^^] [ответить]
| +1 +/– | |
> Зачем бы им заниматься подтасовками?
А я их в этом не обвиняю. Подтасовка предполагает, что действие произведено с таковым умыслом. В данном же случае, причины могут быть куда более прозаичны.
Так, например, перед разработчиком стоит задача произвести сравнительный анализ своего софта и софта копируемого. Разработчик прекрасно знает свой софт, и как его выгоднее собрать, чтобы добиться лучшей производительности. Но при этом сравнительно слабо знает, как сделать аналогичное для копируемого софта: и главное -- у него нет никакого желания глубоко разбираться в этом. Вот так неосознанно и получаются такие результаты безо всяких подтасовок.
В большинстве подобных тестов впечатляющие результаты именно этим и обусловлены, так что пока не будет убедительно доказано обратного, это -- рабочая гипотеза, которую лично я буду считать истинной.
PS: Или вот ещё пример. Буквально в этом году прямо тут на опеннете в новости про Redis (или мб Valkey) был человек, который приводил результаты произведённых им бенчмарков, из которых следовало, что он якобы может выжать из Postgresql более 10k qps для запросов update-а одной и той же строки. Не смотря на то, что это невозможно в принципе, он искренне верил в то, что писал. Он на самом деле произвёл бенчмарки, он совершенно точно не совершал подтасовок. Просто он банально ошибся и закидывал базу update-ами рандомных строк, а не одной конкретной. Так что тесты -- штука такая: очень сильно зависят от того, кто их производит.
| | |
| |
| 5.134, Чтото знающий (?), 00:33, 27/10/2025 [^] [^^] [^^^] [ответить]
| +/– |
Ваша аналогия некорректна. Потому что какая-нибудь cut в реализации и использовании на несколько порядков проще, чем MySQL или PostgreSQL. Следовательно, возможностей накрутить тест в свою пользу гораздо меньше. Далее. Это ведь открытый проект. Если кто-то сомневается в результатах, вполне может провести аналогичные тесты и прийти уже с конкретными цифрами, а не умозрительными подозрениями, как это делаете вы или ваши единомышленники.
| | |
| |
| 6.150, freehck (ok), 10:45, 27/10/2025 [^] [^^] [^^^] [ответить]
| +1 +/– | |
> Если кто-то сомневается в результатах, вполне может провести аналогичные тесты и прийти уже с конкретными цифрами
Вот и сделайте, пожалуйста. Чужим-то временем, чай, легко распоряжаться, да?
| | |
|
|
|
|
|
| |
| 2.94, Чтото знающий (?), 02:12, 26/10/2025 [^] [^^] [^^^] [ответить]
| –2 +/– | |
1. Чем хотят, тем и занимаются. Вам какое дело до этого?
2. А что она доказала? Авторы утилит ведь показывают, что все тесты они пока не проходят. На это и номер версии намекает. Почему же вы считаете их виноватыми в том, что дистрособиратели Убунты решили взять в свой продукт сырое ПО?
| | |
| |
| 3.98, Аноним (17), 02:40, 26/10/2025 [^] [^^] [^^^] [ответить]
| +/– |
Авторы утилит и дистрособиратели Убунты - это одни и те же люди.
| | |
| |
| |
| 5.155, anonymous (??), 14:02, 27/10/2025 [^] [^^] [^^^] [ответить]
| +/– |
А что, эту кривую поделку уже в какой-то LTS затянули? Соболезную пострадавшим.
| | |
|
|
|
|
| 1.95, Чтото знающий (?), 02:14, 26/10/2025 [ответить] [﹢﹢﹢] [ · · · ]
| –5 +/– |
Ух, сколько борцунов с Rust набежало. Чуют недоброе, ох чуют, что скоро только легаси и останется им поддерживать.
| | |
| |
| 2.105, Аноним (105), 07:11, 26/10/2025 [^] [^^] [^^^] [ответить] | +/– | Когда примерно 15-ть лет назад выходили новости про пермиссивные аналоги GNU ути... большой текст свёрнут, показать | | |
| |
| 3.108, Аноним (108), 10:30, 26/10/2025 [^] [^^] [^^^] [ответить]
| +/– | |
> И не забывайте, что пермиссивщик легко превращается в проприетарщика.
Проприетарщик проприетарщику рознь. Одно дело когда это мегамонополисты, и совсем другое дело когда мелкий ремесленник Васян пытается заработать на хлеб закрытой тулзой.
Вся эта очередная классовая "борьба" - как раз и выгодна корпорастам, чтоб рабы даже не вздумали пойти в свободное плавание. Только харкор, только на галерах у воротил, которые заказывает музыку.
Я об этом уже много раз писал лет 20 назад. Но воз и ныне там.
Смысл в том, что не нужно кидаться в крайности.
| | |
| |
| 4.111, Аноним (-), 13:59, 26/10/2025 [^] [^^] [^^^] [ответить]
| +/– | |
Почему-то я вспомнил фильм 1998 года, "Честная куртизанка". Извини.
Понимаешь в чём дело когда возникает "борьба", не бывает оттенков серого, промежуточных состояний. Ты должен сделать чёткий выбор, на какой ты стороне. Когда травили Столлмана люди сделали чёткий выбор. И сделав чёткий выбор они спасли Столлмана.
Я не говорю о том, что "если ты не за нас, то ты против нас" - это аморальное высказывание. Я лишь говорю о том, что во время "борьбы" надо сделать чёткий выбор на какой ты стороне. И это правильно.
| | |
| |
| 5.114, Аноним (108), 16:11, 26/10/2025 [^] [^^] [^^^] [ответить]
| +/– |
Выбор простой. Нечего терять кроме собственных цепей. Хотя кому-то рабство нравится. Многие даже здесь нахваливают своих рабовладельцев.
| | |
|
|
| 3.138, Чтото знающий (?), 00:50, 27/10/2025 [^] [^^] [^^^] [ответить]
| –1 +/– | |
>На 2025 год уже нет, ни у никого нет сомнений в том, что корпорасты хотят максимально избавится копилефтного кода.
Реальность такова, что сколь-либо сложное ПО могут вытягивать только корпорации. Что ярко демонстрирует то же ядро Линукса,в котором около 88% кода пришло от корпораций. Поэтому их желание вполне понятно - кто девушку платит, тот её и танцует.
Но почему вы о корпорациях вспомнили? Речь же о языке программирования, а не типах лицензий.
| | |
| |
| 4.146, Аноним (108), 05:46, 27/10/2025 [^] [^^] [^^^] [ответить] | +/– | Просто некоторые товарищи до сих пор совершенно не подозревают в какую позу их п... большой текст свёрнут, показать | | |
| 4.147, Аноним (108), 06:25, 27/10/2025 [^] [^^] [^^^] [ответить]
| +1 +/– | |
> Но почему вы о корпорациях вспомнили?
Я заметил употребление термина "проприетарщина" с негативным оттенком.
> Речь же о языке программирования, а не типах лицензий.
Кстати да, и лицензия LGPL - не просто так создавалась. Она заточена под проприетарщину (при чём самим Столлманом). В том, что кто-то пробует заработать даже путём закрытия части кода - нет ничего плохого. Это, конечно, сообществом FSF не поощряется, но и не стоит забывать и то, что среднестатистический человек питается не только святым духом.
По поводу Растокостылей. Всё. Не о чем говорить. Баталии уже не актуальны после ChkTag. Если у фирмы (или отдельного кодера) годами складывались наработки на Си и Си++, то ты не переубедишь что-то менять, это архисложная и контр-продуктивная задача.
| | |
| |
| 5.151, Медведь (ok), 12:57, 27/10/2025 [^] [^^] [^^^] [ответить]
| +/– | |
> Баталии уже не актуальны после ChkTag.
Совершенно верно. Предвижу реакцию оппонентов: "Но у нас же гарантии compile time! А ChkTag просто убьет программу в рантайме!" Это так, но при этом все ошибки работы с памятью, от которых гарантирует раст, из критических, чреватых дырами в безопасности, внезапно становятся просто себе логическими ошибками, одними из многих возможных, в одном ряду с любыми другими ошибками, могущими кинуть панику в растовом рантайме.
Ждем выхода процессоров с ChkTag, но уже сейчас компетентные граждане сильно задумаются, стоит ли связываться с растом или просто подождать.
| | |
| |
| 6.153, Аноним (-), 13:29, 27/10/2025 [^] [^^] [^^^] [ответить] | +/– | Это ты сам с собой соглашаешься Я у тебя уже спрашивал в другой теме, почему ... большой текст свёрнут, показать | | |
| |
| 7.156, Медведь (ok), 14:04, 27/10/2025 [^] [^^] [^^^] [ответить]
| +/– | |
> Это ты сам с собой соглашаешься?))
Да, специально для тебя выхожу и захожу, выхожу и захожу.
> Я у тебя уже спрашивал в другой теме, почему если в АРМ
> эта штука уже 7 лет, то проблемы не исчезли.
> Ты как-то не заметил вопроса или слился 🤷🏻♂️
Если у тебя есть статистика по проблемам в софте собранном под ARM с поддержкой MTE, в студию!
> С чего вдруг? Если у тебя внезапно время от времени падает сервак,
> то тебе будет не очень весело искать кто попортил память.
Если сервак падает от паники в коде на раст, меня вряд ли утешит мысль, что зато это же паника на самом раст, практически святая паника! Да и просто ошибки в логике софта меня мало порадуют, скажу честно. Раст от них защищает?
> А еще выкинуть все старые серваки и купить новые.
Чего уж там, перестроить все серверные и проложить новые дороги к ним.
| | |
| |
| 8.164, Аноним (-), 16:28, 27/10/2025 [^] [^^] [^^^] [ответить] | +/– | Пффф, какие у тебя запросы Я ж спросил простой вопрос если МТЕ так крут, то за... большой текст свёрнут, показать | | |
| |
| |
| 10.168, Аноним (-), 17:29, 27/10/2025 [^] [^^] [^^^] [ответить] | +/– | О, вот это здравая мыcль У тебя есть выбор или твой код станет менее дырявым во... большой текст свёрнут, показать | | |
|
|
|
|
|
| 5.152, Аноним (-), 13:24, 27/10/2025 [^] [^^] [^^^] [ответить] | +/– | Но сам Столлман писал в Манифесте ГНУ, что люди программируют не ради денег, зар... большой текст свёрнут, показать | | |
| |
| 6.162, Аноним (162), 15:51, 27/10/2025 [^] [^^] [^^^] [ответить]
| +/– | |
> Напомню что а АРМ аналогичный механизм с 18-19 года. Поддержка уже давно добавлена в андроид. Но, по какой-то странной причине в, практически, 2026 году гугл продолжает...
Мыши плакали, кололись, но продолжали жрать кактус.
Гугл может себе позволить подобные эксперименты, к тому же месье́ знают толк в извращениях. Первый раз что ли? https://gcemetery.co
| | |
| |
| 7.163, Аноним (162), 15:57, 27/10/2025 [^] [^^] [^^^] [ответить]
| +/– | |
И вдогонку: https://killedbygoogle.com
Или может скажете принудительное внедрение Kotlin в андроиде было очень "умной" затеей? Когда традиционной Джавы хватало выше крыши. Все эти бессмысленные нагромождения, метания, погоня за хайпом и баззвордами по прихоти менеджеров-гуманитариев, беспорядок как дань моде - ни к чему хорошему не приведут в конечном итоге.
| | |
| 7.165, Аноним (-), 16:32, 27/10/2025 [^] [^^] [^^^] [ответить]
| +/– | |
> Мыши плакали, кололись, но продолжали жрать кактус.
Да-да, какой глупый гугл)
Мелкомягкие, амазон и прочие тоже?
> Гугл может себе позволить подобные эксперименты, к тому же месье́ знают толк в извращениях. Первый раз что ли? https://gcemetery.co
О, люблю эту ссылку.
Думаю половина проектов были объеденены или поглощены гугловскими творениями.
А тут речь про миллионы строк уже работающих в андроиде.
Ну и вишенка на торт - биндер в ядро линукс, который заменяет старый СИшный.
| | |
| |
| |
| 9.169, Аноним (-), 17:38, 27/10/2025 [^] [^^] [^^^] [ответить] | +/– | А кто говорит про безошибочность Тут речь про то, что если корпы что-то внедряю... большой текст свёрнут, показать | | |
| |
| 10.170, Аноним (162), 17:59, 27/10/2025 [^] [^^] [^^^] [ответить] | +/– | Вот с этого надо было начинать Но сути дела это не меняет Сколько раз не назов... большой текст свёрнут, показать | | |
|
|
|
|
|
|
| 4.154, Аноним (154), 13:50, 27/10/2025 [^] [^^] [^^^] [ответить]
| +/– | |
> ядро Линукса,в котором около 88% кода пришло от корпораций.
Забыл упомянуть, 88% лишнего кода. Линух застыл в нулевых, уже давно ничего фундаментального в ядро не добавляется. Идёт только бесконечное переписывание кроватей с языка на язык и их перестановка между кернел и юзер-спейсами.
| | |
|
|
| 2.109, Аноним (158), 11:55, 26/10/2025 [^] [^^] [^^^] [ответить]
| +2 +/– | |
> Чуют недоброе, ох чуют
А что тут чуять то если это недоброе в новостях.
То там отвалится, то там не обновляется.
А опыт начинания переписывания других проектов говорит о том, что они никогда НЕ МОГУТ полностью повторить оригинал из-за кривизны, которая ограничивает возможности разработки. А кривизна вызвана заточенностью на безопасной работе с памятью, а не удобстве поддерживания одного кода для множества архитектур с использованием множества разных библиотек и их версий.
| | |
| |
| 3.137, Чтото знающий (?), 00:45, 27/10/2025 [^] [^^] [^^^] [ответить]
| +/– | |
они никогда НЕ МОГУТ полностью повторить оригинал из-за кривизны этого самого оригинала
Поправил. Так, пожалуй, точнее будет.
Есть продукты на Rust, которые существенно превосходят оригинал. Например, ripgrep. Или pingora. Или zed.
Просто подобные проекты ведут не корпорации, как правило (pingora - исключение), а энтузиасты. Поэтому быстрого результата ожидать не приходится. Люди, ведь, в своё свободное время этим занимаются, ради удовольствия, а не чтобы конкретно вам угодить.
| | |
| |
| 4.160, Аноним (158), 15:01, 27/10/2025 [^] [^^] [^^^] [ответить]
| +1 +/– | |
> они никогда НЕ МОГУТ полностью повторить оригинал из-за кривизны этого самого оригинала
Вот совершенно не важно. Главное - что они принципиально НЕ МОГУТ.
> Есть продукты на Rust, которые существенно превосходят оригинал. Например, ripgrep. Или pingora. Или zed.
Два последних не видел. ripgrep видел. Явно сырая недоделка. Периодически валящаяся.
Плохой пример.
> Просто подобные проекты ведут не корпорации, как правило (pingora - исключение), а энтузиасты. > Поэтому быстрого результата ожидать не приходится. Люди, ведь, в своё свободное время этим занимаются, ради удовольствия, а не чтобы конкретно вам угодить.
Дело совершенно не в этом, а в том что это на порядки сложнее, и лечит это не собираются.
| | |
|
|
|
| 1.128, Аноним (128), 21:29, 26/10/2025 [ответить] [﹢﹢﹢] [ · · · ]
| +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
"
| | |
| |
| 2.139, Чтото знающий (?), 01:05, 27/10/2025 [^] [^^] [^^^] [ответить]
| –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
Зависит от конкретного проекта. То есть, это необязательно всегда так.
| | |
| |
| 3.176, Кошкажена (?), 23:06, 27/10/2025 [^] [^^] [^^^] [ответить]
| +/– | |
> Нет, Rust гораздо проще C++, чья спецификация занимает около полутора тысяч страниц.
А сколько занимает спецификация раста? А точно, ее же нет.
| | |
| 3.177, Кошкажена (?), 23:08, 27/10/2025 [^] [^^] [^^^] [ответить]
| +/– | |
> Часто хватает 5 минут, чтобы спросить у чата. В особо сложных случаях может растянуться на несколько дней. Но уж точно ни о каких месяцах речь не идёт.
А потом задаются вопросом откуда "уровень совместимости 83.91%".
| | |
|
| 2.140, Чтото знающий (?), 01:20, 27/10/2025 [^] [^^] [^^^] [ответить]
| +/– | |
Продолжение.
Автор статьи говорит о том, что 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"
Автор не знает о существовании Си, Ассемблера?
Резюмирую. Я бы не стал доверять статьям с подобными оценками, потому что или автор некомпетентен, или очень предвзят.
| | |
| |
| 3.149, Аноним (39), 10:04, 27/10/2025 [^] [^^] [^^^] [ответить]
| +1 +/– | |
Той сарказм неуместен, плюсы действительно позволяют и simd и zero-copy, и с куда меньшими затратами. К примеру, даже чтение данных в плюсах можно сделать значительно быстрее, чем в си, посредством пары небольших трюков с libc++.
А ассемблер непонятно каким боком приплетаешь, он может быть максимально быстрым, но вручную ты не оптимизируешь под каждый процессор (они каждый год новые со своими особенностями). Единственное, для чего он полезен, это simd. Про затраты на написание кода даже не будем.
| | |
|
|
|
