into_rust() — скринкасты по Rust. Доступно видео с RustConf 2016.

Ну вот как на C сделать аналог not_null<T>?

Дык, на С++ можно забыть/полениться использовать not_null и компилятор не подскажет. То есть, мы просто (ещё) больше «внимательности» переносим на человека.

Специально для вас цитата:

I think that a partial rewrite would be necessary, in other words start from scratch but
copy-paste code from the old library when possible.

и еще специально для вас

when I started glium (and still today), there was no real reference for how
to design an API. I built an API, then changed my mind and changed it, then changed my mind again.
Each change was justified, but I wouldn't have lost that much time if I knew from the start how to
design things in Rust.

Перевод, специально для вас: «Я бы не потерял кучу времени, если бы сразу знал как проектировать для Раста» и теперь вынужден «начать с нуля, копируя код, где возможно».

Learning curve слишком крута. Нельзя просто сесть и написать, используя опыт из традиционных языков.

Дык, на С++ можно забыть/полениться использовать not_null и компилятор не подскажет.

Что-то я не понимаю. Я могу заставить пользователя придерживаться хорошего тона, если делаю API вида:

class string_piece {
public :
  string_piece( non_null<const char *> value ) {...}
  ...
};

Понятное дело, что всех не заставишь так писать и кучу старого кода под такой подход не перепишешь. Но покажите, как хотя бы такого уровня достичь в чистом C?

Learning curve слишком крута.

И это не особо здорово.

Несколько, видимо, как раз потому, что с общим случаем проблемы.

Не уверен. Если не поленишься посмотреть на либы, то с удовольствием послушаю.

А ещё весьма вероятно, что оно никому особо не нужно.

Понятное дело, что всех не заставишь так писать и кучу старого кода под такой подход не перепишешь.

Именно.

Но покажите, как хотя бы такого уровня достичь в чистом C?

Можно, например, использовать макросы и прикрутить сторонний анализатор, который будет что-то проверять.

А ещё весьма вероятно, что оно никому особо не нужно.

В таком случае «никому особо не нужно» использовать Rust как замену C. Хотя, наверное, кому-то нужно, раз RFC есть.

Ещё раз намекну, что если очень надо, то решение есть вот прямо уже.

Нету. Это решения для частных случаев.

А ещё там написано: «But I'm generally a perfectionnist person and am very critical of my work». Переводить вам судя по всему не нужно.

Я таких людей знаю. (По себе. :-P) У них всегда такое, код, который написали сегодня, намного лучше того, что был написан вчера. :)

То есть, мы просто (ещё) больше «внимательности» переносим на человека

То есть у нас разработчики раканы, документацию мы в принципе не пишем, а разработка архитектуры делается способом штурмовки за пару дней. Но виноват C++

Можно, например, использовать макросы

Вот мне интересно, почему все плюсохейтеры не гввкают на си, а вместо этого предлагают писать на нем говнокод с макросами?

Вот почему на С вам нельзя огрызаться? Дикий бред про «С++ не дает бросать исключения в деструкторах» я видел многократно, и, как я понимаю, от этого бомбит у всех плюсохейтеров. Т.е. дебильные предъявы к C++ более-менее одинаковы у всех и связаны с рукожопием.

Типапамять течет, кококо, сегфолты и т.д. и т.п.

Но ведь у рукожопов такие же проблемы должны быть и на Си. И вот что интересно: рукожопы при упоминании Си начинают корчить из себя целку. Почему так?

Напомни

Давайте на бис.

Ты лучше хорошему учись.

Ничего хорошего нет.

И вот что интересно: рукожопы при упоминании Си начинают корчить из себя целку. Почему так?

Тут есть минимум два варианта:

1) Они не пишут на С, потому не представляют какое говно обычно код на нем и сколько там рутины, кривости и костылей;
2) Они таки используют С, и это их в своих глазах делает крутыми хакерами, а значит те, кому жить проще, - гарантированно лошары и ничерта не понимают в этой жизни.

Ненавидеть Си неинтересно - убогий устаревший язычок, который даже не пытается быть современным. Уныло.

Аргументы из серии, что теорема Пифагора устарела)

Может быть. Но я человек наблюдательный. Вот у них бомбит совершенно одинаково. Но! Я видел опросы никто не вякает на си

А разве нет? Atomic и порядок инициализации он уже умеет?

выбросив, по сути, предшествующие C++ные наработки

FFI же.

когда Rust перейдет из категории многообещающего молодого инструмента в категорию более-менее широко используемого стабильного инструмента

Может тогда, когда языку будет поболее чем 1.5 года?

следование

Опять это следование. По вашей логике и следование практикам С позволяет безопасно писать на С. Жаль, но в реальности так не бывает.

Пока в C++ вы следуете практикам, в Rust неверный код даже не соберётся.

Новую интересную ось представили на днях на С++

На днях... Ей пару лет уже.

проекты на Расте забрасываются своими авторами

Невероятно. С другими языками такого никогда в истории не происходило.

Я заметил, что вы так и не смогли ответить на вопросы, которые вам были заданы (into_rust() — скринкасты по Rust. Доступно видео с RustConf 2016. (комментарий)). Но вот херни наговорили изрядно.

Явное 4.2 же. into_rust() — скринкасты по Rust. Доступно видео с RustConf 2016. (комментарий) И вы этот ответ читали, так как вместо разговора по делу пошли жалобы на невозможность модифицировать итерируемый контейнер.

С++ будет доживать свой век не меньше, чем Cobol.

Ну, если для вас Cobol - это пример живого языка, тогда да. Я уже писал, что вакансии по поддержке старого кода на C++ никуда не денутся, не волнуйтесь.

По сравнению с тем, как развивался C++ до 2011-го года, сейчас все просто в шоколаде.

Модули и всякий асинк/авайт тому порукой! Вроде как понимание необходимости модулей уже лет 10 существует, ещё в 11м ждали.

Ну, уж если сравнивать, как мало новых проектов начинают на Rust-е, в сравнении с количеством новых проектов на других языках, то у C++ еще все хорошо.

Ну да, дедушка ещё достаточно силён, чтоб забороть младенца, определённо он в отличной форме.

Я не утверждаю, что C++ добьёт именно раст. Возможно выяснится, что киллер фичи раста нахрен никому не упёрлись и он так и останется вечно развивающимся языком. С++ помрёт от того, что просто устарел. Собственно, Страуструп всё понимает, поэтому на каждом выступлении требует де-факто похоронить C++ 80-90х, а также наследие C и учить народ писать по-новому. Проблема в том, что для реальной работы с старыми проектами на C++ потребуется знание старого C++, так что никуда от всех этих самописных векторов не деться.

Это нормально. Не всем нужно погружаться в околосистемное программирование или middleware.

Торвальдс возражает с одной стороны, а какой-нибудь Пайк с другой.

Ну, если человек остановился в своем развитии, то да. Только вот он не будет конкурентоспособен в этой индустрии. Тут постоянно нужно учиться.

Ну вы вот учитесь, а толку? Для вас признаком современного программирования является использование emplace_back.

Контрпример чего? Где ваш пример, на который вы мне рекомендуете привести контрпример?

Контрпример всего того, на что вы возражаете. Можете уже не беспокоиться, я видел контрпример со списком тасков, он скорее подтверждает что я писал про «современный C++».

Покажите, как это будет выглядеть по канонам 2010-х.

Ну вот посмотрите на свой код. Он не делает ничего полезного, это аналог пустого цикла, подразумевается, что полезная работа делается где-то в других потоках, а этот кусок только следит за списком тасков, но он уже такого размера, что не стыдно в отдельную функцию выносить. В реальности цикл будет не пустым, кроме вариантов «если А, то удалить текущий элемент» и «если Б, то создать новый элемент» будет ещё 2-3 ветки и с элементами будут что-то делать. В итоге получится портянка на пару экранов. И кто-то обязательно этот код начнёт править, добавлять новые ветки, выносить ветки в отдельные функции и т.п.

И настанет момент, когда кому-то потребуется предыдущий элемент и он не особо задумываясь скопирует итератор. Не потому, что он - дурак, а потому что не заметит, что в одной из веток сидит erase текущего элемента, ведь deque - это специальный контейнер, в котором добавляются и удаляются элементы в один из концов и эта операция не ломает итераторы.

Этот кусок изначально написан хрупким и живёт только благодаря знанию о свойствах deque и о соглашении внутри цикла. Т.е. по хорошему перед циклом нужно написать комментарий, мол, осторожно, удаление из середины дека, валидным является только текущий итератор.

И где-то в этот момент у программиста рождается мысль, мол, а нафига мне вообще этот дек упёрся? Особой скорости тут не будет: удаление из середины дека немногим лучше удаления из середины вектора. Особой понятности тоже, вот, приходится описывать, что можно и чего нельзя в цикле. В итоге плюнет и перепишет на тупой перенос из одного вектора в другой, где всё понятно, нужно чтоб элемент сохранился - переноси в список для следующей итерации, нужно разбить - добавляй новый в тот же список. За что будет презираем программистами из 90х, ведь каждому понятно, что можно было deque заюзать.

https://m.habrahabr.ru/post/306642/

Возможности Go в одном выступлении приводились на примeре сжигания в печах учебников по C++, как это наиболее эффективно организовать.

Тупая злоба всегда отличала фанатиков ненужных языков

Явное 4.2 же. into_rust() — скринкасты по Rust. Доступно видео с RustConf 2016. (комментарий) И вы этот ответ читали

И ответов там не увидел. В особенности про паники, который могут вылетать откуда угодно.

Контрпример всего того, на что вы возражаете.

Т.е. вы сами не знаете, на что мне нужно привести контрпример. Да вы совсем больны.

Ну вот посмотрите на свой код. Он не делает ничего полезного, это аналог пустого цикла,

Talks are cheap, show me the code! (C)

FFI же.

К библиотекам, которые на 70% состоят из шаблонов?

Может тогда, когда языку будет поболее чем 1.5 года?

Может быть. Если для Rust-а все будет нормально, если Mozilla с Samsung-ом не обосрутся с Servo так же, как Samsung обосрался со своим новым флагманским смартфоном.

Но давайте не будем гадать о будущем. По вашему мнению, сейчас на Rust-е можно вести коммерческую разработку софта? (Т.е. когда софт решает какую-то прикладную задачу, есть либо заказчик решения, либо покупатель, есть бюджеты, сроки, команды, которые нужно либо набирать, либо переучивать...)

По вашей логике и следование практикам С позволяет безопасно писать на С.

В принципе, так и есть. Проблема в том, что касательно именно С эти практики, насколько я знаю, не очень эффективные и приводят к серьезному удорожанию процесса разработки.

По вашему мнению, сейчас на Rust-е можно вести коммерческую разработку софта?

Я не руководитель такой компании. Не знаю.

Для моих задач Rust подходит.

Проблема в том, что касательно именно С

Ну так обмазатся шаблонами в плюсах, прогнать код через десяток статических анализаторов, потом через профиллеры памяти типа valgrind, потом собрать прогу с AddressSanitizer и подобными. Помнить, что нельзя модифицировать контейнер и одновременно его итерировать. Помнить, что numeric overflow никак не проверятся. Помнить, все ли исключения мы обработали. Помнить, что все компиляторы собирают код по разному и могут возникнуть не предвиденные баги. Вот тогда да, С++ проще Rust.

Для моих задач Rust подходит.

Так вы же работаете над своими задачами в одиночку и не зарабатываете на своем Rust-овом коде?

Ну так обмазатся шаблонами в плюсах, прогнать код через десяток статических анализаторов, потом через профиллеры памяти типа valgrind, потом собрать прогу с AddressSanitizer и подобными.

Ну давайте подождем, пока к Rust-у не подтянутся толпы индусов, которые начнут лепить на коленках двусвязные списки через unsafe. Тогда посмотрим, что потребуется Rust-у в дикой природе.

Помнить, что нельзя модифицировать контейнер и одновременно его итерировать.

Выше было показано, что это зависит от задачи. Такое может потребоваться делать даже в Rust-е.

Помнить, что numeric overflow никак не проверятся.

За счет чего повышается эффективность кода. А если эффективность нам не нужна, то нам и не нужен ни C++, ни Rust.

Помнить, все ли исключения мы обработали.

Это просто феерический бред. Особенно от Rust-аманов, которых паники не волнуют от слова совсем.

Помнить, что все компиляторы собирают код по разному и могут возникнуть не предвиденные баги.

Да, Rust пока из детских штанишек одной единственной реализации так и не вырос.

Rust пока из детских штанишек одной единственной реализации так и не вырос.

Да и та обязана своему существованию LLVM на С++.

Помнить, что нельзя модифицировать контейнер и одновременно его итерировать

И как ты, например, будешь удалять элементы из контейнера по условию? Делать копию рядом и терять по времени и по памяти?

Помнить, что numeric overflow никак не проверятся.

Раст в релизных билдах тоже не проверяет.

Особенно от Rust-аманов, которых паники не волнуют от слова совсем.

Они и не должны волновать. Паника - это не способ обработки ошибок, а способ «культурно» уронить программу.

Так вы же работаете над своими задачами в одиночку и не зарабатываете на своем Rust-овом коде?

Нет. Я и не доказывал обратное.

которые начнут лепить на коленках двусвязные списки через unsafe.

Они подключат готовый из репы.

За счет чего повышается эффективность кода.

В релизе их нет, а при отладке спасает. Особенно на тестах.

которых паники не волнуют от слова совсем.

Паники != исключения.

Да, Rust пока из детских штанишек одной единственной реализации так и не вырос.

К счастью для раста, альтернативный компилятор ему не понадобится. Не те времена, когда все пилили по компилятору.

Vec::retain()

Паника - это не способ обработки ошибок,

Исключение — это тоже не способ _обработки_ ошибок. Это способ информирования о них. Очень надежный.

а способ «культурно» уронить программу.

Речь про то, как быть с корректной очисткой ресурсов и отсутствием порчи разделяемых данных. И о поведении сложных многопоточных приложений. Если в одной рабочей нити выскакивает паника, не всегда допустимо «ронять» всю программу.

Как раз о том, о чем exception safety в C++ (да и не только в C++, а вообще в языках с исключениями, за вычетом, наверное, Eiffel-я).

Нет.

Ну вот. А часть участников дискуссий вокруг C++ и Rust сильно волнует вопрос заработка на разработке софта. И не смотря на то, что разговоры вокруг Rust-а ведутся уже года 3-4, зарабатывать на C++ сейчас реальнее, чем на Rust-е.

Так что предполагаемая безопасность — это хорошо, только в деньги она просто так не конвертируется.

Они подключат готовый из репы.

Как вы наивны.

Паники != исключения.

Я в курсе. Но раз во время паник дергаются деструкторы, то здесь будут работать те же принципы, что и в C++ при обеспечении exception safety. Получится, что писать на Rust-е код, который спокойно переносит паники нужно будет в том же духе, что и на C++.

Речь про то, как быть с корректной очисткой ресурсов

Чтобы НЕ использовать RAII в растовском коде, надо приложить определённые усилия.

отсутствием порчи разделяемых данных

Не использовать паникующих функций во время транзакций - вполне реально, учитывая, что оных функций не так много.

Чтобы НЕ использовать RAII в растовском коде, надо приложить определённые усилия.

Ну посмотрим, как оно будет в реальной-то жизни.

Не использовать паникующих функций во время транзакций - вполне реально, учитывая, что оных функций не так много.

А что, невозможность выброса паники как-то отражается на сигнатуре функции/метода в Rust-е?

Vec::retain()

std::remove тогда уж. Или ты считаешь, что в Vec::retain нет одновременного прохода по вектору и его изменения?

Ну и ты считерил, взял готовую реализацию, да еще и у вектора. А что ты будешь делать с LinkedList, например?

Лучший способ обработать панику - сохранить стектрейс и попросить пользователя отправить баг-репорт. Или, если приложение серверное, записать в лог, и перезапустить упавший поток.

Возникновение паники должно означать, что в программе есть баг или разработчик не подумал о каком-то варианте развития событий. Так что исправлением такой ошибки должен заниматься разработчик, а не программа.

Лучший способ обработать панику - сохранить стектрейс и попросить пользователя отправить баг-репорт.

Т.е. если у меня Web-браузер с тучей открытых вкладок (или офисный пакет с кучей открытых документов, или CAD с кучей окон с отображением разных параметров модели) и в одной из вкладок вылетает паника, то вы предлагаете грохнуть все остальное и показать стектрейс?

Или, если приложение серверное, записать в лог, и перезапустить упавший поток.

Т.е. внезапно выясняется, что имеет смысл перезапускать только один поток. А если этот поток шарит данные с другими потоками, в каком состоянии эти данные остаются?

Возникновение паники должно означать, что в программе есть баг или разработчик не подумал о каком-то варианте развития событий.

Замените слово «паника» на «исключение» и что изменится?

то вы предлагаете грохнуть все остальное и показать стектрейс?

Вариант, когда программа продолжает работать с потенциально испорченными документами намного лучше? Периодическое сохранение документов никто не отменял.

Замените слово «паника» на «исключение» и что изменится?

То, что исключения сваливают в кучу ошибки вызванные внешними причинами и ошибки программиста.

А если этот поток шарит данные с другими потоками, в каком состоянии эти данные остаются?

Mutex, с помощью которого эти данные шарятся переходит в состояние poisoned. Если другой поток попытается захватить этот mutex, то там тоже возникнет паника. Нужно будет предусмотреть возможность очистки этого состояния, если такая возможность есть.

Вариант, когда программа продолжает работать с потенциально испорченными документами намного лучше?

Это не ответ на вопрос.

Периодическое сохранение документов никто не отменял.

Это один из обходных путей, а не решение.

То, что исключения сваливают в кучу ошибки вызванные внешними причинами и ошибки программиста.

Применительно к обеспечению exception safety это не имеет никакого значения.

По факту же получается, что Rust-оманы не думают о паниках. Ну типа грохнется и все.

Нужно будет предусмотреть возможность очистки этого состояния, если такая возможность есть.

Т.е. приходим к тому, что при любом захвате mutex-а нужно быть готовым к вылету паники по случаю poisoned?

По факту же получается, что Rust-оманы не думают о паниках. Ну типа грохнется и все.

ИМХО, это вполне нормально, как часто ты отлавливаешь out_of_range или bad_alloc в С++?

Т.е. приходим к тому, что при любом захвате mutex-а нужно быть готовым к вылету паники по случаю poisoned?

Если требуется, чтобы приложение сохраняло работоспособность (а не видимость работоспособности) нужно будет предусмотреть обработку паники в потоке и какую-то очистку захваченных потоком шаренных данных.

Если этого не было сделано, то лучше чтобы приложение/сервис/что-угодно упало, а не продолжало делать вид, что работает. Так что быть готовым к вылету паники не нужно. Предусмотреть очистку расшаренных данных после паники в потоке, если это требуется поставленной задачей - нужно.

Это не ответ на вопрос.

Да. Лучше грохнуть всё остальное.

Это один из обходных путей, а не решение.

Решение - это не делать ошибок в программах. Возьметесь реализовать такое решение?