Опубликован релиз языка системного программирования Rust 1.43, основанного проектом Mozilla. Язык сфокусирован на безопасной работе с памятью, обеспечивает автоматическое управление памятью и предоставляет средства для достижения высокого параллелизма выполнения заданий, при этом обходясь без использования сборщика мусора и runtime...Подробнее: https://www.opennet.me/opennews/art.shtml?num=52797
ну всё, теперь и в Rust есть метапрограммирование шаблонов (обобщённых параметрически через T подстановку трейтов и их имплементаций) - теперь можно HKT и GAT делать прямо через макросы, ух! >_<
Там уже есть goto и макросы? Надо срочно обмазаться
Не-не антикор обработка не для Rust, даже прямо наоборот
Безусловный переход безусловно эффективен. Язык без такой базовой инструкции не может быть полноценным. Макросы это конечно хорошо, но говорить с машиной на понятном ей языке ещё лучше.
Попадалась мне в руки как-то довольно забавная книжка, так там автор на базе какого-то примера предложил отказаться от кучи операторов. Мол, а представьте что нет у нас while. И вообще никаких циклов нет. И того нет. И этого нет. Не серьёзно, конечно, предложил.Не помню уж как называлась. Что-то старое из конца 80х - начала 90х. 128 советов чего-то там.
Николас Вирт всегда ратовал за простоту языка (все описание языка должно помещался на одной странице и быть понятным домохозяйке), контроль компилятора за памятью.Также Николас говорил, что язык программирования, компилятор, ядро ОС и процессор должен разрабатывать одна команда. Только в этом случае можно достичь простоты и совершенства. Пример A2 https://en.m.wikipedia.org/wiki/Bluebottle_OS
Ну да, простоты, совершенства и полной бесполезности.
Для обучения простые вещи полезны.
Java+ARM... но кое-кому это очень не понравилось
Жаба.. не понравилась... ну как же такое возможно !!111
>Мол, а представьте что нет у нас whileТак действительно while и не нужен.
Scheme, в чистом языке вообще никаких циклов нет, но задачи все равно красиво и элегантно решаются.
> Не помню уж как называлась. Что-то старое из конца 80х - начала 90х.Уж не знаю, кого читали конкретно Вы, но Абельсон и Сассман издали SICP в 85м, и там вполне наглядно показывалось, что циклы есть синтаксический сахар.
Но очень вкусный и полезный сахар.
> Но очень вкусный и полезный сахар.Кто ж спорит. Но тем не менее это сахар. А без сахара легко обойтись. Обеспечьте в языке рекурсию -- и циклы в принципе уже не обязательны.
упаси боже
По большому счёту может оказаться, что, при нормально растущем стеке, не потребуются ни циклы, ни даже регистры..
Только не просто рекурсию, а рекурсию с tail call optimization.
> Только не просто рекурсию, а рекурсию с tail call optimization.Рекурсия без TCO -- это не рекурсия, а непонятно зачем нужный огрызок. =)
А ежели быть точнее, то когда мы говорим о рекурсии, мы естественно имеем в виду хвостовую рекурсию. Если язык её по умолчанию не предоставляет, а только вон как в случае C -- только в виде оптимизации, которая ещё и срабатывает от случая к случаю -- то толку от такой рекурсии мало, равно как и смысла обсуждать её. Это как обсуждать type inference в Scala -- номинально для галочки есть, но по факту кому от неё в таком виде прок...
>[оверквотинг удален]
> Рекурсия без TCO -- это не рекурсия, а непонятно зачем нужный огрызок.
> =)
> А ежели быть точнее, то когда мы говорим о рекурсии, мы естественно
> имеем в виду хвостовую рекурсию. Если язык её по умолчанию не
> предоставляет, а только вон как в случае C -- только в
> виде оптимизации, которая ещё и срабатывает от случая к случаю --
> то толку от такой рекурсии мало, равно как и смысла обсуждать
> её. Это как обсуждать type inference в Scala -- номинально для
> галочки есть, но по факту кому от неё в таком виде
> прок...кстати type inFErence - в Scala очень полезен, как минимум без него исходники были бы в пару раз больше из за лишних описаний типов
>[оверквотинг удален]
>> имеем в виду хвостовую рекурсию. Если язык её по умолчанию не
>> предоставляет, а только вон как в случае C -- только в
>> виде оптимизации, которая ещё и срабатывает от случая к случаю --
>> то толку от такой рекурсии мало, равно как и смысла обсуждать
>> её. Это как обсуждать type inference в Scala -- номинально для
>> галочки есть, но по факту кому от неё в таком виде
>> прок...
> кстати type inFErence - в Scala очень полезен, как минимум без него
> исходники были бы в пару раз больше из за лишних описаний
> типовНу не в пару -- это Вы сильно преувеличиваете.
Если хотите посмотреть на то, каким type inference должен быть -- приглядитесь к ocaml. У языка строгая типизация, но указывать типы Вам придётся ровно в одном случае: при конструировании новых типов (ну и для функторов, разумеется). Дальше -- всё будет выведено автоматом.
в ocaml это достигается "+." и подобными "особенностями",
а в scala есть интеропрерабильность с jvm и тайп классы - поэтому типов нужно указывать немного больше типов, но я лучше тип укажу чем пользоваться "+." и подобным
> в ocaml это достигается "+." и подобными "особенностями",Да не, этими особенностями никто не пользуется. Обычно мы просто дёргаем модуль, подменяющий операторы, которые мы хотим использовать, на те, что работают с нужными типами. Необходимость смешивания крайне редка, в этих случаях просто дёргаем нужное явно. Посмотрите на библиотеки Core от JaneStreet -- там это практикуется в каждом модуле.
А то, о чём говорите Вы -- это просто атавизмы из SML. Да, они вроде как в OCaml есть, но они так, для обратной совместимости.
Аноним84701, цени своё время.
кто это
>Не помню уж как называлась. Что-то старое из конца 80х - начала 90х. 128 советов чего-то там."128 советов начинающему программисту?"
Да, она. Весьма забавная была книжка в своё время.
всё что выглядит так assert!(...) - это макросы
goto был и есть, даже в пакетной базе (только более свежее на гитхабе, новые изменения очень такие воодушевляющие и пока тестятся и дорабываются на гите)...
чем Rust лучше баш скриптов? разве у баша есть конкуренты?
Ничего не понял, но взял попкорн и ручку (наблюдать и записывать).
А чего не понял добавили хрени для того что бы вклинивать в язык новую хрень прям на уровне языка.
Интересно, а из макроса можно макрос определить ?
"Автоматическое управление памятью в Rust избавляет разработчика от манипулирования указателями и защищает от проблем"
Возможность работы с указателями это плюс для настоящего программиста, для баклана - да, желательно вообще писать на php
Почему вот только у настоящих программистов потом ошибки и уязвимости из-за ошибок с указателями?
>Возможность работы с указателями это плюс для настоящего программиста, для баклана - да, желательно вообще писать на phpБез обид, но вот когда люди, начинают хаить какой-то язык, то это первый признак хренового програмиста - в принципе...
Машины не виноваты, что на них ездят дебилы, так же и с языками...
Чем проще машины, тем больше охламонов на них ездят, так уж мир устроен (к сожалению)...Забивать гвозди микроскопом(поинтерами) конечно можно, но лучше все таки использоть инструменты по назначению и пых на своем месте не спроста уже десятилетия...
Если ты узанал, что такое поинтеры, это далеко не значит, что ты хороший програмист...
Как правило, люди пренебрегающие другие языки - самые страшные багописатели !
>Без обид, но вот когда люди, начинают хаить какой-то язык, то это первый признак хренового програмиста - в принципе...Это не так. Хаят язык, когда он чем-то не устраивает.
Или ты сторонник политкоррктности в отношении языков программирования?Типа "это язык несомненно альтернативно-нужный"?
> Это не так. Хаят язык, когда он чем-то не устраивает.Есть ложка, а есть вилка...
Каждая создана для конкретного применения.
Не устраивает есть суп вилкой? Ну так юзай ложку...Не задумывались, - как много веб продуктов написанно на С/С++ ?
> Или ты сторонник политкоррктности в отношении языков программирования?Причем здесь политика, сестра проститутки которая?
Иди найди работу бэкенд/фронтенд разработчиком где требуются языки програмирования использующие "поинтеры", а когда (если) найдешь, поделись как долго искал...
> Типа "это язык несомненно альтернативно-нужный"?Альтернативно нужный???
Назвать ведущий бэкенд язык альтернативным, - это конечно смело !В бизнесе есть такое понятие: спрос и предложение.
Есть спрос - быстро и дешево делать веб приложения, именно поэтому любой хостинг предлагает ПЫХ, а не С++ как бэкенд.С точки зрения здравой логики, да, С-шная програма значительно более продуктивна, чем тот же ПЫХ, но она и значительно более дорога в создании и сопровождении.
ПЫХ вовсе не виноват, что на нем пишут много недоучек и создают о нем дурную славу, это не мешает тем, у кого руки растут из нужного места поднимать на нем проекты типа мордакниги.
(Кстати, я не ПЫХ програмист, - просто видение реальности не из розовых облаков)
Это раньше фейсбук на пыхе написан был. Сейчас, наверно, во всю используется языкр на него похожий, но со строгой статической типизацией. https://www.opennet.me/opennews/art.shtml?num=50133 наверно наелись неочевидных ошибок и уязвимостей в коде на пыхе.
> ....наелись неочевидных ошибок и уязвимостей в коде на пыхеНу давайте, показывайте ЯП, который не страдает этими симптомами...
Пых вполне неплох и с задачами, для которых он изначально предназначен( своеобразный веб ) он справляется отлично.То ли дело всякие монструозные динозавры типа жабы или плюсов.. или, даже, тормознутый питон :)
Кстати, так и какие языки «безальтернативно-нужные» ?
>Без обид, но вот когда люди, начинают хаить какой-то язык, то это первый признак хренового програмиста - в принципе...Случай выше подходит под ваш ответ, но это не всегда так. ЯП это всегда компромисс на который пришлось пойти его создателям.
Если тебе нужны указатели, то в Rust они есть. Но для реализации большого количества задач они не нужны и с успехом заменяются ссылками.
Был уже тут один монарх, пяткой себя в грудь бил, все говорил о реализации блога на C++. То ли за 21 день собирался он это сделать, то ли за неделю. Но уже скоро год пройдет, а блога как небыло, так и нет.Мораль: выбирай инструмент под задачу.
ну, treefrog все же есть и пока вроде жив. Думаю блог на нем можно было бы сделать (но не буду, у меня руки не оттуда, откуда надо)
Трепло запартное, бегом побежало за пруфами. Исполнять.
Ну я имел дело с сайтом на пюсАх, правда, в качестве поддержки, а не разработки.И до и после попадалось множество разных проектов( пых, жс итп ), но такого убогого *** как тот проект, я не встречал.
Казалось бы, плюсЫ типо_несравненно_круче того же пыха, но потом, правда, оказывается, что пых изначально пилился как подобие шаблонизатора для веб-страниц, на нем огромное множество наработок итп, тогда как плюсЫ - просто_уродливая_надстройка_над_Си_доя_ооп и в задаче генерации вебстраниц с возможностью норм доработок за приемлемое время, плюсЫ начисто проигрывают тому же пыху.Как ни странно, но, да: «любой задаче свой инструмент»
>Ну я имел дело с сайтом на пюсАх, правда, в качестве поддержки, а не разработки.У вас постоянные проблемы с логикой. Вы не знаете что такое С++ и никаком образом С++ от не С++ не отличите. Поэтому толку с этих рассуждений?
>И до и после попадалось множество разных проектов( пых, жс итп ), но такого убогого *** как тот проект, я не встречал.
Опять же - ты не отличаешь жопу от пальца.
>Казалось бы, плюсЫ типо_несравненно_круче того же пыха, но потом, правда, оказывается, что пых изначально пилился как подобие шаблонизатора для веб-страниц
Ты даже о вебе ничего не знаешь. Шаблонизатор и пых сдох лет 10 назад. К тому же только идиот будет писать какие-то шаблоны на крестах.
Запомни на будущие. Если кто-то из мира С/С++ использует текст - это залётный колхозник.
>на нем огромное множество наработок итп,
А ну да, это ещё одна проблема колхозников. Вы не отличаете жопу от пальца везде. Колхозник не может отличить язык и либу. Ты там определись с методичкой - что тебе даёт профит. Если язык как таковой - зачем тебе тонны говнолиб? Если говнолибы, то причём тут язык?
>тогда как плюсЫ - просто_уродливая_надстройка_над_Си_доя_оопЧини методичку. Как я и говорил - ты нихрена о С++ не знаешь. Да и о си тоже.
>и в задаче генерации вебстраниц с возможностью норм доработок за приемлемое время, плюсЫ начисто проигрывают тому же пыху.
Опять же - проблема с методичкой. Гененрируют веб-страницы только колхозники с помойки. Так было всегда. Потуги про приемлемое время в основном сводится к тому, что колхозник попросту не может ни во что, кроме примитивной херни.
Паре трюков на пхп обезьяну можно научить. Так же можно научить перепащивать с СО. С крестами, даже с той породией на кресты о которых кукарекаешь ты - такое не прокатит.
>Как ни странно, но, да: «любой задаче свой инструмент»
Это нелепая херня. Никаких инструментов не существует. Если проще. Есть требования и есть задачи, где эти требования минимальны.
И мир так работает. Сложные и мощные вещи остаются там, где в них есть крайняя необходимость. Они с куда большим профитом во всём могут применяться везде. Но, такого кол-во людей нет.
Поэтому те, кто могут занимаются придумываем говна, что-бы вчерашний поломой мог сгенерировать хтмл-страницу. И именно это называется под задачу.
Давай попроще. Может ли условный шумахер на s-классе возить колхозников в ашан? По мнению идиотов - нет. Реально - да, причём куда лучше. Но проблема в том, что шумахеров мало, как и мало машин представительского класса.Лучшее может выполнять задачи худшего, но задач всегда больше, чем могут обеспечить лучшие. Поэтому вариант один - пытаться организовать выполнение таким образом, что-бы худшие могли делать хоть что-то.
А уже те самые колхозники далее придумывают херню вида "под задачу".
Ну и самое интересное - эта методичка уже протухла. За пруфами далеко ходить не нужно. Колхозники типа тебя орали годами "пхп наше всё - под задачу". Гугл взял сишку, прикрутил к ней гц и ооп-надстройку и оказалось, что даже колхозники могут что угодно пилить.Потому как никакого "под задачу" не существует. Не существует какой-то задачи для скриптухи. Причина проста - рядовой птушник ничем, кроме юзанья api не занимается. И все трюки, которым его научили сводятся к вызову функций. Всё это есть везде, в любой "языке".
Поэтому да, ты выше правильно спалился. Тебе как колхознику нужно api и пару педалей. Какие это будут педали - похрен.
> Был уже тут один монарх, пяткой себя в грудь бил, все говорил
> о реализации блога на C++. То ли за 21 день собирался
> он это сделать, то ли за неделю. Но уже скоро год
> пройдет, а блога как небыло, так и нет.
> Мораль: выбирай инструмент под задачу.А что его делать-то? Любой веб-сервер плюс небольшой html-файл и вот простейший блог. А что? >:-)
Я этот комментарий вижу под каждой статьей про новую версию Rust (с вариациями в "остротах", но с тем же смыслом и к той же цитате). И каждый раз он собирает плюсы. И ведь никто не потрудится минуту поискать информацию и открыть для себя, что указатель - настолько же фундаментальная абстракция для Rust, как и для C. Многое говорит о местной аудитории.Разница с C лишь в том, что по умолчанию в Rust применяется особый тип указателя (ссылка), который также содержит в себе информацию о времени жизни памяти, на которую он ссылается (для нетривиальных случаев есть unsafe и обычные сырые указатели). Но для анонимуса это слишком сложно, можно же просто хейтить и ни во что не вдуплять.
> по умолчанию в Rust применяется особый тип указателя (ссылка), который также содержит в себе информацию о времени жизни памяти, на которую он ссылаетсяМне кажется, так неправильно говорить. Возможно это формалистская придирка, но всё же...
"Указатель который содержит информацию о времени жизни" -- это в моём понимании, что-то типа std::rc::Rc, то есть указателя со счётчиком ссылок. Или, допустим, несуществующий в std, но всё же возможный Gc указатель, вида:
struct Gc<T> {
p: *T,
gc_bit: bool,
}Вот такого рода указатели содержат информацию. И такого рода указателями тоже можно жонглировать в Rust, если использовать трейт AsRef, типа:
fn print_i32<T: AsRef<i32>>(i: T) { ... }
Но по умолчанию используются обычные ссылки, которые плюс-минус C'шные указатели, но с ограничениями на использование. С ними связана информация о времени жизни, но только в процессе компиляции.
> Но для анонимуса это слишком сложно, можно же просто хейтить и ни во что не вдуплять.
Расслабься, это _нормальная_ ситуация. Иметь мнение важнее, чем иметь обоснованное мнение. Эта идея глубоко заложена в нашей культуре, она просматривается везде, например в школе сдать работу учителю, пускай и с бредовым содержимым, гораздо лучше, чем сдать пустой лист или не сдать ничего. За бредовое содержимое при некотором везении можно получить 3 из жалости. Если везения не случится, поставят 2, и скорее всего отвяжутся. А если не сдать ничего, то начнут пропесочивать, могут ещё и родителей подключить, и скорее всего заставят сдать.
> Многое говорит о местной аудитории.
Очень мало говорит. Если взять рандомную аудиторию, то с вероятностью существенно выше 0.5 она будет действовать именно так. Информации в утверждении о том, что аудитория именно такая -log(p), где 0.5<p<1.0, и это меньше 1 бита. Вот если бы аудитория была бы более вдумчивой и попадала бы в другую группу, для которой 0.0<p<0.5, то тогда можно было бы допустить что "много говорит", поскольку там без дополнительных исследований встречаемости таких аудиторий было бы невозможно ограничить -log(p) сверху.
Минусы под данным комментарием можно было бы рассматривать как "счётчик мак^w приматов" (но скаляр всё портит), однако по 2-му пункту таки имею возражение.
"Не тупи, сделай хоть что-то, не стой столбом etc." — вполне себе жизненная тактика. Потому что повышает шанс выжить в наиболее поганых ситуациях. И её надо (на мой вкус) закладывать в рефлексы. Нейронные матрицы, так сказать, обучать. Как раз задача для средней школы (ну и для родителей тоже).
Один из многочисленных минусов такой тактики Вы описа́ли. Но и пытаться зажмуривать всех придурков — тоже унылая антиутопия.
dnl пошёл задёргивать занавески…
Я не сказал, то это свойство культуры плохо, я лишь сказал, что оно нормально в нашей культуре. Мысль о том, что это плохо -- это твоя мысль, а не моя. Хотя, отмечу, я с ней согласен. Я вообще с большим подозрением отношусь к любой норме -- норма всегда субоптимальна.
И правда, какое же это ойти будет без сишных дыр?
У тебя какие-то проблемы с дырами.
С дырами у всех проблемы
У тебя их целых 2, и обе не там. ;)
Может свидетели ржавчины и на ночные сборки будут новости размещать? А то навязчивого спама не хватает)
Ну и заголовки оживите, наподобие - Не ходите к врачам! Достаточно одной совецкой батарейки и двух шурупов..
Ну не мне вас учить сами знаете :)
> Может свидетели ржавчины и на ночные...Автору новости спасибо, интересно было почитать
Да ладно, эта новость довольно показательная -- она выбивается из тренда: очень мало изменений, и все они несущественны. То есть декларации о намерениях стабилизировать язык, видимо, прекращают быть декларациями и становятся стабилизацией. Ещё пара таких новостей, и тогда они станут нормой, и вот тогда, действительно, они перестанут быть новостями. Их можно будет засунуть в мини-новости или вообще не писать о них.
А было бы неплохо, иначе где еще троллить (по доброму шутить) над фанатами раста (лицами навязывающими окружающим подход делать простые вещи сложно)
Кстати никто не заметил, отчего у растаманов плохо с чувством юмора?
чем оно лучше чем Go?
> чем оно лучше чем Go?машинный код в 2 раза быстрее (в среднем), насколько я могу судить нелья разыменовать nil указатели (в Go, к сожалению это сплошь и рядом), гораздо больше языковых средств (если для вас это плюс)
Что ещё за nil указатели?
нулевые, те которое есть, но ни на какие реальные данные не ссылаютсятак понятнее?
> машинный код в 2 раза быстрее (в среднем)Очень сильное заявление :)
> Очень сильное заявление :)что с ним не так? два разных компилятора генерят разный машинный код. решение одной и той же задачи на этих языках будет работать с разной скоростью. между прочим мой тезис подтвердили ниже и позже, с пруфами, но независимо от меня.
Если proof -- это benchmark game от Debian, то проблема в том, что эти игры очень далеки от реальной ситуации. Например, правилами этой игры искусственно запрещается использовать mem pool-ы, в то время, как в Go является более чем нормальной практикой применять sync.Pool, что во многих случаях забесплатно сильно снижает нагрузку на GC (а GC является единственной существенной причиной, почему Go может быть медленнее). Я писал свои варианты для этого benchmark game, которые работают намного быстрее (и код выглядел естественно для Go), но не отправлял эти варианты внимательно почитав правила.Если у вас будут проблемы с производительностью в Go -- вы обратитесь за помощью. Лично я постараюсь вам помочь. Я ещё не сталкивался ни с одной проблемой производительности в Go, которую нельзя было разумно решить из-за ограничений языка.
Но если говорить о реальных Downsides, то это, в первую очередь, потребление памяти, минимальный размер бинария и т.п. Это не даёт свободно использовать Go, например, в Embedded, где вполне можно использовать тот же Rust.
Это вообще разные по областям применения языки, надо спрашивать у сектантов чем это лучше C++ и почему там так много разных и явно лишних закорючек в синтаксисе :)
Я слышал, что в Rust память безопасная, и без GC, это правда?
Не верь этим сказкам сынок, слухи они такие..
Все хочу найти язык с безопасной памятью
Любой лисп, пых, руби.
GC нет. Память безопасна в рамках работы с safe Rust. Чтобы стрелять в ноги, нужно явно указывать блок `unsafe`.
"Закорючки" там не лишние, они обозначают лайфтаймы, которые являются уникальной фичей языка. В большинстве случаев выводятся компилятором, но в нетривиальных случаях нужно расставлять руками.
Не будьте таким серьезным, весьма предположительно, что тот анонимус может знать раст. Просто,
раст выглядит смешным, ну как брайнфак) вот люди и подшучивают по доброму
Ну да, режет глаза, но если привыкнуть, то поймёте, что сильно лучше и не получилось бы
Не совсем разные. Есть пересечения. Они оба лезут в системное программирование, и оба лезут в веб.
И вообще, память безопасная или нет, вопрос десятый, начиная с некоторой квалификации разработчика и использования RAII.
Вот такие реально важные для промышленности вопросы, как легкость и быстрота разработки (соответственно время выпуска продукта на рынок и норма прибыли у компании), удобство чтения кода, время вхождения в проект новых участников, стабильность языка - пока прямыми конкурентами являются такие языки как Malbolge, Brainfuck и пока с далеким отрывом Var’aq ))
> пока прямыми конкурентами являются такие языки как Malbolge, Brainfuck и пока с далеким отрывом Var’aq ))Вы забыли в добавить пояснения: "мне кажется", "на мой вкус", "по моему неосведомленному мнению", "мне друг так сказал" и так далее. А то прочитает ваш комментарий наивный человек и подумает, что вы знаете, о чем пишете. Не вводите людей в заблуждение ))
Ага, вот зайдет наконец на опеннет Лицо Принимающее Решения и капец, Var’aq на фронтэнд а Malbolge на бекенд, и правда поаккуратнее надо с советами
> память безопасная или нет, вопрос десятый,По вашему это нормально, что для индустрии важнее быстрее наклепать, чем безопаснее и надежнее сделать? А если дома строили и самолёты делали тоже с расчетом на скорость разработки? Почему мы не можем научиться у них?
>> память безопасная или нет, вопрос десятый,
> По вашему это нормально, что для индустрии важнее быстрее наклепать, чем безопаснее
> и надежнее сделать? А если дома строили и самолёты делали тоже
> с расчетом на скорость разработки? Почему мы не можем научиться у них?Потому что мало кто хочет платить цену самолета или дома за хранилку фоток котиков?
https://web1.cs.columbia.edu/~junfeng/09fa-e6998/papers/sel4... (верификация микроядра L4)
Нет это не нормально для Вас, но нормально для той системы в корой мы существуем - капиталистической.
Тут важна норма прибыли - накладные издержки будут сокращаться. См. катастрофу Боинг-737 MAX в Индонезии.
В любом случае, трудозатраты и инструмент должны быть адекватны задаче.Насчет раста, язык сырой, до сих пор вносят изменения - самолеты тут вообще не при делах, для авиации используют язык Ада - и в штатах и в россии.
Да я, знаете, не столько за раст конкретно, сколько за безопасность памяти. Пример с авиаиндустрией я у Шнайера почерпнул из его "Практической криптографии". Там он вообще много требований на ЯП наложил.А на Аде как, безопасная память?
Там есть сборщик мусора и своеобразное RAII - через переопределение процедуры Unchecked_Deallocation
Создатели языка не считают тебя идиотом. Нормальный пакетный менеджер. Нет GC. Быстрее, причем намного. Бенчмарки смотри на https://benchmarksgame-team.pages.debian.net/benchmarksgame/...
> We ask that contributed programs not only give the correct result, but also use the same algorithm to calculate that result.binary-trees:
В Go-версии импортируются только системные библиотеки:
import (
"flag"
"fmt"
"runtime"
"strconv"
)В Rust-версии какие-то левые:
extern crate typed_arena;
extern crate rayon;-----------
regex-redux
В Go-версии:
import (
"io/ioutil"
"os"
"fmt"
"regexp"
)В Rust-версии снова:
extern crate rayon;
extern crate regex;-------------
n-body
Go:
import (
"flag"
"fmt"
"math"
"strconv"
)Rust:
ну..... там SIMD на SIMDе и SIMD'ом поганяет. Хоршенько приправлено unsafe. И вообще похоже на макро-ассемблер.
Вобщем, то ещё сравнение получается.
> В Go-версии импортируются только системные библиотеки. В Rust-версии какие-то левыеПотому что в Rust есть нормальный менеджер пакетов, а в Go нет?
> n-body ... там SIMD на SIMDе и SIMD'ом поганяет. Хоршенько приправлено unsafe. И вообще похоже на макро-ассемблер
Там несколько решений, первое хоть и не бьёт сишечку, но выглядит чисто и все ещё в два раза быстрее го
https://benchmarksgame-team.pages.debian.net/benchmarksgame/...
А что не так с гошным менеджером пакетов?
>Создатели языка не считают тебя идиотом.А с чего ты взял, что создатели Go считают?
"The key point here is our programmers are Googlers, they’re not researchers. They’re typically, fairly young, fresh out of school, probably learned Java, maybe learned C or C++, probably learned Python. They’re not capable of understanding a brilliant language but we want to use them to build good software. So, the language that we give them has to be easy for them to understand and easy to adopt."– Rob Pike
>probably learned Java, maybe learned C or C++, probably learned Python. They’re not capable of understanding a brilliant languageТ.е. Пайк считает, что те, кто учил жабу/сишку/пистон, необратимо искалечили свой мозг и уже неспособны выучить нормальный язык?
Старую собаку новым трюкам не научишь.
Имхо, там ключевое на ява/си/питон, а
"They’re typically, fairly young, fresh out of school"
и ещё более, имхо, ключевое:
"but we want to use them to build good software".
Из которого самое ключевое "to use them".
>чем оно лучше чем Go?Порогом вхождения.
Кто-нибудь ставил на реальное железо redox? https://www.redox-os.org/
https://www.phoronix.com/scan.php?page=news_item&px=Redox-OS...
Лучше вот это почитай https://twitter.com/jeremy_soller/status/1251364826464411653
когда тип f16 добавят?
Сразу после того, как их завезут в LLVM
Будем надеяться, сабж избавит нас от дуршлажной сишки
unsafe избавители ничем не лучше твоей любимой сишки.
Лучше. 5% unsafe лучше, чем 100% сишного.
хорошая мантра. Наверно позволяет не задумываться об этих 5%? Ну типа: 5 не 100, все равно я уделал сишников!
В 5% кода можно наделать столько же ошибок, как и в 100%
Только ты знаешь что тестировать и где тестировать. Да и тестировать надо меньше.
это если ты хороший разработчик, и понимаешь чего ожидать. Что-то мне кажется, что если программа на 95% безопасна, то на остальные 5% некоторые могут и забить
Никакой связи. Ложка дегтя в бочке меда портит всю бочку меда. Эскобар.
Уровень мышления псевдотехнарей во всей красе
Так ты еще и гуманитарий. Так и запишем.
Чем плохо быть гуманитарием?
У вас слишком высокое самомнение о себе.
Скажу за себя: код на расте крайне сложно воспринимать, а это сама по себе проблема.
Приведи пример такого кода.
1. #[cfg()]
2. macro_rules! mac_trait {
($i:item) => {
trait T { $i }
}
}
А что тут сложного для линуксоида? Даже типичный bash сложнее.
Пардон, он не сложный, он уродский
Макросы уродуют любой язык. Но людям очень хочется иметь макросы из-за больших возможностей, которые они дают.
Кроме Лиспа, Лисп прекрасен с макросами
Лисп прекрасен только как идея. Читать код на любом из лиспов - задача не для слабонервных, и скобочки тут - самая безобидная из причин.
> Пардон, он не сложный, он уродскийНевозможно не согласиться.
Вопрос в том, насколько хорошо ты знаком с Rust? Пример кода выше я распарсил за секунду, несмотря на его спорные эстетические качества. По-моему, это главная проблема местных критиков - нежелание прикладывать усилия для изучения языка и выделять на это время. Все хотят, чтобы Rust был понятен и радовал глаз вот прям сразу. При этом никого не удивляет, что с естественными языками так не бывает, даже если алфавит тот же, что и в родном языке. Что-то я не вижу жалоб на то, что описание освежителя воздуха на казахском плохо читается.
Безумный синтаксис - болезнь почти всех хипстерских поделок. А потом они визжат, что их новый мегаязык не востребован, и начинают заниматься словесным унижением остальных, так и оставаясь со своими 0.1% условного "рынка".
У кобола синтаксис близок к разговорному английскому и почему на нем ничего не пишут сейчас? Не модно.
> У кобола синтаксис близок к разговорному английскому и почему на нем ничего
> не пишут сейчас? Не модно."синтаксис близок к разговорному английском" - это во-первых не так, а во-вторых, даже если допустить, что так - не меньшее безумие, чем пресловутые хипстерские поделки. Потому и не пишут.
Ещё одна проблема всех хипстерских поделок - они рассчитаны на недалёкого писателя, к которому внезапно почему-то надо адаптировать сам язык. При этом хипстота, "знающая" "как правильно", забывает, что на вкус и цвет все фломастеры разные.
Добавлю про безумие - это взаимосвязано, и все эти языки просто, ну банально, неэффективны. Ни в плане возможностей синтаксиса, ни в плане производительности, C-подобный синтаксис требует _минимум_ специальных обёрток, относительно хорошо _машинно_ оптимизируется, и позволяет при _достаточной грамотности_ творить достаточно чУдные вещи, обходя оптимизатор. Всего этого хипстерские поделки лишены, они упёрты в процесс ("писателя"), нежели в достижение таковым писателем результата.
Ну нет, _минимум_ - это все-таки синтаксис Лиспа. Вот там уж действительно и машине все очевидно, и никаких лишних символов-закорючек нет
> в C нет пристойного механизма обработки ошибокВ тебе говорит тот самый юзер, которого я описывал. Что такое ошибка вообще? Это код возврата из процедуры, обычно. Ну вот от этого и пляши. Можно ещё взять плюсы и играться эксепшнами, которые немножко задачу облегчают, и при этом логике не противоречат. И синтаксис не ломают.
Сорян, я следующему по тексту отвечал, но промахнулся.
> C-подобный синтаксис требует _минимум_ специальных обёртокЭто верно только до тех пор, пока ты ограничиваешь себя теми техниками программирования, которые требуют минимум специальных обёрток в C. Загляни в glibc, там есть, например, функция sort. Эта функция работает вызывая функцию сравнения элементов с передачей этих элементов указателями. Если тебе нужно быстро сортировать, то неплохо было бы функцию сравнения элементов внедрить в код сортировки -- это позволит оптимизатору сделать всё сильно лучше. Но в C это невозможно без специальных обёрток, которые привнесут в C программирование с generic типами как в C++. Альтернатива -- писать реализацию sort под каждую комбинацию типа контейнера и типа элемента. Можно ещё попробовать макрос запилить, для генерации таких реализаций, но макроязык в C немногим лучше sed'а, ради такой мелочи лучше его не использовать.
Хочешь ещё один пример? Я разочаровался в C лет десять назад, когда задумался о том, что в C нет пристойного механизма обработки ошибок, и попытался изобрести что-нибудь вменяемое. Всякие там non-local exits, типа longjmp и тому подобные, я не считал вменяемыми, и решил что раз есть возвращаемое значение, то в нём можно передавать информацию об ошибке. Но отказываться от того, чтобы возвращать return'ом из функции результат работы, и возвращать его присвоением указателю, мне тоже не хотелось. В результате я пришёл к чему-то в стиле:
enum error_t {
NO_ERROR = 0,
// тут перечисление всяких других констант
}struct my_func_returns {
int ret;
error_t err;
}struct my_func_returns my_func(...) {
...
return (struct my_func_returns){ .ret = 42, .err = NO_ERROR };
}Это работало офигенно, машинный код получался прямо как задумано, такой как я бы на ассемблере сделал: функция возвращала два значения в двух регистрах, в одном возвращаемое значение, в другом код ошибки. Но это порождало такое количество boilerplate, то я пришёл к выводу, что это не вариант. Я пытался придумать что-нибудь с макросами, чтобы хотя бы на вызывающей стороне получалось что-нибудь пристойное, чтобы обработка ошибок не перемешивалась бы с основной логикой. Но в C совершенно убогий макроязык, он работает очень локально, не въезжает в синтаксис с которым работает, и поэтому тупо навтыкать на каждое возвращаемое значение по метке, и после каждого вызова функции делать проверку и goto на метку -- это не вариант: меткам всё равно имена надо назначать вручную, и всё равно получается куча формальной писанины, которая нужна только потому, что мне моча в голову ударила работать с ошибками по каким-то правилам.
В C++ же и в Rust это делается _элементарно_. Вместо объявления бесчисленного множества структурок типа my_func_returns, мы можем объявить тип навроде хаскелловского Either (в C++ это std::expected, в Rust -- это std::result::Result) и теперь мы можем не парится обо всех этих объявлениях структур my_func_result:
C++:
expected<int, error_t> my_func(...) {
...
return 42;
}Rust:
fn my_func -> Result<i32, Error> {
...
Ok(42)
}В C++, в Haskell, в rust в стандартных библиотеках есть уже готовые типы для комбинации возвращаемого значения и ошибки в возвращаемый тип, но если бы их не было, написать их не представляет никаких проблем. В C такой подход возможен, но непрактичен, без специальных обёрток, поэтому ни в какой стандартной библиотеке его не встретишь, и сам использовать не будешь: проще переключится на C++, и писать на C с классами^W^W с std::expected.
> относительно хорошо _машинно_ оптимизируется
Относительно чего он о хорошо оптимизируется? Все эти UB лезут в C как раз потому, что он плохо оптимизируется. Он хорошо оптимизировался под PDP-11, программист писал на высокоуровневом ассемблере; компиляторы, стремясь к максимальной оптимизации делали только то, что укладывается в принцип наименьшего удивления (least surprise principle). Но по мере изменения аппаратных платформ он стал оптимизироваться хуже, и разрыв между наивными ожиданиями программиста и реальностью всё увеличивается и увеличивается. На полном серьёзе люди ломают копья в спорах о том, должен ли оптимизатор следовать принципу least surprise или принципу максимальной оптимизации.
> позволяет при _достаточной грамотности_
Но несколько десятилетий развития IT показывают, что средний уровень грамотности постоянно снижается. Программирование, как род деятельности, постоянно снижает уровень требований -- теперь программируют не профессора, и даже не научные сотрудники, а люди, которые в лучшем случае осилили получить техническое образование. Заточка языка на какую-то там подразумеваемую грамотность -- это приговор языку.
rust требует некоторой грамотности, чтобы одолеть borrow checker, но фишка в том, что если грамотности нет, то ты borrow checker не одолеешь. У тебя будет два пути -- либо обрести необходимую квалификацию и забороть borrow checker, либо расчехлить unsafe и обойти borrow checker. Первое хуже наличия грамотности только тем, что требует времени, в течение которого твоя продуктивность будет близка к нулю. Второе же -- палево, потому как детектится элементарным: find . -name '*.rs' -exec grep -H unsafe {} \;
> Это работало офигенно, машинный код получался прямо как задумано
Кем задумано?
Мужчинами которые умеют С?
> Кем задумано?Мне кажется, там понятно написано кем, но ежели я ошибаюсь, то скажу прямо и без ложной скромности: мною так было задумано. Как задумывал, так и вышло. Если бы я на асме писал, я бы пожалуй результат в одном регистре возвращал: если ошибка, значит rax содержит код ошибки, если нет ошибки, значит rax содержит результат, а CF флаг в регистре флагов использовал бы для того, чтобы дать возможность отличить ошибку от результата. Так было бы ещё круче:
call my_func
jc handle_errorНо как такую задумку объяснить компилятору -- я не знаю.
>[оверквотинг удален]
> Мне кажется, там понятно написано кем, но ежели я ошибаюсь, то скажу
> прямо и без ложной скромности: мною так было задумано. Как задумывал,
> так и вышло. Если бы я на асме писал, я бы
> пожалуй результат в одном регистре возвращал: если ошибка, значит rax содержит
> код ошибки, если нет ошибки, значит rax содержит результат, а CF
> флаг в регистре флагов использовал бы для того, чтобы дать возможность
> отличить ошибку от результата. Так было бы ещё круче:
> call my_func
> jc handle_error
> Но как такую задумку объяснить компилятору -- я не знаю.Вот это демагогия :))
Компилятору обьяснять не надо, он вообще-то тупой.. А вот когда программист не знает что такое прерывания и как из него сделать exception...
И да... на x86 какой бы он не был - жизни нет
> Компилятору обьяснять не надо, он вообще-то тупой..Мне надо получить результат от компилятора, и значит мне как-то надо высказаться на языке программирования так, чтобы получить именно тот результат, который я хочу. То есть объяснить компилятору. Так что ещё надо посмотреть, кто именно тут тупой.
> А вот когда программист не
> знает что такое прерывания и как из него сделать exception...Эксепшны для истеричек. Большинство ошибок не фатальные и обрабатываются на месте, может быть надо пару стековых фреймов снять, для ясности, и там будет понятно как обрабатывать. Но из-за этого запускать механизмы размотки стека? И ради того, чтобы эти механизмы могли бы вызывать все деструкторы, стек ещё приводить в состояние, которое позволяет в рантайме найти все эти деструкторы, которые надо вызвать? Сложность ради сложности?
> И да... на x86 какой бы он не был - жизни нет
Язык C позиционируется как кроссплатформенный, и, наверное, это хорошее оправдание тому, что компилятор нельзя научить использовать регистр флагов для возврата булевских значений. Но факт остаётся фактом, сделать идеально на нём нельзя. То есть если даже задаться целью добавить в компилятор возможность генерировать такой код, то совершенно непонятно какие именно высказывания на C должны приводить к этому.
В случае же с Rust'ом, это возможно, по-крайней мере в теории. enum с двумя вариантами, типа Result'а -- это вещь которая семантически идентична тому, о чём я говорю, осталось лишь научить компилятор передавать недостающий бит информации через флаг.
> компилятор нельзя научить использовать регистр флагов для возврата булевских значенийЭто банально не нужно и вообще контрпродуктивно, потому что add/sub в фреймировании легко может убить этот самый регистр флагов. Опять же - упёрлись в "оптимизацию" (кавычки не случайны), но забыли про то, что генерируемый код чуть сложнее, чем кажется.
>> компилятор нельзя научить использовать регистр флагов для возврата булевских значений
> Это банально не нужно и вообще контрпродуктивно, потому что add/sub в фреймировании
> легко может убить этот самый регистр флагов. Опять же - упёрлись
> в "оптимизацию" (кавычки не случайны), но забыли про то, что генерируемый
> код чуть сложнее, чем кажется.Если бы я писал на ассемблере, то я бы легко мог бы сохранить CF в нужном мне состоянии. Компилятор, если бы он задался целью, тоже мог бы, но проблема в том, что нет такой кодовой фразы на C, которая бы перед ним поставила такую цель.
Если бы хотя бы 0.01% программистов была нужна эта фича, уже давно подсуетились бы. Но похоже там цифра тех, кому это реально может понадобиться, колеблется ещё на несколько порядков ниже.
> Если бы хотя бы 0.01% программистов была нужна эта фича, уже давно
> подсуетились бы. Но похоже там цифра тех, кому это реально может
> понадобиться, колеблется ещё на несколько порядков ниже.Ой, нет. В C нет способа сказать ничего подобного. Ты прежде чем продолжать спорить остановись подумать на пять минут вот над каким вопросом: какая конструкция в C может генерировать такого рода код?
В языке в котором есть тип bool, можно было бы сделать, чтобы возвращение bool происходило бы через CF. Но в C нет типа bool, в нём вместо bool используется int, и компилятор не имеет никакой возможности догадаться, что в возвращаемом int'е используется только два значения.
То есть без изменения языка невозможно присобачить возвращения bool'а через CF. А вот чтобы изменять язык, эта фишка должна быть нужна не 0.01% программистов, а хотя бы 10%.
Но это всё цветочки, потому что возвращение bool'а через CF -- это изменение конвенции вызова. А конвенция вызова -- это дело не отдельно взятого компилятора, а гораздо более широкий стандарт. Изменение этого стандарта -- это тоже довольно серьёзно, для этого опять же нужны десятки процентов заинтересованных программистов. Сильно заинтересованных. И я, например, не вхожу в число настолько заинтересованных -- я могу согласиться и на тот способ, который я привёл в исходном комменте. Но если бы я писал на асме, я бы легко мог использовать такую конвенцию, которая удобна мне, заточив её под себя напильником.
>>> компилятор нельзя научить использовать регистр флагов для возврата булевских значений
>> Это банально не нужно и вообще контрпродуктивно, потому что add/sub в фреймировании
>> легко может убить этот самый регистр флагов. Опять же - упёрлись
>> в "оптимизацию" (кавычки не случайны), но забыли про то, что генерируемый
>> код чуть сложнее, чем кажется.
> Если бы я писал на ассемблере, то я бы легко мог бы
> сохранить CF в нужном мне состоянии. Компилятор, если бы он задался
> целью, тоже мог бы, но проблема в том, что нет такой
> кодовой фразы на C, которая бы перед ним поставила такую цель.ВОт это брЕЕд...
Давай, чтобы не прослыть треплом - напишика код который флаг переполнения контролирует, особенно для беззнака. :)))))
Есть две ключевые инструкции, про которые тебе будет интересно узнать: stc и clc. Но бывают и другие способы, которые могут быть удобнее в зависимости от ситуации.
> Есть две ключевые инструкции, про которые тебе будет интересно узнать: stc и
> clc. Но бывают и другие способы, которые могут быть удобнее в
> зависимости от ситуации.Реальный код давай. Тут три четверти псевдо-программистов умеют гуглом пользоваться.
>> Есть две ключевые инструкции, про которые тебе будет интересно узнать: stc и
>> clc. Но бывают и другие способы, которые могут быть удобнее в
>> зависимости от ситуации.
> Реальный код давай. Тут три четверти псевдо-программистов умеют гуглом пользоваться.Дитятко, любая из этих мнемоник -- реальный код. Поставь её на отдельной строчке в .asm/.s файле, и она будет реальным кодом. Открой любой учебник по ассемблеру, и ты узнаешь, ассемблер очень простой язык, гораздо проще всех этих ваших rust, C и тому подобных.
>>> Есть две ключевые инструкции, про которые тебе будет интересно узнать: stc и
>>> clc. Но бывают и другие способы, которые могут быть удобнее в
>>> зависимости от ситуации.
>> Реальный код давай. Тут три четверти псевдо-программистов умеют гуглом пользоваться.
> Дитятко, любая из этих мнемоник -- реальный код. Поставь её на отдельной
> строчке в .asm/.s файле, и она будет реальным кодом. Открой любой
> учебник по ассемблеру, и ты узнаешь, ассемблер очень простой язык, гораздо
> проще всех этих ваших rust, C и тому подобных.Ты че идиот? Еще толпа операций неявно меняют флаги переполнения. Хотя в целом понятно, очередной псевдо-программист. Слышал звон, да явно не знает где он. Хотя таких много последнее время. Ни строчки кода не написано, зато гуглом поиском хорошо пользуется.
> Ты че идиот?Нет ты.
> Еще толпа операций неявно меняют флаги переполнения.
99% (или около того) этой "толпы" находятся в группе арифметических операций.
> Ни строчки кода не написано, зато гуглом поиском хорошо пользуется.
Какие строчки кода ты хочешь от меня увидеть? Вот смотри:
stc
retВыставили CF вернули управление. CF сохранился выставленным. Подойдёт?
Что-то мне подсказывает что нет, не это тебе интересно. Но мне не понятно, какие именно непреодолимые проблемы ты видишь на пути возврата бита из функции через CF. Поскольку я не понимаю, что именно непонятно тебе, я не могу просветить тебя и научить тебя, как это делать. Если тебе что-то интересно, ты спрашивай, но постарайся в вопросе донести информацию о том, что именно тебе непонятно, иначе совершенно неясно как отвечать на твои вопросы.
Я как бы вас понимаю, убитых и загнобленных x86 архитектурой. Но то что ты написал выше - не живет в природе, что подтверждает что ты теоретик. Перед ret тебе как минимум надо будет pop-ить несколько регистров которые ты использовал в функции а это зачастую может повлиять на флаг переполнения. А чушь которую ты напишешь дальше - что типа ты stc будешь ПРОВЕРЯТЬ и Выставлять сразу перед ret я даже обсуждать не хочу - данных вычислений уже акутальных в регистрах не будет. Там будут pushеные в начале функции значения. Далее, если ты щас вздумаешь сболтнуть что будешь результат таскать и сверять через память для установки cf, то опять таки не стоит выеденного яйца, вытащить результат из стека будет стоить дешевле чет ...рней заниматься с флагами переполнения.
И да, не надо мне щас лапшу вешать что ты настолько крут что с 12 регистрами общего назначения сможешь без стека обойтись - не стоит. Не смеши меня и народ.
> Перед ret тебе как минимум надо будет pop-ить
> несколько регистров которые ты использовал в функции а это зачастую может
> повлиять на флаг переполнения.Нет, не может. Содержимое идущее в регистр из стека не меняет флагов. Изменение %rsp командой pop тоже не меняет CF, хотя %rsp при этом и меняется посредством сложения. Единственный способ изменить флаги из стека -- это popf.
А, хотя не, есть ещё iret.
> А чушь которую ты напишешь дальше -
> что типа ты stc будешь ПРОВЕРЯТЬ и Выставлять сразу перед ret
> я даже обсуждать не хочу - данных вычислений уже акутальных в
> регистрах не будет. Там будут pushеные в начале функции значения.Всякие разные конвенции вызова, часто не гарантируют сохранность _всех_ регистров. Даже более того, они _все_ не гарантируют сохранность _всех_ регистров, потому что как минимум один из них используется под возвращаемое значение. Но я к тому, что часто бывают ещё и другие регистры, которые не сохраняются. Но даже если бы это было не так, то никто не помешал бы мне сделать что-то типа:
; бла-бла-бла,
; кладём в %rax возвращаемое значение
add $N, %rsp ; снимаем к чертям локальные переменные со стека
; оставляя пока себе локальные значения регистров, которые нам ещё понадобяться
<тут проверка на ошибку, которая для более показательной сложности не CF выставляет, а ZF>
pop %<saved-reg> ; восстанавливаем регистры, повторяя это для каждого сохранённого регистра
jz 1f ; если ошибка приключилась
clc
ret
1:
stc
retЗаметь: если мне удастся провести проверку на ошибку так, чтобы CF заполнился бы этой ошибкой как надо, то и гнусный условный переход не понадобиться. И это вполне возможно будет именно так, потому как есть всякие арифметические команды, которые выполняются _условно_, если флаги правильно проставлены.
Например, хочется мне сделать сисколл, который возвращает неотрицательный int, в случае успеха, и отрицательный int в случае ошибки (то есть -errno) -- это довольно распространённо при вызове сисколлов в лине. Но мне хочется вернуть в любом случае неотрицательное значение, которое будет сопровождаться CF, чтобы вызывающий код понял, ошибка это или нет, тогда:
; бла-бла-бла
syscall
test $0, %rax
clc
jns 1f
neg %rax
stc
1:
pop <все те регистры, которые испортил syscall, и которые мы не должны портить>
retТолько чтобы конвеер не сбивать в случае, когда всё идёт хорошо, лучше всё от 1: и до ret перенести куда-нибудь выше по коду, дабы переход случался назад. И я вот думаю, что практически наверняка есть какой-нибудь хитрый способ проверить %rax на отрицательность, который заполнит нам CF так как надо, но неохота думать.
> И да, не надо мне щас лапшу вешать что ты настолько крут
> что с 12 регистрами общего назначения сможешь без стека обойтись -
> не стоит.Эмм... Не хочу тебя огорчать, но у меня всегда было плохо с арифметикой, и ещё в досовские времена я ненавидел работать с переменными на стеке, потому что для этого надо было считать их смещение от того значения sp которое было на входе в функцию. Кроме того, мне кошмарно не нравилось занимать целый регистр адресом стекового фрейма, а если не занимать, то в 16-битном режиме было невозможно было косвенно адресовать память через sp. Поэтому у меня выработалась гнусная привычка писать под _стековую_ машину, ну то есть я жонглирую регистрами, а когда мне их не хватает, я делаю push, потом, когда появляется свободный регистр, извлекаю значение обратно при помощи pop. Такие интересные эффекты случаются, когда случается вписать в цикл несбалансированное количество push/pop -- это просто нечто. Хотя, в досе, как правило это кончалось наглухо висящей машиной.
Дурацкая привычка, я не спорю, единственный бонус -- компактность кода, которая бонусом могла быть разве что в 16-битном досе. Но, как бы там ни было, на amd64 есть _КУЧА_ регистров, и тут гораздо проще обходиться без адресации в глубины стека.
Имхо, проблема в том, что когда писали компилятор C под x86 (ещё во времена MSDOS, разные там BCC) c calling convention для них выглядел следующим образом:z = func(2, 1);
push 1
push 2
call func
add sp,4
;значение z располагается в axпосле этого флаг CF уже был потерян. Потом уже придумали разные pascal, fastcall и прочее. Ну и кроме того - это для 86 архитектуры, видимо, был отдельный регистр флагов, который можно анализировать командами условных переходов. Для других архитектур всё могло быть немного иначе.
Кроме того, например, Вы написали (с таким хитрым возвратом, как Вы описали) следующий код:
ret_t ret;ret = my_func(1, 2, 3, 4);
z = a + b * d / f + 4000;
if (ret.err)
{
}для того, чтобы флаг CF не потерялся, его придётся где-то записать в стек, или ещё куда, сразу после возврата, чтобы после вычисления выражения вытащить и таки проанализировать.
В общем, конечно, было-бы неплохо, но тогда, похоже, настолько всё усложнять разработчики компиляторов не стали.
Кстати, то, что Вы предлагаете, по-моему, подавали на включение в стандарт C2X, правда не знаю с каким результатом.
> после этого флаг CF уже был потерян.Может быть. Мне более правдоподобной кажется гипотеза о том, что это было слишком заморочно для компиляторов тех лет.
> для того, чтобы флаг CF не потерялся, его придётся где-то записать в
> стек, или ещё куда, сразу после возврата, чтобы после вычисления выражения
> вытащить и таки проанализировать.Если мы возвращаем Result, то такое вряд ли случится, потому как он требует обработки. То есть его можно записать в переменную и обработать после, но как правило он обрабатывается сразу. Хотя функция часто досрочно завершается и возвращает этот Result, а завершение может потребовать арифметики, а это значит дополнительная возня со флагом, только для того, чтобы завершиться. С другой стороны, это всё происходит в случае ошибки, и скорость её обработки менее важна, чем скорость работы без ошибки.
Но, в общем, я согласен, что тут бабка надвое сказала, стоит оно того или нет. Это надо испытывать на реальных приложениях, затачивать оптимизатор под эти реальные приложения, приспосабливать приложения к оптимизатору, и потом смотреть что получилось. Сложно, долго, и нафиг нужно.
Исключения и явный возврат ошибок в расте принципиально мало отличаются. Это вопрос реализации.
Представь себе, что добавили конструкцию try catch в rust в виде синтаксического сахара поверх обычного механизма Result.
Чем тут method()?other_method()?yet_another_method()? от
try {
method.other_method.yet_another_method
} catch {
}
Сильно различаются?
Возврат Result это тот же checked_exception в Java, только соус другой.
> Исключения и явный возврат ошибок в расте принципиально мало отличаются. Это вопрос
> реализации.
> Представь себе, что добавили конструкцию try catch в rust в виде синтаксического
> сахара поверх обычного механизма Result.Не получится. Одна из основных задач Result -- помочь программисту не забыть обработать ошибки: ты не сможешь добраться до значения, которое вернула функция, не распаковав обёртку из Result'а. Кроме того, тип Result'а может меняться по мере последовательных возвратов: ? проверяет Result, и если он Err, то он либо возвращает его как есть, либо если возвращаемый тип ошибки отличается от того, который в наличии, он пытается сделать from -- то есть сгенерить ошибку нужного типа, из той, что прилетела.
try/catch ты можешь не писать, и исключение продолжит разматывать стек. Result ты не можешь не развернуть, если хочешь работать с результатом функции. Чтобы такое было возможно, компилятор должен генерить всякий специальный код, который будет отрабатывать даже тогда, когда всё идёт норм. Я не вдавался в подробности, но, судя по всему, там нужна какая-то специальная огранизация стека. Там возникают всякие интересности, вида обработки вложенных ошибок, когда исключение вылетело в процессе размотки стека из-за другого исключения.
Передача ошибки возвращаемым значением сильно другая, стек разматывается не принудительно, Result -- это не non-local exit. throw -- это погрейженный longjmp, если присмотреться. Result -- это способ прокинуть информацию об ошибке при помощи return.
А насчёт синтаксического сахара, фишка в том, что в rust есть макрос try!, который в использовании похож на try/catch, но этот макрос заменили синтаксическим сахаром оператора ?.
> Чем тут method()?other_method()?yet_another_method()? от
> try {
> method.other_method.yet_another_method
> } catch {
> }
> Сильно различаются?Если забить на различия в реализациях (на которые на мой взгляд нельзя забивать, они принципиально разные), то тогда отличия только в том, что try/catch многословнее и неудобнее.
В расте же я могу сделать что-то типа:
let ret = method().map_err(|_| "Method failed".to_string())?
.other_method().map_err(|_| "Other method failed".to_string())?
.yet_another_method().map_err(|_| "Yet another method failed".to_string())?;После этого мой код будет выкидывать разные ошибки, в зависимости от того, в каком месте он обломался. В случае же с try/catch ты сможешь понять откуда исключение вылетело только если тебе повезёт, и эти все методы будут выкидывать разные типы исключений.
Помимо этого, Result имеет и другие методы, кроме map_err. Например ok_or_else -- если метод вернул вместо значения ошибку, я могу вызвать другой метод, который вернёт хоть какое-нибудь значение. try/catch можно использовать таким образом, но тебе придётся каждый вызов заворачивать в отдельный try/catch. Это можно, но сильно многословно.
map_err(|_| ...)?;
Глаза снова вытекли.
> map_err(|_| ...)?;
> Глаза снова вытекли.У тебя все глаза сразу вытекают? Или как так выходит, что они вытекают, вытекают, и всё равно что-то остаётся?
Я стараюсь не кормить глаза говносинтаксисом регулярно, поэтому они вытекают редко, только вот в таких вот дискуссиях.
> map_err(|_| ...)?;
> Глаза снова вытекли.Кстати, а ты не напомнишь, как в C делаются лямбды? То есть, в C такого нет понятно -- ни в K&R, ни даже в c99 -- но в gcc есть возможность как-то сделать, я точно помню, что возможность была, я просто не помню как это надо было делать. Что-то типа такого:
map_err((return_type_t)(*)(input_type_t val) { return "Method failed" })
Или там какое-то ключевое слово нужно вставить куда-то, типа __function__? Или может надо ещё одну пару скобочек добавить вокруг аргумента map_err, чтобы парсер C не запутался бы?
А, точно, скобочки, только фигурные:
map_err({return_type_t fn(input_type_t val) { return "Method failed" } fn})
Что-то типа этого ведь, так? А если мы ещё хотим гарантированно не получать варнингов о неиспользуемом val, то к нему какой-нибудь атрибут надо приделать, типа:
map_err({return_type_t fn(input_type_t val __gcc_attribute__((unused))) { return "Method failed" } fn})
Многословно, зато глаза не вытекают, да.
Многословно, да, но всё равно несколько более упорядоченно.
Осталось только придумать, на хрена вообще такая конструкция.
> try/catch ты можешь не писать, и исключение продолжит разматывать стек.Как будто From для Result это бесплатно, открываешь машинный код и видно, что теперь везде есть ветки проверки результата на Ok и если не Ok, то вызов From, а затем return с результатом преобразования. Чем это тебе не разматывание стека? :) Точно также получается кучка преоборазований поэтапно с возвратом в каждую функцию выше и дропом всего, что надо дропнуть.
С исключениями теоретически и на практике это может быть не нужно, например если в Java ты бросаешь исключение без заполнения stack trace, а это легко сделать, то фактически будет выполнен переход сразу на тот try catch какой надо. Весь стек ниже будет просто выброшен без пустопорожних преобразований как в Result и From.
> Одна из основных задач Result -- помочь программисту не забыть обработать ошибки:Я исключения из Java в пример привожу, там есть checked exception.
Если это checked exception, ты просто обязан сделать одно из двух, либо поставить try catch, либо указать, что ты его пробрасываешь выше в throws метода.
Это от Result становится неотличимо по поведению, только синтаксически.
Хорошо, пусть у тебя будет:
let ret = method().map_err(|_| "Method failed".to_string())?
А если тебе надо обработать ошибку, то будет уже иное:
if let Err(e) = method() {
} else {
}
Может быть match менее многословно?
match mathod() {
Ok(_) => {}
Err(_) => {}
}
Да по мне таже фигня.
>> try/catch ты можешь не писать, и исключение продолжит разматывать стек.
> Как будто From для Result это бесплатно, открываешь машинный код и видно,
> что теперь везде есть ветки проверки результата на Ok и если
> не Ok, то вызов From, а затем return с результатом преобразования.
> Чем это тебе не разматывание стека? :) Точно также получается кучка
> преоборазований поэтапно с возвратом в каждую функцию выше и дропом всего,
> что надо дропнуть.В rust'е обработка Result'ов проверяется на этапе компиляции компилятором.
> С исключениями теоретически и на практике это может быть не нужно, например
> если в Java ты бросаешь исключение без заполнения stack trace, а
> это легко сделать, то фактически будет выполнен переход сразу на тот
> try catch какой надо. Весь стек ниже будет просто выброшен без
> пустопорожних преобразований как в Result и From.А это как раз неудобно. Вот смотри, тебе вылетела ошибка FileNotFound. Ты поймал её в main. И чё?
Твой код, парсящий toml/json/что-то ещё из файла, может не знать, как надо правильно реагировать на FileNotFound. Где-то чуть выше по стеку всё равно не ясно, но зато семантика ошибки другая, скажем ConfigFileDoesntExist. А ещё несколькими стековыми фреймами выше всё очень просто -- надо не читать Config из файла, а создать дефолтный.
Если ты присмотришься к ошибке разматывающей стек и примеришь её к каждому стековому фрейму, ты увидишь что смысл ошибки меняется по мере размотки. И Result позволяет это отметить в ошибке с минимум накладных расходов. Даже From писать не обязательно, всегда можно сделать map_err. Вот когда map_err получаются большими -- там хорошо вынести их логику в impl From.
>[оверквотинг удален]
> А если тебе надо обработать ошибку, то будет уже иное:
> if let Err(e) = method() {
> } else {
> }
> Может быть match менее многословно?
> match mathod() {
> Ok(_) => {}
> Err(_) => {}
> }
> Да по мне таже фигня.Я согласен, что checked exception в java по семантике то же самое, что и Result. Различия только в синтаксисе и в деталях реализации.
А насчёт многословности, if let, и match редко нужны для Result'а, как правило оно разруливается иными путями. То есть нужно иногда, и очень полезно в тех случаях, но это редко случается. if let и match описываются в туториалах, потому что это способы общего назначения. Как и что будет сделано в частном случае -- сложно описать или даже перечислить подходы. Это уже от тебя зависит: тебе следует почитать доку на Result и посмотреть что он позволяет сделать с ошибкой.
Например, обработка ошибки может выглядеть так:
let config = read_config_file().unwrap_or(Config::default());
Или если ты сделал
impl Default for Config { ... }
то можно так:
let config = read_config_file().unwrap_or_default();
> в C нет пристойного механизма обработки ошибокВ тебе говорит тот самый юзер, которого я описывал. Что такое ошибка вообще? Это код возврата из процедуры, обычно. Ну вот от этого и пляши. Можно ещё взять плюсы и играться эксепшнами, которые немножко задачу облегчают, и при этом логике не противоречат. И синтаксис не ломают.
> невозможно без специальных обёрток, которые привнесут в C программирование с generic типами как в C++
Это ты сам себе придумал, что я только про чистый C? Нет, я про синтаксис, и только про синтаксис. C, C++, C#, Java и т.п. Прелесть в том, что базовый синтаксис вполне расширяем, и не нужно изобретать велосипеды.
>> в C нет пристойного механизма обработки ошибок
> В тебе говорит тот самый юзер, которого я описывал. Что такое ошибка
> вообще? Это код возврата из процедуры, обычно. Ну вот от этого
> и пляши. Можно ещё взять плюсы и играться эксепшнами, которые немножко
> задачу облегчают, и при этом логике не противоречат. И синтаксис не
> ломают.Эксепшны ломают логику: это нелокальный выход, a la longjmp. Синтаксис у них получше, чем в моём C'шном варианте -- это бесспорно. Но тоже не фонтан, если честно. В C++ есть expected, вот он делает именно то, что я выше написал на C, но в гораздо более приятном синтаксисе.
>> невозможно без специальных обёрток, которые привнесут в C программирование с generic типами как в C++
> Это ты сам себе придумал, что я только про чистый C? Нет,
> я про синтаксис, и только про синтаксис. C, C++, C#, Java
> и т.п. Прелесть в том, что базовый синтаксис вполне расширяем, и
> не нужно изобретать велосипеды.Расширяем, угу. Особенно это видно в C++, чем заканчиваются расширения. Но даже в C, вещи типа:
int (*arr[8])(int)
Оччень расширяемо. Да. Спиралевидно.
Я -- увы -- не могу найти статью, где раскрывалось уродство и неоднозначность этого синтаксиса. Но зато я нашёл статью[1], объясняющую как не напарываться на неоднозначность. Не столь показательно, но всё равно даёт представление о проблеме.
[1] https://wiki.sei.cmu.edu/confluence/display/cplusplus/DCL53-...
> fn my_func -> Result<i32, Error>Глаза вытекают уже на ->
Вы объявление лямбда-функции никогда не видели?
>> fn my_func -> Result<i32, Error>
> Глаза вытекают уже на ->Я лишь могу выразить соболезнования. Если твое глаза вытекают от этого диграфа, то значит ты никогда не сможешь освоить не только rust, но ещё и Haskell, ещё и OCaml, и вероятно кучу других языков программирования, которые могут быть очень увлекательными для освоения. Очень образовательными.
И всё лишь потому, что у тебя глаза вытекают из-за какого-то диграфа. А почему именно этого? От += не вытекают? А от триграфов типа <<= не вытекают?
> никогда не сможешь освоить не только rust, но ещё и Haskell, ещё и OCaml, и вероятно кучу других языков программирования, которые могут быть очень увлекательнымиЯ оперирую критерием полезности, а не увлекательности. При этом гораздо увлекательнее, когда ты имеешь на руках нужный тебе практический результат на нормальных языках, а не десяток "освоенных" ненужных языколяпов в теории. Это как совковый кругозор - вроде и знают много, а толку нет.
>> никогда не сможешь освоить не только rust, но ещё и Haskell, ещё и OCaml, и вероятно кучу других языков программирования, которые могут быть очень увлекательными
> Я оперирую критерием полезности, а не увлекательности. При этом гораздо увлекательнее,
> когда ты имеешь на руках нужный тебе практический результат на нормальных
> языках, а не десяток "освоенных" ненужных языколяпов в теории. Это как
> совковый кругозор - вроде и знают много, а толку нет.Ты программируешь только потому, что тебе платят деньги? Или может ещё и потому, что это увлекательно?
> И всё лишь потому, что у тебя глаза вытекают из-за какого-то диграфа.Я сказал "уже", если ты не понял. Остальное там ещё хуже.
> А почему именно этого? От += не вытекают? А от триграфов типа <<= не вытекают?
+= и <<= легко бьётся на две операции: + = и << =, которые имеют смысл.
Но суть не в этом. Глаза вытекают не от символов, а от самого построения.
>> И всё лишь потому, что у тебя глаза вытекают из-за какого-то диграфа.
> Я сказал "уже", если ты не понял. Остальное там ещё хуже.Это "уже" очень показательно, если ты не понял. Остальное можно не слушать, после этого.
Машинно оптимизируется он, потому что 30 лет процессоры под него проектируют, в ущерб теоретической производительности и чистоте дизайнаЯ не найду сейчас ссылки, где эта тема раскрывается.
Конечно не найдешь, потому что это полная чушь.
https://queue.acm.org/detail.cfm?id=3212479
Спасибо, кажется, именно эту статью я имел в виду
> C-подобный синтаксис требует _минимум_ специальных обёрток, относительно хорошо _машинно_ оптимизируется,Т.е. дать ссылочку на такой "хорошо оптимизирующий машинно" и минимальный (а не на миллионы строк) компилятор С вас не затруднит?
> и позволяет при _достаточной грамотности_ творить достаточно чУдные вещи, обходя оптимизатор
Правда, в осносновном в прохладных былинах и других, более лучших чем наша, реальностях лапшеразвеши^W комментаторов опеннета :(
Потому что в моем варианте реальности, к сожалению, "недостаточно грамотные" неосиляторы из разработчиков ядра, (g)libc, (де)кодировщиков видео, BLAS и т.д, вместо "обхода оптимизатора" средствами "прекраснейшего и эффектнейшего синтаксиса" -- напихали ламерских интринсиков/ассемблерных вставок :(
> "хорошо оптимизирующий машинно" и минимальныйЭто ваши личные половые требования. Мне достаточно первого пункта.
>>> относительно хорошо _машинно_ оптимизируется
>> "хорошо оптимизирующий машинно" и минимальный
> Это ваши личные половые требования. Мне достаточно первого пункта.Что, не все верят анонимным опеннетным комментаторам на слово? Некоторые еще и каких-то пруфов требуют? Совсем оборзели, да! 🙄
Так ты про пруфы или про одновременно "хорошо и минимального размера", болезный?
> Так ты про пруфы или про одновременно "хорошо и минимального размера",Т.е. ты сам не понял, что написал? Если "синтаксис требует _минимум_ специальных обёрток, относительно хорошо _машинно_ оптимизируется,", то где же "хорошо и минимального размера"? Синтаксис-то, если верить анониму, позволяет.
Или можешь дать ссылку на код "_достаточной грамотности_" посложнее хеловрота, который без интирсиков и ассемблерных вставок будет в сборке с O0 быстрее работать чем c О2 (т.е. "обходить оптимизатор")?
Ну или можешь еще что-то придумать -- это ведь ты сделал весьма смелые заявления и соотв. "бремя доказательства" на тебе.> личные половые требования
> болезный?Вах, какие аргументативные аргументы!
Тут не аргументы, тут как раз факты.
> Тут не аргументы, тут как раз факты.Пока что налицо лишь факты онанимного балабольства.
Впрочем, от "знатока", не различающего синтаксис и семантику - ничего иного и не ожидалось.
Синтаксис С это шляпа полная. Достаточно вспомнить, что до clang'а нормально анализировать даже сорцы на чистом С было нечем, даже надёжной подсветки в IDE не было.>относительно хорошо _машинно_ оптимизируется
Далол, постоянно проверять ассемблер, процесс оптимизации от бога.
Аппаратные возможности процов затащили в стандарт всего-то через 10 лет после того, как они стали нужны. Лучший системный язык эвар.
> до clang'а нормально анализировать даже сорцы на чистом С было нечем, даже надёжной подсветки в
> IDE не былоПоржал, пошёл дальше. Спасибо.
У Ruby синтаксис близок к разговорному английскому, и на нем вполне пишут.
угу. И главное как пишут! Поубивал бы некоторых
Некоторых ?
ну, тех, которых не удается убедить больше не писать на руби
Ты перепутал с перлом.
Похоже синтаксис близкий к разговорному причина отказа от использования языков программирования. Под каток уже попали кобол, руби, перл.
>Похоже синтаксис близкий к разговорному причина отказа от использования языков программирования.Угу, например все уже отказываются от
SELECT * FROM Planets WHERE Radius BETWEEN 3000 AND 9000
Это всё же язык запросов, а не язык программирования.
Уже не все так просто. А LINQ?IEnumerable<int> scoreQuery = from score in scores where score > 80 select score;
А на Перле сейчас вполне пишут?
На руби тоже давно ничего не пишут, только поддерживают старые велосипеды.
Пока что визжат и занимаются словесным унижением, как раз-таки, его противники, что наглядно видно по засилью соответствующих комментариев под новостями о Rust, включая ваш. А мы молча пишем код, пока на нас не набрасывается стая визжащих макак, кидающая фекалии в синтаксис.
Смысл? Я спокойненько пишу на C, C++, PHP, без проблем правлю баги в софте на Java и ECMA, благо они все похожи. Разбираться с чем-то альтернативным смысла нет.
Ну пиши, никто тебе не мешает. Но нет, пришёл в новость о Rust и написал over 9000 комментов про то, как у тебя глаза вытекают. Ну так не смотри! Иди и дальше любуйся на прекрасный C++ и нюхай неземной аромат PHP.
Если так не нравятся коментарии - графоманией можно заниматься в ящик ближайшего стола, а не в сеть.
Очередной шажок превратить дорогих программистов в ремесленников?
Если люди с питона, руби и прочей тормозной скриптухи перейдут на раст, то это будет хорошо.
Эй, вам надо пачитать книжка! Rust и питон и руби - языки разных областей применения! Не пересекающихся почти полностью.
Это в теории, а на практике тормозную скриптуху пихают везде.
> Это в теории, а на практике тормозную скриптуху пихают везде.А ведь что мешает сделать интерпретатор Си(с классами) с тем чтобы приучать питонистов и прочих к нормальному языку?
Я в детстве дотнетнировал, как аноним со стыдом в признаюсь сием постыдном грехе (но всегда после мыл руки!) Вот думаю если анонимусу хочется как интерпретатор С (с классами) он тоже может подотнетнировать (после мойте руки, клавиатуру, соблюдайте гигиену!)И таки да, без шуток, питон - НОРМАЛЬНЫЙ язык. Аноним использовал в работе за эти десятилетия C, С++ (98, 11), C#, Java, Python, Ruby, Dart, LSL (моя любовь), Bash, QuakeC и даже Perl.
Просто для каждой задачи нужен свой инструмент.
Учите матчасть.
Питон хорош только тем, что для него наплодили библиотек почти для всех случаев жизни.
> Питон хорош только тем, что для него наплодили библиотек почти для всех
> случаев жизни.Именно библиотеки и есть ремесло...
Библиотеки то, в основном, не питоне. Их из него только вызывают.
Да и переносят когда надо без проблем, вот например с питона на джулию инструмент машинлёнеров уже перенесли
https://github.com/cstjean/ScikitLearn.jl
Я же больше не дотнетнирую! зачем минус то поставили!)
я дотнетирую, мне обидно
> Я же больше не дотнетнирую! зачем минус то поставили!)Взгляд бросил прочитал - детонирует ) MS43 от Siemens очень умеет это обходить.
Уже https://root.cern.ch/cling
>> Это в теории, а на практике тормозную скриптуху пихают везде.
> А ведь что мешает сделать интерпретатор Си(с классами) с тем чтобы приучать
> питонистов и прочих к нормальному языку?Этож Бейсик? НЕ?
Потому что rust - язык без сборщика мусора, якобы предназначен для низкоуровневых вещей - к примеру драйвера (в теории), какие то еще приложения где требуется real-time код, компактность и быстродействие. Так что на практике люди используют "презренные" пехи и руби там где надо. Вы пишете драйвера на питоне? На чем вы будете делать макет алгоритма? на расте?
Просто та область применения для которой раст разработали уже давно занята, оттого фанаты языка такие назойливые.
Автовыведение типов и синтаксический сахар позволяют на rust писать почти так же компактно как на python. При этом предоставляет более низкий порог вхождения чем с++. Я пробовал писать и системные демоны и веб апи, и даже встраивать в python. При должных навыках код получается быстрый и компактный, не такой читаемый как python, но более читаемый чем с++. У rust сейчас одна проблема это сложность создания библиотек и от того их количество.
Ты уж меня извини, но с его синтаксисом там скорее не сахар, а смесь перцев с говном.
Нормальный там синтаксис.
Достаточно немного его попытаться изучить чтоб понять логичность каждой чёрточки. И насколько сложно сделать иначе без потерь.
Вот в этом то и главный косяк этого языка, слишком много телодвижений даже для тривиальных задач.
Конечно в языке все его черточки логичны, суть в том что их слишком много :)
А растовский сахар он такой, вредный, диабет можно заработать.
Попытаться немного изучить = лишние телодвижения?)
Если сравнивать синтаксис Раста и Плюсов
миссклик. так вот> Если сравнивать синтаксис Раста и Плюсов
то окажется, что не так уж раст и страшен, а в некоторых случаях и превосходит
Плюсы проще в базовой форме, когда не уходишь в дебри, но, когда смотришь на некоторые новые фичи 20 плюсов, понимаешь, что вообще-то можно (и, возможно, лучше) вложить время и в изучение раста :)А кроме плюсов у него по сути нет конкурентов. И то, плюсы скорее из-за популярности вытягивают, при этом до сих пор не имя имея дефолт пакетного менеджера и системы сборки (не cmake единым), что позорно для языка такого уровня.
По началу мне тоже так казалось. Много лишнего кода ради проверки всех возможных состояний, но это только от незнания, когда изучил чуть лучше оказалось что для всего уже написан специальный сахар после применения которого код сжался в два раза, примерно до 130% от кода на python. Зато действительно не было такого чтобы собранный код упал на проде. Как написал так он без изменений уже 6 месяцев работает 24/7.
Настолько нормальный, что доля условного "рынка" годами держится в районе 0, а в писателях в основном школота, которой ещё без разницы, что осваивать, и которая потом всё равно перейдёт на что-то более вменяемое.
Не якобы и не в теории, а на практике: https://www.opennet.me/opennews/art.shtml?num=51475
Это какая-то синтетика. Школьники драйвера не пишут и поэтому раст для драйверов не используют.
При чем тут школьники?
> где требуется real-time код, компактность и быстродействиеТут определённо "не" пропущено :)
> Просто та область применения для которой раст разработали уже давно занята, оттого
> фанаты языка такие назойливые.Вот же сволочи назойливые! Уже и новость про новую версию раста комментируют!
Все они пересекаются в вебе и скриптах, и раст это делает быстрее.
Была история одного мейнтейнера реп руби. Снижение времени парсинга логов с 16 часов до нескольких минут :)
> Если люди с питона, руби и прочей тормозной скриптухи перейдут на раст,
> то это будет хорошо.А эти люди знают что такое бинарный поиск?
Дорогие программисты превращаются в дешевых не с помощью инструментов вроде раста - это же просто язык, кстати довольно сложный. А с усовершествованием методов сверхэксплуатации в ИТ индустрии (гибкие методики к примеру), методы тейлоризма при эксплуатации, создание резервной рабочей армии, выносом заказов в другие страны с дешевым трудом.
Цена программиста не зависит от сложности языка
А вот писать легче, чем на UB и UB++, им будет удобнее.
Из википедии:> Rust (язык программирования)
> Объектно-ориентированное программирование как таковое языком не поддерживаетсяОтсюда вопрос: как на этом г-не программировать графический интерфейс (GUI)?
Для начало покажи хотябы одну графическую тулзу на раст. У если найдешь в ее коде и посмотри)
Во-первых, чёткого определения ООП до сих пор нет. Во-вторых, https://github.com/redox-os/orbtk
А по вашему ГУИ без ООП невозможен? На Си нельзя писать с ГУИ?
В си есть ООП. Ядро полно ООП, гтк полон ООП.
При чём ГУИ тут вообще, ГУИ это только ГУИ абстракция.
> В си есть ООП.Если мы используем такое определение для "есть ООП", которое позволяет сказать, что в C есть ООП, то тогда нам придётся признать, что в Rust'е тоже есть ООП. Rust не хуже C позволяет жонглировать указателями на функции, и создать вручную vtable там не проблема нисколько.
> При чём ГУИ тут вообще, ГУИ это только ГУИ абстракция.
Это вопрос к анониму выше, он почему-то считает, что без ООП невозможно программировать гуй.
> В си есть ООП. Ядро полно ООП, гтк полон ООП.
> При чём ГУИ тут вообще, ГУИ это только ГУИ абстракция.Там где надо ООП, люди берут плюсы, и не мучаются :)
Или дотнетик.
Сложно. И не из-за того что нет ооп, а вследствие ограничений на уникальное владение ссылками.То есть, если в обычных языках интерфейс является кучей слабосвязанных объектов, где все могут мутировать всех, то в расте у вас так просто не получится реализовать MVC или MVVM.
Например, у вас приложение на дотнете и есть вью-модель, коротую с одной стороны мутирует с домен, а с другой приходят события от графического представления, и тоже меняют значения внутри неё. Для дотнета всё нормально.
Но в расте получается так, что вью-моделью владеют и домен и вью. Если у вас UI живет в отдельном потоке - то тут проблем будет еще больше. Иметь доступ до одного и того же значения из двух потоков тоже не в стиле раста.
И получается что тот же GTK (https://gtk-rs.org/) как бы есть, но программировать на нём без крепких как сталь нервов вы не сможете. Выход - событийная модель и ELM подобные фреймворки, вот например https://github.com/antoyo/relm , библиотека поверх GTK. Или вот https://github.com/hecrj/iced
Если бы только в UI вызывало проблемы.
Любое модульное приложение, где модули ничего друг о друге не знают кроме публичных интерфейсов лего наваять в Java например. Легко написать тесты как модульные так и интеграционные.
На расте это превращается в жесть с дженериками, иначе тесты хрен напишешь.
Можно конечно передавать всё как dyn Trait, но тогда начинается веселье с borrow checker который уже не может отследить, на что ссылка из структуры заимствуется.P.S. Самое удивительное, что разработка все равно получается продуктивная, хотя повозится приходится.
А это бред. ООП в Расте есть. Просто весь полиморфизм реализован через интерфейсы, а не через наследование.
> весь полиморфизм реализован через интерфейсы, а не через наследование.Очередная зубодробительная новшествА, которая ну ладно, право на жизнь имеет, но в очень ограниченной среде.
Все нравится, нормальный релиз!