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

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

Блин, ну конечно же системные вызовы ты на жаве не напишешь.

Ещё один момент - чтобы на Rust утекла память, нужно постараться. Чтобы на Java утекла память, стараться не нужно

Ты про веселости GC в Java? Если в расте играться с Arc, то можно легко подобный результат получить.

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

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

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

Ещё раз. Раст запрещает несинхронизированное обращение к шареной памяти в safe коде. Несинхронизированное обращение - это data races. Иметь data races в программе, и гарантировать, что она будет работать без проблем - это уровень жонглирования кинжалами с прыжками через горящие обручи. См. например https://www.usenix.org/legacy/event/hotpar11/tech/final_files/Boehm.pdf

Да, если хотите жонглировать кинжалами, вместо того, чтобы синхронизировать доступ - пишите unsafe.

Ты про веселости GC в Java?

Я про то, что ничего не мешает где-нибудь в объекте оставить какой-нибудь бесконечно растущий кеш. С Rust вроде бы с этим намного сложней неявно сделать.

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

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

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

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

Давайте назовем тред: лучше ли Rust, чем C++?

Я про то, что ничего не мешает где-нибудь в объекте оставить какой-нибудь бесконечно растущий кеш. С Rust вроде бы с этим намного сложней неявно сделать

«Сложнее» только потому, что в Rust что угодно сложнее сделать. В остальном Rust никак не ограничивает возможности программиста по бесконечному выделению памяти. Блин, да у меня сейчас под рукой проект SPA на JS, который «программисты» умудрились завалить через неограниченное выделение памяти — были бы криворукие индусы, а язык уже не так важен.

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

Да. Изменяемые ячейки данных — это оптимизация со времен ЭВМ с 4 килобайтами оперативной памяти. Но проблема в том, что нынешние ЭВМ с 64 ГБ памяти работают почти по тем же принципам, что и те с 4 кБ. То есть, машина Тьюринга. Если же ты строишь на базе этой машины новую абстракцию, более подходящую для многопотока, то у этой абстракции есть цена в виде производительности. А если ты готов эту цену платить, то внезапно выясняется, что можно писать на Java, или на Erlang, или на Go — и Rust уже не нужен.

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

Каких конкретно инструментов вам не хватает для реализации, скажем Software Transaction Memory из упоминавшейся Clojure?

Давайте назовем тред: лучше ли Rust, чем C++?

Ок, какие упоминавшиеся выше инструменты есть в С++, которых не хватает в расте?

И как вы собирались заставить программиста на С++ не шарить ссылки/shared_ptr между потоками без использования синхронизации для доступа к данным?

Каких конкретно инструментов вам не хватает для реализации, скажем Software Transaction Memory из упоминавшейся Clojure?

Для реализации STM нужны многоверсионные (персистентные) структуры данных и откат изменений транзакции. В принципе, персистентные структуры данных в расте можно реализовать, а вот с откатом транзакций будет посложнее.

Ок, какие упоминавшиеся выше инструменты есть в С++, которых не хватает в расте?

Одинаково, что там, что там.

И как вы собирались заставить программиста на С++ не шарить ссылки между потоками?

Как ты собрался заставить программиста на Rust не шарить ссылки между потоками? Опять же, через проверку кода сеньором, который убедится, что джун не натыкал unsafe-ов. Да. в крестах аналогичный процесс выглядит сложнее. Опять же, мы приходим к тому, что разница между C++ и Rust чисто организационная — для хорошо мотивированного грамотно писать код программиста разница будет невелика.

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

Как ты собрался заставить программиста на Rust не шарить ссылки между потоками?

Для этого в расте есть Send и Sync. Попытка расшарить между потоками мутабельные данные (ссылками или Arс’ами) без синхронизации даст ошибку компиляции. Третий раз пишу, если что.

А unsafe можно даже не проверять руками. Есть #[deny(unsafe_code)]

Желаете ещё какие-нибудь инструменты по проверке наличия отсутствия data races?

А unsafe можно даже не проверять руками. Есть #[deny(unsafe_code)]

Это типичный подход манагеров. Запретить, расставить в шеренгу в 9:47, ни минутой раньше или позже, и чтобы все пели гимн КНДР 13 минут. Особо отбитые даже предлагали сделать опцию «запрещать использование unsafe до явной директивы разрешения ее в блоке»:

https://internals.rust-lang.org/t/disabling-unsafe-by-default/7988

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

Попытка расшарить между потоками мутабельные данные (ссылками или Arс’ами) без синхронизации даст ошибку компиляции

Не даст, потому что программист напишет «unsafe {...}» или дернет кривую библиотеку, которая реализована через unsafe, примерно как через этот unsafe реализована стандартная библиотека. Это ты сейчас такой невозмутимый и уверенный в библиотеках, потому что под раст кроме стандартной библиотеки толком ничего и нет. А что начнется, когда попрут массово с гитхаба писанные индусами поделки?

хотят вообще в концлагерь превратить

С++: Нормалёк, буду следить за джуном, чтобы херни не напорол.

Rust: автоматически контролируем работу джуна. AAA! Концлагерь, всё пропало!

Показательно. У вас всё в порядке? То средств контроля не хватает, а как показывают, так концлагерь.

С++: Нормалёк, буду следить за джуном, чтобы херни не напорол.
Rust: автоматически контролируем работу джуна. AAA! Концлагерь, всё пропало!
Показательно

С++: следили за джуном. Но все равно БД лежит.

Rust: автоматически контролировали работу джуна. Но все равно БД лежит.

Показательно.

Для того, чтобы было иначе нужно, чтобы компиляторы много больше умели чем анализ лексики, …

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

Для того, чтобы было иначе нужно, чтобы компиляторы много больше умели чем анализ лексики

Такие компиляторы есть, если чо, на них можно доказать программно корректность логики. Это тоже сложно, как и писать на расте, но хотя бы имеет практический смысл, в отличие от тех «гарантий,» которые предоставляет раст. Я писал, что «вижу перед собой собрание манагеров-лезбух из мозилы, как они обсуждают будущее проекта и разрабатывают для него фичи. Мол: никто до сих пор не делал безопасный язык, мы станем первыми разработчиками абсолютно безопасного языка, это убойная фича для маркетинга, мы завоюем мир. И в итоге они фокусируются на идее безопасности, по пути упуская вообще всё остальное, проходя по всем возможным граблям», но сейчас я начинаю осознавать, что увидел не всё, ведь они не просто пожертвовали всем ради «безопасности», они пожертвовали всем, и даже надежностью выполнения, ради отсутствия UB и ради сохранения высокой производительности выполнения, как у C/C++. И получили абсурдный инструмент, который почти никому не нужен.