Разработчики проекта gccrs (GCC Rust) опубликовали четвёртую редакцию патчей с реализацией фронтэнда компилятора языка Rust для GCC. Отмечается, что в новой редакции устранены почти все замечания, ранее высказанные при рецензировании предложенного кода, и патчи удовлетворяют всем техническим требованиям к коду, добавляемому в GCC. Ричард Бинер (Richard Biener), один из сопровождающих GCC, упомянул, что теперь код фронтэнда для языка Rust готов для интеграции в ветку GCC 13, релиз которой состоится в мае 2023 года...Подробнее: https://www.opennet.me/opennews/art.shtml?num=58278
как говорится - Собаки гавкают, а караван идет.
караван не умеет в goto и синглтоны. количество - не значит качество. скорее - ширпотреб.
Орнул, даже и добавить нечего. Разве только ещё антипаттернов.
> Орнул, даже и добавить нечего. Разве только ещё антипаттернов.Ну так номер версии сабжа в тему. Так кого должен любить черт, тринадцатый? %)
Зачем расту goto? Эта конструкция используется в си из-за его хренового эррор хендлинга, ибо какой то из дескрипторов в функции может не открыться, нужно будет закрыть в обратном порядке. А поскольку RAII в си не завезли, выбора нет. Так зачем же goto в языке с RAII?
Кнута почитайте..
Будут ли более веские аргументы? Кроме отсылок почитать Кнута
Зачем в расте unsafe? Что-то принципиально нельзя сделать в "безопасном" режиме?
> Зачем в расте unsafe? Что-то принципиально нельзя сделать в "безопасном" режиме?Да, представляете. Например...
1) Все сисколы операционок мало того что сишные, так еще деланые в лохматых годах. Когда думали ... ну в общем о совсем других вещах. И никто это не будет ради вас переделывать, софта под это уже вся планета, вломы всем столько переписывать. Поэтому интерфейсы ос такие какие есть и с этим придется жить. И разумеется гарантии сабжа при этом немного пролетают. Покажите вообще статический анализ штуки типа ioctl()? Как бы это могло вообще выглядеть?
2) Многие интерфейсы к ЯП, либам и проч - см. выше, та же ерунда. Переписать весь мир на %s это круто конечно. До тех пор пока вот лично вам не приходится этим заняться. А вот тут почему-то оказывается что не так уж это и круто, если вы хатели сделать вон ту задачу а не убить 100500 лет на побочную активность.
3) В системных вещах иногда надо референсить память по конкретным адресам, с пофигом на то что там расположено. И разумеется это не безопасно если вы не понимаете что и зачем делаете.
4) Некоторые алгоритмы могут сильно выиграть по скорости от лобовой математики с адресами и проч, если там минимум допущений и оверхеда. И более того - эффективная их реализация с проверками может быть не особо внятной. Разумеется при этом можно отстрелить себе пятку.
Мог бы просто написать, что на расте всё выше перечисленное сделать невозможно.
> Мог бы просто написать, что на расте всё выше перечисленное сделать невозможно.При сильном желании вроде возможно. Обложившись кучей unsafe, да...
Из очевидных минусов - там такой код, что огого. Из плюсов - проблемные бяки демаркированы как таковые. Не бывает же так что одни только минусы.
> Зачем в расте unsafe?unsafe отключает _некоторые_ возможности статистического анализатора. Всё.
Т.е. со включенным анализатором толком ничего не сделать...
Примерно так же как предохранитель на ружье, что бы ногу себе не отстрелить.
Ну это же только дурачки пользуются оружием с предохранителем, настоящие пацаны знают что если на курок не нажимать то все будет нормально.
С другое стороны, пока ты будешь снимать с предохранителя свое ружье, тебя как раз настоящий пацан и пристрелит пока ты там возишься.
Настоящий пацан успеет прострелить себе ногу. 👏
Аналогия так себе. Овердофига моделей пистолетов, у которых просто нет предохранителя, как детали, управляемой отдельным рычажком или кнопкой. Роль предохранителя выполняет накладка на спусковом крючке (блокирует спуск, пока стрелок не надавит на неё пальцем) или выступающий рычаг на задней стороне рукояти (блокирует УСМ и отключается при утапливании в корпус, когда ладонь стрелка обхватывает рукоять).
Зачем нужно ружье, если не трогать предохранитель?
Еще некоторые auto trait'ы как Send / Sync руками можно только через unsafe объявить.
Статического, конечно же.
Например, без unsafe не написать биндинги к системным библиотекам линукса, которые по сути своей все на Си. https://github.com/gtk-rs/gtk4-rs/search?q=unsafe
> Например, без unsafe не написать биндинги к системным библиотекам линукса, которые по
> сути своей все на Си. https://github.com/gtk-rs/gtk4-rs/search?q=unsafeДа так то по сути и интерфейс сисколов - сишный. И даже редоксеры кажется зассали там вывесить что-то иное, понимая что тогда в их нечто просто не будет софта.
Сисколы они, всё-же, немного не С-шные, а таки процессорные. int 0x80, sysenter и т.д. к C отношения не имеют.
> и т.д. к C отношения не имеют.Вообще-то есть такая штука - syscall(). И мне очень интереcно что такое "int 0x80" в каком-нибудь RISCV. А вот syscall() там тоже будет. Как он там внутрях сделан второй вопрос. Факт в том что так можно доступиться к всем услугам операционки.
Software Developer Manuals for *
Правильна : Все управляющие конструкции можно заменить на while - так победим !
goto нужен только чтобы выпрыгнуть из вложенных циклов - для этого есть более явный человеческий break с меткой. Ну и для очистки ресурсов - но тут это принято через раишный дроп. Синглтоны кроме как для примеров антипаттернов не нужны(хотя и нет проблем их реализовать завернув например банально в лэзи-статик)
> goto нужен только чтобыГоворя "только", ты показываешь свою необразованность.
> goto нужен только чтобы выпрыгнуть из вложенных цикловДля этого даже в самых винтажных сяx break был. А вот goto обычно используется для обработки ошибок и проч чтобы скипнуть солидный блок кода реюзанув общий хвост где подчистка за собой например. Но структурированость этого - все же так себе. Просто другие варианты бывают еще хуже.
>> Для этого даже в самых винтажных сяx break былв "сях" break не поддерживал метки
> break не поддерживал меткиВы хотите недостатки goto + break сразу?! Оба плохи для структурирования программ, а такое комбо просто ужасно. Если вы хотите чтобы чтец неверно понял что вы делали и посадил баг вы на верном пути.
На сях я break использую, но без энтузиазма т.к. слом структурирования. Только 1 вариант как это делать обеспечивает что читающий программу поймет что и зачем было. А вот goto лично я не использую, дабы избежать весьма характерных пролетов. Я видел лишь 1 валидный кейс, обработка ошибочных ситуаций. По иронии именно там то и бывают косяки. В том числе когда кодер из-за де-структурирования сам же и запутался в своем спагетти на какой лэйбл вот отсюда правильно прыгать.
> караван не умеет в gotoМожет оно и к лучшему, а? Все по заветам правильных олдскулеров в этом месте :) Правда, не то чтобы костыли которые вбивают когда это понадобилось сильно лучше - но как видите без него можно.
К сожалению изначальные претензии - "нарушает структурированность программ" все мыслимые костыли придуманные человечеством так же не снимают. Ну то-есть структурированность все равно нарушается, все-равно не очень очевидным образом, etc.
Незачем из Раста делать плюсы, наличие похожих но разных методов только усложняет язык.
А ты и предлагаешь это сделать.
Это тролль
Эдсгер Дейкстра ещё в 1968 году написал всё, что нужно знать про goto. Но ты ж не осилил, даже с переводом.
А Дональд Кнут в своей фундаментальной книжке goto любил и применял. Кнут написал TeX. А что написал Дейкстра, чтобы его слушать?
операционную систему и компилятор к алголу например
ТеХ вродь как вполне себе живет и пользуется. а где та ОСь и тот алгол?
Какой готу, иди книги почитай, этот костыль даже в си используют только криворукие.
так думают только те, кто его один раз в жизни юзал во время изучения языка
Потому что учить надо сначало ассемблер, а потом си. Тогда желание его использовать в си сразу отпадает.
Тебя бэйсиком в детстве ушибло?
Goto тебе никогда и не понадобится (ну или иди на ассемблере прогай). А нужен синглтон - ну так создай объект в самом верхнем скоупе и пробрасывай его везде через DI. А исторически сложившиеся синглтоны в других языках через статические поля и методы, которые потом можно дернуть где угодно - не, спасибо. Ладно бы еще потокобезопасность, так потом на эту фекалию тесты нормально писать невозможно.
> Goto тебе никогда и не понадобитсяДональд Кнут с вами не согласится
Он просто предлагает менее радикальную точку зрения, по сравнению с Дейкстрой. Что если суть алгоритма в прямых переходах, то может стоит не так сильно стесняться ими пользоваться. При этом он не отрицает, что читабельность подобных алгоритмов резко деградирует.
Когда говорил? В 1974? Сейчас компиляторы все сами оптимизируют, никакие готу не нужны.
Парадигма структу́рного программи́рования предполагает отказ от goto
Концептуализирована в конце 1960-х — начале 1970-х годовУдивительно что местные высококомпетентные эксперты по программированию с ней не знакомы.
> Собаки захлёбываются восторженным лаем, впадая в экстаз от переполняющего их энтузиазма, а караван жизни идет мимо, не замечая их радостной истерики.Немного развернул твою мысль, можешь не благодарить.
чем смартпоинтеры в c++ хуже раста?
Тем что они имеют фатальный недостаток
https://ru.wikipedia.org/wiki/%D0%A1%D0%...
В плюсах нет таких сильных гарантий для поинтеров
А что, в расте разве есть какие-то гарантии на по указателям в unsafe?
Сам факт присутствия слова unsafe в синтаксисе уже о многом говорит про язык.
Что говорит?
> Что говорит?- Ты что, глухонемой?
- Да!
(с)
Присутствие слова unsafe говорит что аноним глухонемой?
Или что анонимный эксперт недалёкий?
Да, говорит что язык правильно спроектирован. Без unsafe не написать низкоуровневых примитивов и взаимодействия со всякими кривыми сишным апи, а вот прикладной код должен писаться без ансейфов со следующими из этого гарантиями.
>Да, говорит что язык правильно спроектирован.Ловите дотнетчика!
> В плюсах нет таких сильных гарантий для поинтеровНу смотри, плюсах есть 2 вида умных указателей:
- std::shared_ptr, в котором запрятан счетчик ссылок, его можно копировать сколько угодно раз, и пока счетчик не будет == 0, память не будет освобождена. Ну из минусов - это то, что управляющий блок (там где хранится счетчик ссылок и указатель) выделены в куче, а сам счетчик атомарный (проблема для многопоточки). Используя std::shared_ptr, ты можешь быть уверен, что N раз скопированный указатель будет удален только после того, как счетчик ссылок станет == 0.
Очень удобен, если нужно шарить указатель с кем-то еще.
- std::unique_ptr, в котором запрещено любое копирование, но разрешено перемещение, что так же решает проблемы владения (мы просто перемещаем состояние в новый объект, оставляя старый объект в несогласованном, но консистеном состоянии для его корректного удаления). Тем самым тут отказались от счетчика ссылок и решили еще 1 проблему: выделение управляющего блока в куче. Используя std::unique_ptr, ты можешь быть уверен, что указателем под этим классом всегда владеет только один единственный объект. Удобен, когда нужно сделать что-то похожее на PIMPL или просто автоматически освободить память при выходе из скоупа.Согласно стандартам C++14 и C++17, эти классы гарантируют тебе одинаковое поведение на всех существующих платформах вне зависимости от компилятора и стандартной библиотеки. C чего ты решил, что тут нету гарантий?
Да толку объяснять, если они в глаза даже стандарт С++98 не видели, использовали С++ с классами в свои студенческие годы.
В расте аналог для shared_ptr это Rc\Arc. А для unique_ptr - Box.
Это полноценные объекты с владениями, однако лайфтаймовые ссылки с их валидацией во время компиляции по-прежнему в плюсах не наблюдаются.
> C чего ты решил, что тут нету гарантий?С того, что эти обе штуки позволяют писать код, который продуцирует UB, а это прямой отказ от предоставления гарантий "одинакового поведения на всех существующих платформах вне зависимости от компилятора и стандартной библиотеки".
Чтобы в C/C++ получить одинаковое поведение на всех существующих платформах, тебе придётся а) перерыть документацию по всем тем платформам, и б) научиться видеть все UB в коде глядя на название файла с кодом. Это не достаточное условие, но необходимое. Я не перечисляю другие, потому что уже глядя на это видно, что эти условия не выполняются никогда. А значит и одинакового поведения на всех существующих платформах от программ на C/C++ ждать не приходится.
> Согласно стандартам C++14 и C++17
Эти стандарты никогда не давали никаких гарантий. Они давали лишь устные обещания, и когда эти обещания не выполнялись, они начинали говорить "сама виновата", "ССЗБ", "вон из профессии" и прочие такие штуки.
Для начала уточню, речь идет про С++.> А значит и одинакового поведения на всех существующих платформах от программ на C/C++ ждать не приходится.
Смотри, у тебя есть стандарт языка С++, согласно которому для полной реализации абстрактной машины языка С++, тебе необходимо:
- компилятор, поддерживающий встроенные типы, исключения и шаблоны;
- стандартная библиотека с поддержкой всех встроенных типов, исключений, шаблонов и потоков ввода вывода.
Даже если на целевой платформе не поддерживаются потоки и исключения, тот, кто пишет стандартную библиотеку - обязан это предоставить.
Реализация стандартной библиотеки может быть абсолютно разной, однако для С++ она обязана быть, и к тому же иметь ровно точно такое же поведение, что и на других платформах.
Ну например, у тебя есть шаблон класса std::vector, аллокатор которого должен знать, как ему выделять память (что-то на подобие malloc()), исключений и поддержки как минимум встроенных типов. Стандарт гарантирует, что например, std::vector<int>::push_back() для любой платформы, где есть поддержка стандартной библиотеки, сделает абсолютно одинаковые вещи везде: а именно - аллокатор std::vector`а выделит память (если не получилось - выбросит std::bad_alloc), в эту память он скопирует значение, которое ты передал в качестве параметра.
Если у тебя на платформе нету хотя бы одного, из вышеперечисленных компонентов в реализации стандартной библиотеки, то у тебя нет и компилятора С++. А значит, у тебя нету и С++.
К чему ты всё это пишешь, если UB -- это Undefined Behavior, про который явно говорится, что никаких гарантий относительно его поведения нет?
> Эти стандарты никогда не давали никаких гарантий.Найди мне хоть одну существующую реализацию стандартной библиотеки С++, которая поведением отличается от других.
Если найдешь, я пересмотрю свою точку зрения.
> Ну из минусов - это то, что управляющий блок (там где хранится счетчик ссылок и указатель) выделены в кучеНе существует такого термина как "управляющий блок". И счётчик ссылок рядом с указателем храниться не может. Иди доучивать, пентестер мамкин. Есть сам объект shared_ptr, там хранятся два указателя - на хранимый объект и на счётчик ссылок. При этом при использовании make_shared они смотрят в одну аллокацию. Так в чём здесь минус?
> счетчик атомарный (проблема для многопоточки)
Что за бред?
> Используя std::unique_ptr, ты можешь быть уверен, что указателем под этим классом всегда владеет только один единственный объект
Не можешь.
> C чего ты решил, что тут нету гарантий?
С того что ничто не мешает разыменовать `unique_ptr` хранящий nullptr, или взять два `unique_ptr` на один объект.
> Не существует такого термина как "управляющий блок".https://en.cppreference.com/w/cpp/memory/shared_ptr
Прочитай раздел "Implementation notes".Тоже самое касается атомиков в реализации счетчика ссылок:
To satisfy thread safety requirements, the reference counters are typically incremented using an equivalent of std::atomic::fetch_add with std::memory_order_relaxed (decrementing requires stronger ordering to safely destroy the control block).> С того что ничто не мешает разыменовать `unique_ptr` хранящий nullptr, или взять два `unique_ptr` на один объект
Это не проблема С++, это логическая ошибка, в растее точно так же в unsafe контексте можно взять 2 смарт поинтера на один и тот же объект. Ровно тоже самое про nullptr: в расте тоже можно создать указатель, хранящий нечто похожее на nullptr из С++ и разыменовать его.
> Тоже самое касается атомиков в реализации счетчика ссылокТы сказал что это плохо для многопоточности. Чем это плохо? Наоборот, это хорошо для многопоточности, потому что позволяет обращаться к указателю из разных потоков, и атомики - наиболее эффектвная реализация. Это плохо для однопоточных программ, где приходится впустую дёргать тяжёлые операции.
> Это не проблема С++, это логическая ошибка, в растее точно так же в unsafe контексте можно взять 2 смарт поинтера на один и тот же объект. Ровно тоже самое про nullptr: в расте тоже можно создать указатель, хранящий нечто похожее на nullptr из С++ и разыменовать его.
Это полнейшее непонимание принципов безопасности языка. Это проблема C++ потому что там это можно сделать, всегда, везде, в любом месте и любым способом, и язык никак этому не помешает. В Rust так сделать по умолчанию нельзя. В этом и заключается безопасность.
Простите, я тут из джавы к вам заглянул, сильно не серчайте, но у нас "хорошо" атомики для многопоточности или "плохо" зависит от того, насколько многопоточность конкурентная (речь про contention), так как атомики у нас на compare-and-swap неблокирующих операциях. Если потоков много и все они конкурируют за один атомарный счётчик, то это место становится бутылочным горлышком, потому что потоки постоянно уходят в бессмысленный и беспощадный spin loop.
Тем, что в расте, не пользуясь ансейфом, нельзя работать с кучей не через смартпоинтер. А если говорить в целом, чем он лучше - так это тем, что, первое что пришло в голову:
1) нет null, вместо этого обязательная обработка обоих вариантов развития событий у местного опшинала
2) система типов линейная, в силу чего деструктор будет всегда тривиальным и автосгенеренным компилятором (трейт Drop способом реализовать нетривиальный деструктор нельзя, это тупо коллбек на выполнение кастомной логики при уничтожении объекта, например, закрытия дескриптора, про который раст ничего не знает, потому что он пришел через FFI вызов из сишной DLL/SO).
3) боров чекер и zero-cost имитация reader-writer блокировки через зашитые в компилятор правила работы с mutable/immutable ссылками (у тебя не будет гонки потоков в программе, если тебе язык синтаксически не позволяет выразить стейт, приводящий к гонке).
Короче, то, что в С++ идиома и бест практис, который программсту один хрен нужно будет реализовать, потирая в 4 утра красные слипающиеся глаза перед дедлайном, в Rust является частью compile-time семантики, тупо не позволяющей собрать приложуху, если что-то написано не по феншую.
Поэтому поргромисД на Rust, потирая в 4 утра красные слипающиеся глаза перед дедлайном влупенитЪ(С) unsafe и накропает кусок на плохом С.
Идите в Ж пЫонеры! (С) Одна бабушка
От идиотов ни один язык не страхует.
В твоём случае другой, более адекватный программист на Расте, легко найдёт проблему по маркеру unsafe. В плохом Си глаза у него таки останутся красными в попытке потом найти баг.
При чём тут идиоты. Иногда надо сделать быстро, из говна и палок. Так и получается технический долг.
#include <iostream>
#include <memory>int main() {
auto i = std::unique_ptr<int>(new int);
*i = 5;
std::cout << "i = " << *i << "\n";
std::unique_ptr<int> j = move(i);
std::cout << "i = " << *i << "\n";
// можно написать return 0, но бестолку, потому что предыдущая строчка сегфолтнется
}Смартпоинтеры не дают никаких гарантий, они лишь немного упрощают статический анализ.
А зачем ты читаешь из перемещённого указателя?
Чтобы показать, что C++ ничего не гарантирует. Программист на C++ может гарантировать, но только на словах: "мамойклянус". А C++ не гарантирует ничего.
Гений инвалидировал указатель, создав для него moved-from state контекст, это черным по белому прописанно в стандарте. Почитай, что такое moved-from sate и почему у тебя тут сегфолт, а потом уже ной, что ты не знаешь стандарта.
> Почитай, что такоеСкажи мне, ты действительно настолько тупой, что не понимаешь, что код был скрафчен руками так, чтобы показать UB, и сделано это было с опорой на знание дебилизма стандарта C++?
> Гений инвалидировал указатель
Не надо лести, любой программист прочитавший стандарт сможет сделать то же самое, чтобы продемонстрировать, что при разработке на C++ только программист может что-либо гарантировать, C++ не гарантирует ничего.
Почти аналогичный код на твоем любимом и "самом безопасном" расте.use std::ptr;
pub fn main() {
unsafe {
let ptr: *mut i32 = std::ptr::null_mut();
*ptr = 111;
println!(*ptr);
}
}Догадайся, что будет выведено на экран?
Это еще кстати к слову об "отсутствии" nullptr )
Интересно, если в документации у растоманов это помечено как UB, для них это типа не счиатеся UB?
P.S:
Разумеется, println! принимает формат-строку: по этому коррентнее будет println!("{}", *ptr)
Ничоси! 11 метровый файл на выходе!! Что за нах?
> Ничоси! 11 метровый файл на выходе!! Что за нах?У меня около 9.2 МиБ получился.
А это вот раст, который "легковесный" и в котором все "безопасно" и "без оверхеда" )
Как у них круто реализована концепция "Не платим за то, что не используем".
Вообще у меня такое ощущение, будт-то компилятор туда еще и отладочную информацию запихнул, хотя флаг -g не выставлен.
Если бы ты, кроме форума, читал ещё документацию по обсуждаемому предмету, то знал, что это так и есть. По умолчанию компилятор впихивает отладочную информацию и использует статическую линковку. Если нужно, всё это отключаемо. Но чукча (точнее очередной опеннетный "эксперт") не читатель.
> По умолчанию компилятор впихивает отладочную информацию и использует статическую линковку. Если нужно, всё это отключаемо.Ну, собственно, этим все и сказано. Опять эти "если не нужно - не используй" и тп...
То есть получается, раст не умеет в принципы KISS и "не платим за то, что не используем".
Как жаль, ведь столько громких заявлений было про него.
> Если бы ты, кроме форума, читал ещё документацию по обсуждаемому предмету, то
> знал, что это так и есть. По умолчанию компилятор впихивает
> отладочную информацию и использует статическую линковку. Если нужно, всё это отключаемо.
> Но чукча (точнее очередной опеннетный "эксперт") не читатель.Кстати, а почему бы не пойти дальше, и не запихать вообще все "так нужные" библиотеки в core раста?
Ну а что, было бы удобно: и 100500 реализаций спецификации OpenGL, чтобы GUI рисовать, например.
Вот почему линковаться статически научились по умолчанию, а в реализацию компилятора под такое же кол-во архитектур и написание собственного рантайма без libc - не смогли?
По умолчанию в программу включается отладочная информация. Плюс используется статическая линковка. Всё это можно отключить при необходимости. Об этом уже на этом сайте говорилось огромное количество раз.
Так ты ж сам написал unsafe. Зачем?
Сделай UB без unsafe, тогда поговорим
Похоже, твой оппонент таки был прав. Ты реально глуп. В Расте, если не использовать unsafe, ты подобного не напишешь. В плюсах у тебя нет никаких опций для этого.
> Похоже, твой оппонент таки был прав. Ты реально глуп. В Расте, если
> не использовать unsafe, ты подобного не напишешь. В плюсах у тебя
> нет никаких опций для этого.Похоже, мой оппонент немного фанатик псевдо-безопасного раста, раз пишет подобные заявления.
Использование unsafe контекста для данного примера как раз необходимо, чтобы создать одинаковые условия для сравнения языков, и что их любимый и "самый безопасный" язык точно так же не дает __никаких__ гарантий относительно точно такого же unsafe кода.Как-то опять двойные стандарты пошли: программистам на расте можно говорить что-то про UB в C++, а вот если им начинаю предъявлять за самые глупые ошибки даже в их собственной стандартной библиотеке и про ровно точно такой же код в unsafe, то они плачут и оправдывают это словами "ну это же логическа ошибка" и "по умолчанию так нельзя" и бла-бла-бла.
Кстати, почему вы вообще сравниваете С++ и Rust? По-моему это вообще никак не сравнимо, это абсолютно 2 разных языка с разными подходами к их использованию.
Я согласен, проверка всего этого в compile-time - это здорово, но не нужно это возносить как средство от всего. Кроме того, существование подобной штуки в языке наоборот препядствует адекватному восприятию безопасного кода (логические и семантически ошибки твои compile-time проверки никак не исправят). Не надо натягивать маску клоуна, чтобы выступать в цирке.
> Использование unsafe контекста для данного примера как раз необходимоНет, оно нужно для того, чтобы у тебя появилась возможность заменить смарт-поинтеры raw-указателями.
Попробуй скомпилять вот это, вот тебе unsafe но со смарт-поинтерами:
fn main() {
unsafe {
let i = Box::new(5i32);
println!("i = {i}");
let _j = i;
println!("i = {i}");
}
}Этот код не компилируется:
rustc tmp.rs
error[E0382]: borrow of moved value: `i`
--> tmp.rs:6:17
|
3 | let i = Box::new(5i32);
| - move occurs because `i` has type `Box<i32>`, which does not implement the `Copy` trait
4 | println!("i = {i}");
5 | let _j = i;
| - value moved here
6 | println!("i = {i}");
| ^ value borrowed here after move
|Попробуй найти способ получить в i невалидный указатель, разадресация которого приведёт к UB. Используй unsafe или не используй, как тебе покажется удобнее. Вот когда ты найдёшь такой способ, я смогу тебе на нём объяснить, чем смарт-поинтеры Rust'а лучше C++. А пока не найдёшь, тебе придётся оставаться в неведении.
> Кстати, почему вы вообще сравниваете С++ и Rust?
А ты зачем сравниваешь C++ и Rust? Ты тут самый активный участник обсуждения, и вдруг ты начинаешь всех обвинять, что они это обсуждение ведут. У тебя какая-то конкретная некогерентность в поведении наблюдается.
>> Использование unsafe контекста для данного примера как раз необходимо
> Нет, оно нужно для того, чтобы у тебя появилась возможность заменить смарт-поинтеры
> raw-указателями.
> Попробуй скомпилять вот это, вот тебе unsafe но со смарт-поинтерами:Вот код на расте: https://godbolt.org/z/8hPrK7ddv
Вот аналогичный код на C++: https://godbolt.org/z/j63E6jh4o
И там, и там - это ошибка компиляции, дальше что?> Попробуй найти способ получить в i невалидный указатель, разадресация которого приведёт к UB.
Любой volatile указатель, или указатель, который используется в коде на C. Очевидно, если он приходит от C API, то управляешь им не ты, а значит нужно использовать "сырые" указатели, относительно которых нету гарантий.
> Вот код на растеСори. Там js нужен, у меня не работает.
Но, глядя вот на это:
> И там, и там - это ошибка компиляции, дальше что?
Я могу сказать тебе, что ты аргумент совершенно определённо пытаешься выставить кривым образом. Если C++ код можно написать так, чтобы он фейлился на этапе компиляции, когда программист попросил сделать что-то глупое, то Rust-код нельзя написать так, чтобы он не фейлился на этапе компиляции, когда программист попросил сделать что-то глупое.
Вчитайся в эту фразу. Я её укоротил как мог, чтобы тебе проще логику было бы применять. Оно из-за этого не совсем верное стало: я выкинул оговорку об ограничении классов глупостей программистов. Но ты тем не менее вчитайся, и пойми что приводя примеры когда C++ что-то ловит на этапе компиляции ты ничего не докажешь. Тебе надо показать, что невозможно написать код на смартпоинтерах C++, который не сфейлится на компиляции но сфейлится в рантайме.
> Любой volatile указатель, или указатель, который используется в коде на C.
В смысле смарт-поинтер, или raw-поинтер? Если второе, то тебя опять заносит в raw-поинтеры, хотя мы говорим о смарт-поинтерах. Если первое... Ну я не знаю, например, может ты можешь рассказать как взять raw-pointer, который по логике volatile, завернуть его в Volatile[1], и потом получить UB, работая с Volatile, то расскажи нам об этом. Или может у тебя в голове какой-то другой сценарий? Расскажи нам об этом.
> Этот код не компилируется ...Так же некоторый вопрос: чем же смарт-поинтеры в расте лучше, если компилятор зачем-то перемещает состояние, когда копирование запрещено? Причем делает это неявно, даже не выдавая диагностики.
Хотя C++, например, это вообще-то ошибка компиляции, и компилятор обязан выдать диагностику.
> компилятор зачем-то перемещает состояние, когда копирование запрещено?Компилятор перемещает, потому что я попросил его переместить значение. Я в курсе что Copy не реализован для Box'а, в этом фишка Box'а, это смарт-поинтер, а не член собачий. Box гарантирует, что он будет в единственном экземпляре. Если бы мне нужно было клонировать, я бы сделал:
let j = i.clone();
Но тогда я бы получил вторую аллокацию памяти и в i и j лежали бы разные Box<i32>, которые по значению бы совпадали, но были бы разные. В терминах lisp'а, они были бы equal, но не eq.
> Причем делает это неявно,
Да, это дефолтное поведение типов в ответ на =, описанное в любом материале для личинок растоманов. Clone и Copy -- это дополнительные трейты, которые разработчик этих типов может навешивать на них, а может нет. Таким образом move -- это дефолт в расте.
Но это иррелевантно нашему разговору, разговор о том, что UB не возникает. И ты так и не придумал, как его создать на смарт-поинтерах.
Или может не совсем иррелевантно... Это ведь суть отличий смарт-поинтеров C++ и Rust'а, так? Та самая суть которая делает смарт-поинтеры Rust'а смарт-поинтерами, и оставляет смарт-поинтеры C++ членами собачьими.
> даже не выдавая диагностики.
Ты в глаза долбишься, или что? Я тебе привёл диагностику. Не всю, там ещё хинты всякие для нубов, что можно сделать чтобы код скомпилировался, но я и не стал копировать.
> Хотя C++, например, это вообще-то ошибка компиляции, и компилятор обязан выдать диагностику.
В C++ это не ошибка компиляции, выше по треду есть аналогичный C++ код, и компилятор C++ его радостно компилирует и выдаёт на выходе бинарь. А вот в Rust'е это ошибка, и раст как раз выдаёт ошибку компиляции и диагностику.
Ты чо, крeмлeвcкoй пpoпaгaнgы пересмотрел, и решил что обвинять других в своих грехах -- это хороший способ вести дискуссию? Нет, это может быть эффективным способом пpoпaгaнgы -- не знаю, но в дискуссии тебя будут макать в чан с известной субстанцией за каждую такую попытку.
> move occurs because `i` has type `Box<i32>`, which does not implement
> the `Copy` traitВот чем rust приколен так это абсолютно марсианской диагностикой.
Это не марсианский, это английский.
Санитайзер, да даже clang-tidy тебе об этом скажет
clang-tidy скажет об этой ошибке> used after it was moved [bugprone-use-after-move,-warnings-as-errors]
не говоря уже о санитайзерах.
Странно сравнивать абстракцию для контроля над временем жизни объекта и языком, но: cмартпоинтеры добавляют оверхед в рантайме; смартпоинтеры не устраняют проблемы рейсов; cмартпоинтеры используются и в расте, но по возможности, лучше обходиться без них. А ещё, у раста удобный синтаксис.
И unique_ptr добавляет оверхед в рантайме?
А я всё равно LLVM не брошу, потому что он хороший. ГСС бяка несовременная.
Я тоже отчасти был согласен с этим аргументом до выхода 20го стандарта, однако эта вот самая "бяка несовременная" реализовала модули в ощутимо большем объеме, нежели модный шланг с якобы хорошей для таких дел архитектурой.
Так что ну... не все так просто в этом вопросе
А еще LLVM вымахал в огроменную, жирную и тормозную мегалибу где одна только .so кодогенератора весит 60 метров. А крутая у проекта архитектура - один 60-метровый .so, сразу видно, нонейм раджа из корпорации сархитектил. Не очень думая о том что будет с проектом когда он оптимизаторов навернет и запилит с десяток архитектур. Ведь для реализации задания босика здесь и сейчас все это не надо было, а там получил премию и хоть трава не расти.
Крутая у проекта архитектура. Одна либо на 60 мегов, а не 10 компиляторов для каждой архитектуры по 45 мегов каждый.
> Крутая у проекта архитектура. Одна либо на 60 мегов, а не 10
> компиляторов для каждой архитектуры по 45 мегов каждый.С другой стороны... если я собирался компилять только под вот этот десктоп, мне вгрузится дохреналион мусора, шланг в полном комплекте никак не 45 метров. А с gcc будет только вон то.
Более того - это жирное месиво память будет жрать оптом. Вгружая вообще совсем все. И требования к ресурсам получатся более другие. Хотел ли я компилять под тот ARM на той машине - отдельный вопрос так то.
Более того. Шланг поддерживает здорово меньше архитектур. В какого кадавра ЭТО превратиться если попробовать приблизиться к уровню GCC можно лишь гадать. Но можно с умным видом рассказать что эти архитектуры не надо, как вариант. И мы будем компилять там GCC'ом, а чем же еще.
А если этого мало - пересобрать GCC под желаемый таргет весьма подъемная задача. Я это активно практикую, это в пределах досягаемости смертного с не сильно позорным компом. А вот то же самое для LLVM повторить... уу... это совсем другие затраты ресурсов и усилий и серьезная заявка на билдферму. Или туповэйтинг черти сколько.
Современные разработчики совсем обнаглели. Кто заплатит пользователям за размещение у себя на диске огромной либы на 60мб? Кто заплатит за терабайты оперативной памяти? Разработчики llvm?
Не надо перекладывать с больной головы на здоровую. Это твой хозяин нанял безрукого тебя, чтобы экономить. Это ты работаешь тяп-ляп и быстрей-быстрей. Это ты и твой хозяин - жлобы, а не пользователь ПО. Он, как раз, усердного работает, ответственно тебя учит и лечит, чтобы ты был умный и здоровый, и чтобы ему хватило на новое железо под постоянно растущие требования твоих калькуляторов на JS, Java и C#.
Все так и есть. Я пишу за еду на java и js 😥
А также на kotlin, php, ts. Фронтэнд, бэкэнд и мобильное приложение одновременно.
А ещё на 2 языках запросов к базе данных, 8 фреймворках и это не полный список 😥
А так как программирую плохо и учиться тяжело, то уйти из помойки не могу 😥
слабак. руки ноги все есть ? займись физическим трудом. будешь через месяц плеваться что вс.ал пол жизни в похапе свое
> слабак. руки ноги все есть ? займись физическим трудом. будешь через месяц
> плеваться что вс.ал пол жизни в похапе своеАга, в шахту иди фигачить. Заодно потом сравним продолжительность жизни с пхпшником. Хотя если жить настолько надоело, сейчас есть и более эффективные способы сделать свою жизнь короткой и насыщенной.
LLVM - бяка смузи-модно-молодёжная, потому что.
Впечатление что эти новости кто-то специально форсит, будто ничего другого не происходит в мире opensource.
Мне кажется, это у вас повышенное внимание именно к расту
раст - это 90% хайпа и форсинга. на поверку он не полезнее чем go или c++, каждый из которых хорош в своей нише.
c++ не может быть хорошим по определению, это де тупо говно мамонта и куча угловых скобок
а раст типа свежее и потому лучшее? есть куча не только скобок
> c++ не может быть хорошим по определению, это де тупо говно мамонта
> и куча угловых скобокА в хрусте палочки и закорючки какие-то для примерно того же. Ну и чо, лучше стало? :)
Вот ты и попался, с C++17 угловые скобки для шаблонов не обязательны, а С++20 еще больше старого сахара не обязательно
К тому времени когда его допишут (Раст) уже cpp2 от Саттера будет готов.
Комментарий уровня: "Я создам новый язык программирования (форк JavaScript), в котором не нужно будет писать фигурные скобки, тем самым разработчики сэкономят кучу времени", ...
Новости с растом получаются одними из самых обсуждаемых на этот ресурсе, так почему нет? Тем более язык УЖЕ добавлен в ядро и от него не отвертеться.
> Новости с растом получаются одними из самых обсуждаемых
> язык УЖЕ добавлен в ядроЭто всё следствие искусственного шума. Только не пойму в чьих интересах. Я кроме опеннета на многих ресурсах сижу, большая часть зарубежные. Нигде такого форса нет как тут.
Просто мало кто сюда других новостей пишет, не смотря на то что может каждый. На том же похорониксе за сегодня вышло 10 новостей и все написал один человек. Новость про раст просто теряется среди других.
>Это всё следствие искусственного шума.Не думаю, что Торвальдс падок на такие шумы.
>Я кроме опеннета на многих ресурсах сижу, большая часть зарубежные. Нигде такого форса нет как тут.
Может быть, вы не там сидите? На том же реддите, фочане довольно часто о расте пишут.
r/rust
> Не думаю, что Торвальдс падок на такие шумы.Ну так через него и пролез только минимальный комит с совсем базовым нечто, чтобы желающие могли по...ся с этим уже чуть более предметно. И вот это вот - после нескольких месяцев футбола и откровенных вопросов вида "какой к черту panic() в ядре при нехватке памяти?!" - которые вон тем пришлось привести во вменяемый вид.
Торвальдс падок на эксперименты. В непонятной ситуации он предлагает оставлять обе альтернативы и давать сообществу выбирать победителя. Так всегда было. Вот только является ли сообщество ядра по-прежнему технократическим или хайп, маркетинг и влияние корпораций теперь имеют больше влияния - это открытый вопрос.
Они вроде вполне рациональные технократы. И под этим углом у сабжа есть определенные здравые идеи. Просто общая реализация хайпежная.
> Только не пойму в чьих интересах.Внезапно, в интересах тех, кто это ядро разрабатывает и, что ещё важнее, тех, кто его разрабатывать будет дальше. А недоумение твоё от того, что к разработке отношения имеешь не больше, чем морские свинки к морю и свиньям.
> язык УЖЕ добавлен в ядроА зачем вообще потребовалось rust ДОБАВЛЯТЬ в ядро? У него такой сложный компилятор и такой жирный рантайм, что не получается сделать автономный модуль на rust?
Может сначала rust должен осилить работу на микроконтроллерах с некоим мелким аналогим newlib, а потом уже лезть в ядро?
> Может сначала rust должен осилить работу на микроконтроллерахзадача раста - не в том, чтобы работать...
А в чем?
зарабатывать
Гранты осваивать
Переписывать, переписывать, переписывать
вообще по минимуму такие затеи есть, криво и специфично но все же...а вот зачем newlib в мк - кто б его знает? вообще не критерий.
>> язык УЖЕ добавлен в ядро
> А зачем вообще потребовалось rust ДОБАВЛЯТЬ в ядро? У него такой сложный
> компилятор и такой жирный рантайм, что не получается сделать автономный модуль
> на rust?А еще в огороде бузина. Опеннетные эксперты совсем не палятся "знанием" матчасти.
> не палятся "знанием" матчастиПояснил бы. Понятия не имею что за зверь такой rust и зачем ему так потребовалась поддержка в ядре. Написать модуль для ядра linux на том же C++, или на паскале (допустим, так https://wiki.freepascal.org/linux/kernel), или на ассемблере можно уже сейчас.
Что ж такого потребовалось для rust, что пришлось явно добавлять поддержку rust в ядро?
>> не палятся "знанием" матчасти
> Пояснил бы. Понятия не имею что за зверь такой rust и зачем
> ему так потребовалась поддержка в ядре. Написать модуль для ядра linux
> на том же C++, или на паскале (допустим, так https://wiki.freepascal.org/linux/kernel),
> или на ассемблере можно уже сейчас.И много в ядре модулей на паскале или С++, о теоретик?
> Что ж такого потребовалось для rust, что пришлось явно добавлять поддержку rust в ядро?
Возможность закоммитить свой код в ядро?
>Может сначала rust должен осилить работу на микроконтроллерахС добрым утром.
Все очень просто - язык развивается очень быстрыми темпами и очень много где его пытаются присунуть, от чего ещё больше хайпа
Присунуть, это вы удачно заметили.
"- Что там за шум на улице, Бэрримор?
- Это раст-парад, сэр.
- И чего же они требуют, Бэрримор?
- Убрать сишные дыры, сэр.
- Им разве кто-то запрещает?
- Нет, сэр.
- Так почему же всё-таки они шумят?
- ...rustы, сэр."
"- Что там за шум на улице, Бэрримор?
- Это эксперты по программированию, сэр.
- И чего же они требуют, Бэрримор?
- Чтобы программы писали на ANSI C
- Им разве кто-то запрещает? Пусть пишут.
- Нет, сэр, не запрещает.
- Так почему же всё-таки они шумят?
- Они неспособны, сэр."
Лол, даже сдесь растаманы не смогли ничего придумать и просто переписали уже написанное.
А если серьезно, скопипащу свое размышление:
Мне пришло осознание, что приход Rust вместо C неизбежен. Да и не обязатльно именно Rust.
Да, технически он лучше, для глаза — вырвиглаз, по семантике порог вхождения наоборот выше, примерно как на C++, не для тупых это точно, противоположность Ts-JS.
Да, действительно более безопасный бинарник, и даже не важно, что власть над центральным репозиторием будет у корпоратов под вывеской общественной организации (Rust Foundation).А то, что когда население загонят в облака и онлайн, в интернет людей, то помешать этому мятежным хакерам или конкурентам будет гораздо сложнее.
Корпораты же будут иметь полную власть, которую обретут по примитивным и противоестественным человеку потребностям, пассивности и безответственности населения.
Т.е. они будут писать прошивки-фирмвари для устройств, UEFI, аналогов Intel ME/AMT или AMD PSP, работающих вне всяких ограничений. Всякие системы на крипте и блокчейнах. Это меньшинство интеллектуально лучших разработчиков будет делать.
А фронтом к этому всему и всякому ширпотребу с точки зрения этой всей системы будут вебм@каки, которых всегда предостаточно. Только софт вебм@как будет не системного уровня, и как пример платформа deno — замена NodeJS написана уже не на Си, а на Rust.
Другими словами, вебмакаки и всякие мобильные разработчики просто уровнем ниже в этой пирамиде, и их больше чисто статистически по их способностям.
Т.ч. стартап HAL/LL на Rust взлетит, но правда до того момента, как откажется быть поглощенным. И сделать это не трудно, т.к. объявить адреса памяти и регистров под идентификаторы, получится тот же CMSIS. И так далее.
Закусывать надо все же
Я 6 лет не пью, поэтому соображаю.
В каждой новости про rust начинается бурление.
Он как красная тряпка для местных экспертов по программированию
Позитивная новость. Надеюсь, что через год получится собрать на один llvm меньше ;)
Вроде и позитивная. Но как бы это не стало серьезным якорем для развития самого языка.
Зачем развивать язык? Язык это инструмент. Это всё равно что развивать кувалду или топор. Соответствует тьюрингу? — БОльшего и не надо. Любой синтаксический сахар вреден и от него нужно отказываться, т.к. это усложнение ради усложнения. Посмотрите во что превратился PHP. Он теперь сложнее Java. Язык нужно оптимизировать на уровне компиляции и эффективности генерации машинного кода, а не развивать, добавляя туда как можно больше сложных конструкций.
> Это всё равно что развивать кувалду или топор.Зачем развивать бензопилы, можно топорами деревья рубить. Зачем шуруповёрт, есть отвёртка. Зачем шурупы, есть гвозди. Зачем компьютеры, если есть счёты. Местные эксперты не перестают меня удивлять.
Джаваскриптизеры, молчать!
> Джаваскриптизеры, молчать!У них бензопилы, но цепь у нее все же пластмассовая. Так проще и быстрее произвести было, извините. Как сломается, приходите за новой, с удовольствием продадут новую.
А вы не задумывались, зачем добавляют больше этих конструкций? Не для тго ли, чтобы зык был более выразительным и давал больше информации компилятору? Вот есть тьюринг полный brainfuck. Но вряд ли вы там что-то наоптимизируете
> более выразительнымПотянуло смузи.
Штош.. Пишите и дальше в машинных кодах..
> Штош.. Пишите и дальше в машинных кодах..А ведь таки пишут. Даже вон тот пафосный гугель в своем кодеке не гнушается. А что делать, если simd интринсики разгоняют вон ту операцию в пять раз?!
> машинных кодах
> интринсикиЛамо294, опять ты?
Лучше продолжай писать пафосные простыни без конретики - так у тебя меньше шансов ляпнуть очередную чушь ...
Штош.. Пишите и дальше в машинных кодах..
Настоящий программист это тот кто может написать любую программу на любом соответствующем тьюрингу языке.
Так называемые программисты на rust, как и так называемые программисты на java даже не знают что значит "соответствовать тьюрингу", не знаю что такое шина адреса и вообще ничего не знают, но лезут со своим так называемым языком в ядро.
Иди на Brainfuck пиши, поехавший.
>Вот есть тьюринг полный brainfuckНастоящий программист это тот кто может написать программу на любом полном по Тьюрингу языке. Если программист не может писать любой сложности программу, для однокомандного компьютера с FlipJump, то он никакой не программист, а недалекий растоман и должен идти вон из профессии. Например "программировать" фронтэнд
Настоящий программист знает, что на разных языках сложность и скорость решения задачи разная. Можно и фронтенд программировать на ассемблере, но зачем?
Покажите написанный вами фронтэнд на ассемблере. Очень интересно на это посмотреть
> Посмотрите во что превратился PHP. Он теперь сложнее Java.ПХП вырос вместе со своими пользователями, следуя запросам, которые эти самые пользователи перед ним ставили. Раньше он был языком для написания прототипов, которые не жалко выкинуть и дорого обслуживать, теперь же он подходит и для прототипирования, и для последующей поддержки бизнес-логики.
При этом переход между 5 и 7 дал очень хороший прирост производительности, а опкеш прелоадинг и JIT позволят ему и дальше обгонять всякие питоны.
И в результате PHP стал здоровым монстром, с которым страшно связываться, малореально обслуживать, апгрейд версии требует командочку инженеров......и в результате он как-то взял и стал deprecated. Новые проекты пишут на чем-ниудь другом. А опкеш и JIT его добьют окончательно. И пока они будут рубиться с питоном, штуки типа игого и хруста с тематичными либами их зашибут как таракана тапком. А прикиньте, там не надо париться ни кешами ни jit?! Да и идея прогнать проверки адеквата програмера на фазе сборки - здравая, что ни говори. Сильно лучше чем когда прод с рантайм егором наворачивается.
> Сильно лучше чем когда прод с рантайм егором наворачивается.Ну навернется с паникой, разница то..
> Ну навернется с паникой, разница то..Ну блин, ты хотел чтобы софт вообще никогда нигде не наворачивался? Если требования такие то читать придется что-то типа MISRA C и иные специфичные стандарты, где много вещей диковатых для мягкотелых апликушников.
Только не надо про околосветовую скорость ПХП...
На голом ПХП уже наверное никто не пишет (к сожалению).
А эти ваши ларавели и симфонии с доктринами и вордпрессы тормозят так, что даже джанге и не снилось.
И ни какой opcache не спасает.
*Раньше* он был язык для персонал хоумпагес. Так и развивался.
Посмотри на последние изменения в самом языке Rust. Некоторые функции переведены из бета в стабильный интерфейс. Некоторые функции подшаманили и теперь их можно объявлять constexpr. Некоторый синтаксис теперь можно использовать для других мест, где раньше было ограничено. Почему? Потому что нельзя сделать сразу завершённый язык. Некоторые вещи просто не успели отладить и доделывают, на некоторые просто не было времени, где-то придумали схему как оптимизировать метод внутри, при этом уменьшив ограничения снаружи. Можно ли написать программы без всего этого? Да конечно, просто это требовало больше бойлерплейт кода, обходить ограничения, искать хаки на SoF и прочее. Теперь это всё возможно намного проще в самом языке.
Второй точкой для развития языка является то, что пользователи, когда видят фасад стандартной библиотеки, хотят больше возможностей. Требования к ПО и соответственно требования к языку изменяются со временем. Иначе бы и сейчас все сидели бы на C/C++. Иначе бы не было всех этих C++17, C++20 и далее. Разве нельзя было тоже самое сделать на C99? Лишь тот язык живой, который развивается.
"Соответствует тьюрингу? "
Как это язык или кувалда может соответствовать тьюрингу?
Что это вообще означает "Соответствует тьюрингу"? Знал ли это Алан Тьюринг или это изобретение местных экспертов по программированию.
> Зачем развивать язык? Язык это инструмент. Это всё равно что развивать кувалду или топор.Мне для развития топора подбирать ссылок влом, но давай я про кувалду накидаю?
1. https://www.youtube.com/watch?v=PquEWbQdkvc Чувак куёт простой кувалдой.
2. https://www.youtube.com/watch?v=KsFTp2Qszko Чувак использует power hammer, и обычную кувалду. Но если ты присмотришься к его "обычной" кувалде, то он её явно сам себе делал, и это вовсе не параллелепипед с дыркой, проткнутой палкой.
3. https://www.youtube.com/watch?v=tBEbGb3xyWE а вот это реально уже кувалда эволюционировавшая в пресс, и подумай как такое можно сделать неэволюционировавшей кувалдой.
Как оно может стать якорем? Если gcc не будет поспевать за стандартом раста, его просто не будут использовать, как не используют уже в куче других ниш ге он безнадёжно отстал.
А будет ли раст реализовывать собственный бекэнд? Просто, как я понял, в расте не могут довести до ума некоторые фичи именно из-за llvm.
> в расте не могут довести до ума некоторые фичиЭто его архитектурная проблема от рождения.
Какие например? Вообще переписывать выглядит слишком масштабно и дорого. Кор разработчики обычно стараются идти наиболее практичным путем
https://github.com/bjorn3/rustc_codegen_cranelift
Хде мой карбон?
"If you can use Rust, ignore Carbon" из официального faq карбона
Карбон по синтаксису, да и во возможности интеграции в проект c/c++ кода на порядки лучше раста. Не нужны никакие cbindgen. Я как-то раз увидел биндинги к одной си pdf библиотеке для языка D, больше не открываю сайт Dlang. Из всех убийц Си++ совместимых с Си++ у Карбона есть реальные шансы быть лучшим системным ЯП.
> Из всех убийц Си++ совместимых с Си++ у Карбона есть реальные шансы быть лучшим системным ЯП.Ровно ноль шансов. Даже если рассматривать какие-нибудь маловероятные события, типа божественного вмешательства, всё равно шансов ноль. Как у C++ всегда было было ноль шансов стать системным ЯП, так и у карбона.
Слишком много сложности в языке, с невнятными для системного программирования бонусами от этой сложности. Системное программирование -- это как раз то, которое очень ценит KISS, и если тебе нужен ООП, то ты явно про KISS забыл.
Одна только проблема с этим вашим Карбоном пишет его корпорация не способная сделать нормальный CMake,
а вместо этого нужено JDK ставить и выкачивать пару гигов каких-то классов. Когда научаться писать программы самодостаточные тогда и можно говорить о каких-то аналогах, а пока это собрать без свистоперделок невозможно просто смешно... Загубили все дело своим говеным фантиком...
Посмотри в компайлер эксплорере, что твай карбон выдает
Твой карбон ещё в зародыше, его даже не существует. Первый релиз намечен того гляди на 2024-2025. Если к тому времени гугл дерзко, как мы знаем любит, может выкинуть эксперимент на грейвярд.
Написать прошивку для soho роутера, безопасно и надёжно, вот казалось бы самая ниша для раста.Есть хоть одна такая прошивка, уже не говорю про ОС для soho-роутера?
Нет? А почему? Но зато давайте пропихнем раст туда, раст сюда...
Ну так специально Вам дали шанс. Пожалуйста, напишите прошивку для soho роутера на расте, умоляем Вас
Начни с того: "а это вообще возможно?". Почему под редох не могут написать дрова, но лезут писать дрова в линух?
Да тут множество вопросов риторических.Вот тут уже ниже доложили, что раст не просто так универсальная замена С/С++, а только для браузера, написанного исключительно по аджайл-абырвалг технологии. Вот там всё надёжно будет аж ваще.
А просто прошивки пейсать, это не про раст оказывается.
Эвона чо.
Вы не поняли, коллега, мой пойнт. Повторю.Вот есть Zycell, d-link, tp-link, mikrotik, и так далее.
Они выпускают свои железки, в которых перманентно находят уязвимости и возникают всякие ошибки. С одной стороны.
С другой стороны у нас появился супер пупер дупер безопасный раст, который именно для решения этих проблем и создан.
Хоть кто-то из производителей почесалмя переписать прошивку на раст? Нет.
Вопрос: почему?
Вариантов ответа на вопрос два и оба для раста неприятные.
1. Может и будет лучше, но переписать простейшую прошивку очень долго, очень трудно и очень дорого.
2. Переписывание на раст проблем не решит, поэтому зачем тратить на это ресурсы?
>С другой стороны у нас появился супер пупер дупер безопасный раст, который именно для решения этих проблем и создан.У каждого инструмента - своя область применения. Rust - не для встроенных систем. Rust - это попытка решить проблему ненадежности кода на C/C++, применяемого в таких проектах как Google Android, Google Chromium/Chrome, GNU GCC, Linux. Дело в том, что в этих продуктах при разработке применяется методология Agile, а иногда даже Extreme, а это совсем не то что в обычных проектах по обычной методологии, когда сначала составляется список требований, потом делается прототип, потом разрабатывается рабочий проект, потом пишется код, при этом каждый этап разработки проходит верификацию, потом проект проходит валидацию (опытное эксплуатирование) и только потом сдаётся в эксплуатацию. В agile-проектах Rust _действительно_ позволяет повысить надёжность кода, но в проектах по обычной методологии Rust неэффективен.
Коллега, вы понимаете, что вы занесли сейчас очень тяжёлый бред, говорящий о полной оторванности от реальности?
Я не коллега :), поэтому и оторван от реальности. Но OpenNet -это такое место, где не страшно показать свою некомпетентность, можно надуть щёки и изобразить из себя кого угодно.
Это в какой госконторе вас так мучают? Щас по водопаду работает исключительно военщина и для технических проектов. Все госуслуги, честные знаки и прочее писаны по скраму/канбану (я там был какое-то время, все как везде - дейлики,сторипоинты).
Современные так называемые программисты просто не способны понять этих очевидных вещей
> Они выпускают свои железки, в которых перманентно находят уязвимости и возникают всякие
> ошибки. С одной стороны.Типа, если обезьяне с гранатой выдать гранату другой системы, случится чудо и это перестанет быть обезьяной с гранатой?
> Типа, если обезьяне с гранатой выдать гранату другой системы, случится чудо и это перестанет быть обезьяной с гранатой?Типа да. Но, как мы видим, это разумеется не работает.
Роутеры работают под busybox и подобными сборками.
Есть стартап oxide computer, который ембеддед развивает - пишут firmware для серверов с нуля
>Нет? А почему?А потому что soho роутер не вибрирует и его нельзя туда засунуть.
А что по времени сборки? Если собирать gcc без го, д и ады, только раст и c/c++.
По времени сборки С++20 с модулями быстрее всех языков компилируются в данный момент, только тихо, а то очередные студенты недоучки начнут рассказывать про С++ с классами
Наконец-то C++20 сделал то, что паскаль умел ещё в 80-е. И то, что делали java и C# в 90-х и начале 2000-х. Не нужно в 100500-й раз склеивать и по новой компилировать простыню из инклюдов, если можно посмотреть готовый результат в уже скомпилированном объектнике ;)
дополню чуток...K&R в своё время отчасти торопились, отчасти хотели упростить компилятор, отчасти хотели использовать ГОТОВЫЕ ОТЛАЖЕННЫЕ КУСКИ (препроцессор появился лет за 10 до компилятора СИ).
Страуструп своего компилятора никогда не делал! Он делал cfront - это кодогенератор, который переделывал исходник на C++ в исходник на C (который компилировался компилятором C). В лихие 90-е - во времена исключений и шаблонов... Страуструп сдался и сказал: "Дальше делайте полноценный компилятор C++ сами, cfront стал ну просто пипец какой сложный, я его дропаю", а сам занялся книгами и чуть позже пошёл в комитет по стандартизации C++.
Препроцессор автоматически унаследовался из языка C в стандарт C++ (т.к. по факту это "почти" тот же C, но с наворотами). В модулях придумали как "обойти" препроцессор и сделать как в нормальных языках (по сути скопировали паскаль с его interface/implementation, но главное - добавили ограничений на использование препроцессора; т.к. в паскале препроцессор может сломать программу, как и в C).
> А что по времени сборки? Если собирать gcc без го, д и ады, только раст и c/c++.Возьми да замерь. Зафиг тебе опеннетных экспертов слушать? Думаешь они это делали и скажут что-то дельное?
Один вопрос.Оно сможет собирать без интернета ?
"Интернет людей не хотят только луддиты"
А что мешает скачать все зависимости локально или написать все самим и скомпилировать полностью локально, как это привыкли делать в C?При сильной упоротости или строгих требований к использованию зависимостей это возможно. Только это мало кому нужно, чтобы использовать это как подход по-умолчанию.
Нет, это невозможно и не работает. Без интернета ничего собрать используя только репозиторий дистрибутива - невозможно. А спорят только те кто не пробовал.
и нельзя все пакеты заранее заинсталлировать, типа как nimble install packagename?а потом просто "папочку" копировать с ПК на ПК, зато безопасно
Можно
.cargo там есть, да, наверное можно. но речь шла о раст пакетах в том же дебиане. для того чтоб эта .cargo появилась интернет надо.И это при условии что не понадобиться другая версия одного из пакетов, а это 100% понадобиться т.к там зависимости от зависимостей и жесткая привязка к версиям. Так что бегать в интернеты будете за каждым чихом.
cargo вещь не обязательная же, при большом желании можно скомпилировать чисто с самим компилятором rustc, если скачать пакет и зависимости заранее. Правда это будет очень геморройно и не представляю зачем так нужно делать, кроме совсем крайних случаев
> при большом желании можно скомпилироватьу меня тоже был приступ наивности
> Правда это будет очень геморройно и не представляю зачем так нужно делать, кроме совсем крайних случаевЕсли NIH замучал, и хочется свою собственную систему сборки, то можно. Портянок на bash может не хватает для счастья?
Ещё при большом желании можно panic не бросать и написать компилятор раста на расте.
Что-то новость, которая касается разве что гентушников, которым компиляние раста с постоянно новыми номерами версий нужно как собаке пятая нога в то время как GCC имеет разные версии и параметры по умолчанию даже специально выключены для недодистрибутивов для пользователей, которые не умеют в программирование вызвала словесный ажиотаж у растоманов и его противников. Але, гараж! Раст никуда не выкинули, но теперь он ненужен отдельным пакетом будет в зависимостях когда гентушники протестируют все. А то вам все переводить надо с русского на русский.
Не думаю, что это проблема языка, скорее, сообщества, которое в бОльшей части представляет собой выходцев из веб-макак, но меня ужасно отпугивает стиль написания программ на раст. Сотни зависимостей, которые скачиваются из интернета даже для маленькой программы. И эта культура работы с зависимостями в стиле джаваскрипта в системном языке программирования оставляет очень неприятный привкус. Особенно после программ на Си/плюсах, где софт более самодостаточен и не требуют такого количества зависимостей.
это вы еще du -sh build/ привести забыли для маленькой программы для которой места еле хватает, а вот сложнее хеловорлда уже не каждый сможет себе позволить собрать, не говоря о том чтоб просмотреть исходники хотяб на предмет откровенного слива
На сях софт как раз менее самодостаточен, тк в стандартной библиотеке ваще ничего нет.
Сказал адепт езыка где генератор случайных чисел качается из интернета и к нему еще пару десятков пакетов зависимостей...
И даже при этом стдлиб раста в сто раз полезнее стдлиба сей.
только на хард не влазит. а так да, в сто раз полезнее
это что за стдлиб в котором базовый ранд не придусмотрен ? г-но это, а не стдлиб. а у сей есть все что нужно, до тебя еще никто не жаловался.
А ты пользуешься libc'овым генератором случайных чисел? Я забил давно, потому что там нет понятности с ним никакой -- он генерирует случайные числа или псевдослучайные? Есть ли возможность воспроизвести заданную последовательность псевдослучайных чисел? Нет? Насколько тогда можно полагаться на случайность, в криптографии можно использовать?Когда лет 10-15 назад начались споры об этом, я забил на libc'овые генераторы, потому что когда ты берёшь себе генератор специализированной библиотекой или пишешь ручками, ты _знаешь_ что это за генератор. Ты можешь подобрать такой генератор, который тебе нужен в данный момент. Например для дебаг-сборок использовать линейно-конгруэнтный генератор, которому стартовое состояние задаётся переменной окружения, а для релиза реализацию, которая будет в бекграунде подкачивать энтропию из /dev/urandom по мере надобности, поддерживая состояние юзерспейс-генератора реально непредсказуемым.
libc'овый генератор он вообще никуда не годится. Он не годится для дебаг-сборок потому что хрен ты воспроизведёшь последовательность, он не годится для реальных задач, потому что он заточен под абстрактную задачу, которую себе воображали те, кто писал стандарты, и не подходит ни под одну из реальных.
Я тоже знаю как минимум четыре способа эффективно генерить рандом и что ? В расте нет рандома ибо ВАМЭТОНИНАДА !? Отличная логика, какой дружилюбный язычек.
что мешает чекать транзитивные зависимости у библ, которые хочешь использовать и подключать только те, которые не тащат в виде пакета зависимость, которая, условно, складывает два числа? А в плюсах посмотрите в количество транзитивных зависимостей Qt или Boost - знатно поплюетесь.
А как ты хотел? Чтобы самому иметь пакетный менеджер и все контроллировать без франкенштейнизма, да еще и компилируя код самостоятельно, да еще и используя неправославгый оригинальный компилятор с новомодным подходом? Может тебе еще и схему работы компилятора расписать как сделать то же самое на плюсах с теми же проверками чтобы получился раст код? Вебмакакам нужно чтобы они думали какие они необычные использующие только самые новые тнхнологии и их код это вам не какие-то преобразованные данные в единицы и нолики!
началось...
А смысл в таком компиляторе, если большое количество полезных библиотек с crates io требует не просто последней стабильной версии rustc, а даже nightly? Если есть блоги или статьи о разработке проектов с использованием именно gcc-rust?
> crates io требует не просто последней стабильной версии rustc, а даже nightlyСледствие отсутствия стандарта. И так будет перманентно: время жизни растпроектов - 3 недели. Пользоваться такими, мягко сказать, затруднительно.
Modula-2 Language Frontend Patches Ready For Merging Into GCC 13Что скажут эксперты по программированию?
> Что скажут эксперты по программированию?WTF?
Это откуда взято?
Лец ми гугл ит фор ю: https://www.phoronix.com/news/Module-2-GCC-Merged
Спрошу, какого в стандартном гнутом компиляторе нет поддержки лиспа.