Очередного обсуждения Rust тред

Ты точно мне отвечаешь?.. Процитированное - не моё.

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

Так ведь ничего принципиально не поменялось: свифт там ниже, чем VBA

VBA — это весьма распространенный язык. Можно считать, что все языки из этого опроса — мейнстрим.

Автор позиционирует язык как системный, хотя там и есть сборка мусора. Но вон в D она тоже есть

Настолько же «системный», как C# или Java.

Я не люблю хаскель потому, что это хаскель, а не потому, что это функциональщина. Они в итоге из этого же хаскеля пытаются сделать подобие ML

А скала разве нет? Мне кажется, этот язык даже более перегружен (хотя, отчасти и вынужденно) чем хаскель

Вывод типов скалы опережает мейнстрим лет так на 10-20. Хиндли-Милнера уже давно пора было отправить на пенсию. Собственно, весь язык и был создан из этого вывода типов. В итоге скала существует меньше, а славы сыскала больше, чем хаскель, поскольку хаскель изначально был спроектирован неюзабельным для практических задач, и потому за многие годы самый большой проект, который удалось написать на хаскеле — это сам компилятор хаскеля. Всё, больше на нем ничего написать нельзя.

Всё, больше на нем ничего написать нельзя.

И снова категоричность 100%. Вон тут люди на практике используют, и ничего: https://habr.com/ru/post/193722/

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

Неявный. Порой для того, чтобы понять, что может быть небезопасным, нужно читать комменты в либе. Как в случае того же Arc. Еще раз: растовая безопасность — это исключительно отсутствие UB. Так и стоит говорить: Rust позволяет писать без UB. Rust не позволяет писать безопасный код, там грабли густо разбросаны прямо в стандартной либе.

А если у вас программисты испытывают проблемы с избеганием data race, то у них будут очень большие проблемы с многопоточкой, которые никакой раст сам по себе не решит, потому что многопоточка — это намного больше, чем просто отсутствие data race, и людям, которые не могут написать код без data race-ов, там просто нечего ловить, потмоу что ошибка может оказаться в любой строчке на safe расте, и таки каждую придется каждую внимательно перечитывать.

Ну цель-то «простая»: просто зашкурить ручку, чтобы не кололась. Я как раз и озвучиваю мнение почему так не получается

Мнение понятное. Моя практика его почти подтверждает. На работе я вместо C++ просто использую другие инструменты, а Си использую только для контроллеров, но там куча не используется, что сильно упрощает дело. Дома же с C++ взаимодействую через транслятор, то есть, образно говоря, обматываю ручку изолентой.

Что касается safe, unsafe и Си, то тут надо понимать, что Раст не собирается быть «клеем» для сишных библиотек. Вероятно, амбиции разработчиков требуют другого. Но ведь и Питон себя вроде бы «клеем» не позиционирует. Кстати можно было бы создать тему «каким должен быть идеальный клей для сишных библиотек», но подозреваю, что это только мне интересно.

Ну вот взглянул: https://benchmarksgame-team.pages.debian.net/benchmarksgame/program/spectraln...
Ансейф кода нет, а результат быстрее, чем у С++.

use rayon::prelude::*;

Хорошая попытка, но нет. Так-то и на OpenMP можно на одних безопасных операциях написать на сишке.

Нет, я сам люблю почитать срачи на лоре. Когда-то так лиспом, а затем хаскелем заинтересовался. Уже не помню, но возможно и к расту у меня именно лор интерес подогрел. Но это подходит только как стартовая точка, дальше надо разбираться самому, иначе это будет уровень «Рабинович напел»

Да, чтобы детально разобраться — придется изучать. Например, мое впечатление от Vue по рассказам других людей оказалось совершенно не похоже на впечатление от рассказов про него. Но в этом конкретном случае я бы сказал, что эти писаки SPA до сих пор не разобрались во Vue, типа «деньги капают — ну и пофигу. Как заплатят за то, чтобы разбираться в кишках Vue — так и начну этим заниматься». Я вот знаю чела, который годами пишет код на Vue, и при этом до сих пор теряется в двух соснах.

Коротко мое впечатление можно написать так: Vue написано не самыми изобретательными людьми для не самых обучаемых кодеров-пользователей. Естественно, тебе в этом ключе ничего не будет расказывать, потому что это получается самозашквар. А у меня не получается, потому что я как бы дистанцирую себя от технологии.

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

Много лет назад я многое потерял, наслушавшись фанбоев и просто графоманов по C++ с их божественными иерархиями классов со множественным наследованием и тьюринг полными обобщениями. Это сейчас я понимаю, что был таки прав и писать так на крестах нельзя, но тогда я был молод и глуп, и не видал больших... Чем проще код, тем проще его писать, тем проще его отлаживать, тем проще его поддерживать.

И это одна из ключевых моих претензий к расту — он плодит настолько много сомнительной полезности сущностей, что практическая польза от этого языка становится не так очевидна. Но пользу я таки вижу — в качестве один в один замены для C++. Только не для среднего (плохого) кода на крестах, а для грамотного кода, без бредовых иерархий классов, с уклоном в неизменяемые структуры данных и copy-on-write вместо передачи ссылок, без исключений, с минимумом шаблонов в роли безопасных макросов. То есть, это можно назвать «сишный стиль с элементами C++, ориентированный на качество кода, а не на скорость его выполнения».

Так ведь и as пишется явно, почему это проблема? Ну и разве Deref - это про касты? Я бы скорее TryInto добавил

Ну да, как я и думал — касты в расте можно делать только реализацией собственных трейтов.

Вместо операторов приведения там целый набор трейтов вроде From, Into, Clone, AsRef и т. д. Да, это скорее перегружаемые функции и их надо вызывать явно, что, в общем-то, хорошо: я вот не всегда помню, где в плюсах появились какие автоматически генерируемые операторы приведения и конструкторы копирования, из-за чего иногда приходится ломать голову, что где компилятор самовольно наворотил.

Вот, прямо в тему попалось, чистая алгоритмика: https://github.com/awelkie/RustFFT

4к строк, 65 ансейф, большая часть из которых вызовы одной из нескольких небезопасных функций, в духе: unsafe { self.process_inplace(output) }; Можно было бы нагородить ещё абстракций и свести все ансейфы к нескольким, но, видимо, автор не настолько поехавший, как местные хейтеры.

В src только 2к строк, там же сконцентрированы все unsafe. Остальное — это бенчи, тесты, примеры. Половина всего кода реализации (900 строк) и 45 unsafe-ов (из 63) сосредоточены в src/algorithm/butterflies.rs, которое и является реализацией FFT. Библиотеки C/C++ пишутся в подобном стиле: низкоуровневые небезопасные операции оборачиваются в более удобную и безопасную обертку.

Можно было бы нагородить ещё абстракций и свести все ансейфы к нескольким, но, видимо, автор не настолько поехавший, как местные хейтеры

Конечно можно было, особенно вот это:

        *buffer.get_unchecked_mut(0) =  scratch_evens[0] + scratch_odds_n1[0];
        *buffer.get_unchecked_mut(1) =  scratch_evens[1] + scratch_odds_n1[1];
        *buffer.get_unchecked_mut(2) =  scratch_evens[2] + scratch_odds_n1[2];
        *buffer.get_unchecked_mut(3) =  scratch_evens[3] + scratch_odds_n1[3];
        *buffer.get_unchecked_mut(4) =  scratch_evens[4] + scratch_odds_n3[0];
        *buffer.get_unchecked_mut(5) =  scratch_evens[5] + scratch_odds_n3[1];
        *buffer.get_unchecked_mut(6) =  scratch_evens[6] + scratch_odds_n3[2];
        *buffer.get_unchecked_mut(7) =  scratch_evens[7] + scratch_odds_n3[3];
        *buffer.get_unchecked_mut(8) =  scratch_evens[0] - scratch_odds_n1[0];
        *buffer.get_unchecked_mut(9) =  scratch_evens[1] - scratch_odds_n1[1];
        *buffer.get_unchecked_mut(10) = scratch_evens[2] - scratch_odds_n1[2];
        *buffer.get_unchecked_mut(11) = scratch_evens[3] - scratch_odds_n1[3];
        *buffer.get_unchecked_mut(12) = scratch_evens[4] - scratch_odds_n3[0];
        *buffer.get_unchecked_mut(13) = scratch_evens[5] - scratch_odds_n3[1];
        *buffer.get_unchecked_mut(14) = scratch_evens[6] - scratch_odds_n3[2];
        *buffer.get_unchecked_mut(15) = scratch_evens[7] - scratch_odds_n3[3];

Но тогда бы выяснилось, что у тебя на 500 строк — 45 unsafe-ов. Потому что unsafe-ы в такие стенки там не выстроены, большая их часть — это unsafe fn.

Тем, что в расте ты не сможешь «не обработать ошибку»

Долго думал. Ну типа разница в том, что раст заставляет писать конструкцию обработки возвращаемого значения, а сиха — нет. Чей подход лучше? Я бы сказал, что раст, но только при одном условии — если бы раст давал возможность забивать на обработку ошибок в стиле «если что-то пошло не так — валимся полностью». Это же является одним из плюсов в языке C++, за который его многие любят. К сожалению, раст заменил один сорт говна на другой. Та же претензия уже давно есть у сообщества к Go.

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

Я же пишу «почти». Вот гуглу, фейсбуку, мс, и амазону нужен. Остальным — нет. Конечно, позже сообщество подхватит любой кусок дерьма, который поддержан крупными корпорациями, без малейшего понимания того, зачем этот инструмент их нужен. Вон, гугл создал контейнеры — нынче любой школьник сразу лезет в контейнеры, да еще и с кубернетом, потому что ну как же, у гугла есть контейнеры и кубернет — чем мой бложик хуже гугла? Это поколение пишет на react.js сайты, которые не индексируются поисковиками, на которые нельзя дать ссылку, и которые грузятся по 5-10 секунд — как ты думаешь, какие факторы подтолкнули этих людей делать свой сайт таким? Гугл подхватил питон, сделал TensorFlow — сейчас каждая секретарша бежит учить питон. У меня знакомый на работе крутит гайки, а дома учит питон. Зачем? Он сам понятия не имеет. Это поколение уже даже не в курсе, что питон поднялся на Гугле. Для него смысл слова гугл — это «окей гугл» на смартфоне. Так же «это поколение» не в курсе, что Ruby поднялся на Apple. Собственно, даже многие посетители лора не в курсе этого факта.

Забавно, что в новых стандартах при этом ABI ломать не хотят и из-за этого срачи происходят

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

А я предлагаю посмотреть на Clojure. Которая может дергать родную жаву, но синтаксис совершенно не похож на обычную жаву.

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

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

Статья на английском на хабре?.. Я даже не знал, что так можно. Лучше тогда было на реддите вбросить. Отложил, почитаю на досуге

На реддите и HN уже висит. Всем пофиг.

Всё, больше на нем ничего написать нельзя

И снова категоричность 100%. Вон тут люди на практике используют, и ничего: https://habr.com/ru/post/193722/

Очень мало конкретики по самому проекту.

Кстати можно было бы создать тему «каким должен быть идеальный клей для сишных библиотек», но подозреваю, что это только мне интересно

Да, потому что остальные считают, что «сишные библиотеки не нужны». Беда инструмента, дергающего черные ящики на Си, заключается в том, что эти черные ящики никак не заоптимизируешь, и другой менеджер памяти им не поставишь, и сишные библиотечные контейнеры в автоматическое управление памяти не добавишь. Связан по рукам и ногам, короче говоря. Отсюда и возникает желание переписывать либы на родных языках.

больше на нем [хаскеле] ничего написать нельзя.

Pandoc на хаскеле написан. У меня челюсть отвисла, когда я увидел, что чтобы его поставить на Gentoo, надо скомпилировать 100 хаскель пакетов.

Pandoc на хаскеле написан. У меня челюсть отвисла, когда я увидел, что чтобы его поставить на Gentoo, надо скомпилировать 100 хаскель пакетов

Pandoc меньше GHC будет.

А в C# есть.

Есть, но у него другая семантика.

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

Конструктивно, ничего не скажешь.

Помилуйте, какой конструктив? Тут фанбои достаточно наконструировали.

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

И тем не менее, на С++ пишут далеко не только «performance critical» код. Хватает и тупой бизнес-логики.

Разумеется. Необходим ли там С++? Спорно. Скорее всего, хватит джавы или шарпа.

Ну нет, иначе бы они не возникали в сколь-нибудь серьёзных проектах

Это малая часть всех ошибок.

Ансейф кода нет, а результат быстрее, чем у С++.

И медленнее, чем у С.

С ним какие-то проблемы остались ещё?

Лучше бы остались. Я выше расписал.

Так ведь и as пишется явно,

Нет, реализация as вшита в компилятор, а трейты реализует юзер. От обычных функций они ничем не отличаются.

Нет, реализация as вшита в компилятор, а трейты реализует юзер. От обычных функций они ничем не отличаются.

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

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

Раст ничего не утверждает, это утверждают отдельные поехавшие и их оппоненты. В расте нет безопасности, в расте есть отсутствие UB в safe коде — это еще ни разу не безопасность.

О ядовитом unsafe я говорю, чтобы показать, что в лозунгах раста под memory safety понимается вовсе не то, что обычно

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

И в такой интерпретации это уже вполне себе memory safety жавы/C# — особенно C#, который активно использует либы с родными библиотеками.

Ансейф кода нет, а результат быстрее, чем у С++.

И медленнее, чем у С

На выделение памяти смотри. Самая быстрая версия Rust на полтора процента (1.5%) быстрее самой быстрой версии C++, но жрет памяти в два раза больше крестовой и сишной.

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

Речь идет о трейтах Deref/Into/From и т.д. Здесь матчасть должен учить ты. Вперед https://doc.rust-lang.org/src/core/convert/num.rs.html#99

Раст ничего не утверждает, это утверждают отдельные поехавшие и их оппоненты.

Ну как не утверждает, на главной странице языка это написано. Уже приводил, привожу еще раз:

Rust’s rich type system and ownership model guarantee memory-safety and thread-safety

Ключ как раз в том, что безопасность понимается исключительно как отсутствие UB в safe коде при отсутствии UB в unsafe коде.

Memory safety в настоящем расте, не в лозунгах — это когда ты ничего толком не можешь сделать, кроме как дергать за рычаги, которые для тебя оставили более квалифицированные разрабы

Да, согласен. В чем смысл раста, если жава с точно таким же разменом «безопасно ИЛИ быстро» обладает многократно большим набором библиотек на все случаи жизни?

Rust’s rich type system and ownership model guarantee memory-safety and thread-safety

Ну заявления на лендинге раста — это такая себе история, прохладная, смотри не простудись. А вообще-то очень часто в языках стандартная либа считается частью языка, потому да — в какой-то степени это раст и гарантирует. Правда, только при условии неиспользования unsafe и сторонних библиотек. Потому что кроме того, что стандартная библиотека инструментами компилятора навязывает правила операций в safe программе — стандартная библиотека еще и опирается на откровенный хардкод в компиляторе, вроде Sync/Send. Поэтому рандомная сторонняя библиотека не сможет легко и непринужденно навязать сильно больше гарантий.

В чем смысл раста, если жава с точно таким же разменом «безопасно ИЛИ быстро» обладает многократно большим набором библиотек на все случаи жизни?

Нету GC! Я выше в примере с Go описывал, как Go за счет выноса контейнеров из сборки мусора получил шанс соревноваться с компиляторами без GC. C# тоже шел по подобному пути, за счет чего легко уделал жаву — Go тут далеко не первый.

Это понимали разрабы Go, потому у них контейнеры не подвержены сборке мусора

Как это?

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

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

Разработчики джавы всё-таки не настолько ООПнутые (хотя и налажали с ковариантностью List’а). Числа там - примитивы, не наследуемые от Object. Но из-за выбранного подхода к реализации дженериков с помощью type erasure, положить эти примитивы в дженерик контейнер нельзя, приходится оборачивать в объекты.

Впрочем, после двадцати лет оптимизаций JVM и компилятора, разница в скорости сборки мусора для контейнеров скорее всего не сильно отличается от Go. GraalVM, например, выполняет мономорфизацию, если обнаруживает, что функция вызывается только с одним типом аргументов.

Впрочем, после двадцати лет оптимизаций JVM и компилятора, разница в скорости сборки мусора для контейнеров скорее всего не сильно отличается от Go

https://www.baeldung.com/java-memory-layout — Memory Layout of Objects in Java

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

Если бы ты читал весь тред, ты увидел бы, что я пару страниц про это писал. А ещё для ряда базовых типов и трейтов компилятор несколько меняет поведение. Специалисты по компиляторам набигают.

Настолько же «системный», как C# или Java.

Так-то я тоже считаю, что сборка мусора плохо вяжется с системным языком. Но всё-таки сказал бы, что D и Nim занимают промежуточную нишу между С и джавой. Хотя в расте когда-то тоже был сборщик мусора и одним из аргументов к выпиливанию была фрагментация инфраструктуры. Может и правда проще иметь два разных языка, чем пытаться усидеть на двух стульях одновременно.

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

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

Ну и разве сейчас, с появлением котлина, куда убежали все, кто хотел просто «улучшенную джаву», на скале не остались люди делающие из скалы хаскель (все эти scalaz, cats и т.д.)?

Хорошая попытка, но нет.

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

И это одна из ключевых моих претензий к расту — он плодит настолько много сомнительной полезности сущностей, что практическая польза от этого языка становится не так очевидна

Мне всё-таки кажется, что большую часть этих сущностей и так приходится держать в уме. Скажем, в плюсах сохраняя где-то string_view ты обязуешься гарантировать, что строка будет жить дольше. В расте будут явные лайфтаймы, но и страховка от компилятора. Или в бусте можно задефайнить BOOST_SP_DISABLE_THREADS и тогда shared_ptr будет использовать не атомарный счётчик ссылок. Раст, опять же, явно даёт Rc и Arc и опять с поддержкой от компилятора. Ну и так далее.

Ну да, как я и думал — касты в расте можно делать только реализацией собственных трейтов.

Не уверен, что понял мысль. Это плохо?

Вообще есть transmute и transmute_copy. И что значит «свои трейты»? Перечисленные трейты - «стандартные» и это удобно: можно ожидать их реализацию от стандартных и библиотечных типов.

Я бы сказал, что раст, но только при одном условии — если бы раст давал возможность забивать на обработку ошибок в стиле «если что-то пошло не так — валимся полностью»

Так он даёт. Ведь unwrap/expect - именно про это. Ну да, придётся написать чуть-чуть больше букв, но как по мне это тоже преимущество: когда придётся время перейти от быстро написанного на коленке кода к нормальному, то не придётся мучительно искать места, где обработка ошибок была проигнорирована.

Та же претензия уже давно есть у сообщества к Go.

В Go, как по мне, худшее из двух миров: необходимость писать много шаблонного кода без страховки от компилятора. Ведь всегда возвращается и значение и ошибка, а не что-то одно.

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

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

Ну и разве сейчас, с появлением котлина, куда убежали все, кто хотел просто «улучшенную джаву», на скале не остались люди делающие из скалы хаскель (все эти scalaz, cats и т.д.)

На скале остался суровый прод. На котлин — да, убежали жабокодеры, которые не осилили скалу. Все-таки котлин к жаве близко примерно как TS к JS.

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

Да ради бога, пусть используются, но большая часть реализации все равно сделана в unsafe.

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

Отчасти соглашусь. Действительно любят подражать «успешным» не понимая причин.

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

У меня знакомый на работе крутит гайки, а дома учит питон. Зачем? Он сам понятия не имеет.

Ну может хобби у человека, что в этом плохого? (:

Да и даже если надеется так другую работу найти, то тоже вреда не будет.

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

Если это правда, то разговоры о том, что «С++ свободен так как развивается комитетом, а раст - язык корпорации», которые любят заводить на лоре, звучат ещё смешнее.

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

Для раста есть cxx, правда я эту штуку не щупал, не знаю насколько жизнеспособно. Правда магии там, естественно, нет. Просто эту прослойку они частично пишут на расте, частично генерируют.

в плюсах сохраняя где-то string_view ты обязуешься гарантировать, что строка будет жить дольше

string_view еще не забанили в стандарте?

Или в бусте можно задефайнить BOOST_SP_DISABLE_THREADS и тогда shared_ptr будет использовать не атомарный счётчик ссылок. Раст, опять же, явно даёт Rc и Arc и опять с поддержкой от компилятора. Ну и так далее

Да, это приятная особенность раста. Но это капля в море.

Вообще есть transmute и transmute_copy. И что значит «свои трейты»? Перечисленные трейты - «стандартные» и это удобно: можно ожидать их реализацию от стандартных и библиотечных типов

Я сам не фанат наследования, но подструктурное наследование мне нравится, то есть, использование куска структуры как аргументу у функции другой структуры. Естественно, такой подход улетает в дикий unsafe на transmute.

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

Я бы сказал, что раст, но только при одном условии — если бы раст давал возможность забивать на обработку ошибок в стиле «если что-то пошло не так — валимся полностью»

Так он даёт. Ведь unwrap/expect - именно про это. Ну да, придётся написать чуть-чуть больше букв, но как по мне это тоже преимущество: когда придётся время перейти от быстро написанного на коленке кода к нормальному, то не придётся мучительно искать места, где обработка ошибок была проигнорирована

Там всё чутка тоньше, потому что на самом деле потенциальных источников ошибок больше, и они проигнорированы в расте и/или реализованы в виде паники, чтобы не превращать код в полный угар с unwrap/expect в каждой строчке кода. Они просто забили на эту проблему, типа «и так сойдет».

В Go, как по мне, худшее из двух миров: необходимость писать много шаблонного кода без страховки от компилятора. Ведь всегда возвращается и значение и ошибка, а не что-то одно

Какой там страховки нет? Defer какой-нибудь есть, целостность указателей поддерживается через сборщик мусора. Что еще нужно?

Есть, но у него другая семантика.

Сходу не смог разобраться, но разве unsafe функции там тоже не только в unsafe блоках можно вызывать? Ну и внутри таких функций и блоков можно работать с указателями. Выглядит похожим.

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

В С++ тоже любят говорить про «zero cost». Означает ли наличие не бесплатных абстракций, что нам врут?

Ну и в разговорах про «небезопасность С++» тоже постоянно возражают, что мол просто используйте at вместо скобочек и т.д. Станет ли С++ медленным, если так писать? Как по мне, это всё ерунда. В среднем коде за это плата будет небольшой и оно того стоит, как поведение по умолчанию.

Если это правда, то разговоры о том, что «С++ свободен так как развивается комитетом, а раст - язык корпорации», которые любят заводить на лоре, звучат ещё смешнее

Так а я и не говорю про какую-то там свободу. C++ — это язык корпорации AT&T, которая была гуглом своего времени.

В С++ тоже любят говорить про «zero cost». Означает ли наличие не бесплатных абстракций, что нам врут?

Означает. Врут. Чуда не бывает, если ты становишься ближе к Тьюринг машине для повышения производительности, то ты оказываешься вплотную к медленности и ненадежности Тьюринг машины. А других процессоров пока массово не завезли.

Ну и в разговорах про «небезопасность С++» тоже постоянно возражают, что мол просто используйте at вместо скобочек и т.д. Станет ли С++ медленным, если так писать? Как по мне, это всё ерунда. В среднем коде за это плата будет небольшой и оно того стоит, как поведение по умолчанию

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

Необходим ли там С++? Спорно. Скорее всего, хватит джавы или шарпа.

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

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

К слову, ты бы писал какой-нибудь LibreOffice на джаве?

Это малая часть всех ошибок.

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

И медленнее, чем у С.

И тем не менее. Наглядный пример, что безопасный раст может быть быстрее.

Можно ли написать на С++ быстрее? Наверняка, как и то, что из раста можно ещё выжать. Будет ли unsafe решение быстрее? Вероятно. Но главный вопрос в том: достаточно ли скорости среднего safe решения? Мне кажется, что для многих применений да и в этом и заключается преимущество.

Лучше бы остались. Я выше расписал.

Увидел (позже), но не согласен.

Ведь по факту поведение осталось безопасным (определённым), но и выбор есть. Можно использовать From и проверять наличие ошибки, ну и наконец есть to_int_unchecked. Чего не хватает?

Нет, реализация as вшита в компилятор, а трейты реализует юзер. От обычных функций они ничем не отличаются.

«Пишется явно» неправильно понял как «явно присутствует в коде» (в противовес implicit кастам). Но так и From/TryFrom для примитивных типов определены в стд. Это не сильно отличается от «вшито в компилятор».

Честно говоря, по прежнему не понял в чём тут проблема. В С++ тоже операторы преобразования можно объявлять.

В чем смысл раста, если жава с точно таким же разменом «безопасно ИЛИ быстро» обладает многократно большим набором библиотек на все случаи жизни?

Предлагаю сравнивать с питоном для пущего драматизма.

Но ты ведь и сам понимаешь, что передёргиваешь?..