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

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

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

А я объяснил, почему их сервис на Go — низкокачественный говнокод.

Я не уловил в какой момент ты это сделал.

Я не работаю в дискорде, но я за версту чую мудаков и налюб.

Может ты еще и ауру человека видишь?

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

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

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

Ага. И винить в этом раст нет смысла.

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

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

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

Я не уловил в какой момент ты это сделал.

«Минимум аргументации — максимум пафоса. У них среднее время ответа растет до 20 мс — и это вроде как является причиной перейти с Go на Rust? Прям лёг сервис, все пользователи на протяжении этих 20 мс гневно строчили жалобы в поддержку на тупящий сервис, и все 20 мс поддержка жаловалась разработчикам на то, что «это невыносимо».

А вот что сделали для решения подобной задачи людишки из dgraph:

https://github.com/dgraph-io/ristretto

60 млн запросов в секунду. Оно, к слову, базируется на стандартных map языка Go. Map, который выделяет свои данные вне кучи и они не обрабатываются сборщиком мусора, то есть, у самого map околонулевая стоимость сборки мусора. А значит, дискордовцы с очень большой вероятностью накосячили в реализации и там даже близко нет никаких «мы написали очень эффективный код Go с минимальным количеством выделений памяти» — потому что если вы написали очень эффективный код, то какого хера у вас сборщику мусора вообще есть что собирать?»

погромист сделает логическую ошибку

Fixed

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

Wait-free алгоритмы, как правило, расчитаны на строго ограниченное число агентов. То есть, при бесконечном числе агентов задержка будет расти бесконечно. Wait-free — такое wait-free. А если вспомнить, что многие из них на самом деле пользуются операциями, являющимися лишь contention-free на уровне процессора, то это всё становится детским садом.

Я применяю термин lock-free, потому что он хотя бы как-то интуитивно понятен, типа «используем атомарные операции вместо блокировок». Производительность же того или иного алгоритма зависит строго от задачи и реализации, в целом и общем что бы то ни было анализировать нет никакого смысла.

Ага. И винить в этом раст нет смысла

Я виню раст в бессмысленном переусложнении языка. Которое в том числе приводит к бессмысленному росту времени компиляции.

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

В стандартную библиотеке стараются включать фичи, для которых не нужны компромиссы (trade-offs)

И также я еще раз подчеркиваю, что safe-коду на расте до надежности как до киева раком. Чего нет — того нет, и ничего его выдумывать.

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

в целом и общем что бы то ни было анализировать нет никакого смысла.

В целом и общем вполне можно сказать, что пиковая латентность для lock-free алгоритмов не ограничена. Что влияет на область их применения.

бессмысленному

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

В целом и общем вполне можно сказать, что пиковая латентность для lock-free алгоритмов не ограничена. Что влияет на область их применения

Если ты прикинешь, что вообще должен представлять собой какой-нибудь конечный контроллер с wait-free гарантиями, то есть, hard real-time, то там возможностей остается очень мало. Хэш-таблицу нельзя, бинарное дерево нельзя, блокировки нельзя, malloc/free нельзя — это настолько далеко от типичных инструментов, с которыми работает 99% кодеров, что говорить об этом не имеет особого смысла.

И также я еще раз подчеркиваю, что safe-коду на расте до надежности как до киева раком. Чего нет — того нет, и ничего его выдумывать.

Что-то Вий вспомнился. Так и хочется поднять веки. Гарантия отсутствия data races в safe раст есть? Да? Нет?

Даёт это бОльшую гарантию надёжности, чем в языках где её нет? Да? Нет?

Стоит валить на язык нерешённую (и неизвестно решаемую-ли) в общем случае проблему (быстрая, безопасная и удобная параллельная работа с разделяемыми данными)? Да? Нет?

Сишники/плюсовики так каждый раз млеют от мысли о едином репозитарии и универсальной системе сборки.

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

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

Пф-ф-ф, я выше по треду писал, какой «смысл» у них был. Смысл был оправдать свое сидение на должности. Сделали язык, неплохой язык, но надо лучше? Какой аргумент вы предложите, чтобы наши крестовики пересели на него? Другими словами «как ваш ядерный реактор поможет нам повысить удои коров?». Что нужно мозиле? Скорость и устойчивость к удаленному выполнению кода. Вот они их и сделали. Причем. реализовали в стандартной либе именно инструменты для работы с изменяемыми разделяемыми данными те, которые нужны браузеру, даже частично добавили инструменты вывод Sync/Send в сам компилятор. Как этим будет пользоваться кто-то вне мозилы? Да пофигу вообще. А вне мозилы таки их язык для написания браузеров почти никому не нужен. Особенно с такой медленной компиляцией.

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

А по поводу «тебя спросят» — вот при проектировании Алгола-68 спросили Вирта, Хоара, Дейкстру. Они сказали «ваш язык — говно. Паскаль на голову выше». И что сделал комитет? Утвердил говно, а паскаль в итоге взлетел, только с большим скрипом, потому что долго никому не был нужен язычок, в одно рыло написанный каком-то цвейцарцем.

дискорд пишется на расте

Там какой-то мелкий кусок переписан, который им было лень оптимизировать. Ну переписали и хорошо.

и драйвера в линуксе теперь пишутся на расте.

Можно пример готового драйвера? Насколько помню, ни одного пока нет и пока ограничивались «примерами» как оно должно работать. И то оно написано было так, что должно было кидать panic когда от драйвера этого не ожидалось.

Вот mercurial имеет вариант на rust (только не смотри его). И librsvg переписали зачем-то, теперь он правда собирается по времени почему-то долго.

Вот запилят возможность писать модули ядра на Расте, тогда и поговорим

Вы находитесь здесь

О, у нас тут светило науки, не сегодня-завтра премию Тьюринга дадут.

Эту новость уже обсудили Линус Торвальдс раскритиковал Rust в ядре

Гарантия отсутствия data races в safe раст есть? Да? Нет?

Спорно. Safe Rust не имеет стандартной библиотеки, потому ничего не может делать. Гарантии отсутствия data race есть в стандартной библиотеке. которая unsafe. Но с таким же успехом я могу взять либу под кресты, которая гарантирует отсутствие data race (не важно, насколько это неудобно и медленно работает). Я беру стороннюю либу для раста — я теряю гарантии. Я использую нестандартные методы работы с крестовой либой — я теряю гарантии. В чем отличие? Что в расте чуть более удобные развитые инструменты по принуждению программиста?

Даёт это бОльшую гарантию надёжности, чем в языках где её нет? Да? Нет?

Дает лучше тестируемость и отлаживаемость, что косвенно может дать бОльшую гарантию надёжности. Надежности, до которой по прежнему будет как до киева раком, потому что data race — это одна из многих проблем.

Стоит валить на язык нерешённую (и неизвестно решаемую-ли) в общем случае проблему (быстрая, безопасная и удобная параллельная работа с разделяемыми данными)? Да? Нет?

Конечно же нет. Раст не решает и не пытался ее решать — он не создавался для ее решения. Он создавался для того, чтобы написать на нем браузер. Всё. Он не создавался для написания стабильных приложений, он не создавался для написания высокопроизводительных СУБД — зачем фанбои пытаются валить на язык эти задачи?

Компания подготовила начальный прототип написанного на Rust драйвера для механизма межпроцессного взаимодействия Binder. … Эта работа еще не завершена.

Ок, «подождём», драйвер же готов!

О, у нас тут светило науки, не сегодня-завтра премию Тьюринга дадут

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

Бедняга, тяжело, должно быть, жить непризнанным гением;)

Да я о чем. Безапелляционно заявляет что только он знает как выглядит идеальный язык и в Rust просто все неправильно. Вирт диванный. Send/Sync никто не будет использовать :) По моему он не понимает что именно заначит их «использовать»

Но с таким же успехом я могу взять либу под кресты, которая гарантирует отсутствие data race (не важно, насколько это неудобно и медленно работает)

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

Единственное, что я вижу - сделать обёртки, которые хранят и проверяют thread id при каждом доступе к данным.

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

«Минимум аргументации — максимум пафоса. У них среднее время ответа растет до 20 мс — и это вроде как является причиной перейти с Go на Rust?

20 мс это среднее (average), а в абсолютном респонс тайм пики под 300 мс. Но вообще не очень понятно что именно на этих графиках, так что гадать тут бесполезно.

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

Собственно да, работа в этом направлении ведется, что то пишется, скоро увидим взлетит или нет.

Сказано, что если собирать в дебаге, то это приводит к панике, а если в релизе - к wrapping. Но что такое сборка в дебаге или релизе с точки зрения самого языка в терминах абстрактной машины? Такого нет и в мире C/C++ это бы называлось implemetantion defined или undefined behavior.

Вообще-то в С++ такое есть (assert), implemetantion defined и тем более undefined behavior - это вообще из другой оперы. Да и в расте вполне себе нормально описывается когда какое поведение будет и управлять им можно через опции компилятора, если не хочется зависеть от «профилей» сборки.

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

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

Но вообще совместимость С++ с С не самый удачный пример в данном случае. Лучше посмотреть на котлин: язык вполне себе взлетел и лёгкости перехода на джаву там уделяют много внимания. JVM язык без возможности использования имеющейся инфраструктуры никому не нужен. Даже скала, со всеми её заморочками, и то умеет джава библиотеки использовать.

С точки зрения «убийства» С++ никто ничего такого даже близко не предлагает. Разве что у D есть некая «ограниченная совместимость». Впрочем, не похоже, что им это помогло. Раст же вообще не про это. Тем не менее, на С++ написано много всего и переписывать всё и сразу никто не будет, поэтому «даже» в расте всячески пытаются «совместить» эти языки: cxx, rust-bindgen, cbindgen и т.д. Вон недавно и вот такие извращения попадались: https://mcyoung.xyz/2021/04/26/move-ctors/

Пока ты будешь дергать десять раз cargo check — я уже десять раз скомпилирую и протестирую свою сишку.

Не уверен (и не могу промолчать), но спорить смысла не вижу: очевидно мы друг другу ничего не докажем.

У аудитории из трех человек?

А чего ты хотел? Язык от одного чувака, без поддержки корпораций и чтобы он в топ внезапно пролез?

Тем не менее, вон люди даже на лор новости приносят - очевидно, что язык их чем-то заинтересовал. И статьи в духе «перешёл с раста на ним и рад жизни» тоже появляются.

не нравится TIOBE — ради бога, вот тебе stackoverflow:

Так ведь ничего принципиально не поменялось: свифт там ниже, чем VBA. Да и в целом у меня претензия не к рейтингу была. Просто пропихнуть даже неплохой язык сложно. Удачное стечение обстоятельств может помочь: скажем, как у котлина с андроидом.

Nim — это все-таки не совсем низкоуровневый язык, это скорее диалект питона

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

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

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

Я боюсь, что работу на расте вообще непросто найти.

Проще, чем три года назад. Хотя меня в 2017 году самого внезапно нашли. С тех пор успел в трёх конторах на расте пописать - варианты вполне есть. Если не гнушаться блокчейнами, так тем более. На одном из проектов мы даже джунов набирали.

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

Ну для кого как. (:

Я уже две статьи нахерячил.

Поделишься ссылками?

Реакция чуть более чем никакая

Ну а что ты хотел? Лор должен был тебя закалить: большая часть комментариев будет «не нужно».

Поделишься ссылками?

Думаю, вот.

https://habr.com/ru/users/byko3y/posts/

Только в Java нет нотации для safe/unsafe

А в C# есть. B джаве можно сказать, что граница через JNI проходит.

и Java не декларирует memory safety на главной странице.

Так ведь оно подразумевается - managed языки ведь как раз про это. Даже в данной теме проскакивало что-то вроде «раст не сейф так как там в стандартной библиотеке ансейф, нужна безопасность - идите в джаву».

Да нет никакого смысла, как и в самом атрибуте unsafe.

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

Какую, например? Чтобы предметно поговорить как там обеспечиваются и обеспечиваются-ли гарантии. Если таких нет, хорошо бы услышать про теоретический способ обеспечения гарантий.

Я всё жду, когда прибежит eao197 со своим SObjectizer, и расскажет вам конкретно как.

Понятно, что такая библиотека не может отдавать ссылки/указатели на защищаемые данные (их можно передать в другой поток). Как это реализовать?

А еще можно передать в другой поток некорректный индекс в массиве. или создать условия для дедлока. Но пока ты пользуешься штатными функциями либы, то есть «safe» функциональностью — у тебя есть гарантии безопасности. Причем, в случае SObjectizer это еще и гарантии отсутствия дедлоков, которые Rust в принципе не умеет давать, поскольку Rust гарантирует только отсутствие UB, в число которых входит data race.

Единственное, что я вижу - сделать обёртки, которые хранят и проверяют thread id при каждом доступе к данным

Вот это я делал в делфи и сишке. Но это два куцых языка, в которых нет такого продвинутого RAII и метапрограммирования, как в крестах.

Ну и назвать использование тормозной и неудобной библиотеки «с таким-же успехом» - это таки очень альтернативное понимание программирования

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

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

20 мс это среднее (average), а в абсолютном респонс тайм пики под 300 мс. Но вообще не очень понятно что именно на этих графиках, так что гадать тут бесполезно

95th response time — это время, за которое завершается 95% запросов. То есть, отдельные запросы висят аж целые 200-300 мс. И это недопустимо. Почему-то. Естественно, они даже не понимают, почему это происходит, ведь даже при пике в 25 мс паузы для стабилизации системы нужно обработать повисшие запросы, которые будут обработаны за сравнимое время с повышением загрузки процессора, который у них в норме загружен всего-лишь на 20%. Откуда тогда там 200-300 мс? А черт его знает — давайте лучше напишем сервис на Rust.

Это я имел в виду, когда писал «минимум аргументации — максимум пафоса». Статья вызывает кучу вопросов, поскольку приведенные показатели намекают не столько на проблему Go, сколько на некомпетентность исполнителей и нежелание эту компетентность повышать.

А про 60 млн запросов в секунду я уже написал что это разные метрики

Их загрузка (дискорда) — сотни тысяч запросов в секунду. Либа для Go, на которую я дал ссыль и которая реализована на самом обычном map, выдает 60 млн запросов в секунду — на два порядка выше загрузки дискорда. То есть, она способна за 10 мс обработать все запросы, которые скопились за целую секунду паузы. А говнокодеры из дискорда почему-то не могут за 200 мс обработать запросы, которые скопились за 20 мс.

И я настаиваю на цифре в 10-20 миллисекунд, потому что именно такую задержку на бенчах GC показывает Go при десятках ГБ данных в памяти.

Но вообще совместимость С++ с С не самый удачный пример в данном случае. Лучше посмотреть на котлин: язык вполне себе взлетел и лёгкости перехода на джаву там уделяют много внимания. JVM язык без возможности использования имеющейся инфраструктуры никому не нужен

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

С точки зрения «убийства» С++ никто ничего такого даже близко не предлагает

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

Если я правильно понимаю, то в Расте unsafe не для скорости, а для преодоления недостаточной гибкости safe.

Зачастую эти вещи связаны.

Зачем учить особенности safe, unsafe и Си?

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

Зависит от цели.

Ну цель-то «простая»:

просто зашкурить ручку, чтобы не кололась

Я как раз и озвучиваю мнение почему так не получается: если дать слишком мало нового, то оно того не стоит. Если много - ломаем совместимость.

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

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

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

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

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

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

Вместо безопасности И скорости получается «безопасность» ИЛИ скорость – достаточно взглянуть на «идиоматичный» код на расте на benchmarksgame.

Ну вот взглянул: https://benchmarksgame-team.pages.debian.net/benchmarksgame/program/spectralnorm-rust-5.html

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

Поделишься ссылками?

Поделюся. Вот актуальная:

https://habr.com/en/post/526002/

Лор должен был тебя закалить: большая часть комментариев будет «не нужно»

Comments 0

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

Не ври, в расте нет приведения типов.

Почему?

Есть дырявый каст as

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

Отдельно можно упомянуть deref/into, которые приведением считать сложно и которые пишутся явно.

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

«&mut is now unaliasable»

И почему это плохо? Дополнительная возможность для оптимизаций. Тем более, что для «хакерства с указателями» инструменты всё равно остались.

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

Так ты ничего нормально не узнаешь.

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

Программа, в которой нет unsafe, ничего не делает. Если в программе на 10к строк всего 20 строк unsafe, то она либо катастрофически бесполезна, либо является клеем между библиотеками, в которых осуществляется вся работа.

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

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

В Си функции тоже могут возвращать ошибку. И тоже будут проблемы только если не обрабатывать ошибку. И дальше чо? Чем тогда раст лучше Си?

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

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

Не ври, тебя сюда ФГМ привёл, а не жажда знаний. Ты не слушаешь, что тебе говорят, а, напротив, с упорством, достойным лучшего применения, доказываешь окружающим какие-то свои домыслы.

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

Как это?

https://habr.com/ru/users/byko3y/posts/

Спасибо, почитаю.

А вне мозилы таки их язык для написания браузеров почти никому не нужен. Особенно с такой медленной компиляцией.

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

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

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

Особенно учитывая, что сами бинарные интерфейсы не стандартизированы.

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

https://habr.com/en/post/526002/

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