Здравствуйте, kaa.python, Вы писали:
WH>>Так если у нас типизация динамическая, то как ты будешь эти интерфейсы контролировать? KP>Больше тестов напишешь, они ещё никому не вредили.
Тесты гарантии не дают. Типы дают. При этом проверка типов намного быстрее тестов.
Ну и попробуй тестами поймать то, что ловит borrow checker в rust.
Удачи.
KP>Зависит от языка. Из тех динамических что я знаю — ABCMeta в купе с аннотациями типов в Python вполне себе решает эту проблему. В Closure вот specs завезли, тоже очень удачное решение проблемы типизации для динамики.
То есть добавляем явные аннотации типов?
KP>Нападок на динамику я не очень понимаю если честно. Проблемы в сравнении со статикой просто другие и всё.
Проблемы статики на фоне проблем динамики в микроскоп не видно.
Здравствуйте, WolfHound, Вы писали:
KP>>Больше тестов напишешь, они ещё никому не вредили. WH>Тесты гарантии не дают. Типы дают. При этом проверка типов намного быстрее тестов. WH>Ну и попробуй тестами поймать то, что ловит borrow checker в rust. WH>Удачи.
А вот приведи пример, чего там такого особенного ловит borrow checker. Это я естественно не в защиту динамики (понятно что статика всегда даёт большие гарантии), а просто потому что мне кажется данные вопрос в Rust'е несколько мифологизирован... )
Здравствуйте, alex_public, Вы писали:
_>А вот приведи пример, чего там такого особенного ловит borrow checker. Это я естественно не в защиту динамики (понятно что статика всегда даёт большие гарантии), а просто потому что мне кажется данные вопрос в Rust'е несколько мифологизирован... )
Да хотя бы посмотри на mutex.
В rust он защищает конкретный объект. Причем интерфейс мютекса гарантирует, что прежде чем поток отпустит мютекс, все ссылки на данный объект будут удалены.
Здравствуйте, WolfHound, Вы писали:
_>>А вот приведи пример, чего там такого особенного ловит borrow checker. Это я естественно не в защиту динамики (понятно что статика всегда даёт большие гарантии), а просто потому что мне кажется данные вопрос в Rust'е несколько мифологизирован... ) WH>Да хотя бы посмотри на mutex. WH>В rust он защищает конкретный объект. Причем интерфейс мютекса гарантирует, что прежде чем поток отпустит мютекс, все ссылки на данный объект будут удалены.
Это всё общие слова. Ты можешь показать конкретный пример кода, в котором демонстрировались бы возможности borrow checker в области распараллеливания, недоступные в других (ну во всяком случае из мейнстрима) языках?
Здравствуйте, alex_public, Вы писали:
_>Это всё общие слова. Ты можешь показать конкретный пример кода, в котором демонстрировались бы возможности borrow checker в области распараллеливания, недоступные в других (ну во всяком случае из мейнстрима) языках?
BC не даёт новые возможности. Он исключает ошибки.
В других языках у тебя нет гарантии, что кто-то случайно не сохранит ссылку на защищаемый мютексом объект.
В других языках обычно мьютекс даже не связан с данными. Вся многопоточность чисто на внимательность программиста завязана.
... << RSDN@Home 1.0.0 alpha 5 rev. 0>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, WolfHound, Вы писали:
_>>Это всё общие слова. Ты можешь показать конкретный пример кода, в котором демонстрировались бы возможности borrow checker в области распараллеливания, недоступные в других (ну во всяком случае из мейнстрима) языках? WH>BC не даёт новые возможности. Он исключает ошибки.
Думаю, нужно пояснить.
Защита, которую даёт rust позволяет превратить непрактичные из-за большой когнитивной нагрузки вещи в практичные.
Что фактически даёт новые возможности.
... << RSDN@Home 1.0.0 alpha 5 rev. 0>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, WolfHound, Вы писали:
_>>Это всё общие слова. Ты можешь показать конкретный пример кода, в котором демонстрировались бы возможности borrow checker в области распараллеливания, недоступные в других (ну во всяком случае из мейнстрима) языках? WH>BC не даёт новые возможности. Он исключает ошибки.
Это понятно. Но интересует конкретный пример ошибки реализации многопоточности, которую можно выявить в Rust и невозможно в других языках.
WH>В других языках у тебя нет гарантии, что кто-то случайно не сохранит ссылку на защищаемый мютексом объект.
Ну на самом деле у тебя и в Rust'е нет таких гарантий. Это скорее в каком-нибудь Питоне можно их получить, внедрив защиту мьютексом не в виде объекта-контейнера, а вставив её непосредственно в сам защищаемый тип данных (модифицировав его конкретный экземпляр).
WH>В других языках обычно мьютекс даже не связан с данными. Вся многопоточность чисто на внимательность программиста завязана.
Потому что в большинстве случаев синхронизация завязывается не на куски данных, а на куски кода. Это более логично и востребовано, т.к. код редко работает только с одной переменной (собственно для одной правильнее использовать atomic и т.п.). Однако если есть желание заблокировать на уровне доступа к некой переменной, то с этим очевидно тоже никаких проблем нет — просто реализуем соответствующий тип-контейнер. Собственно в примере Rust'а так и сделано и нет никаких проблем с подобным (ну с поправкой на автоматизацию разблокировки из-за наличия в языке RAII) же в любых других языках.
Здравствуйте, alex_public, Вы писали:
WH>>В других языках у тебя нет гарантии, что кто-то случайно не сохранит ссылку на защищаемый мютексом объект.
_>Ну на самом деле у тебя и в Rust'е нет таких гарантий.
Borrow checker тебе не позволит держать ссылку на защищаемые мьютексом данные дольше, чем ты будешь удерживать мьютекс.
Товарищ WolfHound прав насчёт когнитивной разгрузки -- Rust, например, позволяет взять малоопытных разработчиков и посадить писать их бизнес логику. И при этом не беспокоиться что они забудут там какой-то нибудь synchronized написать или данные замодифицируют так, что ты получишь состояние гонки в какой-нибудь совершенно параллельной части твоей системы.
Можно не понимать в деталях, как работают Send и Sync, но при этом Rust надаёт тебе по рукам при попытке написать код с ошибками синхронизации. Даже более тонкие моменты, типа какого-нибудь "умного" указателя, запрятанного глубоко в твоих структурах данных и использующего счётчики, которые небезопасны в условиях многопоточности (т.е не atomic счётчики ссылок, например).
Правда, эта когнитивная разгрузка по более опытным разработчикам бьёт, так как им приходится проектировать систему так, чтобы её borrow checker одобрил (не всякая забракованная программа -- дефектна, в частности, поэтому порой нужен unsafe), но на то они и более опытные.
Здравствуйте, alex_public, Вы писали:
WH>>BC не даёт новые возможности. Он исключает ошибки. _>Это понятно. Но интересует конкретный пример ошибки реализации многопоточности, которую можно выявить в Rust и невозможно в других языках.
Я уже давал ссылку. https://blog.faraday.io/saved-by-the-compiler-parallelizing-a-loop-with-rust-and-rayon/
Покажи мне язык, который на этапе компиляции может такое поймать. Мне правда интересно.
WH>>В других языках у тебя нет гарантии, что кто-то случайно не сохранит ссылку на защищаемый мютексом объект. _>Ну на самом деле у тебя и в Rust'е нет таких гарантий.
Код в студию.
Положи объект в мьютекс и попробуй получить доступ к нему или его части не под блокировкой без использования unsafe.
После того как несколько часов побьёшься головой о каменную стену поймёшь почему люди говорят что rust хороший язык.
_>Это скорее в каком-нибудь Питоне можно их получить, внедрив защиту мьютексом не в виде объекта-контейнера, а вставив её непосредственно в сам защищаемый тип данных (модифицировав его конкретный экземпляр).
Многопоточность? В питоне? GIL передаёт привет.
WH>>В других языках обычно мьютекс даже не связан с данными. Вся многопоточность чисто на внимательность программиста завязана. _>Потому что в большинстве случаев синхронизация завязывается не на куски данных, а на куски кода. Это более логично и востребовано, т.к. код редко работает только с одной переменной (собственно для одной правильнее использовать atomic и т.п.).
Ты же сам пишешь про работу с конкретным набором данных.
Просто в rust данные нужно положить в один объект.
_>Однако если есть желание заблокировать на уровне доступа к некой переменной, то с этим очевидно тоже никаких проблем нет — просто реализуем соответствующий тип-контейнер. Собственно в примере Rust'а так и сделано и нет никаких проблем с подобным (ну с поправкой на автоматизацию разблокировки из-за наличия в языке RAII) же в любых других языках.
Под контейнером ты подразумеваешь объект, в котором все поля приватные. А все публичные методы первым делом захватывают мьютекс?
Если да то в других языках это решение всё равно не даёт никаких гарантий.
Что бы будешь делать, если тебе нужно сделать несколько операций под мьютексом? А если тебе нужно два объекта заблокировать и перекинуть данные между ними?
В случае с rust проблем не будет. Ибо мьтекс живёт снаружи объекта. Объект в общем случае даже не знает, что его в многопоточном коде используют.
... << RSDN@Home 1.0.0 alpha 5 rev. 0>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Pony. Еще наверняка ATS, но там редкая птица долетит до середины.
На уровне чуть проще, в этом примере многое сводится к
The GenerateToken API assumes that our token-generator is a read-only object. This is good, because we want to access it from multiple threads! But in the test code, we need to create some “interior” mutable state.
И любой язык, знающий что такое иммутабельность / read-only, не дающий менять данные за read-only интерфейсом, тут уже дал бы по рукам и проблема была бы решена безо всяких борроучекеров.
Здравствуйте, D. Mon, Вы писали:
WH>>Покажи мне язык, который на этапе компиляции может такое поймать. Мне правда интересно. DM>Pony.
Там тоже пилили систему типов для решения проблем с многопоточностью.
Rust ИМХО получился намного более практичным.
DM>Еще наверняка ATS, но там редкая птица долетит до середины.
Его вообще не для людей делали.
DM>На уровне чуть проще, в этом примере многое сводится к DM>
The GenerateToken API assumes that our token-generator is a read-only object. This is good, because we want to access it from multiple threads! But in the test code, we need to create some “interior” mutable state.
DM>И любой язык, знающий что такое иммутабельность / read-only, не дающий менять данные за read-only интерфейсом, тут уже дал бы по рукам и проблема была бы решена безо всяких борроучекеров.
1)Ты докапываешься к мелочам. Точно так же там могла идти речь про что-то другое. Например, сделали что-то с использованием типа Rc, а через год другой программист начал это параллелить и получил по рукам. Ибо для многопоточности нужен Arc.
2)Rust очень хорошо знает, что такое иммутабельность. И по умолчанию бьёт по рукам не хуже хаскеля.
Просто ещё он знает, что иногда нужно ехать, а не шашечки.
... << RSDN@Home 1.0.0 alpha 5 rev. 0>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, Иван Дубров, Вы писали:
WH>>>В других языках у тебя нет гарантии, что кто-то случайно не сохранит ссылку на защищаемый мютексом объект. _>>Ну на самом деле у тебя и в Rust'е нет таких гарантий. ИД>Borrow checker тебе не позволит держать ссылку на защищаемые мьютексом данные дольше, чем ты будешь удерживать мьютекс. ИД>Пример.
Ну замени в этом коде тип у stolen например на *const std::sync::MutexGuard<'_, usize> и гарантии вдруг резко куда-то пропадут... )
ИД>Товарищ WolfHound прав насчёт когнитивной разгрузки -- Rust, например, позволяет взять малоопытных разработчиков и посадить писать их бизнес логику. И при этом не беспокоиться что они забудут там какой-то нибудь synchronized написать или данные замодифицируют так, что ты получишь состояние гонки в какой-нибудь совершенно параллельной части твоей системы.
Большая доля правды в этом конечно же есть, но не до абсолютных значений (о которых говорят в терминах гарантий и про которые говорил WolfHound).
ИД>Можно не понимать в деталях, как работают Send и Sync, но при этом Rust надаёт тебе по рукам при попытке написать код с ошибками синхронизации. Даже более тонкие моменты, типа какого-нибудь "умного" указателя, запрятанного глубоко в твоих структурах данных и использующего счётчики, которые небезопасны в условиях многопоточности (т.е не atomic счётчики ссылок, например).
Только вот например следование такой простой схеме реализации многопоточности, как "модель акторов", тоже по сути гарантирует отсутствие большинства ошибок многопоточности. Причём в любом языке — для её реализации не требуются какие-то хитрые механизмы. Соответственно возникает вопрос — а стоят ли все эти усилия того? Т.е. не слишком ли велика цена за достаточно элементарные вкусности, которые можно получить и другими способами... Это я уже не по поводу вопроса к WolfHound, а просто рассуждаю о том стоит ли применять Rust или нет.
ИД>Правда, эта когнитивная разгрузка по более опытным разработчикам бьёт, так как им приходится проектировать систему так, чтобы её borrow checker одобрил (не всякая забракованная программа -- дефектна, в частности, поэтому порой нужен unsafe), но на то они и более опытные.
Лично меня больше раздражает не необходимость следования моделям borrow checker (они в принципе довольно разумные, а для C++ программиста, привыкшего к работе с умными указателями, вообще кажутся родными), а слишком большое количество пустой писанины ради обеспечения его работы.
Вообще даже смешно становится: синтаксис самого языка вроде как сделали максимально лаконичным (все эти fn, let, mut и т.п.), но при этом реальный код выглядит намного более громоздким чем даже C++ или Java, как раз из-за необходимости громоздить дикие типы на пустом месте.
Здравствуйте, alex_public, Вы писали:
ИД>>Borrow checker тебе не позволит держать ссылку на защищаемые мьютексом данные дольше, чем ты будешь удерживать мьютекс. ИД>>Пример.
_>Ну замени в этом коде тип у stolen например на *const std::sync::MutexGuard<'_, usize> и гарантии вдруг резко куда-то пропадут... )
Да, указатель можно сохранить (достаточно "*const usize"), вот только воспользоваться ты им без "unsafe" не сумеешь.
_>Лично меня больше раздражает не необходимость следования моделям borrow checker (они в принципе довольно разумные, а для C++ программиста, привыкшего к работе с умными указателями, вообще кажутся родными), а слишком большое количество пустой писанины ради обеспечения его работы.
_>Вообще даже смешно становится: синтаксис самого языка вроде как сделали максимально лаконичным (все эти fn, let, mut и т.п.), но при этом реальный код выглядит намного более громоздким чем даже C++ или Java, как раз из-за необходимости громоздить дикие типы на пустом месте.
Не замечал такого. Да, поначалу было непривычно иметь что-нибудь типа Option<Box<Data>>, но я бы не назвал это "дикими типами". Наверняка где-нибудь у нас есть и 5-6 вложенных типов, но это редкость (и скорее от лени, когда вместо структур HashMap на HashMap наворочено).
Здравствуйте, alex_public, Вы писали:
_>Большая доля правды в этом конечно же есть, но не до абсолютных значений (о которых говорят в терминах гарантий и про которые говорил WolfHound).
Не используй unsafe и будут абсолютные.
Ты так и не показал, как обойти гарантии, которые даёт rust без unsafe.
_>Только вот например следование такой простой схеме реализации многопоточности, как "модель акторов", тоже по сути гарантирует отсутствие большинства ошибок многопоточности. Причём в любом языке — для её реализации не требуются какие-то хитрые механизмы. Соответственно возникает вопрос — а стоят ли все эти усилия того? Т.е. не слишком ли велика цена за достаточно элементарные вкусности, которые можно получить и другими способами... Это я уже не по поводу вопроса к WolfHound, а просто рассуждаю о том стоит ли применять Rust или нет.
В большинстве языков эта модель ничего не гарантирует. А в тех, где гарантирует там либо копирование каждого сообщения. Либо типы ещё веселее, чем в rust. Pony передаёт привет.
Вот в rust можно сделать акторы с гарантиями и без копирования сообщений.
И в отличие от пони можно и без акторов. Например, через такую штуку: https://github.com/jonhoo/rust-evmap
Там кстати алгоритм позволяет сделать такое с любой структурой данных, а не только со словарём.
_>Лично меня больше раздражает не необходимость следования моделям borrow checker (они в принципе довольно разумные, а для C++ программиста, привыкшего к работе с умными указателями, вообще кажутся родными), а слишком большое количество пустой писанины ради обеспечения его работы.
Ты так и не показал эту писанину.
_>Вообще даже смешно становится: синтаксис самого языка вроде как сделали максимально лаконичным (все эти fn, let, mut и т.п.), но при этом реальный код выглядит намного более громоздким чем даже C++ или Java, как раз из-за необходимости громоздить дикие типы на пустом месте.
Что-то я это не заметил. У меня код получается почти как на немерле.
... << RSDN@Home 1.0.0 alpha 5 rev. 0>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, WolfHound, Вы писали:
WH>>>BC не даёт новые возможности. Он исключает ошибки. _>>Это понятно. Но интересует конкретный пример ошибки реализации многопоточности, которую можно выявить в Rust и невозможно в других языках. WH>Я уже давал ссылку. WH>https://blog.faraday.io/saved-by-the-compiler-parallelizing-a-loop-with-rust-and-rayon/ WH>Покажи мне язык, который на этапе компиляции может такое поймать. Мне правда интересно.
Статья максимально наигранная. Ну не могу я поверить, что даже студент способен на такой подход — максимум школьник. Типа переходим к многопоточности с помощью замены цикла for на parallel_for, без всякой ревизии кода внутри цикла. Серьёзно? ))) И потом конечно же с гордым видом сообщить, что Rust спас меня тут от "совершенно неожиданной" ошибки.
WH>>>В других языках у тебя нет гарантии, что кто-то случайно не сохранит ссылку на защищаемый мютексом объект. _>>Ну на самом деле у тебя и в Rust'е нет таких гарантий. WH>Код в студию. WH>Положи объект в мьютекс и попробуй получить доступ к нему или его части не под блокировкой без использования unsafe. WH>После того как несколько часов побьёшься головой о каменную стену поймёшь почему люди говорят что rust хороший язык.
Посмотри моё сообщение Ивану выше.
_>>Это скорее в каком-нибудь Питоне можно их получить, внедрив защиту мьютексом не в виде объекта-контейнера, а вставив её непосредственно в сам защищаемый тип данных (модифицировав его конкретный экземпляр). WH>Многопоточность? В питоне? GIL передаёт привет.
Эм, мы же вроде обсуждали тут безопасность, а не быстродействие. Или по твоему GIL как-то мешает безопасности? )
WH>>>В других языках обычно мьютекс даже не связан с данными. Вся многопоточность чисто на внимательность программиста завязана. _>>Потому что в большинстве случаев синхронизация завязывается не на куски данных, а на куски кода. Это более логично и востребовано, т.к. код редко работает только с одной переменной (собственно для одной правильнее использовать atomic и т.п.). WH>Ты же сам пишешь про работу с конкретным набором данных. WH>Просто в rust данные нужно положить в один объект.
Так а зачем плодить лишнюю сущность? Только ради того, что Rust по другому не умеет? )
_>>Однако если есть желание заблокировать на уровне доступа к некой переменной, то с этим очевидно тоже никаких проблем нет — просто реализуем соответствующий тип-контейнер. Собственно в примере Rust'а так и сделано и нет никаких проблем с подобным (ну с поправкой на автоматизацию разблокировки из-за наличия в языке RAII) же в любых других языках. WH>Под контейнером ты подразумеваешь объект, в котором все поля приватные. А все публичные методы первым делом захватывают мьютекс? WH>Если да то в других языках это решение всё равно не даёт никаких гарантий. WH>Что бы будешь делать, если тебе нужно сделать несколько операций под мьютексом? А если тебе нужно два объекта заблокировать и перекинуть данные между ними? WH>В случае с rust проблем не будет. Ибо мьтекс живёт снаружи объекта. Объект в общем случае даже не знает, что его в многопоточном коде используют.
Нет, я имею в виду точной такой же код, как и в Rust'е. Он же точной такой же пишется на всех языках. Разве что в тех, в которых нет RAII, придётся вызывать функцию отпускания mutex'а руками. Это если говорить о статических языках. В динамических (типа Питона) мы можем модифицировать не только какой-то тип, но и конкретный объект (экземпляр типа), вставив проверки на захваченный мьютекс перед любым обращением к объекту.
Хотя на практике подобные параноидальные проверки никто не использует — гораздо больший эффект даёт следование более высокоуровневым подходам к многопоточности, в которой синхронизация мьютексами даже не рассматривается.
Здравствуйте, Иван Дубров, Вы писали:
ИД>>>Borrow checker тебе не позволит держать ссылку на защищаемые мьютексом данные дольше, чем ты будешь удерживать мьютекс. ИД>>>Пример. _>>Ну замени в этом коде тип у stolen например на *const std::sync::MutexGuard<'_, usize> и гарантии вдруг резко куда-то пропадут... ) ИД>Да, указатель можно сохранить (достаточно "*const usize"), вот только воспользоваться ты им без "unsafe" не сумеешь.
Ну так в Rust'е то unsafe очень комфортный. Там не то, что специальную опцию компилятора для этого не надо ставить, но и даже не требуется менять объявления функций/классов — можно просто один маленький незаметный блок поставить. Типа:
Да, и главное, что этот код может находиться в совсем другом модуле приложения, которое пишется совсем другим человеком (т.е. реально "захват" ссылки на глобальную переменную без мьютекса происходить без всякого unsafe). Вот почему-то не сомневаюсь, что всяческие "индусы" будут использовать именно такой метод борьбы с компилятором. )))
_>>Лично меня больше раздражает не необходимость следования моделям borrow checker (они в принципе довольно разумные, а для C++ программиста, привыкшего к работе с умными указателями, вообще кажутся родными), а слишком большое количество пустой писанины ради обеспечения его работы. _>>Вообще даже смешно становится: синтаксис самого языка вроде как сделали максимально лаконичным (все эти fn, let, mut и т.п.), но при этом реальный код выглядит намного более громоздким чем даже C++ или Java, как раз из-за необходимости громоздить дикие типы на пустом месте. ИД>Не замечал такого. Да, поначалу было непривычно иметь что-нибудь типа Option<Box<Data>>, но я бы не назвал это "дикими типами". Наверняка где-нибудь у нас есть и 5-6 вложенных типов, но это редкость (и скорее от лени, когда вместо структур HashMap на HashMap наворочено).
О, ты хотя бы совершенно правильно понял, о чём именно я писал. А то некоторые слишком ярые фанаты языка даже делают вид, что не понимают о чём я. Ну а что касается того, раздражает это или нет — это уже дело вкуса. Личной для меня это ощущается как излишний синтаксический мусор...
Здравствуйте, WolfHound, Вы писали:
_>>Большая доля правды в этом конечно же есть, но не до абсолютных значений (о которых говорят в терминах гарантий и про которые говорил WolfHound). WH>Не используй unsafe и будут абсолютные. WH>Ты так и не показал, как обойти гарантии, которые даёт rust без unsafe.
Эм, какие гарантии?
_>>Только вот например следование такой простой схеме реализации многопоточности, как "модель акторов", тоже по сути гарантирует отсутствие большинства ошибок многопоточности. Причём в любом языке — для её реализации не требуются какие-то хитрые механизмы. Соответственно возникает вопрос — а стоят ли все эти усилия того? Т.е. не слишком ли велика цена за достаточно элементарные вкусности, которые можно получить и другими способами... Это я уже не по поводу вопроса к WolfHound, а просто рассуждаю о том стоит ли применять Rust или нет. WH>В большинстве языков эта модель ничего не гарантирует. А в тех, где гарантирует там либо копирование каждого сообщения. Либо типы ещё веселее, чем в rust. Pony передаёт привет.
Эээ что? Ты вообще в курсе модели акторов? Если ей следовать, то просто гарантированно не будет одновременно разделяемых между потоками данных. Конечно для некоторых специфических задач это не очень применимо, по причинам быстродействия (всё же расшаренные мутабельные данные иногда бывают самым эффективным решением). Но если уж по быстродействию модель акторов подходит, то безопасность она гарантирует.
WH>Вот в rust можно сделать акторы с гарантиями и без копирования сообщений.
Эээ, копирование? У тебя похоже вообще странное представление о подобном коде.
WH>И в отличие от пони можно и без акторов. Например, через такую штуку: WH>https://github.com/jonhoo/rust-evmap WH>Там кстати алгоритм позволяет сделать такое с любой структурой данных, а не только со словарём.
Ох, показывать обычные локфри структурки, как нечто особенное. Тем более с такой наивной демонстрацией производительности. Вот например https://habr.com/ru/post/328374/ как следует разбирать подобные сложные темы. В которых без чётко указанных особенностей конкретной задачи, просто нельзя говорить о том, какое решение более эффективно.
_>>Лично меня больше раздражает не необходимость следования моделям borrow checker (они в принципе довольно разумные, а для C++ программиста, привыкшего к работе с умными указателями, вообще кажутся родными), а слишком большое количество пустой писанины ради обеспечения его работы. WH>Ты так и не показал эту писанину.
Вот Иван прекрасно понял о чём я, и даже сам показал примеры этого дела. Правда он сказал, что его подобное не раздражает — ну это дело вкуса видимо...
_>>Вообще даже смешно становится: синтаксис самого языка вроде как сделали максимально лаконичным (все эти fn, let, mut и т.п.), но при этом реальный код выглядит намного более громоздким чем даже C++ или Java, как раз из-за необходимости громоздить дикие типы на пустом месте. WH>Что-то я это не заметил. У меня код получается почти как на немерле.
Ну может у тебя весь код представляет собой одну гигантскую функцию, без всякого структурирования — тогда действительно будет не так много мест, для написания этих диких типов (разве что там, где автовывод не используется).
Здравствуйте, alex_public, Вы писали:
WH>>Не используй unsafe и будут абсолютные. WH>>Ты так и не показал, как обойти гарантии, которые даёт rust без unsafe. _>Эм, какие гарантии?
Гарантии отсутствия гонок. Гарантии корректного освобождения памяти. Гарантии отсутствия доступа к освобождённой памяти.
Сможешь показать, как нарушить их без unsafe?
WH>>В большинстве языков эта модель ничего не гарантирует. А в тех, где гарантирует там либо копирование каждого сообщения. Либо типы ещё веселее, чем в rust. Pony передаёт привет. _>Эээ что? Ты вообще в курсе модели акторов? Если ей следовать, то просто гарантированно не будет одновременно разделяемых между потоками данных.
Я-то в курсе. А вот ты, похоже, что чисто теоретик, который поверхностных статей начитался.
Для того чтобы получить гарантии нужно либо глубокое копирование сообщений как это сделано например в ерланге. Либо очень кучерявая система типов и специализированный сборщик мусора как это сделано в пони. Либо какая-то другая навороченная система типов типа BC из rust'а.
_>Конечно для некоторых специфических задач это не очень применимо, по причинам быстродействия (всё же расшаренные мутабельные данные иногда бывают самым эффективным решением). Но если уж по быстродействию модель акторов подходит, то безопасность она гарантирует.
Например С++ный SObjectizer ничего не гарантирует. Показать тебе как там гонки устроить или сам догадаешься?
_>Эээ, копирование? У тебя похоже вообще странное представление о подобном коде.
В отличие от тебя у меня есть понимание нескольких вариантов того как оно может быть реализовано на низком уровне.
_>Ох, показывать обычные локфри структурки, как нечто особенное.
Я не показывал это как нечто особенное.
Просто эта штука не совместима с некоторыми методами реализации модели акторов.
_>Тем более с такой наивной демонстрацией производительности. Вот например https://habr.com/ru/post/328374/ как следует разбирать подобные сложные темы. В которых без чётко указанных особенностей конкретной задачи, просто нельзя говорить о том, какое решение более эффективно.
И что там такого наивного? Там честно расписаны сценарии, когда эта структура ведёт себя хорошо. И когда не очень. Например, в сценарии, когда преобладает запись она хуже, чем chashmap. Но я из своей практики не могу вспомнить сценарии, когда преобладает запись. Обычно чтений в десятки, если не сотни раз больше.
Прежде чем оценивать тесты этой структуры нужно понять, что на чтение блокировок нет вообще. Там даже атомиков нет. Только три барьера памяти и несколько операций с целыми числами.
_>Вот Иван прекрасно понял о чём я, и даже сам показал примеры этого дела. Правда он сказал, что его подобное не раздражает — ну это дело вкуса видимо...
А ничего что в твоём любимом С++, если писать правильно, типы получаются намного длиннее? Или ты из тех, кто на голых указателях работает?
... << RSDN@Home 1.0.0 alpha 5 rev. 0>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, alex_public, Вы писали:
_>Статья максимально наигранная. Ну не могу я поверить, что даже студент способен на такой подход — максимум школьник. Типа переходим к многопоточности с помощью замены цикла for на parallel_for, без всякой ревизии кода внутри цикла. Серьёзно? ))) И потом конечно же с гордым видом сообщить, что Rust спас меня тут от "совершенно неожиданной" ошибки.
Серьёзно. Так и нужно делать. Компилятор железный. И имеет абсолютную внимательность. Для него проверить весь код тривиальная задача. А для человека нет. Человеку на такой анализ в большой кодовой базе понадобятся дни. И то не будет гарантии, что он что-то не пропустит. Более того внесение изменений, обычно другим человеком через год, тоже будет хождением по минному полю.
Ты просто привык к тупым языкам, которые такое поймать не могут. Вот тебя такой подход и шокирует.
_>>>Это скорее в каком-нибудь Питоне можно их получить, внедрив защиту мьютексом не в виде объекта-контейнера, а вставив её непосредственно в сам защищаемый тип данных (модифицировав его конкретный экземпляр). WH>>Многопоточность? В питоне? GIL передаёт привет. _>Эм, мы же вроде обсуждали тут безопасность, а не быстродействие. Или по твоему GIL как-то мешает безопасности? )
А если нет производительности то нафига многопоточность? Да и гарантий на самом деле тоже нет.
WH>>Ты же сам пишешь про работу с конкретным набором данных. WH>>Просто в rust данные нужно положить в один объект. _>Так а зачем плодить лишнюю сущность? Только ради того, что Rust по другому не умеет? )
Я вообще не могу вспомнить из своей практики случая, когда нужно было защищать только часть объекта. Так что если она и лишняя, то в настолько редких случаях что ими можно пренебречь.
Но зато у нас есть гарантии корректной работы с мьютексом.
_>Нет, я имею в виду точной такой же код, как и в Rust'е. Он же точной такой же пишется на всех языках. Разве что в тех, в которых нет RAII, придётся вызывать функцию отпускания mutex'а руками. Это если говорить о статических языках. В динамических (типа Питона) мы можем модифицировать не только какой-то тип, но и конкретный объект (экземпляр типа), вставив проверки на захваченный мьютекс перед любым обращением к объекту.
Что-то я совсем перестал понимать, о чём ты говоришь. Код покажи.
... << RSDN@Home 1.0.0 alpha 5 rev. 0>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, WolfHound, Вы писали:
_>>Конечно для некоторых специфических задач это не очень применимо, по причинам быстродействия (всё же расшаренные мутабельные данные иногда бывают самым эффективным решением). Но если уж по быстродействию модель акторов подходит, то безопасность она гарантирует. WH>Например С++ный SObjectizer ничего не гарантирует. Показать тебе как там гонки устроить или сам догадаешься?
