Опубликован релиз языка программирования общего назначения Rust 1.66, основанного проектом Mozilla, но ныне развиваемого под покровительством независимой некоммерческой организации Rust Foundation. Язык сфокусирован на безопасной работе с памятью и предоставляет средства для достижения высокого параллелизма выполнения заданий, при этом обходясь без использования сборщика мусора и runtime (runtime сводится к базовой инициализации и сопровождению стандартной библиотеки)...Подробнее: https://www.opennet.me/opennews/art.shtml?num=58333
Я вот до сих пор не пойму, вот что стоило создателям раста оставив полный список своих фич по безопасности и всё такое сделать просто нормальный синтаксис. Ведь казалось бы вроде всё складно говорят, но почему нельзя сделать синтаксис, который можно было бы хотя бы нормально читать. Это какая-то форма насилия над личностью или средство самовыражения? Почему, кто мне это объяснит?
Это как в анекдоте - солдат должен копать не для того, чтобы вырыть яму, а для того, чтобы задолбаться...
Вы видимо в армии не служили, тогда бы над этим не смеялись. Молодые люди оставленные без работы (любой) не находят ничего интереснее, чем выявлять кто является альфой, а кто омегой в коллективе. Поэтому с точки зрения любого солдата, между копать яму чтобы задолбаться и быть отпинаным сапогами сослуживцев, надо выбирать первое.Это вам напутствие по поводу "тупизны менеджеров". Любят их тупыми выставлять, хотя никогда ответственности ни за что и ни за кого не несли.
Копание окопов и ям - это навык безусловно полезный, но чтобы решить проблему с выяснениями кто альфа, а кто омега, можно солдат полезным делом занять, а не имитацией деятельности. Ну хотя бы, например, военному делу научить.
Непосредственно на войне, "военное дело" занимает, максимум 1% времени.
Остальное - обустройство жизни (уборка, готовка, заготовка, чистка-смазка, ремонт, залатывание, сон, еда, туалет, помощь в уходе за раненными, обустройство позиции, наряды, наблюдения, помощь тыловым службам. Если не рядовой - куча бумажной работы (заявки, накладные, отчётность, боевой журнал, доклады, рапорта, документация подразделения...))
>но чтобы решить проблему с выяснениями кто альфа, а кто омега, можно солдат полезным делом занятьОмеги копают, Альфы "помогают", все давно в этом мире изобретено. И ребра/носы целы, и проблема решена)
Зачем какому-то военному делу учить. Всеж знают, которое самое полезное дело, чтоб солдат занять - строить коттеджи для генералов.
С точки зрения альфы лучше пинать сослуживцев сапогами чем копать окопы 😥
Значит альфа помрет не своей смертью.
Прямо вот наблюдаю последствиея это порочнейшей практики чем бы не занимался.. Лишь бы..
Ты видимо софт никогда не разрабатывал. Зачем собирать молодых людей чтобы они даже просто вебдвижек Servo не могли написать. Почему бы не сделать так чтобы они не задолбались, а просто выпустили продукт в продакшн.
И опыт армии что показал? Что если рыть, то поиски альфы прекратятся? Кому интересно всегда найдет время и способ.
Синтаксис вполне нормальный, а когда к нему привыкаешь, то он становится более читаемым чем синтаксис цпп, но меня больше волнует другое. Язык по "раздутости" и сложности догоняет цпп, хотя преподносит себя как конкурент Си.
Он преподносит себя просто как язык системной разработки. А насчёт сложности - тут как с языком Scala, синтаксически фич до одури, но самых простых довольно немного, чтобы пользуясь только ими писать рабочий код. Все остальное только как средство выразить идею "красиво" или решить что-то специфические. В том же C++ метапрограммированием на шаблонах занимаются только разработчики библиотек, обычные разрабы на зарплате в продуктовом коде используют только простые и понятные фичи шаблонов - специализацию под тип, variadic-и, perfect forwarding и SFINAE.
Это примерно никогда?
Синтаксис это единственная прелесть раста. Я всё ещё жду асинхронные генераторы, прежде чем его можно будет где-нибудь применить. Ну и средства отладки получше бы, у меня помнится были сложности с вычислением куда память утекает или в другом случае какого чёрта исполнение фризится на пустом месте. Буквально построчное чтение и вывод строки после регулярки, но рандомно фризится на принте. Судя по strace на мютексе и это ни о чём не говорит.
Может все-таки на регулярке фриз? Просто я не могу в это поверить, но если у вас такое, то хотелось бы подробностей.
у некоторых и МК сам по себе "звенит". Причём не каждый. Без кондёров, без катушек, без внешнего источника тактирования - которые убрали для поиска источника шума. Вот просто пищит микроконтроллер на ШИМе и всё и хоть тресни. Причём, даже неясно, чему там вообще шуметь
На РАсте ? Утекает память ? O_o
Это же невозможно по определению языка !!!!
Рекламщики ушли, раст программист остался один на один с компилятором. Зато как нравился синтаксис - на то и купился. )
Скорее всего юродствуешь, тролль, но если вдруг случайно (не верю!) я не прав (тогда извини), поясню: раст в силу своей технологии управления памятью не любит циклические ссылки. Это должен уже программист контролировать, вручную обрабатывать, а иначе память не очистится в зацикленных конструкциях. Ну и конечно еще можно неверно работать с внешними сишными библиотеками.
Привыкайте. Много скрыто от программиста и много умолчаний. Предлагаю более серьезные платные курсы.
Ой, да хватит уже про синтаксис заливать. Столько лет уже прошло. Уже можно было привыкнуть 10 раз.
А зачем привыкать? Сегодня есть rust, потом про него забыли. Как хобби или работа для саморазвития и так пойдет.
Вон, сколько с D носились и где он сейчас? Как были C/C++/C#/Java мейнстримом так и остались, ну Python еще гдето там болтается.
Но java, c# и python это инерпритируемые языки, они для написания системных компонентов, не предназначены.
Даже основные реализации их виртуальных машин написаны на других языках, си++ у джава и си у питона
Речь о распространенности и схожести синтаксиса. В случае чего, не нужно много переучиваться
D погубила пляска со стандартными библиотеками и версиями. Только к нему начали присматриваться, как понеслось: tango, mango, phobos, версия 2, несовместимая с 1. Ну, это почему я от него отказался. Да и недолго так носились - лет, эдак, 5, потом на убыль пошло. И корпорации его особо не использовали в продакшене.
У раста в этом плане стабильность: код для 2015-эдишн сейчас вполне себе соберётся, носятся с ним уже скоро лет 10 как (с 2013 носятся активно), корпорациям зашёл на ура, даже тем, которые свои языки пилят.
Ты просто смогло в ML-семейство и поэтому страдаешь.Хотя будь Rust ближе к ML синтаксически, протащить его в массы было бы несколько сложнее. От така загогулина.
Может кто-то внятно объяснить, в что именно не так в синтаксисе раста и какие вы предлагаете альтернативы?
Кто видел синтаксис плюсов, к расту претензий не имеет...
Похоже, что только видел.
Zig. Единственный язык, который выполнил свои обещания.Ничего лучше с системным программированием не случалось.
Что на нём системного написано?
https://github.com/nrdmn/awesome-zig
А чего тогда про него ничего не слышно?))
Корпорации не вливают денежные массы, нет фанатов-шизиков с СДВГ.
Дайте время,он пока версии 0.10 (хотя на нём можно уже писать серьёзный приличный код)
> Дайте время,он пока версии 0.10 (хотя на нём можно уже писать серьёзный
> приличный код)
> https://github.com/oven-sh/bunНенужное и неспользуемое в проде поделие для говножс с 30% кода на плюсах. Успех, однако.
Сомнительный язык, как по мне.
1. Объявляются const, которые меняют свои значения. Т.е. значение const подставляется во время выполнения программы, а не компиляции.
2. В `pub fn main() !void `, что значит конструкция !void? Зачем инвертируют void?И для версии 0.10 такие мелочи являются большим минусом.
П.С. Мимо крокодит голанг разраб...
3. Зашел в какую-то репу, там весь код состоит из `pub const`.
Что???When a local variable is const, it means that after initialization, the variable's value will not change. If the initialization value of a const variable is comptime-known, then the variable is also comptime-known.
!void это тип, который может вернуть (любую) ошибку. Обычно Error!RetType. Очень классная конструкция, кстати.
> !void это тип, который может вернуть (любую) ошибку.Нет, яву вам не переплюнуть.
> ... это тип, который может вернуть (любую) ошибку.Что за набор слов? "Тип, который возвращает..." --- полный п..ц.
Конечно он криво написал. Это тип при вычислении (evaluation) которого бросается ошибка.
Вычисление в данном случае это как в фразе "вычисли 2 + 3".
Так и вы написали не лучше.> Это тип при вычислении (evaluation) которого бросается ошибка.
Вычисление типа (в данном контексте) это вообще что?
> это как в фразе "вычисли 2 + 3".
Ну и что у нас "тип"? 2 или 3?
Я просто интересуюсь. Вам известно такая фраза как вычисление выражения?
Например, 2 вычисляется в целочисленное число 2. Тип выражения int. (2 + 3) вычисляется в 5. Тип выражения int.
Литерал "Hello world" вычисляется в объект типа String.
Вот и тип выражение for(;;) {} имеет тип !. Пример для rust `fn foo() -> ! { loop { } }`
Конструкция throw new Exception() имеет тип !. Вот и тут есть литерал, который фактически бросает ошибку и имеет тип !. При этом тип ! является подтипом всех типов, что важно.
Вот можете же, когда прижмут. "Возвращает тип" --- ахинея; "возвращает объект типа" --- осмысленное.
Не слышал про bottom type в теории типов? Ненаселённый тип. В других языках это Nothing или Never.
По сути тот же тип что возвращает конструкция for(;;) { }
>Zig. Единственный язык, который выполнил свои обещания.Ну вот и посмотрим, кто победит :)
Профессиональным экспертам-программистам с опеннет, привыкшим к низкоуровневым си и ассемблеру, сложно понять зачем нужны строгая типизация, автоматическое управление памятью, отсутствие null, проверки комплилятором.
Они легко управляют регистрами и памятью вручную, неопределенное поведение для них возможность оптимизации, а ограничения rust им только мешают.
Неопределённое поведение для местных экспертов - как радиация: раз не видно, не слышно и не пахнет - значит, ничего нет. Программа скомпилировалась и работает? Вот и чудненько.
Синтаксис не такой как в сишечке, вот и людей корежит.
Просто синдром утенка. Люди видели си и паскаль, кто-то джаву, кто-то 1с. Может еще что-то.
А все остальное прошло мимо них.
Дать бы тебе в языке синтаксиса sendmail.cf поразбираться...
Ты был бы счастлив.
sendmail.cf - это уже за гранью добра и зла.
На мой взгляд, нельзя так над людьми издеваться.
Ну вроде как очевидный косплей C и C++. Они же вроде как ближе всех к системному программированию. Питонообразный дереференс ссылок тем ещё бы насилием над эстетикой был бы. Опять же, где lifetime метки после def вкорячивать?
Это средство самовырождения.
Вот поэтому на нём ничего и не написали.
А что конкретно ненормально?
Я не защищаю Rust, просто мне интересна эта тема, языки программирования в целом, в том числе и синтаксисы, с точки зрения удобства, понятности и прочих харакретистик.
Есть у вас конкретные примеры того что "ненормально" и как бы вы сделали нормально?
Потому что вебщики делали.
Для меня, синтаксис раст это весомая часть от того, из-за чего я его использую (там где могу, где не могу — с++)
У Rust очень приятный синтаксис. Это просто такая особенность человеческого мозга, что непривычное кажется плохим; программисту про эту особенность надо знать и ей противодействовать.
Он великолепен!
Растогедон?
>Растогедон?Фракталогедон ...
Там немного другое окончание: фрактадopacт.
Как-то редко версии выходят, всего лишь раз в месяц.
ну да, надо чаще. А то про него могут забыть
Да пора уже отбросить это первое незначащее число номера версии.
Раз в полтора месяца. С момента релиза версии 1.0 в 2015 году, каждые 6 недель выходят минорные релизы. Пора бы уже привыкнуть.
"Каждое новое поколение заново открывает для себя секс"
В отношениях с растом многие куколды- предпочитают, чтобы с ним трахался кто-то другой.
Что неудивительно, потому что раст- это девочка с сюрпризом.
Выбираете суровый брутальный мужской секс с сишечкой?
В отношениях многие опеннет эксперты предпочитают заниматься аутокопрофилией.
Что неудивительно, потому что это сущность опеннет экспертов
> реализации типажейКак это понимать? Куда это понимать?
Для каждого типажа программиста, своя реализация
В контексте единства ядра, общежитие си и раст можно будет охарактеризовать - взболтать но не смешивать.
Наверное, что-то подобное тому, что в Си++...
Те же концепции - не обязательно к классам привязаны могут быть.
impl TryFrom<Vec<T>> для Box<[T; N]>
Вот пример реализации типажа (трейта)
есть такой типаж людей, который любит англйиские термины на русский переводить. обычно это старые больные на голову бюджетники типа преподов
В тэбэ - мозог протатчэный?
Американцы и англичане - ну совсем бы не поняли, о чём это вы...
А вот и смузи-программист пожаловал.
>Как это понимать? Куда это понимать?**Rust-энтузиаст на проводе**
Меня тоже корежит этот перевод "trait" -> "типаж". Но как лучше? "Свойство", "особенность", "черта", "характеристика" совсем не в кассу. "Интерфейс" тоже не то: уже изрядно перегруженное слово. "Грань" звучит странно.
лучше trait или трейт. а вообще зачем отдельное слово?
Типаж уже устоявшийся термин. Ты ещё до слова поток не дошёл, это и thread и stream. И что-то никто не спешит называть стек - стогом сена или магазинной памятью.
По-моему, лучший перевод trait'а - поведение.
Абсолютно непригодный никчемный язык. Паразитирует на сишных библиотеках, и своей целью ставит заменить С/С++ - нонсенс.
я бы опроверг эти слова, но у меня сейчас под раст места на диске не хватает
Всё работает, всё понятно: https://git.pashev.ru/mendeleev/tree/mendeleev.rs
Знаете, какой-то он - ... некрасивый, что ли...
То ли дело - брейнфак!
Да где уж ему с плюсами в "красоте" сравниться.
Отрицание
Гнев <--- вы находитесь здесь
Торг
Депрессия
Принятие
Интересно, будет ли Rust++ или Rust# ?
сначала - визуал-раст
Кстати, полностью лживая, нерабочая схема. В реальности "принятие" происходит редко.
То есть ошибочен только пятый пункт, но схема все равно "полностью" лживая?
Пятый пункт ключевой, без него вся схема рушится.
Очень печально что эксперты-программисты с опеннет останутся в депрессии из за rust.
Как же столь квалифицированные специалисты будут писать свои замечательные программы...
Если учесть что это схема принятия неизбежного как-то неожиданно что она может быть применена в случае когда неизбежное не принимается.Или как в случае с этим недоязычком принятие очень сильно избежное настолько что схема полностью не имеет смысла.
Уже вполне очевидно, за этим языком будущее. Допускаю, что каких-то возможностей в нем пока не хватает, но он уже вполне себе годный для написания большого класса программ и библиотек, что и показывает динамика развития.Избегать прогресс до сих пор мало у кого получалось долго, а Rust - это прогресс. Поэтому схема полностью рабочая, нравится это луддитам или нет.
Подтверждаю. systemd так и не стал общемировым станда.. а ой. Стал.
на системду нет стандарта. Как и на раст.
Системд находится в руках кучки заговорщиком, укравших у майкрософт идею системного менеджера, потому что у адептов много у майкрософт.
>В реальности "принятие" происходит редко.Естественно, наблюдаемые редко до него доживают.
Забыли расставить if )
Стоит признать, раст слишком немощьный для низкоуровневого программирования:
- Каст &[u16] в &[u8] невозможен без сторонних библиотек
- Нет литералов для null terminated string
- У половины контейнеров нет типового параметра для кастомного аллокатора, например у String
- Сконкатенировать два массива - непосильная для раста задача: нельзя написать тип [T; N + M]
Ну и так далее. Банальные вещи, которые в C++ есть давно и никто даже не задумывается, что этого вообще может не быть. Но зато в расте есть async, конечно, это намного важнее чем скастить или конкатенировать байты. Ведь это именно то, что мы хотим на низкоуровневом языке без сборщика мусора: писать асинхронный код!
Стоит признать, что очередной опеннетный эксперт ничего не понимает в идеологии языка в частности и в системном программировании вообще. Говоря простыми словами, сел в лужу.Каст правильно невозможен, иначе можно получить числовое переполнение. Создатели языка стремились сократить потенциальное количество ошибок, а не приумножать их.
Какие ещё литералы, и зачем они нужны для null terminated string? Собственно, как и сами эти строки, которые есть ничто иное, как очередной костыль, придуманный когда-то от безысходности, и который приводит к куче багов с переполнением буфера.
Объединять два массива в Rust, конечно же, можно, только делать это стоит с большой осторожностью, потому что происходит всё в куче (для динамических массивов).
Ну и так далее.
Есть такая ОС Redox. Написана полностью на Rust. Гугл недавно рапортовал, что использует Rust в ОС Android. Линус согласился принимать код на Rust. Если это не системное программирование, то что?
> Каст правильно невозможенПочему? В чём принципиальная проблема? Какое ещё переполнение? Что мешает при касте паниковать или возвращать Err в случае переполнения? Эта операция вполне легальна в раст, только для неё нужно подключить дополнительную библиотеку:
https://play.rust-lang.org/?version=stable&mode=debug&editio...Вот пример того, как просто это делается. Только этого нет в std, хотя часто нужная вещь. Причём тут Redox и Linux? Можно я свой код буду на расте писать, а не ядра ОС всякие? Я говорю про свой опыт использования и уверен, много кому нужно то же самое. К чему эта неуважительная риторика про "сел в лужу"? Я стараюсь объективно взглянуть на язык, извини, что я не фанатик, как многие, кто любят раст.
Сишные литералы нужны, само собой, чтобы взаимодействовать с Сишными библиотеками. Странно, что это нужно объяснять. Сейчас в расте приходится делать Си-строку из &str, а без аллокации это невозможно, так как нет места под нулевой байт, соотвественно это вредит производительности.
>> потому что происходит всё в куче (для динамических массивов)
Я привёл пример типа [T; N + M] - что является обычным массивом, не динамическим. Опять же, странно что растер этого не понимает и путает его с Vec<T>.
Вообще, это странно выгораживать подобные недостатки языка тем, что якобы это небезопасно и вообще не нужно. Я уверен, это можно сделать и этот функционал относительно не сложен. Ну уж точно не сложнее async, но почему-то разработчики языка именно так расставили приоритеты, сделав раст труднопримениым на практике. Конечно, есть Redox, Linux и Android - только вопрос в том, сколько там unsafe? Зачем мне писать на языке, где всё что мне нужно делается через unsafe? Почему бы сразу не взять для этого unsafe язык вроде Zig или C++?
А почему вы не хотите взять сырые указатели и скастить их? Почему вы хотите кастить именно ссылки, для которых запрещены небезопасные операции by design?
Можно мне объяснить, чего небезопасного в касте &[u16] в &[u8]? Я показал пример, где это делается без всякого unsafe кода. Да, внутри там всё равно unsafe, но снаружи безопасный api, как и многое в std. Что принципиально мешает так сделать?
> Что принципиально мешает так сделать?Ничего не мешает. Просто всего в std не утащишь. Если у вас есть понимание, что это нужно в std и в каком именно виде оно там должно быть - создайте issue.
Для работы с сишными строками есть типы CString и CStr. Вы можете сконструировать CStr из байтового строкового литерала:Но это небезопасная операция (нет гарантии, что ваша последовательность байт обязательно заканчивается нулём). Но вы можете использовать простой макрос c_str чтобы избавиться от unsafe:
use std::ffi::CStr;const MSG: &CStr = unsafe { CStr::from_bytes_with_nul_unchecked(b"Hello\0") };
https://play.rust-lang.org/?version=stable&mode=debug&editio...
const MSG: &CStr = c_str!("Hello");Да, на уровне синтаксиса языка Rust нет поддержки литералов C-строк. Но её относительно легко добавить с помощью макроса.
Спасибо за совет. Однако, видимо с точки зрения разработчиков языка создание сишных строк настолько редкая и ненужная операция, что не то что сишные литералы отсутствуют в языке, даже подобного макроса нет в std. Не понимаю что принципиально мешает это сделать?
В итоге получается вот такой неоптимальный код при вызове сишных библиотек:
https://github.com/grovesNL/glow/blob/main/src/native.rs#L1200
> В итоге получается вот такой неоптимальный код при вызове сишных библиотек:
> https://github.com/grovesNL/glow/blob/main/src/native.rs#L1200В этом месте по другому и не сделать, тут же не литерал используется, а строковый срез &str. Так что вам все равно нужно аллоцировать строку заново, чтобы добавить ещё один
символ в конце.
А почему авторы библиотеки решили принимать &str, а не &CStr?
Уж не потому ли, что нормальной поддержки сишных строк нет и проще сделать так?
Это пример к слову о "ненужности" си-строк. При всём моём уважении к расту и его сообществу, поддержка сишных библиотек сделана откровенно плохо. У C++ и Zig в этом плане гораздо более существенные преимущества, хотя и языки сами по себе небезопасны.
> А почему авторы библиотеки решили принимать &str, а не &CStr?
> Уж не потому ли, что нормальной поддержки сишных строк нет и проще сделать так?Это уже вопрос к авторам библиотеки. Написать &CStr вместо &str не намного сложнее, не находите?
> Это пример к слову о "ненужности" си-строк. При всём моём уважении к
> расту и его сообществу, поддержка сишных библиотек сделана откровенно плохо. У
> C++ и Zig в этом плане гораздо более существенные преимущества, хотя
> и языки сами по себе небезопасны.Эти вещи взаимосвязаны: многие вещи в Си (включая строки) небезопасны by design. Они плохо вписываются в подходы обеспечения безопасности в Rust. Поэтому и не поддерживаются прозрачно, чтобы их использовать нужно приложить усилия. То есть их следует использовать, если нет других альтернатив.
> Написать &CStr вместо &str не намного сложнее, не находите?Написать то не сложно, только как потом пользователи библиотеки будут вызывать эти функции? Либо макрос придётся свой городить, либо делать строку из CString, ну либо CStr::from_bytes_with_nul(b"hello\0").expect("тут нул-терминейтед-стринг, я клянусь"). В общем, неудобно это, проще принимать &str.
> небезопасны by design
Тогда интересно, в чём именно их небезопасность? Растовый тип CStr столь же безопасный как и другие типы, с учётом отдельных unsafe методов которые так же есть и у родных растовых строк. Или компилятор не в состоянии проверить инвариант литерала строки, например чтобы в середине не было нулевых байт? При этом проверять валидность utf-8 он прекрасно может
Я думаю авторы библиотеки рассчитывали, что пользователи в своем коде будут оперировать динамическими Rust-строками, поэтому при вызове сишной функции всё равно нужно будет делать новую аллокацию. Эта проблема не связана с отсутствием синтаксиса для литералов сишных строк, она скорее о том "почему в Rust по-умолчанию принято использовать строки не такие как в Си".
Кстати, есть RFC и issue для добавления сишных строковых литералов: https://github.com/rust-lang/rust/issues/105723
Мне вот недавно потребовалось выделить под буфер кусок динамической памяти, размер которого не известен на стадии компиляции. То, что в Си элементарно делается при помощи malloc() а в Си++ при помощи new. И знаете, я был в шоке, когда погрузился в подробности этого процесса в Rust и выяснил, что просто так это сделать невозможно. Мы можем выделить только массив, размер которого известен на этапе компиляции. Это 3.14сец, товарищи. В итоге я вынужден был использовать вектор с unsafe блоком для принудительного изменения его длины. Можно было также использовать другой костыль Vec::as_mut_slice() но это те же яйца, только сбоку. Не будет ли любезен претендующий на понимание идеологии и системного программирования уважаемый джинн ответить, какого хера для реализации одной из повсеместно используемых базовых операций нужны такие танцы с бубном?
В Rust можно динамически выделять память руками, просто нужно иметь ввиду, что придется самому определить лайаут, скастить указатели и обеспечить инициализацию памяти. Это unsafe операции, так что тут ответственность ложится на плечи программиста:https://play.rust-lang.org/?version=stable&mode=debug&editio...
use std::{alloc::{alloc, Layout}, slice};fn main() {
let n = 1000;
let a = unsafe {
let layout = Layout::array::<i32>(n).expect("Layout overflow");
let ptr = alloc(layout) as *mut i32;ptr.write_bytes(0, n);
slice::from_raw_parts(ptr, n)
};
println!("{a:?}");
}
>[оверквотинг удален]
> let layout = Layout::array::<i32>(n).expect("Layout
> overflow");
> let ptr = alloc(layout)
> as *mut i32;
> ptr.write_bytes(0, n);
> slice::from_raw_parts(ptr, n)
> };
> println!("{a:?}");
> }
> https://play.rust-lang.org/?version=stable&mode=debug&editio...
Да, подобный костыль тоже возможен, но то, что это все вообще требуется говорит о том, что далеко не все там продумано должным образом. Ибо операция выделения буфера произвольного размера в реальном низкоуровневом коде встречается настолько часто, что средство для этого просто обязано быть простым и понятным. Нужно что-то типа fn alloc_slice(size: usize) -> Option<Box[u8]> и это что-то должно быть в стандартной библиотеке а не делаться на коленке в с применением unsafe блоков
> Нужно что-то типа fn alloc_slice(size: usize) -> Option<Box[u8]>Если вам нужен Box<[u8]>, то делайте так:
vec![0; n].into_boxed_slice()
А почему бы не выделить нужную память вектором Vec<u8> или Box<[u8]>?
> А почему бы не выделить нужную память вектором Vec<u8> или Box<[u8]>?Выше написано, что я так и сделал. Но, в данном случае, это лишняя сущность, которую мы плодим без надобности. Собственно, чтобы было более понятно, вот текущий код:
fn read_data_block(&mut self)-> Option<usize>
{
let mut r : Option<usize> = None;
// Флаг повторного считывания даных в случае, если функция была
// прервана сигналом (ErrorKind::Interrupted)
let mut read_flag = true;while read_flag
{
// Мы используем внутренний буфер вектора как мутабельный слайс
match self.data_src.read(&mut self.buf.as_mut_slice())
{
// В случае успеха возвращает количество считанных байт
Ok(n) =>
{
// Повторное считывание не требуется
read_flag = false;
// Установим новое количество байт в векторе, так как
// он сам ничего не знает о том, что в него были
// считаны данные извне
// Эта операция считается небезопасной, поэтому
// используем unsafe блок
unsafe
{
self.buf.set_len(n);
}
// Подготовим возвращаемый результат
if n > 0 { r = Some( n ); }
},
Err(e) =>
{
if e.kind() != ErrorKind::Interrupted
{
read_flag = false;
self.io_error = Some( e.kind() );
}
}
}
}
// Вернем результат считывания
r
}
Он требует доработки, чтобы еще была правильно обработана ошибка обрыва Пипы, но, в целом, вполне рабочая.
А для чего тут self.buf.set_len(n)?
Можно после прочтнения в буффер взять слайс у &self.buf[..n] и получится то же самое, только без unsafe. Если нужно получать как результат именно Vec<u8>, можно позвать безопасный метод self.buf.resize(n, 0) или self.buf.truncate(n) который сделает то же самое что и unsafe аналог.Ещё у трейта Read есть вспомогательные методы, например read_exact
https://doc.rust-lang.org/std/io/trait.Read.html#method.read...
Которые игнорируют ErrorKind::Interrupted и продолжают читать дальше. Возможно, в вашем случае один из подобных вспомогательных методов упростил бы код
А что будет делать ваш код, если self.buf будет нулевой длины?Вот вариант блочного чтения без unsafe:
fn read_data_block(&mut self) -> Option<usize> {
let mut bytes_read = 0;
let mut buf = self.buf.as_mut_slice();while !buf.is_empty() {
match self.data_src.read(buf) {
Ok(0) => break,
Ok(n) => {
bytes_read += n;
buf = &mut buf[n..];
}
Err(err) => if err.kind() != ErrorKind::Interrupted {
self.io_error = Some(err.kind());
break;
}
}
}
self.buf.truncate(bytes_read);
if bytes_read > 0 { Some(bytes_read) } else { None }
}
Только нужно помнить, что до вызова этого метода self.buf должен иметь нужный вам размер.
“Основанного проектом Mozilla”?!?!?
А ничего, что “проект Mozilla” лет так 8 или 9 игнорировал Rust, который по сути пет-проект их сотрудника?
Да-да... а Джобс и Гейтс - в гаражах начинали, ага...
Сотрудник кстати раст не развивает.
Кстати да, возникает резонный вопрос - почему Фаерфокс до сих пор не на Расте?
Мало мазохистов и программистов с другими девиациями чтобы это сделать.
Вы его давно крайний раз собирали? Раста там... много...
Но и С++ не мало...
Опять попытался попробовать Rust. Уже, наверное, 4-5ый раз. Но опять провал. Уж очень, очень, чрезвычайно когнитивно сложный.Как человек, профессионально освоивший 10 языков программирования, для меня это очень необычно и удивительно.
Как на этом писать многопоточные программы и разные хитрые структуры данных? Если честно, даже С++ кажется и то более понятным (без шаблонного метапрограммирования).
Пожалуй, лучше Zig в мире системного программирования, ничего нет. На нём и останусь.
Всего 10? Лол. Учись, студент:https://git.pashev.ru/gcd
https://git.pashev.ru/mendeleev/tree/mendeleev.rs
Многие люди второй-третий язык удержать в голове могут.
Я например 😥
Не одновременно))) А на протяжении карьеры.Конечно про С# (2.0) я помню... ничего)
*не могут
Ну да, сам себя не похвалишь - никто не похвалит))
Я тут резюме отправил. Там знание Rust желательно было написано.
Так ответили "нам нужен питонист, а не плюсовик" 🤨
Кому вообще нужен c++ без метапрограммирования? 🤔
В C++ на самом деле не лучшее метапрограммирование, особенно, если сравнивать с языками, где оно спроектировано хорошо (например, LISP). Так что и ответ простой: C++ нужен и без метапрограммирования, это не самая сильная его часть.
Количество — это ещё не всё. Haskell освоили?Разные хитрые структуры данных писать по-разному и по-хитрому: есть разные методы в зависимости от требований.
Иногда хорошо работает подход "всё кладём в Vec, далее работаем с индексами". Я такой подход очень люблю, даже библиотеку свою сделал (https://crates.io/crates/components-arena). Но иногда издержки такого варианта неприемлемы.
Другой подход — использовать специальные библиотеки интрузивных коллекций.
Третий — написать сложное место как unsafe и закрыть safe оболочкой.
Четвёртый — использовать счётчики ссылок.
И т. д.
Что там с выравниванием структур и вообще с организацией данных в памяти. Чет беглый взгляд привел к каким-то сериализаторам, а можно обычно просто штатно положить данные в память единообразным способом без выравнивания и прочего ...
"Чо, сильно умный, да? - Йиш, що дають!"
Сколько народ в 90-х на Джаву бубнел!...
А теперь - ничего.
Некоторые - даже удовольствие получают!
#[repr(C)]
struct ThreeInts {
first: i16,
second: i8,
third: i32
}// Default representation, alignment lowered to 2.
#[repr(packed(2))]
struct PackedStruct {
first: i16,
second: i8,
third: i32
}// C representation, alignment raised to 8
#[repr(C, align(8))]
struct AlignedStruct {
first: i16,
second: i8,
third: i32
}
Такого ужаса даже в брейнфаке нет.
опеннет эксперт по программированию первый раз увидел код.
Увидел код на расте и не стал писать на расте. Будь как эксперт не пиши на расте.
я итак не пишу, на работе с головой хватает kotlin, java, js, php и 8 фреймворков.
И в чём ужас? Буковки латинские? Или "как они посмели наши фигурные скобочки спереть"? Или i16 непонятны?
К счастью нет, нельзя. Этот подход доказал свою ущербность и остался в прошлом.
Можно, только загрузка их займет не один такт а два.
Любимый язык по версии JavaScript.ru
А где там опрос?
> по версии JavaScriptУже смешно :)
Знакомлюсь с Rust. Пока первый взгляд через википедию.
Цитата: "const — постоянные. Живут в течение всего времени работы программы. А именно, у них вообще нет определённого адреса в памяти. Это потому, что они встраиваются (inline) в каждое место, где есть их использование,"Получается "код, не прошедший через компилятор" не сможет получить доступ к константе? По сути это #define?
Знакомлюсь с Rust через комментарии на опеннет и понимаю что ни один эксперт с опеннет, специалист по низкоуровневым си и ассемблеру не будет на нем писать
си-программист ядра так заглядывает в раст исходник. Видит знакомое const и ищет из другого модуля где же она.
А если враги получат доступ к твоей памяти и поменяют значение const? А если const везде встроить то сразу везде её поменять будет сложно. Это называется безоРАСТность!
Константы помещаются в память защищенную от записи. Не считайте меня кэпом я просто юнгу учу)
Ты так уверен что на всех платформах и на всех архитектурах никто никаким способом не может писать в защищенную память? Это я уже не говорю про дизассамбилрование и правку самого бинарника. Ну тебе так-то и раст не нужен с такой верой)
А вы так уверены что раст-способ безупречен? Хакеры ломают программы, а вы ломаете стандарты. Трудно было синтаксис подправить чтобы объявление отражало сущность. inline незнакомо?
Я считаю что раст дно как и все кто на нём пишут.
Несомненно все люди должны прислушаться к мнению такого компетентного и уважаемого эксперта
И да ядро и модули ядра в одном пространстве. Так что как и сказал общежитие раст и си это взболтать но не смешивать.
Глобальные переменные, живущие весь цикл программы - это static. Если ты о них. Но использовать их крайне не приветствуется, доступ только через unsafe.
static mut VAL: ty = expr;const VAL: ty = expr; // строго типизированная константа, вычисленная на этапе компиляции по выражению справа
const fn foo() {} // функция, которую можно применять как в рантайме (как обычную функцию), так и в компайлтайме в выражениях для расчета констант
А знаете почему unsafe? Потому что константа это простая сущность. А по концепции rust программист не должен иметь доступа к сущности. Не будем уточнять по какой причине (неопытность, сговор АНБ и пр.) Но Rust один из языков рекомендованных АНБ для применения. И в этом топике я показываю как разно "говорят" раст и си программисты. И идея интегрировать в единое ядро сомнительна. Они не будут понимать друг друга. Как интерфейсный? может быть.
Ну вот и свидетель АНБ насмотревшийся РЕНТВ. АНБ Ruby и Java рекомендуют. И тоже не просто так... Им то уж лучше знать у кого куда должен быть доступ.
Ну вот и ответственный за срабатывания алярм-фильтра АНБ. ) Говорит витеевато и непонятно. На всякий случай копипаст с этого сайта "АНБ рекомендует переходить на языки программирования, безопасно работающие с памятью
14.11.2022 10:12"
Питон безопасно работает с памятью в рекомендованных АНБ его нет. Вопрос знатоку: "Почему?"
Хоть АНБ вряд ли желает людям добра, но предположу, что они хотят, чтобы в системы входили только они по бэкдорам, а не рандомные васяны по скачаным эксплоитам на 1001 уязвимость в среднестатистическом девайсе. Ну и типа если раст такой плохой, то АНБ скорее всего делает закладки в llvm на этапе кодогенерации. Задумаемся
Нет, const — это не define, а inline.Суть в том, что для static переменной гарантируется, что она будет в программе в одном экземпляре. Для const количество экземпляров не регламентируется, от нуля и до неограничено. От const можно взять указатель, но два указателя на один const могут статься будут указывать на два разных экземпляра.
Ну так и писали бы inlineconst. Что народ ложной сущностью привлекать.
В дополнение может кто ответить. Читал что раньше в раст были свои реализации потоков, а теперь нативные операционной системы. То есть программисту надо знать особенности потоков в ОС? Так и пишите не многопоточность, а поддержка объектной модели пригодной для многопоточности. Рекламы в раст больше чем что-то особенного. Свой синтаксис и включение наработок из других языков.
> То есть программисту надо знать?Да, программисту желательно хоть чего-то немножко знать.
В продолжение. Не понимаю как они собираются связывать в ядре две парадигмы Переменная? В Си переменная это именованный адрес, а в Rust это "ссылка имеющая владельца".
>>> В Си переменная это именованный адрес <<<Ох, уж эти местные эксперты:)
Приведи пример переменной без адреса, Карл.
Сразу предупрежу, что у регистров тоже адреса, а на некоторых платформах регистры ещё и отображаются в общее адресное пространство.
Уважаемый эксперт-программист. Уточните пожалуйста, какой адрес у AX, BX, CX ?
Их адреса вшиты в инструкцию
ты не ответил на вопрос какой адрес.
смотри modrm - это ответ на твой вопрос.
гугли хотя бы modrm
*(int *)0xdeadbeaf = 0xdead;
то что слева чисто технически это и есть переменная и это не именованный адрес как прекрасно видно!
Это ничем не отличается от проходной ячейки памяти. Просто умный автор решил забрутить свой код. И сам потом не вспомнит сто там не посмотрев спеки на железо.
То, что ты намакакокодил, и есть имя адреса в шестнадцатеричном представлении.
>>> имя адреса в шестнадцатеричном представлении <<<По вашей логике, то что справа от оператора присваивания это имя числа в шестнадцатиричном представлении? Хм... я почему-то всегда думал, что это так называемые литералы.
Почему "самые умные" сразу обзываются. ( При этом сам сказал глупость. Чтобы сразу боялись критиковать?
Это адрес без имени переменной (имя которое понятно хотя бы автору спустя какое-то время).
Имя может быть у переменной! Содержимое переменной может являться адресом другой переменной, - такая переменная называется указателем. Но у самого адреса нет никакого имени. Адрес это просто адрес!!!
Имя это то что отличает вас от других людей. Имя ячейки памяти для этого же.
Слушайте, я уже вам всё расжевал, как только мог! Если вы попрежнему считаете что переменая это как вы сказали именованный адрес, - дальше я вас переубеждать не стану;)
Меня убеждать не надо. Я и до этого знал что имя существоет только в пределах компилятора. )
в си все понятно даже без определения. А вот в раст такое не прокатит. там параметрический полиморфизм и программист оперирует связываниями. И такие хаки не прокатят.
Теперь понятно, почему редох загнулся и не хочет работать на реальном железе.
Теперь понятно, что ты - пустопорожний балабол. А Редокс вполне себе на реальном железе работает https://www.redox-os.org/screens/
>>> переменной без адреса <<<Так о том и речь, - у переменной есть адрес! Переменная это область памяти содержимое которой можно изменить; да у переменной может быть имя, но это необязательно. Но уж точно переменная это НЕ какой-то там именованный адрес!
Просто в качестве имени вы использовали адрес и поместили его слева. Минуя таблицу компилятора. Вы в интернет тоже ходите минуя ДНС?
>>> вы использовали адрес <<<Так о том и речь, что в конечном то счете - нет никаких имен, - есть только адреса!
> нет никаких имен, - есть только адреса!Сразу! видно настоящего! растамана!
Если вы также считаете что В Си переменная это именованный адрес, то переубеждать я вас в этом не собираюсь! Все что хотел, - я сказал!
Успокойтесь ) Все поняли что имен не существует. Вот и в расте даже сущности не существет. Положил яблоко, чихнул и нет яблока, один огрызок. Жалуешься а тебе в ответ - надо было предупреждать что вам нужна copy связность а не move. У нас по умолчанию move. И вот таких умолчаний - туча и мужики не знают )
register int noadr;Получите и распишитесь, бездари.
Реч идет о фактической адресации а не о "сахарке" который вам компилятор подсыпал.
>Реч идет о фактической адресации а не о "сахарке" который вам компилятор подсыпал.Речь как раз то о сахарке. И о его количестве в разньіх ЯП.
И в єтом контексте насавший топик соврал 2 раза.Во первьіх, даже в асемблере переменньіе єто уже не просто именованньіе адреса (там уже есть инфа про размер переиенной, байт, полуслово, слово), а в С так и подавно. В С у переменньіх есть типьі.
Практически єто значит, что вьіхлоп у такого кода: "c = a + b;" будет разеньій в зависимости от типов переменньіх. А если учесть что компилятор оптимизирущий, то может оказаться что у переменной с нет адреса, потому что ее просто вькинуло при оптимизации.
И про раст, бред про ссьілки. Знаток "сахара" уж должен то понимать что ссьілка - єто сахарок компилятора над указателем.
Есть один секрет они ничего и не связывают. Они кричат что все кругом дураки и что все кругом виноваты. А они святые и раст святой.
> , а в Rust это "ссылка имеющая владельца".А запутанном С++ это просто `constexpr int c = 123;` в отличии от просто `const int = 123;`
Причем тут переменная и заинлайненное значение?В расте все на порядок веселее, ведь там есть zst (zero sized types). Пустой кортеж — () гарантировано имеет размер в 0 байт. При этом, ты можешь им оперировать как обычным типом, например, создать вектор в 100 элементов из пустых кортежей. И размер этого вектора будет 100 * 0 = 0 байт (+ несколько байт переменных на длину массива, его капасити и пр.). И при этом все работает. Ты можешь по нему итерироваться, уменьшать длину, увеличивать.
У любой переменной в расте можно взять адрес. И это даже безопасная операция, просто число. И его можно взять и у zst типов. Раст просто вернет какое-то число, чтобы от него отвязались. А вот разыменование этого числа (превращение его опять в переменную) — это небезопасная операция. И если ты попробуешь адрес от zst типа преобразовать опять в переменную, то скорее всего, это будет ub, со всем вытекающим. Но можешь это делать только в unsafe блоках. Там ты сам себе буратино.
Так что, возможно, и на const можно получить какой-то адрес. Но физического смысла в нем не будет.
Ну да. Надо отучить от работы с сущностью. А потом уже подсунуть нужное при этом логика программы не пострадает.
> Так что, возможно, и на const можно получить какой-то адрес. Но физического смысла в нем не будет.Ну почему, будет. Компилятор любезно положит константу в память и вернёт вам соответствующий адрес, если без этого никак.
продолжайте программировать на javascript не отвлекайтесь
> В пакетном менеджере "cargo" предложена команда "remove", позволяющая из командной строки удалять зависимости из манифеста Cargo.toml.Теперь понятно почему так много зависимостей в проектах. Просто растоманы не могли удалить, что добавляли.
Ну да, руками то править файлы нельзя было раньше же
> Ну да, руками то править файлы нельзя было раньше жеС поиском всех транзитивных зависимостей?
В Cargo.toml нет транзитивных зависимостей, при чем они тут?
> В Cargo.toml нет транзитивных зависимостей, при чем они тут?Cargo.lock кто будет обновлять после удаления?
Все зависимости от указанного крейта cargo remove также вычистит и из Cargo.lock. Или в чем вопрос?
Дурочку включил? Cargo remove только добавили. Перечитай ветку.
> Cargo.lock кто будет обновлять после удаления?Cargo.lock вообще руками трогать не надо, он обновляется автоматически самим cargo (всегда так было).
>> Cargo.lock кто будет обновлять после удаления?
> Cargo.lock вообще руками трогать не надо, он обновляется автоматически самим cargo (всегда
> так было).Ты сообщения вообще прочитал? Вот воправил ты руками cargo.toml, а cargo.lock сам обновится без какой-либо команды?
После изменения Cargo.toml при вызове команд cargo update, или cargo build, или cargo run и т.д. Cargo.lock обновится автоматически самим cargo.
Зачем этот язык всё время форсят, если даже его создатель Мозилла не смогла переписать на нём свой браузер?
чтобы было больше боли пониже спины, унижений и комментариев от опеннет экспертов.
Типичный приём смещения фокуса внимания с проблем, на ощущения.
У вас какие-то проблемы?
Чтобы не говорить что Мозилле облажалась.
Чтобы не как у всех. Это как BDSM UX в GIMP -- чисто по фану
> Зачем этот язык всё время форсят, если даже его создатель Мозилла не
> смогла переписать на нём свой браузер?В какой-то степени смогли, Servo даже работал. Просто не довели дело до конца, по двум причинам:
1) Сменилось руководство и новый менеджмент сместил фокус компании и бизнесс-ориентиры.
2) Servo утонул в растовом легаси. Проблема в том, что проект развивался вместе с языком, который в то время очень быстро и радикально менялся. Поэтому к финалу, когда Rust уже пообкатался и стабилизировался, возникла потребность переписать Servo.
Таким образом, итог Servo - развитие языка и экосистемы Rust (он им очень во многом помог), плюс созданы некоторые компоненты, которые добавили в Firefox (WebRender, CSS engine и пр.).
Синтаксис похож на смесь JS, CSS и HTML..
опеннет эксперты, не видевшие ни js, ни css, ни html строят догадки, на что они могли быть похожи.
> В перечислениях c целочисленными представлениями (атрибутом "#[repr(Int)]") разрешено явное указание дискриминантаВот это реально здорово. Ещё немного и на стабильном Rust можно даже будет программировать. Но пока всё же nightly наше всё.
Программирование на атрибутах. Слишком много декларативщины.
Да они паскаль уже почти догнали!
> Да они паскаль уже почти догнали!И давно в Паскаль алгебраические типы данных завезли? Для обычных-то енумов дискриминаторы давно можно было указывать.
Вы сами поняли смысл того, во что буквы сложили?
> i*::{checked_sub_unsigned, overflowing_sub_unsigned, saturating_sub_unsigned, wrapping_sub_unsigned}Почему-то именно там, где весьма стоило бы подсократить, любовь авторов Rust к сокращениям улетучивается.
Просто грибы были разные.
Это к тому что ЯП создателем был назван по мотивам семейства грибов. Смотрел сериал Элементарно, так вот в оном эпизоде был преподаватель которой учеников просвещал при помощи грибов. Просто промелькнула ассоциация )
А когда мозиловцы выкинут сабж из обязательных зависимостей?
>Добавлена функция core::hint::black_boxФункция то уже была test::bench::black_box . Вот к сожалению Bencher до сих пор в ночной версии, а штука то полезная.
>BTreeSet::{first, last, pop_first, pop_last}
>BTreeMap::{first_key_value, last_key_value, first_entry, last_entry, pop_first, pop_last}
>Duration::try_from_secs_{f32,f64}Это и всё такое прочее хорошо. Поскорей бы всё остальное стабилизировали, а то вечно как чуть что нужная функция, так иди включай ночную сборку. Когда уже можно на стабильном писать.
> Когда уже можно на стабильном писать.Нет стандарта - будут постоянные проблемы.
Есть стандарт. Есть Rust Edition 2015, 2018 (RFC 2052), 2021 (RFC 3085). То что нет стандарта это устаревшая информация.
Но какие-нибудь банальные функции вроде checked_add стали стабильными только недавно.
Эти?
https://www.rfc-editor.org/rfc/rfc2052https://www.rfc-editor.org/rfc/rfc3085
Но интересно, почему разработчики rust выбрали именно такие номера
Потому что у них последовательно добавилось более 3300 предложений 😞
RFC - не стандарты, это "Request for Comments".
Иными словами, RFC - "тема для обсуждения". И уж никак не стандарт.
Иными словами, отсутствие стандарта в общепринятом понимании этого слова (отдельный документ) не помешало однако создателям GCC добавить поддержку Rust. Поэтому как бы аргумент "нет стандарта" уже совсем не аргумент.
> Иными словами, отсутствие стандарта в общепринятом понимании этого слова (отдельный документ)
> не помешало однако создателям GCC добавить поддержку Rust. Поэтому как бы
> аргумент "нет стандарта" уже совсем не аргумент.Дааа, вот когда твоя программа на расте не будет собираться при переходе на gcc-шную версию, вот тогда ты вспомнишь про отстуствие стандарта.
Я перейду на стабильный когда там появятся все необходимые мне фичи. Это включает как минимум#![feature(alloc_error_handler)]
#![feature(allocator_api)]
#![feature(asm_const)]
#![feature(asm_sym)]
#![feature(associated_type_defaults)]
#![feature(const_btree_new)]
#![feature(const_char_from_u32_unchecked)]
#![feature(const_maybe_uninit_as_mut_ptr)]
#![feature(const_mut_refs)]
#![feature(const_ptr_write)]
#![feature(const_trait_impl)]
#![feature(core_ffi_c)]
#![feature(default_alloc_error_handler)]
#![feature(generic_arg_infer)]
#![feature(extern_types)]
#![feature(iter_advance_by)]
#![feature(iter_collect_into)]
#![feature(iterator_try_collect)]
#![feature(naked_functions)]
#![feature(negative_impls)]
#![feature(never_type)]
#![feature(nonnull_slice_from_raw_parts)]
#![feature(once_cell)]
#![feature(panic_abort)]
#![feature(panic_info_message)]
#![feature(ptr_metadata)]
#![feature(raw_ref_op)]
#![feature(result_flattening)]
#![feature(slice_ptr_get)]
#![feature(slice_ptr_len)]
#![feature(start)]
#![feature(stmt_expr_attributes)]
#![feature(strict_provenance)]
#![feature(trait_alias)]
#![feature(trusted_len)]
#![feature(type_alias_impl_trait)]
#![feature(unsize)]
> когда там появятся
> #![feature(alloc_error_handler)]Прошло 16 лет разработки...
>Прошло 16 лет разработки...Типичный комментарий опеннетного эксперта :).
Ты такой типичный что мы знаем все твои комментарии наперед.
>> когда там появятся
>> #![feature(alloc_error_handler)]
> Прошло 16 лет разработки...Не надо рушить веру детей в безопасного деда мороза
Отрасль много потеряет без тебя, поэтому весь коллектив разработчиков завтра же кинется дорабатывать так необходимые гениальному программисту всех времён и народов фичи.
Что за наезд на пустом месте?
Для разработки чего вы используете Rust со всеми этими фичами?
> Для разработки чего вы используете Rust со всеми этими фичами?Так, мелочёвка всякая для себя или почти для себя. Пет-проекты в общем. В основном два глобальных направления: 1) кроссплатформенная (Window, DOS, Linux и кто знает что ещё) игра-рогалик, 2) вспомогательные утилиты для модов на Morrowind, а так же метамоды — программы, которые запускаются на компьютере конечного пользователя и генерят мод (например https://www.fullrest.ru/files/espb).
Стремится по сложности к Ada, F90 и PL/1.
Думаю, и будущее его ждет ровно по стопам предшественников - частичные реализации, язык "для избранных", полнотой синтаксиса владеют не только лишь все.
Язык Ада просто няшка по сравнению с растом!
>Думаю, и будущее его ждет ровно по стопам предшественниковОчень может быть. У предшественников (Си, C++) были периоды адекватности, когда они являлись лучшим инструментом в той или иной области. Если у Раста будет такой период — это успех. А потом да, усложнится и будет вытеснен другим инструментом. Это нормально, это эволюция технологии (подробнее у Лема).
>>Думаю, и будущее его ждет ровно по стопам предшественников
> Очень может быть. У предшественников (Си, C++) были периоды адекватности, когда они
> являлись лучшим инструментом в той или иной области.Пфффф. Они и сейчас являются таковыми. Докажи обратное. Если раст лучший, то почему за 16 лет никто на нем не написал свое РАБОЧЕЕ ядро?
О, свидетели 16 лет подтянулись...
Уже написали рабочее ядро. Можешь даже на свой комп поставить.
Оно не работает. Только в виртуалке.
> О, свидетели 16 лет подтянулись...
> Уже написали рабочее ядро. Можешь даже на свой комп поставить.Ты наверное уже поставил и пишешь из под нее?
>> О, свидетели 16 лет подтянулись...
>> Уже написали рабочее ядро. Можешь даже на свой комп поставить.
> Ты наверное уже поставил и пишешь из под нее?С твоей логикой (и руками) и макось с какой-нибудь солярко-бздой - "нирабоичии!".
Ты поставил или нет? А то с твоей логикой ты по утрам пьешь коньяк и избиваешь жену.
> Пфффф. Они и сейчас являются таковыми. Докажи обратное. Если раст лучший, то почему за 16 лет никто на нем не написал свое РАБОЧЕЕ ядро?Рабочее ядро есть. Нет ядра, поддерживающего все 100500 вариаций всевозможных железок. Так его и на плюсах с сишкой, внезапно, нет (для опеннетных экспертусов - нет, поддержка большей части железа даже в линуксе писалась и пишется совсем не разработчиками ядра).
Отличный язык для того чтобы показать, а смотрите как я могу. Сделать простую вещь, но с подвыподвертом.
Опеннет эксперты делятся своими фантазиями о языках программирования
Смысл Вашего поста не понятен, скромный Вы наш.) Пусть скромными будут другие и мнения свои прикусят?
Сегодня свершилось - я нашел полезную для себя программу на Rust
Я уже видел где-то это...
Так с нодой такая же обкатанная тема была, ура евентлуууупппп
Все засуетились начали переписывать чето, и спустя 10 лет дошло что это калл
Вышел гошка, та же песня, все начали восхвалять, это же гугл, все бегом переписывать на гошку.
Опять прозрение...
Вышел раст, ну как его еще пропиарить, ну занесли чутка линузу, он в ядро его кинул, все опять урааа, все бегом на раст переписывать. Он кста Линузу еще боком выйдет, уже нарушил правило консистентности системы. Нахер там не нужен в ядре.
Синтаксис просто солянка из всех яп надерганная. Каждый кодер знает, что как удобно саджест на точке когда, а не эта фиш нотация. По языку видно что хоум пет проджект выкатили хомякам.
Для повседнева питон, для ентерпрайза сишарпик, для системного сишка, все остальное от лукавого, поделки для хомяков.
> Так с нодой такая же обкатанная тема была, ура евентлуууупппп
> Все засуетились начали переписывать чето, и спустя 10 лет дошло что это
> каллКак бы технология стабильна, на ней пишут и дальше, а сам проект под крылом Linux Foundation. И да, libuv такой кал, что его используют Julia или neovim.
> Вышел гошка, та же песня, все начали восхвалять, это же гугл, все
> бегом переписывать на гошку.
> Опять прозрение...Эмм. На го дофига чего пишут, особенно в облачных технологиях.
> для ентерпрайза сишарпик
Все понятно. В след. раз лучше сразу это в начале писать, чтобы время других не отнимать.
Сектант? Какое время отнимать ?
Весь фин сектор от бирж до банкинга на джаве и шарпах.
Весь стек апишек из каропки.Если противопоставить раст и сишку, то раст даже не зеро кост, он ван фрии кост, зачем пипл наябывают этим, непросвещенную в подкапотные моменты публику. Дизайна нет у языка. Синтаксис грязный, кучу атрибутов. Был бы дизайн френдли, было бы все по внятным слоям апи. Асинхронщина сырая совсем. Ансейф без борроу чекера = та же сишка. Не реди продакшен увы. Нвим, хеликс, пару бд типа тика пока это все поделки для хоум юзинга.
Может к 2 версии нормальная стд будет, асинхронщина, аби бинарей, и прочее , а пока онли фан юзерспейс поделки на клапе
> Весь фин сектор от бирж до банкинга на джаве и шарпах.Типичная черта местных экспертов, что они всему верят и даже не пытаются проверить. Например, tradingview, alpaca и даже тинек используют go.