Ушат помоев в сторону крестолюбов

Какое-то баранье упорство, честное слово. Вы, когда используете std::vector, разве не полагаетесь на то, что он реализован верно?
Иначе зачем его использовать?
Та же история, то что работает через ансейф, тестируется для исключения ошибок работы с памятью.

специально заглянем в детали реализации, дабы проверить, где же там unsafe прячется.

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

Какое-то баранье упорство, честное слово.

Про наличие heartbleed-а в OpenSSL тоже никто не подозревал.

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

Растовский подход — отделение небезопасного от безопасного.

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

Большущий плюс Rust-а в том, что объем этих тестов можно изрядно сократить. Правда расплачиваться за этот плюс нужно переходом на новый язык с дурацким синтаксисом и упоротыми последователями. Одна надежда, что процент упоротых со временем снизится и подтянутся вменяемые пользователи.

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

Степенью покрытия unsafe-кода, да.
И не забывайте про настоящую киллерфичу — гарантию отсуствия гонок данных.

Реализация Deque без ансейф кода: http://cglab.ca/~abeinges/blah/too-many-lists/book/fourth-final.html
Советую прочитать полностью главу, во избежание глупых вопросов, там всё разжевано

дурацким синтаксисом

Вкусовщина

упоротыми последователями

Это Вы по ЛОРу судите? Лол.

Реализация Deque без ансейф кода: http://cglab.ca/~abeinges/blah/too-many-lists/book/fourth-final.html

Вы уверены, что с сылкой не ошиблись? А то ведь там вона чего пишуть:

Alright, so that's implementing a 100% safe doubly linked list in Rust. It relies on some unstable standard library features, and had massive implementation leak issues particularly surrounding acquiring internal references. ... From here on out, we're going to be focusing on other side of this coin: getting back all the control by making our implementation _unsafe_.

Выделение слова unsafe, кстати, из оригинального текста.

Советую прочитать полностью главу, во избежание глупых вопросов, там всё разжевано

Да там всей главы-то всего четыре коротких абзаца. Точно ссылкой не ошиблись?

Начало главы тут, конец — final code, то что я скинул. http://cglab.ca/~abeinges/blah/too-many-lists/book/fourth.html

вона чего пишуть

То же самое, о чем я тут уже вторую страницу втираю. Реализовать полностью безопасно можно, но сложнее и смысла ноль. И это никак не противоречит принципам раста

From here on out, we're going to be focusing on other side of this coin: getting back all the control by making our implementation _unsafe_.

В следующей главе он будет показывать ансейфную реализацию

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

Товарищ выше утверждал что это __невозможно в принципе__. Это явная ложь, я привел аргументы и пруф того, что это не так.
Что вас не устраивает?

Сделали бы borrow-checker опциональным - была бы помощь, а так любой unsafe означает, что borrow-checker не работает.

И чем опциональный borrow-checker лучше ансейфа? Кстати, в ансейф блоках borrow-checker в какой-то степени работает.

Как по мне, так это заявление из категории 640Kb RAM хватит всем.

Почему? В моей практике на плюсах такое тоже полезно делать: обкладывать «опасные места» асертами, тщательно писать тесты и всякое такое. И далеко не весь код (при соблюдении определённых практик) требует такого внимания. В расте оно просто вынесено на уровень языка.

Правда расплачиваться за этот плюс нужно переходом на новый язык с дурацким синтаксисом и упоротыми последователями. Одна надежда, что процент упоротых со временем снизится и подтянутся вменяемые пользователи.

Я, конечно, понимаю, что тебе доставляют удовольствие такие «подколы», но раст-сообщество не ограничивается лором. Более того, уверен, что неадекватные плюсовики, которые (тут) тоже имеются, тебя ничуть не смущают.

MISRA C++?

https://www.youtube.com/watch?v=3SdSKZFoUa8

ps: И, да, хеадюниты BMW на плюсах по все поля :)

Более того, уверен, что неадекватные плюсовики, которые (тут) тоже имеются, тебя ничуть не смущают.

Вообще-то более чем смущают и не только здесь. Но мне уже надоело объяснять одно и то же по 200 раз тем, кто не любит исключения, не понимает шаблонов, утверждает, что auto не нужно и т.д.

А вот Rust мне интересен как потенциальная поляна для деятельности, поэтому хочется собирать адекватные оценки. Посему неадекваты от Rust-а раздражают, т.к. жаль отнятого ими времени.

раст-сообщество не ограничивается лором

По-моему, Rust-сообщество ЛОР вполне вменяемо.

По-моему, Rust-сообщество ЛОР вполне вменяемо.

Ну я не буду ни в кого тыкать пальцем, но «местами» встречаются перегибы с «фанатичностью». Может, конечно, это следствие самого ресурса или нападок от хейтеров.

В любом случае, до технических или хотя бы просто интересных нюансов дело в растовых темах на лоре редко доходит.

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

Товарищ выше утверждал что это __невозможно в принципе__.

Вообще, это я тот самый товарищ. И про в принципе ничего не говорил. меня интересовало не возможность в принципе, а возможность полезная практически. Теоретические рассуждения задротов-теоретиков про принципиальную возможность работают только при защите диссера (а еще свойственны жертвам высшего образования, пока привитые заморочки не выветрятся под воздействием реальности, когда станет понятно, что «правильные» в теории инструменты угробят проект еще до первого релиза). Меня интересует реальная жизнь и если в моей задаче сортировка пузырьком или полный перебор будут достаточно хорошо работать, то я выберу их и буду тратить время на другие полезные задачи (и насрать мне на мнение теоретиков про асимптотическое поведение).

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

Ты теоретически рассуждаешь о своем видении раста, где borrowck мешает тебе реализовать linkedlist без unsafe — я тебе теоретически отвечаю, что не мешает.
Теоретической задаче — теоретическое решение.

С практической точки зрения, твоя задача (linked list без указателей) и выбор инструмента (rust без unsafe) неверны с самого начала.

И если на то пошло, в моей задаче LinkedList, реализованный через Rc будет удовлетворять меня по производительности и мне может быть насрать на best practices

И чем опциональный borrow-checker лучше ансейфа?

Тем что отношение к нему будет более реалистичным. Сейчас вокруг бегают толпы растофанов с горящими глазами и убеждают всех, что Rust гарантирует безопасную работу с памятью, в том числе и многопоточную. В реальности, без unsafe ничего не получается (как тут уже указали, многие контейнеры реализованы через unsafe и по другому не через жопу не получится, многопоточка тоже построена через unsafe, а ее даже через жопу по другому сделать не выйдет). В результате Rust не гарантирует безопасности, потому что без unsafe ничего не получится. Зато он гарантирует, что придется бороться с borrow checker, что в результате повышает порог и время написания кода.

По мне, так как эксперимент, показывающий возможности и ограничения borrow checker, Rust полезен, и, возможно, как опциональный инструмент, будет полезен и в других языках (как const в плюсах). Т.е. сейчас borrow checker - это концепция, которая накладывает жесткие ограничения (потому что без его удовлетворения ничего не скомпилируется), насквозь дырявая (без unsafe ничего не работает), которая в результате ничего не гарантирует, но вокруг все равно бегает множество фанатов, утверждающих обратное. Или другой вариант, когда эти проверки опциональны (для специально помеченного кода), что даст те же гарантии, но более реалистичное восприятие технологии и кучи безумных фанатов. И да, разница лишь в том, что вместо пометки unsafe, будет явный safe (или checked), для проверяемого кода.

P.S. Синтаксис у Rust уродский (неудобный).

многие контейнеры реализованы через unsafe
многопоточка тоже построена через unsafe
по другому сделать не выйдет

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

Ты то дядька взрослый, чего в тред влез? :)

Зато он гарантирует, что придется бороться с borrow checker

Нет. Только, если доведётся писать такое в коллективе, не удивляйся, что потом тебя будут бить ногами по лицу.

что даст те же гарантии

Суть не в гарантиях, а в простоте локализации ошибок.

но более реалистичное восприятие технологии

Твоё восприятие - твои проблемы.

И да, разница лишь в том, что вместо пометки unsafe, будет явный safe (или checked), для проверяемого кода.

И ещё trusted для небезопасного кода в безопасных секциях. А смысл всей бодяги лично мне тогда будет совершенно непонятен.

Синтаксис у Rust уродский

Вкусовщина.

неудобный

Для каких целей и почему?

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

Справедливости ради, сторонники раста периодически тоже набегают в темы о других языках. Впрочем, меня это (в основном) устраивает: лор действительно «более агрессивный», но это придаёт ему живости. (:

сделают невозможное?

Вот в этом главная проблема растоманов. Им дали одну упрощённую модель, и они теперь утверждают, что всё, что за её пределами либо «небезопасно», либо «невозможно».

Цитата крестофаната, а проблемы у растоманов. Ну действительно.

Ты крестофанат?

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

Честно говоря, не понимаю почему это должно поменяться.

В результате Rust не гарантирует безопасности, потому что без unsafe ничего не получится.

Я надеюсь, ты понимаешь, что это ерунда? Давай не будем смотреть на «фанатиков», а обратимся к «первоисточнику» - гарантии есть для безопасного кода. Да, в unsafe можно выстрелить себе в ногу, ну и что? Если мы верим коду, который под капотом использует unsafe, то какие проблемы? Да, совсем без него никак. При этом почему-то гарантии той же джавы всех устраивают и не важно на чём написана её виртуальная машина.

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

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

P.S. Синтаксис у Rust уродский (неудобный).

P.S. Нет (оптимальный).

Для тебя — хоть царь Гвидон.

Недурной садово-поливальный камуфляж.

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

Eдинственный реально работающий варинат exception safety, это:

#define throw *((nullptr*)0) = 0;
#define try *((nullptr*)0) = 0;
#define catch *((nullptr*)0) = 0;

Тут, конечно, большой простор для улучшения, чтобы ошибки все-таки из runtime сдвинуть в сторону compile time, но суть, думаю понятна: никогда и ни при каких условиях не бросать и не ловить исключения.

Плюсую. Вот Oна - железо-бетонная реализация исключений для С++.

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

Когда ты перейдешь на следующий уровень владения С++ ты осознаешь что использую С++ ты не можешь гарантировать вообще что-нибуть.

Можешь начать с изучения сырцов стандартного рантайтма.

Языки, на кои алгориѳмы толмачити подобаѣтъ, токмо Коболъ, Фортранъ и АПЛъ суть. Прочiя новодѣлiя бѣсовскiя отъ лукаваго суть пошли.

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

Я говорил здесь что C++ не нужен?

Причем Фортран только не моложе 77.

написанном на голом WinAPI

Объясните дураку, что значит «писать на голом WinAPI»? Имеется в виду ассемблер с вызовами винапи?

На дырчатыхъ картахъ плотной бумаги-съ.

Объясните дураку, что значит «писать на голом WinAPI»? Имеется в виду ассемблер с вызовами винапи?

Нет это означает не использование ни MFC, ни ATL, ни ккакой либо другой извращенной (технологии) системы классов.

Даже в &php есть.

Ну так это...

как какому выводу-то пришли?

а kawaii_neko может и опозорить перед почтенной публикой.

Даже царь не мог — а плохая копия тем более :)

C - отвратительное уродливое поделие конца 60-х годов

Неправда! Как раз для 60-ых это был изумительный, краткий язык, позволивший «подняться над ассемблером» и дающий высокоуровневые конструкции, не намного ухудшающие аналогичный ассемблерный код.

...а С++ - работа над ошибками

Налицо полное незнание истории С++. Этот язык был ТОЛЬКО попыткой привнести «нечто, похожее на ООП» в уже распространённый Си. Этакая «ООП-нашлёпка» над высокоуровневым ассемблером. Именно поэтому из С++ торчат кишки низлежащего языка.

Естественно что на 2016 год не актуально ни то, ни другое, все используют .NET или Java.

А вот это правда! Однажды попробовав C#, вернуться к сипиписному безобразию невозможно.

А вот это правда! Однажды попробовав C#, вернуться к сипиписному безобразию невозможно.

оХГДЕЖ, абизянка подсела на сахарок и экстраполирует :)

Си — рулез.

Сипипи... не очень...