Опубликован релиз языка программирования Rust 1.91, основанного проектом Mozilla, но ныне развиваемого под покровительством независимой некоммерческой организации Rust Foundation. Язык сфокусирован на безопасной работе с памятью и предоставляет средства для достижения высокого параллелизма выполнения заданий, при этом обходясь без использования сборщика мусора и runtime (runtime сводится к базовой инициализации и сопровождению стандартной библиотеки)...Подробнее: https://www.opennet.dev/opennews/art.shtml?num=64149
Что за ABI такой: gnullvm?
Windows targets similar to *-pc-windows-gnu but using UCRT as the runtime and various LLVM tools/libraries instead of GCC/Binutils.
https://visualstudio.microsoft.com/ru/
ни с чем не совместимое нечто :)
Хороший язык для начинающих - этакий надувной круг-уточка, не дающий чайнику утонуть.
Хорошая шутка
Скорее, это бассейн, заполненный смолой, в которой предлагают плыть
во-во, особенно кто старых как рыба, да хоть в том же пыхе
> Хороший язык для начинающих - этакий надувной круг-уточка, не дающий чайнику утонуть.Вот только обычно инструментами "не дающими утонуть" пользуются профи.
Это чайник скажет "да тут всего щиток на ХЗ сколько вольт, я сейчас возьму дидовые пассатижи и всё поправлю".
А потом его аккуратно сметают веничком в пакет и выкидывают.Профи соблюдают ТБ и используют СИЗ: кольчужные перчатки хирургам, каски, очки и наушники строителям, две разнесенные кнопки прессовому оборудованию...
Чайники и бракоделы делают как попало, а потом C̶V̶E̶ получается фигня)
> Чайники и бракоделы делают как попало, а потом CVE получается фигня)это как в CVE-2025-62518 aka TARmageddon?
А что намекает на то, будто tar-это хороший формат?
Встроенного сжатия нет, расчитан изначально на запись на магнитных стримерах, 100500 вариантов формата, насильно объединенных во франкенштейна в попытке стандартизовать...
> Встроенного сжатия нетАга, и mp4 воспроизводить не умеет. Наверно потому что это архиватор, а не видеоплеер или компрессор.
> изначально на запись на магнитных стримерах
Какая разница что там было изначально?
> 100500 вариантов формата
Поменьше: по сути вам (растаманам) надо было реализовать только ustar и pax. Но вы и тут облажались. И, кстати, у сишников что-то не было такой проблемы с кучей форматов.
>> Встроенного сжатия нет
> Ага, и mp4 воспроизводить не умеет. Наверно потому что это архиватор, а не видеоплеер или компрессор.Чел, изначально было заявление, что tar - плохой формат. Архиватор, а не компрессор говоришь? Ну так подскажи, эксперт, как в твоем "хорошем" tar.gz получить список файлов (не говоря уж о том, чтобы извлечь один последний файл) в 10 GB архиве, не перечитывая-распаковывая при этом весь tar.gz?
Прекрасный формат, да. Прямо хрестоматийный пример тупиковости подхода Unix-way. Диды дизайнили!
Господи, и твоему же комментарию еще плюстки ставят! В очередной раз показывает уровень местных экспертов.
> Ну так подскажи, эксперт, как в твоем "хорошем" tar.gzПочему ты меня об этом спрашиваешь, если ты сам архив запаковал?
> Прекрасный формат, да. Прямо хрестоматийный пример тупиковости подхода Unix-way.
И зачем тогда растаманы пишут софт под Unix-like? Не умеешь - не берись. Вам всего-то надо было переписать (как обычно на расте) существующую реализацию.
> Диды дизайнили!
Диды и процессоры дизайнили, с которого пишет своё нытье.
> Господи, и твоему же комментарию еще плюстки ставят!
Кармадрочер чтоли?
> Какая разница что там было изначально?Намекну: ленты где-то с 1984 (DLT) имеют своё сжатие, а индекс для ускорения случайного доступа там не требуется, потому что случайного доступа нет.
> Ага, и mp4 воспроизводить не умеет. Наверно потому что это архиватор, а не видеоплеер или компрессор.
В разделении на компрессор и архиватор нет чего-то такого, чем стоит гордиться.
Противоположный путь выбрали не только в винде, но и в макоси (.sit, .xar, .aa), и в линуксовых ФС. Помимо очевидного, EROFS, SquashFS, DwarFS - по сути монтируемые архивы (в которых не реализовали функцию добавления файла ради простоты или по идеологическим причинам...).
Ну все как всегда -- этот мир нам не подходит, дайте другой, с правильным tar, рулеткой и стюардессами.
Встроенное сжатие зачем гвоздями прибивать? Для tar есть возможность выбора сжимальщиков: gz, bz2, lzma, xz, ...
Ой, да они там без встроенного сжатия не смогли два формата архивов реализовать, аж целую CVE создали. А прикинь если бы в tar'е было еще и встроенное сжатие? - была бы еще одна CVE как минимум
Всего одна CVE у растоманов в tar? Да, до Сишников им еще учиться и учиться:CVE-2025-45582: Directory traversal vulnerability in crafted TAR archives, potentially leading to file overwrites.
CVE-2022-48303: A heap-based buffer overflow in versions up to 1.34 that can allow for remote code execution.
CVE-2021-20193: Flaw found in src/list.c in versions 1.33 and earlier.
CVE-2019-9923: A NULL pointer dereference in pax_decode_header in versions before 1.32.
CVE-2018-20482: Mishandling of file shrinkage when using the --sparse option in versions through 1.30, which could lead to a denial of service.
CVE-2016-6321: Directory traversal vulnerability that can bypass protection mechanisms to write to arbitrary files, affecting versions 1.14 through 1.29.
CVE-2010-0624: A heap-based buffer overflow in the rmt_read__ function in versions prior to 1.23, potentially allowing remote code execution.
>[оверквотинг удален]
> CVE-2022-48303: A heap-based buffer overflow in versions up to 1.34 that can
> allow for remote code execution.
> CVE-2021-20193: Flaw found in src/list.c in versions 1.33 and earlier.
> CVE-2019-9923: A NULL pointer dereference in pax_decode_header in versions before 1.32.
> CVE-2018-20482: Mishandling of file shrinkage when using the --sparse option in versions
> through 1.30, which could lead to a denial of service.
> CVE-2016-6321: Directory traversal vulnerability that can bypass protection mechanisms
> to write to arbitrary files, affecting versions 1.14 through 1.29.
> CVE-2010-0624: A heap-based buffer overflow in the rmt_read__ function in versions prior
> to 1.23, potentially allowing remote code execution.Дак сишники пишут на небезопасном языке поэтому такое бывает. А растаманы то пишут на безопасном языке, а все равно CVE допускают.
Да и можно подумать если бы растаманы писали на Си, то не допускали бы ошибок? Растаман, пишущий на Си, допустил бы куда больше ошибок, чем сишник пишущий на Си.
Всего одну? Считаю, что отлично! А вот в GNU tar совсем все плохо с безопасностью, в свежем CVE за этот год опять относительные пути при распаковке не проверяли, и тут дело даже не в языке...
А нафига вообще контейнер в виде тара? Это лишняя сущность, которую надо просто выкинуть и никогда больше не вспоминать.
Права доступа и прочие атрибуты хранить. Кто так умеет ещё? RAA мог бы, но он поддерживает только метаданные NTFS.
*RAR
ZIP умеет.
> Встроенное сжатие зачем гвоздями прибивать?Чтобы не ампутировать индекс и повысить устойчивость к повреждениям. Это не мешает использовать внешний компрессор для особых случаев (тогда встроенное сжатие отключаем).
>> Чайники и бракоделы делают как попало, а потом CVE получается фигня)
> это как в CVE-2025-62518 aka TARmageddon?Нет, как CVE в ХОрг или ядре линукс).
Раст предотвращает и дает гарантии на конкретный список проблем.Ты же не будешь ныть что книпексовые клещи на 1000 вольт пробиваются на 10000?
Если вам нужно больше - то АДА или формальная верификация, если у вас хватит денег))
> Раст предотвращает и дает гарантии на конкретный список проблем.Вот когда на деле _реально_ предотвратит, тогда и приходите. А пока один булшит про безопастность.
>Вот когда на деле _реально_ предотвратит, тогда и приходите.Возьмите и начните писать аналогичную программу на си и на расте. Первая же ошибка компиляции - ура проблема поймана.
TARmageddon компилировался. И в Бубунте утили компилировались... Пришлось потом на ужасносишной старьё руками откатывать.
>TARmageddon компилировался.А там ошибок управления памятью почему-то нет. Логическая ошибка != управлению памятью.
>И в Бубунте утили компилировались...Ну так сама утилита на расте работала, не работала убунтовская обвязка.
> TARmageddon компилировался.Тем временем в gnu tar все еще (в 2025) путаются в относительных путях:
CVE-2025-45582: Directory traversal vulnerability in crafted TAR archives, potentially leading to file overwrites.
И снова: "компилируется -- значит работает!" Я смотрю, растуны оригинальностью не отличаются, исправно пересказывают рекламу. Парни, серебряных пуль не бывает, это вас обманули.
>И снова: "компилируется -- значит работает!"Удивительно, но факт.
>Парни, серебряных пуль не бывает, это вас обманули.Давайте ищите CVE, в которых проблема в любом управлении памятью: хоть висячий указатель, хоть двойное освобождение, хоть ещё что-то. Когда найдёте, тогда и приходите.
ЗЫ раст обещал снижение проблем управления памятью, а не абсолютно всех проблем сразу, но вот лично вы почему-то считаете, что раст должен магически решить абсолютно всё и сразу.
>> И снова: "компилируется -- значит работает!"
> Удивительно, но факт.
> ...
> раст обещал снижение проблем управления памятью, а не абсолютно всех проблем сразу,И эти две фразы в одном посте, а две мысли -- в одной голове...
>И эти две фразы в одном посте, а две мысли -- в одной голове...Я не пойму, вы что, ни разу код не писали? Те случаи, когда в си или питоне требуют отладки, а порой и всплывают спустя месяцы после релиза, находятся в расте сразу же после завершения компиляции. Вон в соседней теме в иксах баги из 1994 года правили. Или вы не понимаете, что чем меньше искать ошибок вручную, то тем лучше?
>>И эти две фразы в одном посте, а две мысли -- в одной голове...
> Я не пойму, вы что, ни разу код не писали?Конкретно этот воин - нет, не писал. Он же в предыдущих темах о Расте предлагал ошибки работы с памятью ловить при помощи юнит-тестов и интеграционного тестирования. А еще искренне недоумевал, почему borrow checker не помогает при работе с растовым Arc/Rc.
Это чтобы ты понимал уровень этого персонажа.
Компилируется значит работает? Неудивительно, почему столько проблем у uutils...
Ho ведь в GNU coreutils на порядки больше ошибок, особенно CVE...
> Ho ведь в GNU coreutils на порядки больше ошибок, особенно CVE...А в Линукс-ядре сколько дыр-то! Переходите на венду, там с растом будет идеал безопасности!
> Вот когда на деле _реально_ предотвратитВас в РГУ логике обучали? Утверждение «Х противоречит Y” (то есть предотвращает) доказывается математически, а не бытовыми примерами. А вот опровергается элементарно - достаточно 1 примера, когда не предотвратил. Примеры есть? Нету? До свидания.
А на СИ там бы еще за границу буфера вышли и обратились бы к освобождённой памяти, не забыл вызвать переполнение. А раст, да, плохой, не позволяет все это сделать, и потому тебе пришлось искать CVE с !логической! ошибкой (а раст то тут причем?) в реализации кривого формата.
Нет. Это остальные 9 миллиардов CVE в переполнением памяти/буфера/кучи/стэка.
Вы как всегда не различаете ошибк управления памятью и прочие уязвимости. Как и ожидалось от ненависников раста.
У программы есть два состояния: с ошибками и без ошибок.
>У программы есть два состояния: с ошибками и без ошибок.Но количество программ без ошибок будет куда больше, если запретить работу с сырыми указателями. Данный тезис вам не оспорить.
И как тогда компилятор написать? Или драйвер в ядре?
>И как тогда компилятор написать?Зачем вам для компилятора указатели?
>Или драйвер в ядре?Для драйвера придётся придётся написать какое-то количество unsafe кода, но это гораздо лучше, чем когда весь код - unsafe.
> Зачем вам для компилятора указатели?В смысле зачем? Потому что я не хочу все AST-дерево копировать при передачи в функцию. Открой хотя бы gcc и посмотри зачем там указатели.
>Потому что я не хочу все AST-дерево копировать при передачи в функцию.Эм. Если вы пишете на языке со сборщиком мусора, то у вас из коробки данные будут автоматически передаваться по ссылке, послностью прозрачно для вас. Если вы пишите на расте, то у вас будут самые обыкновенные ссылки, с контролем владения, которые разыменновывать надо руками. Если у вас c++, swift, и целой плеяде кучи других языков - у вас будут умные указатели. В 2025 году даже в исключительных случаях, вроде драйверов и операционных систем, указатели нужны только в исключительных случаях, когда по другому просто никак.
У программистов на раст слишком много проблем с прочими уязвимостями. Флагманский проект uutils столько ошибок имеет.
Но ведь такой же сишечный проект от gnu на порядки больше ошибок/CVE имеет. Неудобно как-то получилось...
>У программистов на раст слишком много проблем с прочими уязвимостями.Вы так говорите, словно от того, что проект писался бы на си, уязвимостей у него было бы меньше.
>Флагманский проект uutils столько ошибок имеет.Ошибки != уязвимости
Псс, смотри что я нашел:
додо...
это поэтому хоккеисты сначало играют в шлеме с Ме решёткой на все щи, потом со стекляшкой в половину, ну а профи уже и без стеклаа чем "дидовые" пасатижи хуже так плохи? нет предохранителя от попадания пальца?
Ну вообще-то профи давно заковали в броню, спонсоры команд больше не готовы платить миллионы за контракты, чтобы потом смотреть, как очередного "профессионала" уносят на носилках со льда, т.к. ему шайба попала в голову, т.к. он не надел шлем (да-да, таки без шлема больше на лед не пускают).
> кольчужные перчатки хирургамЧерт! В следующий раз операцию себе сам делаю.
Лучший язык программирования! Хай языков вроде си прошёл - Правительство США призывает отказаться от небищопасных языков.
А раст это навсегда! В отличии от других языков, которые ну выучили, может даже и лучше, но их хайп пройдёт и работу не найдёте! А если у вас проект - будите платить огромные деньги за переписывание, ибо кто поддерживать будет? Никто!
> А раст это навсегда!Не дай боже!
Если раст застрянет как дыряха на 40+ лет, то это будет просто ужасно.Раст должен будет заменить еще более безопасный язык, напр. с автоматической или хотя бы с дешевой верификацией, который будет не давать сделать хотя бы часть логических ошибок.
> Раст должен будет заменить еще более безопасный язык, напр. с автоматической или хотя бы с дешевой верификацией, который будет не давать сделать хотя бы часть логических ошибок.Не туда смотришь. Нужен язык умеющий работать с владениями и коллекциями (разными структурами).
rust не умеет от слова совсем. Фактически - это концепт. Что бы из него сделать пилотный язык - надо полностью переделывать.
>Что бы из него сделать пилотный язык - надо полностью переделывать.Ну так делайте, и про зависимые типы тоже не забудьте. А то критики раста почему-то до сих пор на сишке дырки плодят.
> язык, ..., который будет не давать сделать хотя бы часть логических ошибок.предположу, ИИ, после 10 лет эволюции, отменит эту необходимость в большинстве областей программирования. Он почти не будет ошибаться, будет "внимательный" и "всёзнающий" в этой "узкой" области. В том числе, по причине всё той же своей "внимательности", не будет и необходимости в безопасности по памяти, хотя я полностью за раст. Т.е. ИИ и на сишке сможет безопасно (во всех смыслах) писАть. Главное суметь ему объяснить, что тебе надо.
Смысл в языке, в котором без ИИ никуда?
Неосилятор? Без ИИшки в простом языке разобраться не можешь?
Конечно неосилятор. Иначе бы знал, что раст появился до ИИ.
Но он получился как будто бы специально для ИИ!
1. Ещё не подтянулись всякие ЛГБТшники со своим инклюзивным кодом - ИИшка учится на хороших примерах, написанных умными человеками
2. Строгий конпилястор - бьёт ИИ-шке по рукам в случае чегоТолько я этого не понил: "Добавлено lint-предупреждение "dangling_pointers_from_locals" "разыменование подобного указателя приводит к неопределённому поведению" - это же должен быть егог, а не вагнинг!?
> Только я этого не понил: "Добавлено lint-предупреждение "dangling_pointers_from_locals"Не удивительно.
> "разыменование подобного указателя приводит к неопределённому
> поведению" - это же должен быть егог, а не вагнинг!?Так там же другой ворниниг "a dangling pointer will be produced" - вы создаете dangling pointer, а не разыменоваваете.
Если ты его вернешь и никто не будет его использовать - то ничего страшного не случится.
А в safe коде ты просто не сможешь его разыменовать. Вот вообще))Значит тебе придется писать unsafe, а раз ты это сделал - то знаешь что делаешь.
А если не знаешь - то не пиши unsafe, пользуйся ссылкой, а не указателем.
И все это добро потом компилируется компилятором, написанным на плюсах?
> И все это добро потом компилируется компилятором, написанным на плюсах?Нет, компилируется компилятором написанным на раст. rustc называется.
В нем и происходят все валидации типов, проверки времени жизни, владения и тд.
На выходе получаем LLVM-IR.А вот LLVM-IR компилируется llvm в машинные коды.
Но llvm не единственный кодогенератор для раста.
Есть еще и Cranelift, написанный тоже на расте, которых хоть и отстает от llvm по количеству оптимизаций и поддерживаемых платформ, тоже неплохая альтернатива.ЗЫ: а вас не смущает что ядро и весь остальной код на си компилирует компилятор на с++?
Неужели на сишечке не осилили?))
Так не только я разобраться не могу. Повальное большинство программистов на раст тоже не может без ИИ в нем разобраться. Иначе почему в рейтингах раст ниже php?
Феноменальная логика. В коболе видимо даже ИИ не помогает, а чтобы писать на Форте нужен оракул, не иначе.
На коболе и фортране почти уже никто не пишет. Вы хотите сказать, что на раст тоже никто не пишет?
Раньше правительство США ратовало за язык Ада.
Ох, ну куда вы лезете? Оно за аду ратовало, потому что оно ее создало!
Без разницы кто его создал. В обоих случаях правительством был выбран некий язык, казавшийся серебрянной пулей в программировании.
> Правительство США призывает отказатьсянашли кому верить
ну не тебе же !
TIOBE врать не будет;) Интерес к Rust в поисковиках падает...
> TIOBE врать не будет;) Интерес к Rust в поисковиках падает...Это тот у которого Visual Basic на 7 месте и опережает Go?
А Delphi опереждает SQL?
Swift проигрывает Classic Visual Basic?Однозначно серьезный рейтинг)))
А вот если бы VB был на 7-м месте, опережая Go, Delphi опережал SQL, а Swift проигрывал CVB, но Раст был бы на первом месте, то ты бы первый орал, что рейтинг самый правильный. :)
> то ты бы первый орал, что рейтинг самый правильный.Нет конечно!
Я спросил бы "а где толпы веб-камак? ну всякие бессмертные ПХПшники и прочие жабаскриптеры?".
> А раст это навсегда!Боюсь что его ждет та же участь что и перловку, - вроде все хорошо и правильно, но семантика языка где в изобилии пвседо символы вместо человеческого... люди предпочтут нечто то более читаемое
Вы забыли пометку "сарказм" или "ирония" поставить, здесь это нужно - большинство тут социопаты с фобией общения и не выкупают иронию.
Не люблил раст, но вот сейчас сижу и смотрю почему течет flutterJNI на android и rust уже не кажется таким уж переусложненным на ровном месте. Если посмотреть на существующие распространенные решения, то rust там мог бы решить большой спектр проблем.
> почему течет flutterJNI на android и rust уже не кажется таким уж переусложненнымдак он раст написан
Interface between Flutter embedding's Java code and Flutter engine's C/C++ code.Раст во все поля.
C/C++ https://api.flutter.dev/javadoc/io/flutter/embedding/engine/...
А rust нифига не гарантирует отсутствие утечек памяти. Сюрприз! Меньше слушай хайповые крики растунов.
Так растеры это прямо говорят. Это сишники возмонили, что раст должен все проблемы решать.
> Так растеры это прямо говорят. Это сишники возмонили, что раст должен все проблемы решать.Это они прямо говорят, когда носом ткнешь. В самой новости: куча текста про "бизапаснасть", ни слова про возможные утечки.
> Не люблил раст, но вот сейчас сижу и смотрю почему течет flutterJNI на android и rust уже не кажется таким уж переусложненным на ровном месте.
Откуда бы у товарища такие умонастроения, уж не из-за рекламы ли раста из всех утюгов?
> Это они прямо говорят, когда носом ткнешь.Ну, мы подразумеваем, что для нормального хейта хейтеры хотя бы доку прочитать должны.
"Preventing memory leaks entirely is not one of Rust’s guarantees, meaning memory leaks are memory safe in Rust."
(doc.rust-lang.org/book/ch15-06-reference-cycles.html)> В самой новости: куча текста про "бизапаснасть", ни слова про возможные утечки.
Разумеется! Потому что утечки не дарят рут и не выполняют произвольный код :)
Максимум что можешь произойти - oomkiller сработает.
>В самой новости: куча текста про "бизапаснасть", ни слова про возможные утечки.Утечки памяти не нарушают безопасности памяти. Безопасность памяти - это невозможность данными одной структуры переписать вторую, так, чтобы это повлияло на семантику программы.
>Откуда бы у товарища такие умонастроения, уж не из-за рекламы ли раста из всех утюгов?А что вы у меня спрашиваете, у него самого спросите. Вы лучше скажите, откуда у вас столь искажённое представление о расте: когда вам прямо указывают на систему гарантий, вы галлюцинируете и видите то, чего нет.
Улыбнуло. В Rust реализуемо переполнение буфера cve-rs и другие уязвимости 100 проценто безопасно (без unsafe кода)
> Улыбнуло. В Rust реализуемо переполнение буфера cve-rs и другие уязвимости 100 проценто безопасно (без unsafe кода)Ага, та самая которую неделю ломали, и в итоге пришлось писать самописный null_mute, велосипедно-обфусцированный transmute и тд?
Так это отличный пример!
Вам придется хорошо напрячься, написать кучу кода, чтобы получить ошибку.ps кажется ваша методичка уже не актуальна
https://github.com/Speykious/cve-rs/issues/3
cve-rs это баг компилятора если что, да, представляете, даже в компиляторе написанном на расте оказывается есть баги!
Это не баг компилятора. Кто-то клоуна спустил методичку и они стали повторять. Это фундаментальная дыра в дизайне. Как и никакой фейкстатик до сих пор не починен и не будет никогда починен.Аналогично клоуны бегали и орали "ну просто неправильные типы написали", а потом когда спустили методичку про гаты начали рассказывать "щас как заживём". Всё это полнейшая чушь.
Модель в принципе не может проверять отношения лайфтаймов. К тому же в растомусоре не может быть "багов" потому что основная методичка была про верификацию и ноль багов. Тут нужно либо прошлые методички отменять и рассказывать что верификация и ноль багов это фейк, либо обтекать.К тому же странный баг который чинят уже второй десяток лет, а именно всё время существования этой поделки. Вернее его не чинят и не чинили. Просто кто-то выкатил cve-rs и позор был настолько масштабным, что пришлось хаками в "компиляторе" запрещать используемый там код.
Всмысле прямо говорят? Они прямо говорят обратное - раст это безопасный язык, позволяющий безопасно работать с памятью и избавляющий программист от ручного управления памятью. Нахера там утечки тогда нужны в расте? Это типа избавление от ручного управления памятью путем добавления утечек памяти? А хитро вы это придумали.
>Всмысле прямо говорят?С разморозкой. Берём первый попавшийся материал https://github.com/brson/rust-anthology/commits/master/src/m...
>Commits on Jun 12, 2016Материалу 9 полных лет, а вы об этом впервые слышите. Очень хороший уровень компетенции.
>Нахера там утечки тогда нужны в расте?Да будет вам известно, что даже языки с GC не гарантируют отсутствие утечек памяти.
>Это типа избавление от ручного управления памятью путем добавления утечек памяти?Да будет вам известно, что в си тоже есть утечки памяти. И утечки памяти от подхода в расте не добавляются.
>С разморозкой. Берём первый попавшийся материалЗачем мне брать какой-то материал. Очевидно что где-то там наверху никто не будет отрицать очевидное. В материал написано так же что и от гонок раст не спасает и не может спасать, но каждый адепт же об этом орёт?
Абсолютно плевать что и где написано важно то чем это является в реальности. 98% раст-адептов не знают что утечки проблемами не считаются.
>Да будет вам известно, что в си тоже есть утечки памяти. И утечки памяти от подхода в расте не добавляются.
Никакого "подхода раста" в природе не существует. Раст это ворованный огрызок цпп-семантики. Скоре более сишный cleanup aka defer. Но всё это так же огрызки цпп-семантики, потому что это пытаются обернуть в какие-то более связанные с временем жизни примитивы, а это именно цпп-семантика.
Раст же добавляет множество проблем с утечками, как и не с утечками. Просто потому что это убогий огрызок. Даже цпп их добавляет несмотря на то что это оригинальная куда более мощная модель, а не огрызок.
Банально если в цпп изначально думали о том делать со слабыми ссылками, где и как аллоцировать счётчики, то в расте просто наворовали огрызков. И спустя 10лет родили слабоссыльные костыли.Это без учёта захардкоженного глобального аллокатора(и то ворованного сишного) и прочих приключений.
> Абсолютно плевать что и где написано важно то чем это является в реальности. 98% раст-адептов не знают что утечки проблемами не считаются.Ты проводил опрос и собрал статистику?
Или просто решил наpыгать красивых чиселок, чтобы прикрыть свою убойищность?> Никакого "подхода раста" в природе не существует. Раст это ворованный огрызок цпп-семантики.
Хахаха, ну покажи где в крестах есть такие фичи, желательно в compile time.
А потом включи межушную пустоту и подумай зачем вот прям сейчас комитет лепит Safe C++, если в крестах оно уже должно работать)> Это без учёта захардкоженного глобального аллокатора(и то ворованного сишного) и прочих приключений.
О боже! Если где-то украли, то он в С++ пропал?
Или ты просто несешь чушъ как и пологается долбодятлам-растохейтерам?
>Ты проводил опрос и собрал статистику?Да. В любом случае её ненужно собирать достаточно посмотреть твоё позорище как ты ссылаешься на какой-то мусор, а не на статистику. Если ты это делаешь, то у тебя уже проблемы.
>Хахаха, ну покажи где в крестах есть такие фичи, желательно в compile time.
Какие фичи, клоун? raii? Ты хоть в букварик зайди почитай.
>А потом включи межушную пустоту и подумай зачем вот прям сейчас комитет лепит Safe C++, если в крестах оно уже должно работать)
Никакого safe в расте нет и уж тем более никакой комитет не лепит safe этот вброс уже давно разоблачили. Как можно лепить того чего нет? Ты вообще знаешь что такое комитет и как это работает? Не позорься.
>О боже! Если где-то украли, то он в С++ пропал?
Да, пропало. Погугли что такое авторство и то почему ты не можешь взять свойства чужого и выдать за свои. Ты не можешь написать фанфик и рассказывать "какие круты у меня персонажи" - это воровство.
>Или ты просто несешь чушъ как и пологается долбодятлам-растохейтерам?
Да зачем мне хейтить каких-то убогих нонеймов? Ты думаешь локальное анонимное трепло что-то из себя представляет? Нет. Ты просто пустое место, которые ничего не зная пытается прильнуть к струе. Авось тебя кто-то заметит.
> Да. В любом случае её ненужно собиратьПотому что ты просто болтливое угребище))
> Какие фичи, клоун? raii?
И raii тебе все проверит в компайлтайме и выдаст ошибку?
НИЧОСИ! Вот до чего фанатиков СИ и крестов, доводит злоупотребление веществами!!>>А потом включи межушную пустоту и подумай зачем вот прям сейчас комитет лепит Safe C++,
> Никакого safe в расте нетМалохольный, ты что читать не умеешь?
Написано же Safe C++, причем тут раст?> Как можно лепить того чего нет?
Пока нет. Поэтому комитет и лепит. Пока треснул на 2 враждующих лагеря.
Вот драфт из-за которого чуть ли не глотки друг-другу перегрызли.
safecpp.org/draft.html>>О боже! Если где-то украли, то он в С++ пропал?
> Да, пропало. Погугли что такое авторство и то почему ты не можешь взять свойства чужого и выдать за свои.Авторстово на идею? Вот это поворот!
А подскажи пункт лицензии которое это нарушает))Давно не попадались такие 🤡
>Зачем мне брать какой-то материал.Затем, что ты - классический неосилятор, из палаты мер и весов. Прибежал с набросом, а когда указали, что это общеизвестный факт, сразу же дал заднюю.
>98% раст-адептов не знают что утечки проблемами не считаются.А что сразу не 100%? Не стоит проецировать свою абслоютную некомпитетность на всех остальных.
Ещё раз, зачем мне о чём-то спорить с пустым местом? С каким-то анонимным треплом?>А что сразу не 100%? Не стоит проецировать свою абслоютную некомпитетность на всех остальных.
Скорее всего их будет ~100% просто я пощадил тебя. Как это доказать - заходим на ютуб и смотрим миллиарды видео про меморилики, смотрим миллионы статей про меморили. ЦА которых растосброд.
Ты посмотрел очередной видосик? Ты потому и анонимное трепло - боишься что-то делать с историей ведь как потом оправдываться. Посмотрел видосик и побежал "ой утечки не считают", хотя до этого бегал и сообщал другое.
Завтра видосики выйдут вы узнаете почему гонки работают. И будете так же орать. Я не видел ни одного растофанатика с мозгом. Вернее они есть, но каждый из них перестал быть растофанатиком. Либо перестанет быть в будущем.Это всё банальные свойства мироздания как и то, что никакой раст-фанатик кода на расте не пишет, а даже если пишет он просто ворует бабки на галере - это обычная скамина. Это не ситуация нормальной конкуренции.
carbon похоронит ржавчину, вот как только зарелизится так сразу!
> carbon похоронит ржавчину, вот как только зарелизится так сразу!Пфф, манямирок анонов такой маня)
Авторы carbonʼа сами пишут вот прям в описании проекта:
Existing modern languages already provide an excellent developer experience: Go, Swift, Kotlin, Rust, and many more. Developers that can use one of these existing languages should.
github.com/carbon-language/carbon-lang?tab=readme-ov-file#why-build-carbonБолее того, расширяют мысль
If you can use Rust, ignore Carbon
https://github.com/carbon-language/carbon-lang/blob/trunk/do...Что-то я им больше верю, чем твоим фантазиям.
Проблема с Карбоном что он сложный. Не менее сложный чем C++ и Rust. Почему первые версии Java и C# привлекли разработчиков ? Потому что были проще C++.
Java с идеей стирания типов в генериках небезопасна на что сверху может накладываться динамическое разрешение методов. Все есть Object
И это всегда будет так? Появились новые идеи в программировании - делаем новый язык?Завтра какая-то новая идея возникнет, опять новый язык появится?
Я понимаю, конечно, развитие не остановить. Но ведь мы не выкидываем русский язык из-за того что появились новые идеи? Да, мы проводим реформы (принимаем новые стандарты). Но блин, никому не приходит в голову, русский язык устарел, давайте теперь говорить на иксигрекзетовом...
Надо развивать существующие а не плодить новые.
От чего мы все запихиваем в наш любимый C++
> И это всегда будет так? Появились новые идеи в программировании - делаем новый язык?Ну... так обычно и происходит)
> Завтра какая-то новая идея возникнет, опять новый язык появится?
Зависит от...
Например если у нас древний ЯП, который писали в прошлом тысячелетии, адепты которого молятся на "ОБРАТНУЮ СОВМЕСТИМОСТЬ!!!" и поддержку железок из 70х, то нет.
Они упрутся, скажут зачем нам прогресс, мы можем в луже и палкой копалкой работать.Второй вариант - сделать версию ЯП, которая ломает совместимость.
Но это тоже не очень, тк народ будет их путать.> Я понимаю, конечно, развитие не остановить. Но ведь мы не выкидываем русский язык из-за того что появились новые идеи?
Зато выкидываем старые стандарты производства или строительства.
> Да, мы проводим реформы (принимаем новые стандарты). Но блин, никому не приходит в голову, русский язык устарел, давайте теперь говорить на иксигрекзетовом...
Чего? В 18 и 56 году хорошо так поменяли.
Выкинули кучу букв Ѣ, Ѳ, І. Убрали из окончаний Ъ. Изменили грамматику.
По сути получили новый "русскоподобный язык".Те кто жил в те смутные времена даже ругались:
"Зачем все эти искажения? Для чего это умопомрачающее снижение? Кому нужна эта смута в мысли и в языковом творчестве?? Ответ может быть только один: всё это нужно врагам национальной России. Им; именно им, и только им." - Иван Александрович Ильин> Надо развивать существующие а не плодить новые.
А если не хотят развивать?
Если держатся за священную корову "я могу скомпилять для 8008!!"
Если не хотя учиться новому?
Проще не спорить и создать новый ЯП.
Сразу видно человека, который больше хелловорлдов ничего не писал.
>> Да, мы проводим реформы (принимаем новые стандарты). Но блин, никому не приходит в голову, русский язык устарел, давайте теперь говорить на иксигрекзетовом...
> Чего? В 18 и 56 году хорошо так поменяли.
> Выкинули кучу букв Ѣ, Ѳ, І. Убрали из окончаний Ъ. Изменили грамматику.
> По сути получили новый "русскоподобный язык".В смысле? Мы не получили "русскоподобный язык", мы говорим на русском языке. Он видоизменяется со временем, поэтому приходится стандарты подгонять под современность.
Да, есть в нём какие-то неудобные моменты и проблемы, исключения, неоднозначности, существенные отличия с разговорномым и т.п. Да, он не самый распространённый в мире.
Понятно, что аналогия не полная, фактически каждый из нас является сотворцом языка и может придумать новое слово или конструкцию, которое лет через 200 может попасть в толковый словарь.
>> Надо развивать существующие а не плодить новые.
> А если не хотят развивать?Кто не хочет? Покажите мне этого человека.
> Если держатся за священную корову "я могу скомпилять для 8008!!"
Рано или поздно придётся отказаться от этого.
>> По сути получили новый "русскоподобный язык".
> В смысле? Мы не получили "русскоподобный язык", мы говорим на русском языке.Неа!
Язык настолько покромсали и переделали, что от старого остались только какие-то общие структуры.
Как сейчас говорят "СИ подобный синтаксис"))ru.wikipedia.org/wiki/%D0%A0%D1%83%D1%81%D1%81%D0%BA%D0%B0%D1%8F_%D0%B4%D0%BE%D1%80%D0%B5%D1%84%D0%BE%D1%80%D0%BC%D0%B5%D0%BD%D0%BD%D0%B0%D1%8F_%D0%BE%D1%80%D1%84%D0%BE%D0%B3%D1%80%D0%B0%D1%84%D0%B8%D1%8F
> Он видоизменяется со временем, поэтому приходится стандарты подгонять под современность.
Его видоизменили буквально за год.
Причем насильно, через монополию напечатную продукцию.
ru.wikipedia.org/wiki/%D0%A0%D0%B5%D1%84%D0%BE%D1%80%D0%BC%D0%B0_%D1%80%D1%83%D1%81%D1%81%D0%BA%D0%BE%D0%B9_%D0%BE%D1%80%D1%84%D0%BE%D0%B3%D1%80%D0%B0%D1%84%D0%B8%D0%B8_1918_%D0%B3%D0%BE%D0%B4%D0%B0> Понятно, что аналогия не полная, фактически каждый из нас является сотворцом языка и может придумать новое слово или конструкцию, которое лет через 200 может попасть в толковый словарь.
Ну попробуйте прочитать, а тем более написать (по правилам!)
въ смꙑслѣ? мꙑ не полѫчили "роусскопѫдобнꙑи ѩꙁꙑкъ" мꙑ говоримъ на роусскомъ ѩꙁꙑкѣ. ѻнъ видоиꙁменѧѥтсѧ со врѣменемъ поѥтомоу приходитсѧ стандартꙑ пѫдгонѧть пѫдъ соврѣменность.
да ѥсть въ немъ какꙑѥ-то неоудобнꙑѥ моментꙑ и проблемꙑ исключенїꙗ неѻдноꙁначности сѫщественнꙑѥ ѿличїꙗ съ раꙁговорномꙑмъ и т.п. да ѻнъ не самꙑи распространеннꙑи въ мире.
понѧтно что ꙗналогꙑа не полнаꙗ фактическꙑ каждꙑи иꙁъ насъ ꙗвлѧѥтсѧ сотворцомъ ѩꙁꙑка и можетъ придоумать новоѥ слово или констроукцїю котраѥ лѣтъ чрѣꙁъ 200 можетъ пѫпасть въ толковꙑи словарь.> Кто не хочет? Покажите мне этого человека.
Коммитет С?
> Рано или поздно придётся отказаться от этого.
Ага.
И проще заменить ЯП, чем лепить горбатого до стены.
>Ну попробуйте прочитать, а тем более написать (по правилам!)Осталось слова только заменить, а то у вас современные слова в старой грамматике.
> Язык настолько покромсали и переделали, что от старого остались только какие-то общие структуры. Как сейчас говорят "СИ подобный синтаксис"))Да пожалуйста, кромсайте, переделывайте. Только не вводите ещё два десятка новых.
> И проще заменить ЯП, чем лепить горбатого до стены.
Заменить - пожалуйста, вводить два десятка языков параллельно - нет.
>Мы не получили "русскоподобный язык", мы говорим на русском языке.Нет. Возьмите дореволюционные учебники, научите по ним ученика, чтобы он ставил "ъ" в конце слов, и так далее, а потом дайте ему сдать ЕГЭ. Если уж на то пошло, то говорим мы на языке образца какого-то года, но сами эти образцы между собой несовместимы.
В качестве хорошего примера возьмите китайский. У вас есть 中文（简体）и 中文（繁體). Как не сложно догадаться, зная один вы мало что поймёте в другом.
>Кто не хочет? Покажите мне этого человека.Посмотрите местных: линтеры не нужны, концепция владения не нужна, и так далее.
> Нет.Да. Это русский язык, немного изменённый, но всё ещё русский.
> сами эти образцы между собой несовместимы.
Совместимость понятие растяжимое. Дореформенные тексты вполне можно прочитать даже без подготовки.
Но речь не о том, сильно изменили или не сильно, пусть даже изменили сильно. Речь о том что не ввели его параллельно, а заместили им старый язык, как новый стандарт С++ заменяет старый.
> Дореформенные тексты вполне можно прочитать даже без подготовкиА писать?
Сможете без ошибок расставить все яти?> Речь о том что не ввели его параллельно,
Так в момент внедрения оставалось куча литературы, напмсанной на старом варианте.
И ее читали.Да и для программинга такое невозможно, разве что ходить по домам и бить палками по рукам, чтобы не писали на старье.
> а заместили им старый язык, как новый стандарт С++ заменяет старый.
А он не заменяет. Он дополняет.
Можно продолжать пользоваться старым. Вон ядро до 22го года было на С89. И что?Если нужно "расширять старый", то почему у нас не Алгол-2025?
Почему появился СИ, хотя был B?
Зачем сделали С++, если можно было расширить СИшку?
> А писать?без тренировки не смогу, разумеется
> Зачем сделали С++, если можно было расширить СИшку?
Не можно, а нужно. Как раз с++ и есть по-большому счёту расширение с. В 99% случаев сишный код компилируется в с++.
Когда-то надо выкидывать совместимость со старым кодом. Это произойдёт рано или поздно и с с++ (или же его самого выкинут как алгол). Вопрос только, когда и как. Объявить какие-то конструкции устаревшими и перестать их поддерживать лет через какой-то разумный срок - почему нет? Да, это не так быстро, как сляпать новый язык, но это правильный, разумный, эволюционный путь развития.
>В 99% случаев сишный код компилируется в с++.Слова эксперта. Сишный код компилируется во что угодно - в ассемблер, промежуточное представление, во что угодно, только не в c++.
>Объявить какие-то конструкции устаревшимиНу и чем это будет лучше раста?
>и перестать их поддерживать лет через какой-то разумный срок - почему нет?Разумный срок - это какой? У вас будет всё равно тот же самый раст, только лет на сто позже.
> Разумный срок - это какой? У вас будет всё равно тот же
> самый раст, только лет на сто позже.Да, позже, но всё старое спокойно перекочует в этот новый "раст".
> без тренировки не смогу, разумеетсяНу, т.е придется брать учебни и учиться.
На учебние будет написанно Церковный Русский Язык.
А я мог бы вспомнить старославянский."Не лѣполи ны бяшетъ, братіе, начяти старыми словесы трудныхъ повѣстій о пълку Игоревѣ, Игоря Святъславлича!"
От чо такое "лѣполи ны бяшетъ"?А ведь его же тоже можно было расширать, а не делать отдельно русский, украинский, белорусский?))
> Не можно, а нужно. Как раз с++ и есть по-большому счёту расширение с. В 99% случаев сишный код компилируется в с++.
Что-то меня терзают смутные сомнения про 99%.
Скомпилироваться оно то сможет, а вот корректно работать...
Посмотри сколько ерраты пишут для разных версий компиляторов, да еще и для разных версий языков.> Когда-то надо выкидывать совместимость со старым кодом. Это произойдёт рано или поздно и с с++ (или же его самого выкинут как алгол). Вопрос только, когда и как.
Ну как мы наблюдаем прямо сейчас.
Примерно так же было и 20 лет назад. И 30 тоже.> Объявить какие-то конструкции устаревшими и перестать их поддерживать лет через какой-то разумный срок - почему нет? Да, это не так быстро, как сляпать новый язык,
Ну думаю что добавить deprecated это сложнее чем сделать новый язык.
Как добавить боров в СИ, чтобы не сломать совместимость?
А если коммитет не хочет?> но это правильный, разумный, эволюционный путь развития.
Эволюционный - появление нового более приспособленного ̶в̶и̶д̶а̶ языка программирования.
Выпуск новой модели авто, самолета или даже компа, у которой несовместимые детали, разьемы или двигатели вас же не смущает?
> Ну, т.е придется брать учебни и учиться.А зачем мне учиться писать на устаревшем языке?
>> Не можно, а нужно. Как раз с++ и есть по-большому счёту расширение с. В 99% случаев сишный код компилируется в с++.
> Что-то меня терзают смутные сомнения про 99%.
> Скомпилироваться оно то сможет, а вот корректно работать...В том и дело, что нормально работает, проверено, с минимальной обработкой напильником. И это правильный подход.
> Ну думаю что добавить deprecated это сложнее чем сделать новый язык.
Сложнее конечно, но это правильный путь.
>Да. Это русский язык, немного изменённый, но всё ещё русский.У вас не будет дискретного перехода, типа говорили не на русском, а потом вдруг раз и на русском. Но вот историки и лингвисты, описывая тот старый язык будут называть его по другому, вроде древнерусского и так далее.
>Совместимость понятие растяжимое.Вы просто не чувствуете изменений. Возьмём для примера шутку
>мальчик склеил модель в клубеЕсли бы вас изолировали от изменений в языке, вы бы поняли данную фразу иначе. И таких фраз, которые приобретают новый смысл с течением времени становится всё больше. В какой-то момент вы перестанете понимать язык настолько сильно, что он для вас будет звучать как иностранный.
>Дореформенные тексты вполне можно прочитать даже без подготовки.Прочитать - понятие растяжимое. Как только меняется алфавит, так сразу же меняется и чтение. А алфавит менялся не раз и не два, в том числе и количество букв. В частности, беглый поиск говорит о том, что букву й как удаляли, так и восстанавливали. А это значит, что правильно прочитать этот символ вы попросту не в состоянии, как минимум не зная дату публикации текста. Просто у лингвистов нет ни системы контроля версий ни даже такого понятия, вот они и не пишут русский язык 1780, русский язык 2025. А то, что у них начало названия совпадает "русский язык", так это так, совпадение.
>Речь о том что не ввели его параллельно, а заместили им старый языкКак вы себе это представляете? Вот возьмут и внедрят самую малость - запретят нулевые указатели. И всё - почти весь код, за исключение совсем hello world перестал собираться.
>как новый стандарт С++ заменяет старый.В C++ стандарты не заменяют друг друга, они просто расширяют язык. Вам никто не запретит писать так, как будь-то на дворе 90-ые - без умных указателей и так далее.
> Как вы себе это представляете? Вот возьмут и внедрят самую малость - запретят нулевые указатели. И всё - почти весь код, за исключение совсем hello world перестал собираться.Всё просто по-моему. Допустим по какой-то причине решили запретить и вместо нулевого указателя теперь надо использовать nullptr. Дальше нулевые указатели продолжают работать какое-то время, на протяжении X стандартов (где Х = 1, 2, 4, 10 в зависимости от тяжести изменений и трудности поддержки), но выдаётся предупреждение. После этого в очередном новом стандарте старый код перестаёт компилироваться и выдаёт ошибку.
> В C++ стандарты не заменяют друг друга, они просто расширяют язык.
Никто не запрещает в новом стандарте объявить какую-то конструкцию устаревшей.
> Дальше нулевые указатели продолжают работать какое-то время, на протяжении X стандартов (где Х = 1, 2, 4, 10 в зависимости от тяжести изменений и трудности поддержки), но выдаётся предупреждение.Предупреждение затыкается, как было в ядре, где попытались сдалеть "warning == error".
Оказалось тонных дидовых хаков отвалились.> После этого в очередном новом стандарте старый код перестаёт компилироваться и выдаёт ошибку.
Народ сидит на старом.
Те кто решил пользоваться новым приходится спотыкаться о старые костыли, которые еще поддерживаются.> Никто не запрещает в новом стандарте объявить какую-то конструкцию устаревшей.
Конечно.
Но если у тебя ломается вся логика языка, то так будет очень сложно.
> Предупреждение затыкается, как было в ядре, где попытались сдалеть "warning == error".
> Оказалось тонных дидовых хаков отвалились.Для тонны хаков нужны соответствующие решения в стиле нового стандарта. Это займёт, разумеется, какое-то время. Возможно даже потребуется доработка стандарта.
>> После этого в очередном новом стандарте старый код перестаёт компилироваться и выдаёт ошибку.
> Народ сидит на старом.Когда-то придётся переходить на новый (когда поддержку старого стандарта выкинут). Тут уж хозяин-барин. Есть однако большая разница между "подправить проблемные места" и "перейти на принципиально другой язык".
> Те кто решил пользоваться новым приходится спотыкаться о старые костыли, которые еще
> поддерживаются.Да, так сейчас в с++, к сожалению. Потому что старые костыли надо всё-таки постепенно выкидывать. А в современном с++ всё ещё bool при вызове функции автоматически конвертируется во float...
>> Никто не запрещает в новом стандарте объявить какую-то конструкцию устаревшей.
> Но если у тебя ломается вся логика языка, то так будет очень
> сложно.Так никто и не обещал, что будет просто. Но это всё равно проще, чем переход на совершенно другой язык.
>Допустим по какой-то причине решили запретить и вместо нулевого указателя теперь надо использовать nullptrНет. У вас будет option.
>в зависимости от тяжести изменений и трудности поддержкиУ вас поломались абсолютно все сишные проекты.
>но выдаётся предупреждениеВы масштабы себе представляете? Ядро Linux - более 40 000 000 строк кода. Допустим, каждая 1 000 строка имеет проблему, у вас 40 000 предупреждений. Всё, вы утонули в этих предупреждениях, поскольку ну даже 10 ошибок в коде, никак не связанных с этой проблемой просто потеряются во всех этих 40 000-ах. Вам нужно прямо сейчас бросать всё и идти чинить эти предупреждения, так как иначе, если вы будете их откладывать, то никогда не закончите. Далее, у вас появились гигиенические макросы, держите ещё 40 000 предупреждений. Это не говоря уже о том, что какие-то моменты автоматически доказать нельзя, и код придётся переписывать целиком.
>в зависимости от тяжести изменений и трудности поддержкиНу дадут вам лет 50 на исправление ошибок, а сейчас как жить?
>[оверквотинг удален]
> 000 предупреждений. Всё, вы утонули в этих предупреждениях, поскольку ну даже
> 10 ошибок в коде, никак не связанных с этой проблемой просто
> потеряются во всех этих 40 000-ах. Вам нужно прямо сейчас бросать
> всё и идти чинить эти предупреждения, так как иначе, если вы
> будете их откладывать, то никогда не закончите. Далее, у вас появились
> гигиенические макросы, держите ещё 40 000 предупреждений. Это не говоря уже
> о том, что какие-то моменты автоматически доказать нельзя, и код придётся
> переписывать целиком.
>>в зависимости от тяжести изменений и трудности поддержки
> Ну дадут вам лет 50 на исправление ошибок, а сейчас как жить?А зачем исправлять сразу все 40000000 строк? Включил для одного модуля (файла), исправил, включил для другого - исправил... Делов-то... Какие-то высосанные из пальца проблемы придумываешь.
В любом случае это гораздо легче и проще, чем переписывать на совершенно другом языке.
>А зачем исправлять сразу все 40000000 строк?Не сразу, а когда? Через сто лет? Вы понимаете, что либо эти строки исправляются здесь и сейчас, либо откладываются на неопределённое будущее?
>Включил для одного модуля (файла), исправил, включил для другого - исправил... Делов-то...Именно такой подход и используют программисты на расте.
>Какие-то высосанные из пальца проблемы придумываешь.Вы видимо пропустили, что это исправление только одной проблемы. А проблем много. И переписывать по частям вам придётся почти весь код.
>В любом случае это гораздо легче и проще, чем переписывать на совершенно другом языке.Вы всё равно будете переписывать. Либо на C 2.0, чуть лучшем чем текущий C, либо на rust. Поскольку с текузими технологиями можно без особых проблем сконвертировать почти всё ядро на unsafe rust, и тогда сишных файлов либо не останется совсем, либо доли процента, полностью автоматически. Но вот этот вот unsafe rust всё равно придётся переписывать вручную.
> Совместимость понятие растяжимое. Дореформенные тексты вполне можно прочитать даже без
> подготовки.О какой реформе идёт речь? Их было сильно больше чем та, что была в начале 20-го века.
Попробуйте почитать тексты середины, а ещё лучше начала тысячелетия, сильно удивитесь, как русский язык, живой язык (!), менялся со временем.
А выпячивание псевдорусскости оставьте показушникам, стремящимся на её основании заявить о воображаемом величии.
>> Совместимость понятие растяжимое. Дореформенные тексты вполне можно прочитать даже без
>> подготовки.
> О какой реформе идёт речь? Их было сильно больше чем та, что
> была в начале 20-го века.Это нормально, когда возникают небольшие трудности с пониманием текста написанного 100 лет назад. Такой темп изменения вполне приемлем. Сравни теперь с языками программирования.
Желание выкинуть один популярнейший язык и заменить его новым, в котором ОДНА какая-то идея реализована лучше это просто безумие...
Но если с++-ный комитет не будет решать насущные проблемы, то так и будет.
>Сравни теперь с языками программирования.У языков программирования стремительный прогресс. Вас же не смущает, что ламповые радиоприёмники уже не продаются в магазинах?
>Но если с++-ный комитет не будет решать насущные проблемы, то так и будет.Они заложники крестов, поскольку решение проблем автоматически означает выкидывания существующего кода.
> можем в луже и палкой копалкой работать.нуда нуда, совочком с пласиковым ведёрком куда приятнее куличики лепить
> В 18 и 56 году хорошо так поменяли.
> Выкинули кучу букв Ѣ, Ѳ, І. Убрали из окончаний Ъ. Изменили грамматику.Ну это в начала 20-го века, а в 1956 что русском меняли?
Посмотрите на изменения с 1918 по 1956gramota.ru/journal/stati/yazykovaya-politika/reformy-russkoy-orfografii
wikiwand.com/ru/articles/Орфография_русского_языка_до_1956_года
Русский язык - плохой пример . Над тем что "отцам и детям" требуется переводчик - шутили ещё в 70х . А многие ли могут перевести на современный выражение "не мытьём , так катаньем" ? Справка: мытьё - сбор налогов , катанье - телесные и финансовые наказания .
Согласен, возвращаемся на Lisp и Fortran! Ну ладно, можно еще COBOL для хипстеров, которые любят все новое!
> И это всегда будет так? Появились новые идеи в программировании - делаем новый язык?Да. В чём проблема?
> Я понимаю, конечно, развитие не остановить. Но ведь мы не выкидываем русский язык из-за того что появились новые идеи?
Доброе утро, русский давно выкинули.
> Надо развивать существующие а не плодить новые.
Ну вот C++ развивают, и кому от этого хорошо?
> И это всегда будет так? Появились новые идеи в программировании - делаем новый язык?Вот как раз относительно новых идей в программировании -- раст обречен на застой и стагнацию.
Во-первых, добавить в ядро языка новые идеи и концепции или очень сложно, или невозможно: а вдруг они нарушат "бизапаснасть"? а кто будет допиливать боровчекер? а насколько еще более тормозным он станет после изменений? Даже довольно простая идея со специализацией генериков висит в nightly много лет и провисит еще столько же.
Во-вторых, растуны, радостно повизгивая, ломанулись в критически важный код, не обратив внимания, что это ловушка, в которую попал, увы, C: "что? доработать язык под новые идеи? а кто гарантирует, что старый код не сломается? нет уж, вот у нас тут архимегаважный пакетик собирается -- и пусть его собирается, никто экспериментировать не будет! в этих ваших закорючках пока разберешься, ишь чо удумали!"
О! Какие люди! Медведь вылез из берлоги.
А чего не посетили тему про очередные дырени в дидовых иксах?
Неужели так него сказать было, а тут есть?))
Пффф, от это забористый копиум)> Во-первых, добавить в ядро языка новые идеи и концепции или очень сложно, или невозможно:
С чего вдруг? Открой ченджлоги для edition и увидь, что постоянно что-то меняется.
> а кто будет допиливать боровчекер?
Те же кто пишет язык сейчас.
> а насколько еще более тормозным он станет после изменений?
Вот сделают и проверят.
Скомпилированный код всё равно будет быстрый, а для разработчика можно и машинку побыстрее.
(Да всякие б0мжи-гентушники будут ныть, но всем пофиг)> Даже довольно простая идея со специализацией генериков висит в nightly много лет и провисит еще столько же.
А она готовая? Или автор хочет чтобы за него сделали? Если ты про 1210, то там почти нифига не сделано, суда по чекам.
Если мало кому нужны такие "фичи", то оно будет висеть еще очень долго.> Во-вторых, растуны, радостно повизгивая, ломанулись в критически важный код, не обратив внимания, что это ловушка, в которую попал, увы,
Судя по теме визжат только СИшники, которым что-то не нравится)
> доработать язык под новые идеи? а кто гарантирует, что старый код не сломается?
Концепция Edition и гарантирует.
> нет уж, вот у нас тут архимегаважный пакетик собирается -- и пусть его собирается, никто экспериментировать не будет!
Ну так сидите на старых версиях, чего бухтеть?
> в этих ваших закорючках пока разберешься, ишь чо удумали!"
Такое может сказать только неосилятор, которые раст в жизни не видел.
>С чего вдруг? Открой ченджлоги для edition и увидь, что постоянно что-то меняется.Что, так сложно было сделать язык, который бы сразу мог закрыть необходимые потребности? У других языков как-то получается обходиться без частых обновлений.
>Скомпилированный код всё равно будет быстрый, а для разработчика можно и машинку побыстрее.А на Си и код быстрый, и компиляция, а ошибки можно статическим анализатором найти.
>Судя по теме визжат только СИшники, которым что-то не нравится)Неработоспособность кода на раст не нравится. Какое мнение будет у человека, который решил попробовать установить убунту впервые, а в ней не работают обновления?
> Какое мнение будет у человекаЯ думаю, что он скажет нахир я связался этим убунрастом, говорил Вася, ставь нормальную ось - Виндовс и не выпендривайся. Я я дурак не послушал его...
>У других языков как-то получается обходиться без частых обновлений.У других - это у каких? Может быть у питона?
>А на Си и код быстрый, и компиляцияОчень быстрая, да
Опубликован набор патчей, ускоряющих сборку ядра Linux на 50-80% - https://www.opennet.dev/opennews/art.shtml?num=56449
>а ошибки можно статическим анализатором найти.Ну вот возьмите и найдите. Почему до сих пор не нашли?
>Какое мнение будет у человека, который решил попробовать установить убунту впервыеЧеловек установил убунту, а мнение будет о расте.
>У других - это у каких?С++
>Опубликован набор патчей, ускоряющих сборку ядра Linux на 50-80%Добавят еще раста и станет на 50%-80% медленнее (на самом деле больше).
>Почему до сих пор не нашли?Регулярно находят.
>Человек установил убунту, а мнение будет о расте.Будет плохое мнение о Линукс в целом, а все из-за дыр в коде на раст.
>>Опубликован набор патчей, ускоряющих сборку ядра Linux на 50-80%
> Добавят еще раста и станет на 50%-80% медленнее (на самом деле больше).Вранье.
Вон в ядро добавили биндер для андроида.
opennet.ru/opennews/art.shtml?num=64092И что?
Кода получилось даже меньше, скорость не пострадала.> Будет плохое мнение о Линукс в целом, а все из-за дыр в коде на раст.
Но дыр станет меньше.
Просто по причине, что так написать не позволят автоматические проверки.
>И что?
>Кода получилось даже меньше, скорость не пострадала.Я про скорость компиляции, если что.
>Но дыр станет меньше.
>Просто по причине, что так написать не позволят автоматические проверки.Дыр касательно памяти может быть и будет меньше, а вот касательно логики работы будет больше. Кто просил их добавлять новые в uutils?
Ты бы хоть разобрался в чем проблема была в uutils, прежде чем набрасывать.
Они использовали какой-то флаг, который используется исключительно в гнутых утилитах. Причем этот флаг был добавлен за месяц до релиза убунты, но они не обновили свою версию.
Но виноваты конечно растеры))> Кто просил их добавлять новые в uutils?
Да куча причин.
Дыры обычных гнутых утилит.
Раковая лицуха.
>С++Ага, и выбрали язык с UB, отвратительным временем компиляции и колосальной сложностью в освоении
>Добавят еще раста и станет на 50%-80% медленнее (на самом деле больше).Ну разумеется никаких доказательств этому у вас нет.
>Регулярно находят.Старые находят, новые добавляют.
>а все из-за дыр в коде на растОчень ловко вы ошибку(а не дыру) в убунте записали в дыру раста. А давайте ещё сишные ошибки туда же засунем?
> Концепция Edition и гарантирует.А растики смешные. Сам сообразишь, насколько гарантии поддержки старых editions и их совместимости относительно совместной линковки "вдохновляют" разработчиков компилятора вносить даже самые расчудесные улучшения в язык? А когда этих editions станет не 4-5, а 10? 20?
> Сам сообразишь, насколько гарантии поддержки старых editions и их совместимости относительно совместной линковки "вдохновляют" разработчиков компилятора вносить даже самые расчудесные улучшения в язык?Может ты не будешь трепать языком как помелом, а просто приведешь пример(ы)?
Думаю какого-то сообщения от разработчика "ой, у вас тут Editionʼы? Не не буду добавлять свою убер фичу!" будет достаточно.> А когда этих editions станет не 4-5, а 10? 20?
От когда станет, тогда и поговрим.
Пока разработка идет, фичи добавляются.
20 Edition по 3 года каждый... ты думаешь прожить еще лет 60?
Боюсь что ты, что я до этого не доживем.
Многие вещи висят годами нестабильными не потому что есть какие-то технические ограничения, а потому что не понято вообще нужно ли это тащить в язык.Те же специализации темплейтов в плюсах настолько сложные и непредсказуемые, с кучей правил и мелких факторов, что зачастую лучше бы их и не было. Уже десять лет в расте живут без специализаций дженериков и всем нормально. Хочешь другую реализацию — ну создай еще одну функцию с новым именем. Зато явно будет видно, что в коде вызывается.
>И это всегда будет так? Появились новые идеи в программировании - делаем новый язык?Это всегда так было. Вы новые идеи к старым языкам либо не прикрутите вообще, либо через огромную кучу костылей.
>Завтра какая-то новая идея возникнет, опять новый язык появится?Совершенно верно.
>Но ведь мы не выкидываем русский язык из-за того что появились новые идеи?Какие новые идеи? Между си и растом - фундаментальная разница: концепция владения, алгебраические типы данных, гигиенические макросы и так далее.
>Да, мы проводим реформы (принимаем новые стандарты)Нам нужна потеря совместимости со старым кодом. Если в C++23 до сих пор можно жонглировать указателями, то это обязательно кто-то сделает и попортит память.
>Надо развивать существующие а не плодить новые.Как только условный с/c++ потеряют обратную совместимость, то получим ещё один раст, ничуть не лучше текущего.
> Нам нужна потеря совместимости со старым кодом. Если в C++23 до сих
> пор можно жонглировать указателями, то это обязательно кто-то сделает и попортит
> память.Согласен.
> Как только условный с/c++ потеряют обратную совместимость, то получим ещё один раст,
> ничуть не лучше текущего.Ну и прекрасно.
Реализовывать идеи в виде нового языка - это нормально.А вот начинать его всюду пропихивать, в т.ч. в прекрасно существующие проекты на других языках, и переписывать всё подряд на своём самом лутшем языке - это уже нездоровое.
> А вот начинать его всюду пропихивать, в т.ч. в прекрасно существующие проекты на других языках,А это уже закрещено?
К создателям проекта приходят с предложением. Они могут принять или нет.
Никакого пропихивания.Да и никто не может запретить переписать любой софт на другой ЯП.
Сколько там было версий emacs на разных языках от разных создателей?> и переписывать всё подряд на своём самом лутшем языке -
Напомню что СИ был создан для того, чтобы переписать unix.
ПЕРЕПИСАТЬ, тк оно уже было и работало.> это уже нездоровое.
Только в твоих фантазиях)
Серьезыне организации, как например разработчики ядра уже оценили достоинства новых подходов.
Корпорации уже массово используют.
> Реализовывать идеи в виде нового языка - это нормально.
> А вот начинать его всюду пропихивать, в т.ч. в прекрасно существующие проекты на других языках, и переписывать всё подряд на своём самом лутшем языке - это уже нездоровое.С этим полностью согласен. Конечно, без проверки пихать какую-то новую идею типа borrow в с++ было бы неправильно. Конечно сначала надо её обкатать это где-то, новая идея должна доказать свою полезность, проявить себя во всей красе... Если идея себя зарекомендует с лучшей стороны, то её внедрят все вокруг со временем (или сдохнут). Надеюсь всё же на то что внедрят... Но основания для опасений есть, потому что с++ очень долго был застывшим языком и не развивался, накопив изрядную долю проблем, которые не решены и по сей день.
> Но ведь мы не выкидываем русский язык из-за того что появились новые идеи?Поэтому
- в C++ и D хорошая совместимость с C.
- языков для JVM или .NET сильно больше одного
- JS продолжают развивать
- TS строят поверх JS
- питону уже 34 года
- к питону прикручивают аннотации
- живёт идея, что из питона можно сделать что угодно (sympy, jax, triton)
- мейнстримная функциональщина успешно проникает в живые языки, независимо от их возраста (pattern matching в Java 17, лямбды в C++11)Как видно, поступательное развитие вполне реально, но иногда дешевле оказывается "весь мир насилья мы разрушим: до основанья, а затем..."
>Методы работы с памятью в Rust избавляют разработчика от ошибок при манипулировании указателями и защищают от проблем, возникающих из-за низкоуровневой работы с памятьюНе избавляют.
избавляют
Только от очень небольшого списка, а этого недостаточно.
Достаточно, чтобы избавиться от 70% проблем C/C++. Гугл с Майкрософтом приводили статистику.
Если бы раст помог избавиться от всех проблем работы с памятью, но это не так.
> Только от очень небольшого спискаТолько этот список генерирует наибольший список _опасных_ проблем. Т.е. даже не то правило "20/80", а наверное все "5/95" получается.
fn f() -> *const u8 {
let x = 0;
&x
}чесногря читая о безопасном языке раст думал, что подобные конструкции на нём компилироваться в принципе не должны. а тут они в версии 2.91 выдали предупреждение. мдя. и сколько ещё подобного "безопасного" на расте можно написать?
>чесногря читая о безопасном языке раст думал, что подобные конструкции на нём компилироваться в принципе не должны.Вы путаете указатели и ссылки. С вашим уровнем знаний вам на си и крестах писать противопоказано
>и сколько ещё подобного "безопасного" на расте можно написать?В том, что вы возвратите указатель нет ничего страшного. А для разыменновывания указателей нужен unsafe. А unsafe писать без особой необходимости попросту нельзя.
> В том, что вы возвратите указатель нет ничего страшного. А для разыменновывания указателей нужен unsafe.Т.е. вон то - safe код? Но ведь реально ошибка не по месту разыменования, получается, всё это время пропаганда врала что якобы нужно внимательно проверять только unsafe блоки а во всём остальном коде ошибок с памятью быть не может?
> нужно внимательно проверять только unsafe блоки а во всём остальном коде ошибок с памятью быть не можетДа. Именно так.
включите немного голову, пока указатель не разыменован есть ли разница что за адрес в нем?
>а во всём остальном коде ошибок с памятью быть не может?Безусловно.
>нужно внимательно проверять только unsafe блокиСовершенно верно. Вы не сможете разыменновать в safe блоке указатель.
>Но ведь реально ошибка не по месту разыменованияСлушайте, а вы что, реально не понимаете разницу между указателем и ссылкой? По умолчанию, программист на rust использует ссылки - они висячими не бывают. Программист может безопасно превратить любую ссылку в указатель, от этого ничего плохого не будет. А вот разыменновывание указателя - это вещь опасная, и каждый раз, когда программист это делает, он принимает риск на себя. Как только вы видите в коде на rust блок unsafe, вы должны сразу же задать вопрос - а зачем он здесь есть? Если же блок действительно нужен, то следом вы должны проверить, что все приходящие в него данные полностью корректны. Указатели нужны только для особых, исключительных случаев.
>всё это времяЕсли вы не заметили, в статье приведён один единственный частный случай, как можно получить висячий указатель, но по факту их гораздо больше. Нет абсолютно никакого смысла гоняться за каждым таким случаем, поскольку как только вы пишите unsafe, вы подразумеваете, что знаете, что делаете. Просто не пишите unsafe, ни разу.
> В том, что вы возвратите указатель нет ничего страшного.Т.е. созданая на стеке локальная переменная изчезнет при выходе из функции, а возвращенный указатель на нее где-то там всё еще может "безопастно" указывать на... что?
>а возвращенный указатель на нее где-то там всё еще может "безопастно" указывать на... что?Указатель на то и указатель, что для него не осуществляется никаких проверок. Хотите проверок - берите ссылку. Поскольку выход из функции, это не единственная причина, по которой указаетль может стать висячим.
> чесногря читая о безопасном языке раст думал, что подобные конструкции на нём компилироваться в принципе не должны.Это raw-указатели. Они всегда идут без каких-либо гарантий. Поэтому любая разадресация raw-указателя -- это unsafe операция. Но присвоение raw-указателю значения -- это вполне себе safe операция, потому что она не лезет в память.
Вот если ты попытаешься вернуть ссылку:
fn f() -> &u8 {
let x = 0;
&x
}то ты получишь ошибку о том, что время жизни x меньше чем время жизни ссылки на него.
Просто не надо трогать unsafe, и всё будет хорошо.
Какая-то минорщина с обновлением линтера. Где фичи?
> Где фичи?Как где - вон тебе на два экрана мелким шрифтиком подвезли "новых шт@6ильных" закорючек, иди зубри.
И так раз в неделю, а то немодным и немолодежным окажешься.
К чему такие мелкие выпуски? Это какой-то майлстоун или как? Вот завтра выйдет новая версия - в ней можно ли будет указать для компиляции любую предыдущую вплоть до 0.01?
И в то же время часть пакетов всегда требует ночную экспериментальную сборку.
Пишиьте письма разработчикам пакетов.
Точно так же они погут использовать С23.AOSP например позволяет использовать Edition 2015, 2018, и 2021.
Вот прям в доке записано.
>Пишиьте письма разработчикам пакетов.Точно так же они погут использовать С23.
Зачем? Они делом заняты, а не переписыванием. Выбрали нужную версию и с ней работают, а обновляться будут при необходимости.
Значит у авторов пакетов тоже была необходимость использовать найтли.
Они же лучше разбираются чего им надо.
Вы потребитель, а они создатели.
Максимау что вы можете - не пользоваться этим пакетом.
> Значит у авторов пакетов тоже была необходимость использовать найтли.В большинстве случаев ни разу. Просто это хобби проекты авторы которых сидят на ночнушках. Ни на чём другом не проверяют.
Правильно! Я же об этом и говорю.
Это хобби проект, его делают для себя.
Делают так, как они хотят в удобном для них окружении. Может им просто хочется попробовать новые функции.Это и есть - "достаточная необходимость" использовать найтли.
То что вы взяли такой пакет, это ваши личные трудности.
> crates in one edition *must* seamlessly interoperate with those compiled with other editions
Ты походу не догнал вопрос... Речь не про какие-то там кря-кря, а про компилятор.
Rust отличный язык для написания софта где требуется работа в реальном времени без сборщика мусора, к примеру пишем софт аи модуля автоматического наведения дрона на двигатели самолетов, собственно для сбития вражеских транспортных, и не только, самолетов, то есть дрон сам может находить взлетающую цель, наводится на двигатели, ну а дальше в полезной нагрузке дрона просто стальной брусок, который весело попадает прямо в движок. Несколько таких дронов почти гарантированно сбивают самолет на начальном этапе взлета, и все благодаря Rust + ИИ, компьютерному зрению и так далее, даже оператор дрона не нужен, надо лишь заранее разместить дрон и дать когда требуется указание на взлет.
> в полезной нагрузке дрона просто стальной брусокНу раз в нагрузке стальной брусок, то да -- только rust, однозначно. Какой же стальной брусок без rust? Разве что наждачкой начищать каждый день, особенно в агрессивном климате.
Это не будет работать, т.к. раст предоставляет гарантии безопасности использования, а эта затея выглядит опасно.
брусок утечет из-за oomkiller
Интересно, а подойдет rust - как первый язык программирования? Да и действия насильственного характера с borrow checker пугают. Не будет ли это напрасной потерей времени и сил?
>Интересно, а подойдет rust - как первый язык программирования?А вам зачем, что вы собираетесь делать?
>А вам зачем, что вы собираетесь делать?А с какой целью вы интересуетесь? Вам это знать не нужно.
Думаю нет.
Т.к он сразу подразумевает понимание сложных концепций.
Для первого ЯП нужно что-то простое, что позволит освоить алгоритмы и структуры данных.
> Для первого ЯП нужно что-то простое, что позволит освоить алгоритмы и структуры данных.Basic ! No, PowerBasic ! Хотя не, Повер уже был довольно мощной штучкой, лучше в руки детям не давать :)
Дело не в языке программирования. Просто занимайся тем что лично тебе кажется интересным. Если прёт от Раста - занимайся Растом, если не прёт - лучше им не занимайся. Главное глаза должны гореть.
К сожалению, для "горящих глаз" - возраст совсем не подходящий. Меня больше интересует вопрос соотношение времени написания кода к его отладке в сравнении с тем же С и С++.
Времени написания кода больше чем на с/с++ и иногда существенно.
Особенно если не продумал архитектуру и взаимодействие компонент, то придется много переписывать и не получиться "х-к, х-к и в прод", потому что оно просто не скомпилируется.
Для геймдева подходит так себе.Зато нет бессонных ночей с поиском "а кто же испортил память на проде когда меркурий был ретроградным"
Это самое главное, что мне и хотелось узнать. Благодарю! Значит, связка Python/C++ - будет наилучшим возможным решением.
А да ты ленивый программист! Ну так бы сразу и сказал бы, типа я ленивый! А то у людей спрашиаешь, типа интересен Rust. Да не интересен тебе Rust! Тебе надо чтобы всё легко было.
Чем проще, тем лучше. Прототипирование на Python, с последующим переписыванием на С++.
> Чем проще, тем лучше.
> С++Ты то ли тролль, то ли тебя ждет много интересных открытий.
>Чем проще, тем лучше.Ну так берите си, тогда без питона прототипировать будете. Зачем лишний раз переписывать?
> Ну так берите си, тогда без питона прототипировать будете. Зачем лишний раз переписывать?И начать с реализации String-типа потому что в недоязыке такого нету из коробки?
А потом плавно переходить к поддержке юникода.
Примерно через год, можно будет посмотреть в сторону работы с сетью.
И тд))
>И начать с реализации String-типа потому что в недоязыке такого нету из коробки?Так вы слона не продадите. Человек хотел простой язык - я ему и советую простой. А то пока всякие питоны с моржовыми операторами выучит, а потом ещё кресты учить. Писать будет быстро, ну а время отладки его не пугает.
По вашему выходит, что Rust придуман, чтобы программист страдал? Столько страданий, а язык допускает висячие сырые указатели. Просто предупреждение, которое можно и проигнорировать ради дела. )
Nim - простота Python, сборка мусора, производительность C/C++, трансляция в C++, C, JavaScript, и WebAssembly
> сборка мусораОпциональная. На выбор разные gc, а так же счётчики ссылок. Arc/orc могут работать (и это подтверждено на практике) на микроконтроллерах, даже таких дохлых как avr.
Можно вообще отключить сборщик и работать руками. И стандартная библиотека от этого не пострадает.
Посмотрите реализацию сортировки вставками на каждом языке и вам станет понятно, на чем программировать проще и быстрее.
Смотря какого кода.Ну вот например, сразу готовься к написанию кучи boilerplate, ибо каждый трейт имплементируется с 0, переиспользование реализаций практически никакое, исключая методы с дефолтной реализацией в трейтах.
Вместо наследования -- исключительно композиция: Truck будет владеть Car, а не наследовать от него. Ничто не мешает ему владеть хоть десятком Car.
Делегирование реализации методов вложенному объекту -- только явное: если Car и Truck имплементят трейт Vehicle, то Truck должен явно реализовать каждый метод из Vehicle, даже если он сводится к простому вызову такого же метода у Car. Ну или обмазываемся макросами.
Полиморфизм -- исключительно через трейты.
То есть если предметная область подразумевает иерархическую модель сущностей, то абзац.
Да, отсутствие нормального наследования - это весомый недостаток.
> Да, отсутствие нормального наследованияС каких это пор наследование в стиле C++ начало считаться нормальным?
> С каких это пор наследование в стиле C++ начало считаться нормальным?Уточка увидила наследование как в с++ первым и теперь считает что это единстванное верное наследование :)
> Уточка увидила наследование как в с++ первым и теперь считает что это единстванное верное наследование :)... завопили адепты языка, где наследования реализации нет совсем, ни в каком виде. Ну покажите в расте ООП как в smalltalk, или что вы там считаете классикой ООП.
>> Уточка увидила наследование как в с++ первым
> Ну покажите в расте ООП как в smalltalk, или что вы там считаете классикой ООП.Чел, иди проспись. Ты сам заливал про ООП именно в том виде, которое оно есть в C++, а теперь вдруг запел про Smalltalk и какую-то "классику ООП". Ты из нейронки бред копипастишь, или как это объяснить?
Да хоть какое-то ООП покажи уже в этом своем убогом расте, дятел. Какая на фиг разница, говорю я про ООП в стиле C++ или smalltalk, если в твоем жалком недоязычке нет ни того ни другого.Внимание, сейчас растуны начнут вопить, что в коране... ой, в расте есть все что нужно, а если чего-то в расте нет, то оно и не нужно.
и что? помогло твое ООП С++ в ядро попасть? А?
так что, знай свое место !
> и что? помогло твое ООП С++ в ядро попасть? А?
> так что, знай свое место !На Linux свет клином не сошелся, в ряде ОС компоненты ядра написаны на С++, а, к примеру, BeOS|Haiku так и вообще целиком на C++ и отлично себя чувствует. Так что сиди там у себя на коврике под дверью и не отсвечивай.
> а, к примеру, BeOS|Haiku так и вообще целиком на C++ и отлично себя чувствует.Настолько отлично, что никому нафиг не нужна)
Ты бы еще более марнинальных маргиналов привел в пример.
> Ты бы еще более марнинальных маргиналов привел в пример.Ну раз ты просишь -- Windows NT. ЕМНИП, графическая подсистема и ряд сервисов там активно используют C++.
По поводу маргинальных примеров: как полагаешь, что показательнее: написать практически всё ядро haiku на C++ или полтора нерабочих драйвера в ядре Linux -- на рже?
Да, и не забудь сравнить haiku с redox -- если haiku маргинальщина, то как назвать это ржавоподелие я даже не знаю.
Зачем ты споришь, если ты не программист? Это же видно
А, пошли финальные аргументы... Завидую твоему зрению -- видишь то, чего нет. По сути вопроса есть что сказать?
>если в твоем жалком недоязычке нет ни того ни другого.Вот интересно, а многоуважаемый эксперт не знает, что существует целая куча языков без ООП? Haskell, SML, Go, C, Lua и так далее?
>в расте есть все что нужно, а если чего-то в расте нет, то оно и не нужно.У ООП есть недостатки, и протаскивать всюду ООП излишне.
>если в твоем жалком недоязычке нет ни того ни другого.Если вам вдруг действительно нужно именно ООП, то вы можете реализовать его в стиле Lua или JS. Как минимум можно реализовать что-то вроде этого(пусть настоящие растовики предложат вариант получше):
struct Animal {
my_type : String,
say : fn (&Box<Animal>) -> (),
say_type : fn (&Box<Animal>) -> ()
}fn new_animal() -> Box<Animal> {
Box::new(
Animal {
my_type: String::from("Animal"),
say : |_a : &Box<Animal>| {
println!("Couldn't say");
},
say_type: |a : &Box<Animal>| { println!("{}", a.my_type) }
}
)
}fn new_cat() -> Box<Animal> {
let a = new_animal();
Box::new(
Animal {
my_type: String::from("Cat"),
say : |_a : &Box<Animal>| {
println!("Meo");
},
..*a
}
)
}fn main() {
let a = new_animal();
(a.say_type)(&a);
(a.say)(&a);
let c = new_cat();
(c.say_type)(&c);
(c.say)(&c);
}Вот просто удивительно, как легко и просто мы взяли и унаследовали say_type.
>я про ООП в стиле C++То-то же в C++ изобретаютс вякие CRTP.
Короче говоря, очередной плач неосилятора.
> Truck будет владеть Car, а не наследовать от него.Господи! Гуру ООП в треде!
Есть ли хоть что-то в чем ты разбираешься вообще?
Растуны такие растуны. Когда возразить по сути нечего, начинают разговор в духе гопников: "А ты кто такой?" Фу таким быть!
При чем тут раст и растуны, ты примитивнейшую иерархию классов даже для примера описать не смог, а ведешь себя будто что-то понимаешь.
> Когда возразить по сути нечего, начинают разговорЧел, по сути ти написал чистый бред "Truck будет владеть Car, а не наследовать от него" - что тут возражать, если ты сам расписался в своем уровне экспертизы?
Подойдет. И вообще, новичкам советуют для начала вообще не париться с lifetime. То есть, .clone() везде, Rc/Arc, а потом, как освоишься, можно и оптимизировать.
>Подойдет.Одежда должна подойти. С ЯП это так не работает.
На С++ учат сразу использовать умные указатели и семантику перемещений, а в раст наоборот учат не использовать его фичи, потому что сложно и непонятно.
> На С++ учат сразу использовать умные указатели и семантику перемещений,И продолжают пложить CVEшки.
Даже всякие костыли в виде MiraclePTR или Safe C++ пытаются делать, но выходит не очень> а в раст наоборот учат не использовать его фичи, потому что
C++ так и остается дырявым.
И UBшным.
И что за CVE с умными указателями? Покажите.
> И что за CVE с умными указателями?CVE-2024-5839 напр. MiraclePtr bypass due to PtrCount overflow
Но с ними другие проблемы - они потребляют ресурсы. Даже тут новость была opennet.ru/60482
"Потребление памяти основным процессом браузера при применении MiraclePtr увеличивается на 5.5-8% в сборках для настольных систем". И они защищают в основном от use-after-free.
Это велосипед от гугла, а нормальный умный указатель из стандартной библиотеки.
Не будет. В отличии от дырявого ты сразу будешь учиться писать код правильно.
Поэтому учись на Python.
Неиронично да.
Ну скорее всего да, и это фактически единственный верный способ его понять.
Нет. Не подойдёт. Лучше начать с книги "Structure and Interpretation of Computer Programs".
Мда, пока в других сферах специалисты с каждой итерацией стараются как-то упростить себе работу, программисты все делают наоборот. Мало того, что нужно разбираться в бизнес-логике, так еще и в синтаксисе ржавого. Грядет коллапс разработки ПО!
> стараются как-то упростить себе работуДа, напр. сделать так, чтобы за владением следил компилятор, а не разработчик.
Wait, oh shi...> так еще и в синтаксисе ржавого
Плюсовики смотрят на это утверждение с недоумением
> Грядет коллапс разработки ПО!
Так давно уже.
С момента когда на переносимом ассемблере, созданном для быстрого портирования ядра на 10к строк на другую архитектуру, начали писать код на десятки миллионов строк. Но все также нужно было контролировать ручками. А внимание программистов внезапно не резиновое.
А что у плюсовиков? Вот только необычным было применение <..> для параметров шаблонов, когда их добаввили. Но это было уж давно, все уже привыкли. И ничего экстравагантного в синтаксисе с тех пор не добавилось.
>Плюсовики смотрят на это утверждение с недоумениемС недоумением, потому что сделать синтаксис хуже C++ нужно было суметь.
>сделать синтаксис хуже C++ нужно было суметьСначала было прилично. То есть не хотели. Но потом... одно за другое, и имеем:
<pre>
template<typename T> requires requires (T x) { x + x; }
</pre>Вот зачем там двойной requires, я уже никогда не пойму (потому что потерял к C++ всякий интерес).
Одно ограничивает тип, второе возвращает булево значение. Отделите второе в концепт:)
Типичная ситуация. Мы видим альтернативы? Видим описание проблемы? Видим проблему? Нет. Жалкий наброс.Давай я тебе научу как это делается. Есть цпп-синтаксис с <>-скобками, который использует правктически любой язык. И вот там `foo<bar>` это базовый синтаксис. Раст не смог это родить и потому там `foo::<bar>`. Сравнение есть, эквивалетный код есть. Позор есть.
Что же набрасывает этот персонаж? Там нет никакого двойного requires. А даже если бы был, то к чему это? Ты можешь показать альтернативный синтаксис? Альтернативую реализацию? А её нет. С чем ты синтаксис сравнивал?Такого синтаксиса в принципе нет requires не может существовать сам по себе. Ему кто-то сказал про двойной и он нелепо побежал генерировать чушь. Невежество твоё второе имя, а какие-то сказки про интерес - оправдания. Ты не можешь в базовую логику. Да и в принципе программировать не оубчен потому как в примере написана полнейшая ахинея. Даже вне относительного того что ты не знаешь что такое requires.
В реальности же requires это часть декларации, предикат. Каким образом ты на его место запишешь второй, если это совершенно иное? Убрать его нельзя потому что `requires !requires` и прочее.
Наверное сложно жить когда человек не можето сознать омонимы. Это му ещё в детсаде учат. Ты ушлышал в детстве ел ель и обнулился?
```
x = requires{}
requires x
```Второе requires это просто выражение. Очевидно что ты его можешь подставить куда угодно в том числе под предикат. Претензия в чём? В том что не сделали сахарок? Ну так ! тебя бы тоже обнулило. Тебе сложно от того что у них одинаковое название? Причём тут синтаксис?
Ты от `{foo: foo{}}` тоже обнулишься?
Да не трясись ты так.
Так вот, похоже, что это AI за него всюду топит. Чтобы человека из сферы программинга вытеснить поскорее.
Ага, свет клином сошелся у кодеров на этих Си,Раст. Остальное либо ругать не за что,либо просто нечего. D
> Ага, свет клином сошелся у кодеров на этих Си,Раст. Остальное либо ругать не за что,либо просто нечего. DА остальные тут причем?
У всяких пихонов и жабаскриптов своя ниша.
У шишарпов и джавы - тоже своя.А СИшка и Раст играют на одном поле, даже в одном ядре.
Логично что их сравнивают.
Всякие D и форты не взлетели по разным причинам.
Rust пытается играть на поле C. Это C подобный язык, но не C++
У Чистой нет конкуррентов. Раст конкурент C++.
> Раст конкурент C++.раст конкурент разве что корявых шишек.
Коллапс разработки начался как только придумали языки программирования.
>Последующее разыменование подобного указателя приводит к неопределённому поведению.Как же так, как же могла быть в таком безопасном языке разрешена такая ситуация? Видимо надо было просто сишку юзать, а не на пустые обещания вестись.
Разыменование голого указателя возможно только внутри блока unsafe.
тут в соседней ветке уже ответили
Уфф, пронесло. На этот раз нигде в std типы аргументов или возвращаемых значений не меняли. Так что есть все шансы на перекомпиляцию без правок исходников.
Хм, мне казалось что такая проблема может быть только с хоббийными проектами.
В тех проектах в которых я принимал участие фиксировалась версия языка (что для СИ, что для С++).Там завезли какие-то супер фичи или фиксы, чтобы была необходимость всять самую свежу версию?
Последний раз мне больно досталось с выходом Rust Version 1.85.0 (2025-02-20), когда core::ffi::c_char сменился с i8 на u8. https://doc.rust-lang.org/stable/releases.html#version-1851-...
Они честно написали "The new definition may result in compilation failures but fixes compatibility issues with C". Но мне от этого легче не стало.> Там завезли какие-то супер фичи или фиксы, чтобы была необходимость всять самую свежу версию?
Проблема в том, что желающих поддерживать свои библиотеке для всех версий Rust исчезающе мало. Поэтому исправление критической уязвимости где-нибудь в ESP-IDF-HAL требует перехода на новую версию компилятора. Или же твой ESP32 окажется уязвим и будет торчать дырой в эфире, доступный любому желающему уже известной уязвимостью воспользоваться.
Странно, а мне вот чуть выше по треду с пеной у рта доказывали, что editions решают абсолютно все, ну вот прям совсем все проблемы с поддержкой легаси-кода. Неужто врали? ;)Спасибо за ваш пост.
> с пеной у рта доказывали,Это ты сам выдумал?
> что editions решают абсолютно все, ну вот прям совсем все
И это то же)?
> проблемы с поддержкой легаси-кода. Неужто врали? ;)
Если выдумывать несущесвующие "постулаты", то та - вам все врут.
Напомнило одного местного, который носился с "раст не защищает от всех уязвимостей!!11"
Его спрашиваешь "а кто тебе такое обещал?"
В ответ "Абырвалг!!!"
Rust это про супер супер вау, но не поддержку и фичи. Все недоделанное какое-то и несовместимое между собой. Даже в core utils на Rust налажали, но зато "безопасно"🤷♂️
>> Последний раз мне больно досталось с выходом Rust Version 1.85.0
> Странно, а мне вот чуть выше по треду с пеной у рта доказывали, что editions решают абсолютно всеЧел, он пишет как раз о новом edition (2024). Перестань позориться наконец-то...
Позорятся тут в основном растуны. Если проект развивается на моменты выхода свежатинки, ты всерьез предлагаешь одну половину оставить на старой редакции, другую допиливать на новой?
> Если проект развивается на моменты выхода свежатинки, ты всерьез предлагаешь одну половину оставить на старой редакцииДа что ж ты такой тугой? 🤦 Проект должен развиваться с фиксированным стабильным edition, но персонаж этого сделать не удосужился.
Я тебе еще раз повторяю: прекращай позориться - очевидно же, что ты не шаришь даже в базовых вещах Раста.
> Проект должен развиваться с фиксированным
> стабильным edition, но персонаж этого сделать не удосужился.Ну вообще-то проект никому ничего не должен, особенно если он сторонний.
Вот хочу и использую найтли, и что ты мне сделаешь?))Просто нужно
- или не завязываться такие проекты
- или не жаловаться что что-то где-то сломалось в нестабильном edition.
- ну или самому придти в проект и поддерживать его работу в нужном стабильном, но это уже совсем круто.
>>> Последний раз мне больно досталось с выходом Rust Version 1.85.0
> Чел, он пишет как раз о новом edition (2024). Перестань позориться наконец-то...Очень интересно, а почему новый edition (2024-N?) вышел в феврале 2025 года? Или всё же в прошлогодний edition внесли изменения?
> Или всё же в прошлогодний edition внесли изменения?Откройте указанную вами же ссылку на список изменений.
Version 1.85.0 (2025-02-20)
The 2024 Edition is now stable. See the edition guide for more details.
Ну и что толку с такого edition, который стабилизировали больше года?
А для ESP32-C3 (RISC-V) использовать предыдущий edition возможности не было. Разве что nightly.
> Ну и что толку с такого edition, который стабилизировали больше года?
> А для ESP32-C3 (RISC-V) использовать предыдущий edition возможности не было.Чел, предыдущий edition был 2021 (1.56). Если ты использовал компилятор равной или более новой версии, то у тебя БЫЛА ВОЗМОЖНОСТЬ зафиксировать ее. Но ты этого не сделал, и сидел на нестабильной edition, который - ВНЕЗАПНО111 - сломал совместимость. Но виноват при этом Раст, да.
В следующий раз потрудись разобраться с инструментом, прежде чем писать свои хэллоуворлды и тем более критиковать его.
>> Ну и что толку с такого edition, который стабилизировали больше года?
>> А для ESP32-C3 (RISC-V) использовать предыдущий edition возможности не было.
> Чел, предыдущий edition был 2021 (1.56).Читать умеете?
> Если ты использовал компилятор равной или
> более новой версии, то у тебя БЫЛА ВОЗМОЖНОСТЬ зафиксировать ее.Мда, явно читать не умеете. Прочитайте выше, я популярно всё описал.
> Читать умеете?
> Мда, явно читать не умеете.Так я тебя и спрашиваю: каким таким образом у тебя не было возможности использовать предыдущий (текущий?) edition, но при это была возможность обновиться на 1.85 (да еще и с включением 2024 версии, которая до этого момента была нестабильной)?
>> Мда, явно читать не умеете.
> Так я тебя и спрашиваю: каким таким образом у тебя не было
> возможности использовать предыдущий (текущий?) edition
>>> Проблема в том, что желающих поддерживать свои библиотеке для всех версий Rust исчезающе малоИными словами, несмотря на то, что у меня использовался edition 2021, вся сборка обвалилась, пока я не перешёл на новые версии esp-idf-svc, esp-idf-hal и esp-idf-sys.
Например, можете проверить на этом открытом проекте https://github.com/vpetryaev/GateRTO-1000
Если откатиться на один коммит, то проект не соберется c ворохом ошибок
expected `*const u8`, found `*const i8`
или
expected `*mut *const u8`, found `*mut *const i8`
> The 2024 Edition is now stableПока пациента стабилизировали - он протух.
> Странно, а мне вот чуть выше по треду с пеной у рта доказывали, что editions решают абсолютно все, ну вот прям совсем все проблемы с поддержкой легаси-кода. Неужто врали? ;)Увы, такая кроссплатформенность в одного язычка, где деды не смогли определиться ни с размером, ни со знаком для примитивного типа.
> Увы, такая кроссплатформенность в одного язычка, где деды не смогли определиться ни с размером, ни со знаком для примитивного типа.Да что ж такое-то, кто только растунов не обижает! Вон, и деды, делая стандарт, забыли посмотреть в хрустальный шар и понять, как они обижают растунов в будущем... Нет, решительно, расту и растунам нужен какой-то другой мир, этот им не подходит.
> Они честно написали "The new definition may result in compilation failures but fixes compatibility issues with C". Но мне от этого легче не стало.c_char надо всегда кастовать в нужный тебе тип, потому что если твой код сломался тут - значит он сломался бы и на любой платформе на которой c_char изначально unsigned
Неприятно, да, но у кода изначально была проблема с портабельностью
> Неприятно, да, но у кода изначально была проблема с портабельностьюОчень интересно, как под ESP32 на уровне HAL можно писать кроссплатформенный код. Поделитесь опытом?
> Очень интересно, как под ESP32 на уровне HAL можно писать кроссплатформенный код.
> Поделитесь опытом?Окей, в ESP32 действительно обе платформы (risc-v, xtensa) используют unsigned
Я однако думал речь про linux/windows/macos, потому что на винде/macos всегда оно signed, а на linux заисит от архитектуры, и в этом случае надо поддерживать оба варианта
>"dangling_pointers_from_locals"Это же не имеет смысла. Как такое концептуально допускает Rust, который как раз призван бороться с этим?
Такие предупреждения и C выдает.
Он и не такое допускает. Скажем, runtime panics из-за неверного обращения с владением, которое чекер зевает на этапе компиляции, причем ни разу не в unsafe коде.
use std::cell::RefCell;fn main() {
let data = RefCell::new(0);let mut first_borrow = data.borrow_mut();
*first_borrow = 50;
println!("Первая ссылка: {}", *first_borrow);
// ...
let mut second_borrow = data.borrow_mut();
*second_borrow = 100;
println!("Этот код никогда не выполнится");
}Этот код замечательно компилируется и вываливает панику при запуске. Сейчас набигут растуны и завопят, что я ничего не понимаю, что так никто в здравом уме не напишет, что так и должно быть, и т.д., и т.п. Но тем более странно, что их святой практически боровчекер такую элементарную ошибку пропускает.
>Он и не такое допускаетУх, вот это ыкспердище!
>Скажем, runtime panicsЫкспердище не понимает, что даже в этом случае семантика программы сохраняется, и порчи памяти не происходит. Си в данном случае просто попортит память, либо упадёт с сегфолтом, в зависимости от фазы луны.
>что так никто в здравом уме не напишетВы за годы существования раста так и не смогли понять, какие гарантии он допускает и как работает, и хвастаетесь своим невежеством.
Нет, ребятки, это вы, когда вас тыкаешь носом в косяки дизайна, вопите "так это же описано, вот, смотрите! мы от такого и не договаривались спасать! вы это, RTFM со своими претензиями!" Вопрос как раз в том, нафига так спроектировано? Зачем было реализовать такой хороший способ грохнуть софтину в рантайме? Пусть без порчи памяти и фатальных последствий, но для критичного софта и это как-то не комильфо, разве нет?
> Нет, ребятки, это вы, когда вас тыкаешь носом в косяки дизайна,Кто определает "косяки"?
Чувак который показывает чудеса своек кекспертноти вот прям щас?> вопите "так это же описано, вот, смотрите! мы от такого и не договаривались спасать!
Именно.
Есть четки определения от чего и как спасает.
Требовать чтобы авто выдерживало падение в жерло вулкана с криками "вы сказали что там ремни и подушки и вообще самый безопасный авто на рынке!!!" это просто идьйотизм.> вы это, RTFM со своими претензиями!"
Ага, каждый раз приходится посылать очередного растохейтера в доку.
> Вопрос как раз в том, нафига так спроектировано?
Because we can (c)
Тебе не нравится? Можешь сделать лучше?
RFC принимаются от любого. Можешь прийти и показать "как надо".> Зачем было реализовать такой хороший способ грохнуть софтину в рантайме? Пусть без порчи памяти и фатальных последствий,
Фатальные последствия бывают разные.
Если у тебя упадет сервак это печально.
А если он не упадет, но там будет дырочка для кахеров - то может быть и фатально для бизнеса.> но для критичного софта и это как-то не комильфо, разве нет?
Ну так разрабатывай критичный софт, соответственно. Пиши тесты, проектируй архитектуру.
Знаешь, раст не защитит например, от логической ошибки и бесконечного зацикливания конечного автомата.
И? Поэтому его не использовать?
Ну так не используй. Пользуйся СИшкой, там же такого не может быть, бггг))
> Вопрос как раз в том, нафига так спроектировано?
> Зачем было реализовать такой хороший способ грохнуть софтину в рантайме?Ппц ты тyпой...
Так было сделано именно для того, что "без порчи памяти и фатальных последствий", а не втихаря перетерли не там где нужно.
> но для критичного софта и это как-то не комильфо, разве нет?У разработчика есть выбор как интерпритировать ошибку.
Если это критика - то программа должна быть завершена.
Если нет, то ты просто используешь правильную функцию try_borrow_mut и ВНЕЗАПНО все работает и ничего не падает.Просто ты раст видел только в инетнете.
Или вообще делаешь вид что видел его в интернете.Вот исправленный твой код play.rust-lang.org/?version=stable&mode=debug&edition=2024&gist=e962d0d87621986500595fba861bd2f8
И там все работает.use std::cell::RefCell;
fn main() {
let data = RefCell::new(0);let mut first_borrow = data.borrow_mut();
*first_borrow = 50;
println!("Первая ссылка: {}", *first_borrow);
let mut_borrow_result = data.try_borrow_mut();
match mut_borrow_result {
Ok(mut borrowed_value) => {
*borrowed_value = 100;
}
Err(e) => {
println!("Что-то пошло не так {:?}", e);
}
}
println!("Этот код таки выполнится!");
}
> Вопрос как раз в том, нафига так спроектировано? Зачем было реализовать такой хороший способ грохнуть софтину в рантайме?Не вопрос: покажи, как делать рантаймовые проверки владения БЕЗ использования GC.
>Вопрос как раз в том, нафига так спроектировано?Для того, чтобы избежать порчи памяти, очевидно же.
>Пусть без порчи памяти и фатальных последствий, но для критичного софта и это как-то не комильфоА что для критичного софта комильфо? Попорить памяти и попытаться продолжать работать?
Эмммм... А читать мы разучились?Borrows for RefCell<T>s are tracked at runtime, unlike Rust’s native reference types which are entirely tracked statically, at compile time.
> Эмммм... А читать мы разучились?
> Borrows for RefCell<T>s are tracked at runtime, unlike Rust’s native reference types
> which are entirely tracked statically, at compile time.Да ежу понятно, отчего этот код компилируется и отчего потом вылетает паника -- все строго в соответствии с дизайном языка. Вопрос в другом -- зачем он, такой дизайн? Сначала делаем супер-пупер-проверки каждого чиха в compile-time, рассказываем всем с фанфарами, как это здорово, а потом закладываем под фундамент небольшую бомбочку.
Итог: неофиты, счастливые, что пишут на "самом безопасном языке", ведутся на любимый лозунг растунов "компилируется -- значит работает!" и получают пинок туда, где не ожидали. Особенно весело получится, если этот неправильный захват владения происходит по условию и сравнительно редко -- даже тесты могут не помочь вовремя исправить багу.
И еще: А читать мы разучились? Документация по многострадальному C точно так же позволяет объяснить, что, отчего и как. От этого дизайн C стал лучше?
> Сначала делаем супер-пупер-проверки каждого чиха в compile-time, рассказываем всем с фанфарами, как это здорово,А проверки compile-time не работают?
Еще как работают)> а потом закладываем под фундамент небольшую бомбочку.
Судя по тому сколько ты уже настрочил, то бомбочка бобманула у тебя на стуле)
> Итог: неофиты, счастливые, что пишут на "самом безопасном языке", ведутся на любимый лозунг растунов "компилируется -- значит работает!"
Лозунг только в твоей больной фантазии.
> и получают пинок туда, где не ожидали.
С чего не ожидали? Вон в доке все написано.
> Особенно весело получится, если этот неправильный захват владения происходит по условию и сравнительно редко -- даже тесты могут не помочь вовремя исправить багу.
И оно упадет? Ну бывает. Тесты нужно писать лучше.
Я понимаю что это не настолько круто как у дырявых "out of bounds и получайте рута"...
Инструмент не идеален на 100%, он развивается. Может когда-то и такой случай в компайлтайм будут отлавливать.
Ему достаточно быть ощутимо лучше остальных.> И еще: А читать мы разучились? Документация по многострадальному C точно так же позволяет объяснить, что, отчего и как.
Объяснить на уровне "а хй его знает что тут произойдет, пусть будет UB"? Да, сможет.
Поможет ли это писать программы на дыряшке? Нет.
>> Borrows for RefCell<T>s are tracked at runtime, unlike Rust’s native reference types
> Вопрос в другом -- зачем он, такой дизайнВ смысле, зачем? Если ты явно использовал RefCell всесто нативных ссылок, что очевидно, у тебя были причины для этого - и ответ на вопрос "зачем" как бы должен быть очевидным.
>и получают пинок туда, где не ожидалиСемантика раст программы - она либо выполняется, либо паникует, но не портит память. Сколько лет расту, а вы настолько некомпитетны, что до сих пор этого не узнали.
>Документация по многострадальному C точно так же позволяет объяснить, что, отчего и как.Если вы не прочитаете документацию по rust, программа упадёт, и на этом всё закончится, семантика программы не поменяется. Если вы не прочитаете документацию по си, то программа будет иногда работать, иногда содержать cve, иногда просто портить память, иногда падать в непредсказуемых местах, у программы нет абсолютно никакой семантики. Более того, поведение может поменяться буквально от того, что её собрали другим компилятором. Почувстуй разницу.
Двойное враньё от адепта. Первое раст завяляет зерокост/кт-проверки. Как только адепта ловят он начинает маневрировать "а зерокост ненужен", "а рт тоже проверки".Для людей мало знакомых с темой сложно понять манипуляцию сектантов и то почему люди часто на это ссылаются. Да и людям так же сложно это объяснить. Дело в том, что все эти "кт"-проверки на самом деле в 95% случаев не работают и не потому что нельзя, а потому что они убогие. Поэтому ты вынужден использовать рт-проверку не потому что там есть какой-то рантайм, а потому что иначе нельзя.
И что показывает этот фанатик? Он пишет "ну там сказано рантайм", но здесь есть подлог. Есть рантайм-проверка, а есть рантайм-семантика. Вот рантайм-семантику мы можем проверить только в рантайме, очевидно. Но в расте рантайм-проверки никак не связаны с рантайм-семантикой что и показано в примере выше. Её там нет.
Вон там ещё один сектант пытается манипулировать. Нейробот родил try_borrow_mut, но в оригинале её не было. Это ещё одно враньё от секты "ой у нас проверки всего", "ой у нас нельзя игнорировать ошибки" можно. Именно поэтому там и сделан borrow_mut чтобы скрывать эти проблему, а так же чтобы ты его мог писать в случаях когда у тебя кт-семантика и ты точно знаешь что ошибки не будет.
> Первое раст завяляет зерокост/кт-проверки.Да, именно так.
Компайлтайм проверки есть? Есть.
Работают? Работаю.
Чего тебе надо, @?> Как только адепта ловят
Ловят на чем? Что не все проверки в компайлтайме? А это вы сами придумали.
Зерокост еще как нужен. И чем больше перенесется в компайлтам, тем лучше.> Для людей мало знакомых с темой
Людей вроде тебя?)) Попробуй открыть доку и почитать.
> на самом деле в 95% случаев не работают
Пруфы приведешь? Или ты сюда так, пришел лужи погазифицировать?
> Вон там ещё один сектант пытается манипулировать. Нейробот родил try_borrow_mut, но в
> оригинале её не было.То что ее не было - проблема рукоопого пейсателя оригинального кода. Он жалуется на то, что в таком случае код паникует, хотя это именно ожидаемое поведение от кода.
> "ой у нас проверки всего"
Про "всего" - это фантазии растохейтеров.
Но проверка прошла и программа запаниковала - отлично, цель достигнута, потому что программа не попортила память и не подарила рут.> Именно поэтому там и сделан borrow_mut чтобы скрывать эти проблему
Опять же, скрывает только для тех, кто доку не читал. Но таким уже ничем не поможешь.
Мне настолько лень с тутошними одноклеточными спорить. Паника существует - существует. Проверки нет - нет. Почему каждый сектант ссылается на какую-то свою доку?>Но проверка прошла и программа запаниковала - отлично, цель достигнута, потому что программа не попортила память и не подарила рут.
Проверок никаких нет. То, что ты где-то украл тормозящие рт-проверки они к тебе отношения не имеют. Они есть везде и ничего не стоят. Их даже специально выключают чтобы не тормозило, собственно твой рантайм на 95% и состоит из подобного ворованного кода. Как и то, твоя секта называет компилятором.
Падение хуже порчи памяти, да и на самом деле он портит память. У тебя есть ворованные исключения и попытка их косплеить, а безопасности исключений нет. Поэтому любая паника с перехватом есть порча памяти, но тебе об этом не рассказали. Сектанты патаются пихать это в потоки чтобы ворованный сишный рантайм с этим что-то сделал.
В результате сравнивается фентезийный "дал рут", который буквально недавно растосекта давала не осилив реализацию архиватора.
Вот представим себе ивл/аэс где код писал расто-сектант. Что хуже мочь уронить всё, либо какая-то маня-уязвимость которая эксплуатируемая в единицах процентов и даже после этого нужно ещё сделать не просто эксплуатацию, а с последствиями. И то лучшее что ты можешь сделать этой эксплуатацией это уронить. Сделать что-то хуже требует гигантских усилий, допустим знание о том как работает АЭС, как ей управлять и как крутить чтобы что-то сломать. Ещё проверки нужно как-то обойти, которые могут быть(и будут) физическими.
И в этом проблема сектантов. Любой раст-адепт это малообразованный школьник. Он почему-то решил что ворованная сишная паника это какая-то раст-инновация. И что сишный софт не паникует/не проверяет всё подряд просто потому что там глупые люди.>Пруфы приведешь? Или ты сюда так, пришел лужи погазифицировать?
Это ты должен приводить, а не я. Ты как сектант утверждаешь что твои заявления работают, а значит ты должен доказывать что-то, а не я.
Тебе как раз таки показали пример где заявления не работают - проверки нет. Поверка в контексте растосекты это именно кт-проверка.
>Rust is blazingly fast and memory-efficient: with no runtime or garbage collector, it can power performance-critical services, run on embedded devices, and easily integrate with other languages.
базовая агитка. Конечно это всё враньё, но твоя задача доказывать. Как ты там в ембедед-девайсах собрался паниковать.
Тех кто захочет подобных убогих глушить достаточно anyhow/unwrap и количество arc и им подобных в любой раст-клоаке, а так же попыткой реализовать любой примитив из стд. Ничто в расте за пределами букваря не проверятся в кт.Такая же ситуация с тем как раст-сектанты орали про "исключения плохо/типы непонятно", а в реальности в ядре инт ворованный из сишки, а везде anyhow и подобный нелепой косплей на исключения. Ноль кт хотя каждый сектант тебе будет орать про result и типы, которые в реальности никто не использует.
И даже для того чтобы букварь их мог использовать пришлось воровать неявные преобразования типов и дереф. Кстати, который сектант так же орал что явное лучше неявного. В прочем это не что следует обсуждать с тутошними амёбами.
> Паника существует - существует. Проверки нет - нет.Ты совсем тупой?
Паника это результат выполненной проверки.> Мне настолько лень
Но ты продолжаешь трятись и гадить))
> где-то украл тормозящие рт-проверки они к тебе отношения не имеют.
И где украл?
> твой рантайм на 95% и состоит из подобного ворованного кода. Как и то, твоя секта называет компилятором.
Чего??
Дадя, завязывай бухать и употрблять вещества. Это вредно для здоровья.
Начинай заниматься спортом и кушать смузи, тогда перестанешь нести такую еб--ну)> Падение хуже порчи памяти, да и на самом деле он портит память.
Правда? О новое слово в софтостроении.
По мнению бебенашек падение это хуже чем уязвимость живущая десяток лет!> ворованные исключения
> чтобы ворованный сишный рантаймНафаня! Сундук украли!!
Кажется ты долбанулся на тебе "ворованое")АЭС должна писаться на языке с формально верификацией.
Иметь кучу аппаратных и софтварных степеней избыточности.
И это не раст, и уж точно не дыряшка.> Любой раст-адепт это малообразованный школьник.
Только в покореженных мозгах таких бебенашек как ты.
> И что сишный софт не паникует/не проверяет всё подряд просто потому что там глупые люди.
Да, коммитет просто испоганил язык, на что сами создатели ругались.
СИ просто дает рута на простой выход за пределы массива.>>Пруфы приведешь? Или ты сюда так, пришел лужи погазифицировать?
> Это ты должен приводить, а не я.Лол, твой ви-сер просто смешной, так что давай пруфы.
"бремя доказывания" - доказательства должна приводить сторона обвиняющая.> Ты как сектант
Только в твоих фантазиях.
Никакого доказательства ты не привел.> Как ты там в ембедед-девайсах собрался паниковать.
Определяешь panic_handler и делаешь всё что душа пожелает.
Но ты об это не знал, потому что ты убогий хейтер.> инт ворованный из сишки
Ахахаха!
Дядя иди лечись)
> Мне настолько лень с тутошними одноклеточными спорить....и поэтому я накатаю очередную простыню текста.
> Паника существует - существует. Проверки нет - нет.
Не, ну это гениально. Проверки нет, но паника при этом откуда-то взялась.
> Проверок никаких нет. То, что ты где-то украл тормозящие рт-проверки
Опять: проверок нет, но украденные проверки есть. Ноль противоречий! Кстати, где украл? У кого?
> То, что ты где-то украл тормозящие рт-проверки они к тебе отношения не имеют. Они есть везде и ничего не стоят.
Сперва "тормозящие проверки", и тут же "они ничего не стоят". Так "тормозящие" или "ничего не стоят"? Чел, ты там в порядке вообще?
> ворованная сишная паника
В Си нет никаких паник. То о чем вообще?
Что за глупость? Паники не портят память. Или где мне увидеть пруф обратного?
>>> на самом деле в 95% случаев не работают
>> Пруфы приведешь?
> Это ты должен приводить, а не я. Ты как сектант утверждаешь что твои заявления работаютНо ведь это ты, а не он, утверждаешь, что "все эти "кт"-проверки на самом деле в 95% случаев не работают". Так что или давай пруфы, или прекращай трепать языком..
> Тебе как раз таки показали пример где заявления не работают - проверки нет.
Но ведь это вы заявляете, что RefCell должен проверяться в кт, в то время как в его документации написано о рт.
> Поверка в контексте растосекты это именно кт-проверка.
В документации RefCell черным по белому написано, что он проверяется в рантайме. Ты снова воюешь с ветряными мельницами.
> в ядре инт ворованный из сишки
Оказывается, целочисленные типы в сишке изобрели! А до Сишки люди поди вообще на абаках считали.
Как уже было сказано мне лень отвечать настолько одноклеточным. Для примера разберу пару набросов.>...и поэтому я накатаю очередную простыню текста.
Калась не тебе, а тем кому интересно.
>Опять: проверок нет, но украденные проверки есть. Ноль противоречий! Кстати, где украл? У кого?
Тут мы видим всю немощь этого одноклеточного. есть рт-проверки и кт-проверки ему написано нет кт-проверок есть ворованный рт-проверки. Бот перегрелся увидел два слова "проверки" и решил что он кого-то поймал.
>В Си нет никаких паник. То о чем вообще?
Ты совсем упоролся? Паники это базовая сишная концепция. Это баталии ещё времён создания сишки/юникса. Аналогично вся сишная скриптота имеет die.
>Оказывается, целочисленные типы в сишке изобрели! А до Сишки люди поди вообще на абаках считали.Тут одноклеточное увидело инт вставило в гугл ей написали "целочисленный тип" и она побежала демонстрировать своё невежество.
Да, инт и прочее в сишке изобрели, но одноклеточное даже не поняло в чём проблема. Вопрос не в инте, а в кодах возврата. Что раст-сектантами называлось днищем и вообще есть adt. Причём в ядре adt родить максимально просто в отличии от прикладухи, но даже там не смоглось.
>> В Си нет никаких паник. То о чем вообще?
> Ты совсем упоролся? Паники это базовая сишная концепция.О как! Да еще и базовая! Давай ссылочку на стандарт Си или POSIX.
> Да, инт и прочее в сишке изобрели,
Вопросов больше не имею.
>О как! Да еще и базовая! Давай ссылочку на стандарт Си или POSIX.Давай ссылочку на стандарт растомусора.
К тому же причём тут стадарт си какое отношение стандарт си имеет к си? И причём тут посикс, который появился после? Какое вообще посикс имеет отношения к теме? Ты вообще знаешь что это?
В прочем я не должен за тебя отвечать - просто бежишь и сообщаешь мне о связи.
Для тех кому интересно про панику в юниксе написано даже на вики я проверил. Даже искать ненужно и тут не может быть маз "ну сложно искать". Не сложно. Этого достаточно чтобы позорище опозорилось. К тому же panic/die это хайлевел концепция. Сама попытка найти её в каких-то лоулевел-интерфейсах уже говорит многое о клоуне.
> Падение хуже порчи памятиДальше можно не читать, человек явно разработкой чего-либо серьёзного не занимался
Ты хоть понял, что сам написал?
> Но в расте рантайм-проверки никак не связаны с рантайм-семантикойНу, тут уже совсем какая-то гуманитарная пыль в глаза пошла. Ты что имел в виду вообще?
Люди используют рантаймовые проверки, когда компайлтайм проверки физически невозможны. Это же очевидно, нет? Видишь ли, поведение любой прораммы всегда зависит в т.ч. и от внешних параметров (из файлв, сети, периферийных устройств и т.п.), о которых компилятору не может быть ничего известно.
>Двойное враньё от адепта. Первое раст завяляет зерокост/кт-проверки. Как только адепта ловят он начинает маневрировать "а зерокост ненужен", "а рт тоже проверки".Вы настолько необразованы, что не понимаете разницу между тем, что в расте есть проверки нулевой цены и тем, что в расте абсолютно все проверки нулевой цены?
>Поэтому ты вынужден использовать рт-проверку не потому что там есть какой-то рантайм, а потому что иначе нельзя.Что? А что, на си тоже нельзя без проверок времени выполнения? Да как же так? А в крестах тоже нельзя? Тогда в чём ваша претензия?
>Вон там ещё один сектант пытается манипулировать. Нейробот родил try_borrow_mut, но в оригинале её не было.А вот это тогда что? https://doc.rust-lang.org/std/cell/struct.RefCell.html#metho...
>Для людей мало знакомых с темой сложно понять манипуляцию сектантовВот действительно. Если для вас rust слишком сложный, то пишите на Go, Ocaml, но не вкоем случае не на си и не на крестах. Поскольку сишные сектанты убеждают как у них всё хорошо, но продолжают плодить очередные дыры.
> Эмммм... А читать мы разучились?
> Borrows for RefCell<T>s are tracked at runtime, unlike Rust’s native reference types which are entirely tracked statically, at compile time.Это бесполезно. Этому персонажу уже в других темах не раз повторяли, что borrow checker работает во время компиляции, а Rc/Arc - во время выполнения. Но персонажу не доходит и он продолжает всплывать с той же темой...
> RefCell
> странно, что их святой практически боровчекер такую элементарную ошибку пропускает.Чел, ну тебе черным по белому написано "RefCell A mutable memory location with dynamically checked borrow rules". DYNAMICALLY, понимаешь?
> Сейчас набигут растуны и завопят, что я ничего не понимаю
Ну да, ты действительно не понимаешь, что такое "dynamically checked" и "statically checked". Или в инглише не бум-бум, я хз.
>Это же не имеет смысла.Ещё один не осиливший разницу между указателем и ссылкой.
>> Это же не имеет смысла. Как такое концептуально допускает Rust, который как раз призван бороться с этим?
> Ещё один не осиливший разницу между указателем и ссылкой.Ещё один, не понимающий (или притворяющийся), что вопрос был именно о концепции и дизайне языка, а не о том, почему это скомпилировалось.
> Ещё один, не понимающий (или притворяющийся), что вопрос был именно о концепции и дизайне языкаЕсли ты спрашиваешь, зачем существует RefCell/Rc/Arc - то очевидно, что для случаев, когда проверки времени компиляции физически невозможны. Разве не очевидно?
Нет, раст-сектант опять врёт. Как было сказано выше в 95% случаев раст-сектант пишет подсчёт ссылок не потому что требуется, а потому что его днище не смогло.Это о чём я писал выше. Есть рантайм-семантика это то когда физически невозможно. Рантайм-проверка это просто рантайм-проверка она никак не связана с рантайм-семантикой. Её можно всунуть куда угодно. Это типичная манипуляция от сектанта.
Ну банально тот пример с которым бегают они.
```
vec v;
v.push();
r = v[0]
v.push();
```сектанты бегают и рассказывают как они ловят эту ошибку. На самом же деле они её не ловят, а просто не могут. r алиасится с вектором и далее push не работает потому что требует mut который не работает при 1+1. Это не значит что оно понимает что здесь ошибка, либо что будет ошибка.
Поэтому в примере когда я сменил в векторе аллокатор на бесконечный, либо когда я рукой делаю
```
vec v;
v.reserve(100000);
v.push();
r = v[0];
v.push();
```Очевидно что здесь никакой ошибки нет. Как и если это бесконечный аллокатор. Как и если это какой-нибудь псевдомассив со стабильными ссылками.
Аналогично, допустим, в растомусоре хеши не имеют стабильных ссылок. Потому что были ворованы с цпп хешей без стабильных ссылок. Они пытаются бегать и орать что они побеждают какие-то цпп-хеши со стабильными ссылками. Почему? Потому что апи со стабильными ссылкам там не работает.
Даже slice они до сих пор не могут сделать, а может уже и сделали.
> Как было сказано выше в 95% случаев раст-сектант пишет подсчёт ссылок не потому что требуется, а потому что его днище не смогло.Ты опять набрасываешь без каких-либо пруфов. Иначе покажи сценарий, в котором "правильный" язык реализует кт-проверку там, где ростовый borrow checker "не смог".
> Есть рантайм-семантика это то когда физически невозможно. Рантайм-проверка это просто рантайм-проверка она никак не связана с рантайм-семантикой. Её можно всунуть куда угодно. Это типичная манипуляция от сектанта.
Очередное пускание абстрактной пыли в глаза без какой-либо конкретики.
> сектанты бегают и рассказывают как они ловят эту ошибку. На самом же деле они её не ловят, а просто не могут. r алиасится с вектором и далее push не работает потому что требует mut который не работает при 1+1. Это не значит что оно понимает что здесь ошибка, либо что будет ошибка.
Borrow checker срабатывает в этом случае? Срабатывает. Дальше какой-то бред про "1+1" и "оно не понимает".
> Очевидно что здесь никакой ошибки нет.
Очевидно, что есть, ибо в общем случаев и число в reserve(), и количество push() может зависеть от внешних данных (напр., прочитанных из файла). Поэтому компилятор закономерно нечего не послабляет для такого случая.
> Потому что были ворованы с цпп хешей без стабильных ссылок.
Шта? Что такое "цпп-хеши"?
> какие-то цпп-хеши
А, ок - ты и сам не в курсе...
Насколько же одноклеточное. Видим как только дело доходит до конкретики бот ломается. Он не знает ни что такое бч ни как работает раст в принципе.>Borrow checker срабатывает в этом случае? Срабатывает. Дальше какой-то бред про "1+1" и "оно не понимает".
Оно перегрелось и в принципе не осилило понять ни пример ни то как здесь работает бч. А уж не понять что такое 1+1 это прям позорище.
>Очевидно, что есть, ибо в общем случаев и число в reserve(), и количество push() может зависеть от внешних данных (напр., прочитанных из файла). Поэтому компилятор закономерно нечего не послабляет для такого случая.
Нет, клоун. Здесь оно не зависит, а то что оно может зависеть тебя волновать не должно. Аналогично тебе привели примеры с тем, когда в векторе стабильные ссылки всегда. ТЫ почему-то потерялся? Нейробот не смог найти ответ?
Аналогично тебе писали про бесконечные аллокации. Тут даже в принципе невозможна ситуация ошибки потому что:
> Address sizes: 46 bits physical, 48 bits virtual
Вообще никак и никогда. Не говоря уже про реальность где 46бит памяти никогда не будет.
>Шта? Что такое "цпп-хеши"?Самое смешно то почему раст-сектант это всегда амёба. Понятно что он не знает что такое программирование, раст, хеши и прочее. Понятно что он не знает ни что такое стабильность ссылок/итераторов.
Но тут достаточно зайди в букварь про который раст-сектант постоянно тебе что-то рассказывает и в букваре написано следующие:
>The hash table implementation is a Rust port of Google’s SwissTable. The original C++ version of SwissTable can be found here, and this CppCon talk gives an overview of how the algorithm works.Это типичный пример того почему раст-сектант всегда врёт. Он не читал никакой букварь просто нелепо мажется по спущенной заранее методичке.