Здравствуйте, so5team, Вы писали:

S>>>Если ей следовать, то не будет. Передача ссылок на разделямые мутабельные данные в сообщения -- это не следование модели акторов, а нарушение ее основных постулатов.
WH>>А как убедиться, что ты ей следуешь?
S>Так же, как и в случае, когда в Rust вынуждены прибегать к unsafe.
Не путай несколько строк на программу и весь код.
При этом думаю, что со временем будет написано достаточно библиотек, чтобы unsafe в прикладном коде стал вообще не нужен.

S>В C++ помогает наличие const-а.
Не помогает. Совсем.

S>В D есть invariant.
Как он может помочь?

S>Как только вы к себе в код затягивате что-то с unsafe внутри, все хваленые гарантии Rust-а, по сути, превращаются в "мамой клянусь". Т.к. корректность вашего кода оказывается в зависимости от качества тестирования того же rust-evmap.
Ещё раз. Не путай несколько строк, которые нужно проверить.
В когда вообще весь код минное поле.
Неважно что ты сделаешь но ты не сможешь изолировать unsafe операции внутри SObjectizer'а. Ибо С++ не имеет нужных возможностей.
А вот если ты перепишешь его на rust, то можно сделать, так что в прикладном коде не будет ни одного unsafe.

Здравствуйте, WolfHound, Вы писали:

WH>Не путай несколько строк на программу и весь код.

Не путаю. А вот у вас очевидные двойные стандарты: если не Rust, то подавай гарантии. А если Rust, то даже наличие непроверяемых unsafe под капотом обеспечивает 100% гарантию. Вы уж либо крестик...

S>>В C++ помогает наличие const-а.
WH>Не помогает. Совсем.

Помогает. Не защищает, но помогает.

S>>В D есть invariant.
WH>Как он может помочь?

Обеспечивает реальную иммутабельность. Причем транзитивную. Нет проблем передавать в сообщениях invariant-ссылки, да и сами сообщения могут быть invariant-объектами. И не будет у вас разделяемых данных.

И да, в своей ажитации Rust-ом вы несколько забыли предмет разговора. При использовании акторов проверять придется лишь места отсылки сообщений. Точнее даже не места отсылки, а содержимое сообщений. Если в них находятся только value-type, то проблем нет вообще. Если в них передаются объекты типа unique_ptr (т.е. передача владения единственной ссылкой), то проблем нет. А поскольку в реальном коде на акторах типов сообщений не так, чтобы уж сильно много, да и места их отсылки/приема легко локализуются, то контролировать все это не так уж и сложно. Поэтому, на практике, в каких-то задачах "модель акторов даст пользователю удобство и безопасность, которую пользователь не получит работая с разделяемыми данными вручную". Гарантий при этом в C++/Java/Scala/Kotlin/C# не будет, но и проблем каких-то значительных так же не будет.

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

Здравствуйте, so5team, Вы писали:

WH>>Не путай несколько строк на программу и весь код.
S>Не путаю. А вот у вас очевидные двойные стандарты: если не Rust, то подавай гарантии. А если Rust, то даже наличие непроверяемых unsafe под капотом обеспечивает 100% гарантию. Вы уж либо крестик...
Жизнь такова что у нас всегда есть некоторый код которому мы вынуждены доверять.
Компилятор, стандартная библиотека, ОС,...
В случае с С++ у нас к этому добавляется весь прикладной код.
В случае с rust весь прикладной код и почти весь библиотечный код проверяется на вшивость компилятором.
Так что нет никаких двойных стандартов.

Здравствуйте, reversecode, Вы писали:

C>>Mozilla Firefox, однако. На Расте написаны части движка.
R>я об этом в курсе, к сожалению уныло и хреново
R>тормозилла у меня всегда тормозила
Мозилла работает быстрее Хрома на многих тестах.

R>и съедает памяти на трех табах столько же сколько хром на сотне
R>последствия раста ?
Мозилла однозначно использует меньше памяти, чем Хром.

R>вообщем я к чему веду, поскольку раст ни в каком крупном юзерском софте особо не засветился
Firecracker от Амазона, linkerd для кластеров — это то, что я сам использую.

Здравствуйте, WolfHound, Вы писали:

_>>Эм, какие гарантии?
WH>Гарантии отсутствия гонок.

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

WH>Гарантии корректного освобождения памяти. Гарантии отсутствия доступа к освобождённой памяти.

Да, это есть. Точно так же как и в 90% используемых сейчас языков. За исключением разве что совсем древних, типа Fortran, C и т.п. Так что не вижу особого смысла гордиться этим простейшим фактом. Хотя лично мне конечно же нравится конкретный подход, используемый в Rust для решения этой задачи. Но он опять же сильно вторичен и использовался в других языках.

WH>Сможешь показать, как нарушить их без unsafe?

А откуда взялось это требование, про "без unsafe"? Ведь оно же по сути ничем не отличается скажем от аналогичного запрета на использование в C++ проекте (ну или опять же в большей его части) голых указателей и т.п.. И то и то является административным запретом, который контролируется ревью кода или даже возможно статическими анализаторами. Но в любом случае в своей первооснове это административное ограничение на использование опасных (но иногда нужных) техник языка. Так в чём ты видишь тут концептуальное отличие именно Rust'а?

WH>>>В большинстве языков эта модель ничего не гарантирует. А в тех, где гарантирует там либо копирование каждого сообщения. Либо типы ещё веселее, чем в rust. Pony передаёт привет.
_>>Эээ что? Ты вообще в курсе модели акторов? Если ей следовать, то просто гарантированно не будет одновременно разделяемых между потоками данных.
WH>Я-то в курсе. А вот ты, похоже, что чисто теоретик, который поверхностных статей начитался.
WH>Для того чтобы получить гарантии нужно либо глубокое копирование сообщений как это сделано например в ерланге. Либо очень кучерявая система типов и специализированный сборщик мусора как это сделано в пони. Либо какая-то другая навороченная система типов типа BC из rust'а.

Я смотрю ты кажется понял ошибочность своего спора с моим тезисом и пытаешься понемногу сместить акцент в другую сторону. Смотри, мой тезис был: "если следовать модели акторов (это предусловие, не важно как достигаемое!), то это устранит все классические проблемы многопоточности (результат)". Ты с этим начал спорить, но похоже что сейчас до тебя дошло, что ты не прав. И теперь ты пытаешься перевести разговор на то, можно ли гарантировать на уровне компилятора следование модели акторов в разных языках или нет. Как будто бы это кто-то обещал или вообще обсуждал.

_>>Конечно для некоторых специфических задач это не очень применимо, по причинам быстродействия (всё же расшаренные мутабельные данные иногда бывают самым эффективным решением). Но если уж по быстродействию модель акторов подходит, то безопасность она гарантирует.
WH>Например С++ный SObjectizer ничего не гарантирует. Показать тебе как там гонки устроить или сам догадаешься?

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

_>>Эээ, копирование? У тебя похоже вообще странное представление о подобном коде.
WH>В отличие от тебя у меня есть понимание нескольких вариантов того как оно может быть реализовано на низком уровне.

Ну давай, поделись своими гениальными пониманиями. )))

Я вот к примеру реализовывал полноценную модель акторов на банальных системных потоках (createthread) и системных очередях (postmessage) винды. Причём занимало это десяток строчек (естественно это была не универсальная внешняя библиотека и даже не выделенный модуль внутри приложения, а просто определённая архитектура), но при этом обладало всеми гарантиями корректности многопоточности. Да, и никаких копирований там не наблюдалось.

_>>Ох, показывать обычные локфри структурки, как нечто особенное.
WH>Я не показывал это как нечто особенное.
WH>Просто эта штука не совместима с некоторыми методами реализации модели акторов.

Вообще говоря при использование модели акторов, подобные штуки не нужны в принципе. Они появляются только в том случае, если нам начинает нехватать быстродействия модели акторов и есть желание перейти неким глобальным мутабельным данным (причём управляемые не мьютексами, а через CAS).

_>>Тем более с такой наивной демонстрацией производительности. Вот например https://habr.com/ru/post/328374/ как следует разбирать подобные сложные темы. В которых без чётко указанных особенностей конкретной задачи, просто нельзя говорить о том, какое решение более эффективно.
WH>И что там такого наивного? Там честно расписаны сценарии, когда эта структура ведёт себя хорошо. И когда не очень. Например, в сценарии, когда преобладает запись она хуже, чем chashmap. Но я из своей практики не могу вспомнить сценарии, когда преобладает запись. Обычно чтений в десятки, если не сотни раз больше.

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

_>>Вот Иван прекрасно понял о чём я, и даже сам показал примеры этого дела. Правда он сказал, что его подобное не раздражает — ну это дело вкуса видимо...
WH>А ничего что в твоём любимом С++, если писать правильно, типы получаются намного длиннее? Или ты из тех, кто на голых указателях работает?

Нет, получаются короче. Потому как минимум один уровень "контейнеров" в Rust'е возникает обычно из-за BC.

Да, и кстати, у тебя вообще-то какое-то странное восприятие меня в данной дискуссии. Ты похоже считаешь меня любителем концепций C++ и при этом противником концепций Rust'а. В то время как это невозможно — концепции по сути одни и те же. Более того, на тему Rust'а (а так же D и Nim) я писал на этом форуме в контексте поиска замены C++ задолго до того, как ты начал упоминать этот язык. )))

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

Здравствуйте, WolfHound, Вы писали:

ИД>>Угу. Я опрашивал разных людей, которые тусят в Rust community (да и в твиттере пробегают срачи регулярно) и регулярно общаются с C/C++ коллегами. У C/C++ программистов в массе почему-то сразу какой-то защитный механизм включается и аргументы в стиле "да я все свои границы всегда проверяю", "код внимательно проверяю".
WH>Ещё я заметил очень сильную корреляцию между людьми которые считают что могут писать надёжный код на С/С++ и любителями динамической типизации.
WH>В обоих случаях компилятор мало что контролирует и оставляет всё на внимательность программиста.
WH>Видимо мы имеем дело с мачо-программистами, которые действительно верят в то, что они могут за всем уследить. Они реально считают, что контроль компилятора им не нужен. И все эти системы типов только мешают полёту их фантазии и заставляют писать лишние буквы.

Некоторые люди не возводят отсутствие багов в абсолют. Код без багов имеет определённую цену и не все готовы её платить. Эти лишние буквы выливаются в лишние часы работы, в сорванные дедлайны. А баги ни во что не выливаются. Есть баг — пофиксил. А может и не пофиксил, если это мелочь какая-то. 99.999% программистов не пишут софт для марсоходов и искусственных сердец.

Поэтому выбор между языками не так однозначен, так же, как и выбор в пользу, например, 100% покрытия кода тестами (или вообще в написание хоть каких-то тестов). Это всё по сути плата за уменьшение числа багов. И в каждом проекте она своя. Код на JS, по крайней мере до какого-то момента писать проще, чем на TypeScript, например. Код на Rust уж точно сложней писать, чем код на C++.

C>>>Mozilla Firefox, однако. На Расте написаны части движка.

R>>я об этом в курсе, к сожалению уныло и хреново
R>>тормозилла у меня всегда тормозила

C>Мозилла работает быстрее Хрома на многих тестах.
C>Мозилла однозначно использует меньше памяти, чем Хром.

это в какой то видимо другой галактике или в десятом измерении
но в 2019 году, на планете земля, это совершенно не так как вы говорите

Здравствуйте, vsb, Вы писали:

vsb>на Rust уж точно сложней писать, чем код на C++.

Не подтверждается моим опытом (не личным, а работы в команде с совершенно разными уровнями разработчиков).

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

Самый криминал -- это постоянные ".clone()" и ".to_string()".

Здравствуйте, WolfHound, Вы писали:

_>>Статья максимально наигранная. Ну не могу я поверить, что даже студент способен на такой подход — максимум школьник. Типа переходим к многопоточности с помощью замены цикла for на parallel_for, без всякой ревизии кода внутри цикла. Серьёзно? ))) И потом конечно же с гордым видом сообщить, что Rust спас меня тут от "совершенно неожиданной" ошибки.
WH>Серьёзно. Так и нужно делать. Компилятор железный. И имеет абсолютную внимательность. Для него проверить весь код тривиальная задача. А для человека нет. Человеку на такой анализ в большой кодовой базе понадобятся дни. И то не будет гарантии, что он что-то не пропустит. Более того внесение изменений, обычно другим человеком через год, тоже будет хождением по минному полю.
WH>Ты просто привык к тупым языкам, которые такое поймать не могут. Вот тебя такой подход и шокирует.

Если ты реально считаешь, что Rust даёт гарантии отсутствия гонок, то у меня для тебя неприятные новости... Причём насчёт твоей квалификации в данной теме в целом.

WH>>>Многопоточность? В питоне? GIL передаёт привет.
_>>Эм, мы же вроде обсуждали тут безопасность, а не быстродействие. Или по твоему GIL как-то мешает безопасности? )
WH>А если нет производительности то нафига многопоточность? Да и гарантий на самом деле тоже нет.

Производительности там нет относительно какого-нибудь C++ и т.п. А производительность многопоточного Питона очевидно лучше, чем однопоточного. Так что смысл очень даже есть.

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

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

WH>>>Ты же сам пишешь про работу с конкретным набором данных.
WH>>>Просто в rust данные нужно положить в один объект.
_>>Так а зачем плодить лишнюю сущность? Только ради того, что Rust по другому не умеет? )
WH>Я вообще не могу вспомнить из своей практики случая, когда нужно было защищать только часть объекта. Так что если она и лишняя, то в настолько редких случаях что ими можно пренебречь.
WH>Но зато у нас есть гарантии корректной работы с мьютексом.

Какая ещё часть объекта? Понятно же, что под набором данных подразумевался не кусок какого-то объекта, а наоборот набор разных — на практике только так и встречается собственно. И для реализации автоматического доступа через мьютекс к этим данным, тебе придётся добавить лишний тип, агрегирующий в себя все эти объекты (а так же переписать везде код, чтобы доступ был только через экземпляр этого нового типа). Более того, с учётом специфики Rust'а, у тебя ещё возникнут сложности в случае неравного времени жизни (а это тоже очень даже вероятный сценарий) этих объектов.

_>>Нет, я имею в виду точной такой же код, как и в Rust'е. Он же точной такой же пишется на всех языках. Разве что в тех, в которых нет RAII, придётся вызывать функцию отпускания mutex'а руками. Это если говорить о статических языках. В динамических (типа Питона) мы можем модифицировать не только какой-то тип, но и конкретный объект (экземпляр типа), вставив проверки на захваченный мьютекс перед любым обращением к объекту.
WH>Что-то я совсем перестал понимать, о чём ты говоришь. Код покажи.

Ну открой код Rust'а и посмотри — просто контейнер, агрегирующий некий объект и возвращающий ссылку на него по функции Lock, в случае языков без RAII. А в случае наличия RAII в языке, будем возвращать специальный объект для автоматического отпускания мьютекса, точно так же, как и в Rust.

Здравствуйте, reversecode, Вы писали:

C>>Мозилла работает быстрее Хрома на многих тестах.
C>>Мозилла однозначно использует меньше памяти, чем Хром.
R>это в какой то видимо другой галактике или в десятом измерении
R>но в 2019 году, на планете земля, это совершенно не так как вы говорите
https://www.pcworld.com/article/3213031/best-web-browsers.html?page=2

Здравствуйте, WolfHound, Вы писали:

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

Извините что встреваю в такой восхитительный срач, а ты случаем не тот РСДН-ер, что в приблизительно аналогичной агрессивной форме за Немерле топил, пока бобик не сдох?

Здравствуйте, alex_public, Вы писали:

_>Ну этого естественно нет ни в каком из существующих языков. Более того, гонки могут возникнуть даже в однопоточном коде, причём развивающаяся популярность использования сопрограмм, существенно умножает этот ранее редкий случай. И никакими средствами, кроме использования мозга, эти проблемы не решить. Ну во всяком случае во всех существующих сейчас концепциях промышленного ПО.
Ты начал очень широко трактовать гонки.
Тут речь шла про доступ к разделяемой памяти из нескольких потоков без надлежащей синхронизации.

_>Да, это есть. Точно так же как и в 90% используемых сейчас языков. За исключением разве что совсем древних, типа Fortran, C и т.п.
Не забывай про С++.
Там часто хрен поймешь, кто память должен освобождать, не читая документацию.

_>Так что не вижу особого смысла гордиться этим простейшим фактом. Хотя лично мне конечно же нравится конкретный подход, используемый в Rust для решения этой задачи. Но он опять же сильно вторичен и использовался в других языках.
Не такой уж он и простейший.

WH>>Сможешь показать, как нарушить их без unsafe?
_>А откуда взялось это требование, про "без unsafe"?
Оттуда что ты отключаешь контроль компилятора. А если ты его отключил то, какие вопросы к компилятору?

_>Ведь оно же по сути ничем не отличается скажем от аналогичного запрета на использование в C++ проекте (ну или опять же в большей его части) голых указателей и т.п.. И то и то является административным запретом, который контролируется ревью кода или даже возможно статическими анализаторами. Но в любом случае в своей первооснове это административное ограничение на использование опасных (но иногда нужных) техник языка. Так в чём ты видишь тут концептуальное отличие именно Rust'а?
В том что даже если в С++ запретить голые указатели он всё равно ничего не гарантирует.
А rust без unsafe безопасен.

_>Я смотрю ты кажется понял ошибочность своего спора с моим тезисом и пытаешься понемногу сместить акцент в другую сторону. Смотри, мой тезис был: "если следовать модели акторов (это предусловие, не важно как достигаемое!), то это устранит все классические проблемы многопоточности (результат)".
"если следовать модели мьютексов (это предусловие, не важно как достигаемое!), то это устранит все классические проблемы многопоточности (результат)"


_>Ты с этим начал спорить, но похоже что сейчас до тебя дошло, что ты не прав. И теперь ты пытаешься перевести разговор на то, можно ли гарантировать на уровне компилятора следование модели акторов в разных языках или нет. Как будто бы это кто-то обещал или вообще обсуждал.
Я всегда именно это и говорил.
Либо глубокое копирование. Erlang.
Либо кучерявая система типов. Rust, pony.
Либо язык ничего не гарантирует. Почти все остальные языки.
Вот с чего всё началось:

WH>>>>В большинстве языков эта модель ничего не гарантирует. А в тех, где гарантирует там либо копирование каждого сообщения. Либо типы ещё веселее, чем в rust. Pony передаёт привет.

_>С учётом того, что на протяжение большого числа сообщений в дискуссии с so5team, ты так и не смог ничего показать, думаю мне не стоит продолжать этот очевидный спор. )))
У тебя проблемы с пониманием написанного?

WH>При том что ни он ни С++ не защищают от того что пользователь сделат это случайно.

Соответственно, SObjectizer вообще не причем, т.к. он не может привнести в C++ качества, которых в C++ нет и не может быть в принципе.

(С)

Автор: so5team
Дата: 08.05.19

Вполне конкретное признание того что SObjectizer от проблем не защищает.

_>Я вот к примеру реализовывал полноценную модель акторов на банальных системных потоках (createthread) и системных очередях (postmessage) винды. Причём занимало это десяток строчек (естественно это была не универсальная внешняя библиотека и даже не выделенный модуль внутри приложения, а просто определённая архитектура), но при этом обладало всеми гарантиями корректности многопоточности. Да, и никаких копирований там не наблюдалось.
Как минимум часть этих утверждений ложна.
Скорей всего не было там никаких гарантий и всё держалось на внимательности программиста.

_>Вообще говоря при использование модели акторов, подобные штуки не нужны в принципе. Они появляются только в том случае, если нам начинает нехватать быстродействия модели акторов и есть желание перейти неким глобальным мутабельным данным (причём управляемые не мьютексами, а через CAS).
В случае с rust нам ничто не мешает использовать и то и другое.

_>Наивность там в самом подходе в построение отчётности (посмотри на графики повнимательнее). Но я не хочу влезать сейчас в эту тему, потому как lock-free структуры уж точно не имеют никакого отношения к обсуждаемому нами вопросу.
Понятно. Сказать нечего, но очень хочется.

_>Нет, получаются короче. Потому как минимум один уровень "контейнеров" в Rust'е возникает обычно из-за BC.
Только не нужно рассказывать это тому, кто на обоих языках писал. В С++ без контейнеров вообще жить нельзя. А в rust в большинстве случаев голые ссылки.
А твои претензии к Option вообще абсурдны. Nullable типов вообще быть не должно. Они сами по себе большая проблема.

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

Здравствуйте, alex_public, Вы писали:

_>Если ты реально считаешь, что Rust даёт гарантии отсутствия гонок, то у меня для тебя неприятные новости... Причём насчёт твоей квалификации в данной теме в целом.
Код в студию. Покажи, как без unsafe получить доступ к памяти без надлежащей синхронизации.

_>Ну и гарантии естественно есть. Разве что они рантаймовые — будет сообщение об ошибке, в случае попытки доступа не под мьютексом.
Вот тут давай объясняй, как питон это делает.
Звучит, как самолёты подлетают к границе и падают.

_>Какая ещё часть объекта? Понятно же, что под набором данных подразумевался не кусок какого-то объекта, а наоборот набор разных — на практике только так и встречается собственно. И для реализации автоматического доступа через мьютекс к этим данным, тебе придётся добавить лишний тип, агрегирующий в себя все эти объекты (а так же переписать везде код, чтобы доступ был только через экземпляр этого нового типа). Более того, с учётом специфики Rust'а, у тебя ещё возникнут сложности в случае неравного времени жизни (а это тоже очень даже вероятный сценарий) этих объектов.
Давай про свою практику рассказывай подробнее. Ибо в моей практике такое не встречалось вообще ни разу. Всегда разделяемые данные естественным образом оказывались в одном объекте.
Особенно интересует пример, в котором объекты под мьютексом живут разное время.

_>Ну открой код Rust'а и посмотри — просто контейнер, агрегирующий некий объект и возвращающий ссылку на него по функции Lock, в случае языков без RAII. А в случае наличия RAII в языке, будем возвращать специальный объект для автоматического отпускания мьютекса, точно так же, как и в Rust.
Да причем тут вообще RAII?
Я не понимаю, как ты работу с мьютексами организуешь. RAII это мелкие детали реализации.
Сначала я подумал, что ты предлагаешь засунуть мьютекс в объект и в каждом методе его захватывать. Так очень часто делают.
Можешь без юления объяснить, что ты делаешь?

Здравствуйте, kaa.python, Вы писали:

WH>>Видимо мы имеем дело с мачо-программистами, которые действительно верят в то, что они могут за всем уследить. Они реально считают, что контроль компилятора им не нужен. И все эти системы типов только мешают полёту их фантазии и заставляют писать лишние буквы.
KP>Извините что встреваю в такой восхитительный срач, а ты случаем не тот РСДН-ер, что в приблизительно аналогичной агрессивной форме за Немерле топил, пока бобик не сдох?

Хы, ты почти прав. Только он был не просто фанатом Немерле, а одним из главных разработчиков (речь естественно о последних итерациях, которые активно пиарились на rsdn, а не о изначальном польском проекте). Так что он просто физически не мог не "топить" за Немерле. )))

Правда какое-то время назад он вроде забросил это дело и Влад2 теперь там наверное один пытается что-то вытянуть. А вот про то, что он после этого услышал про Rust и теперь неожиданно позиционирует себя как эксперта в нём — это действительно что-то новое. И забавное в том числе и потому, что когда мы тут на форуме 3-5 лет назад активно обсуждали Rust и D как раз в контексте потенциальной замены C++, от него не было ничего слышно (ну помимо того, что метапрограммирование в C++/D/Rust — это лишь жалкая поделка по сравнению с великими макросами Nemerle).

Здравствуйте, WolfHound, Вы писали:

_>>Если ты реально считаешь, что Rust даёт гарантии отсутствия гонок, то у меня для тебя неприятные новости... Причём насчёт твоей квалификации в данной теме в целом.
WH>Код в студию. Покажи, как без unsafe получить доступ к памяти без надлежащей синхронизации.

А для того, чтобы получить проблемы с многопоточностью совсем не обязательно получать доступ к памяти мимо мьютекса. Более того, как раз мьютексы и вызывают довольно большую часть проблем (например https://users.rust-lang.org/t/using-rayon-in-code-locked-by-a-mutex/20119 — ты помнится прямо эту библиотечку тут хвалил?) в многопоточном коде. Так что твои смешные идеи в стиле "просто поменяем последовательный запуск кода на параллельный и компилятор отследит все некорректности" — это очевидно фантастика.

_>>Ну и гарантии естественно есть. Разве что они рантаймовые — будет сообщение об ошибке, в случае попытки доступа не под мьютексом.
WH>Вот тут давай объясняй, как питон это делает.
WH>Звучит, как самолёты подлетают к границе и падают.

Не "Питон это делает", а такое можно сделать на Питоне. И я вполне подробно описывал как в сообщениях выше — просто модифицируем код (грубо говоря вешаем декораторы на всех его членов, плюс добавляем пару новых методов типа lock/unlock) того объекта , доступ к которому надо защитить мьютексом. Естественно это не программист руками будет делать, а всё произойдёт автоматически при подключение защиты к данному объекту — у динамических языков есть свои преимущества.

_>>Какая ещё часть объекта? Понятно же, что под набором данных подразумевался не кусок какого-то объекта, а наоборот набор разных — на практике только так и встречается собственно. И для реализации автоматического доступа через мьютекс к этим данным, тебе придётся добавить лишний тип, агрегирующий в себя все эти объекты (а так же переписать везде код, чтобы доступ был только через экземпляр этого нового типа). Более того, с учётом специфики Rust'а, у тебя ещё возникнут сложности в случае неравного времени жизни (а это тоже очень даже вероятный сценарий) этих объектов.
WH>Давай про свою практику рассказывай подробнее. Ибо в моей практике такое не встречалось вообще ни разу. Всегда разделяемые данные естественным образом оказывались в одном объекте.

Звучит как фантастика.

WH>Особенно интересует пример, в котором объекты под мьютексом живут разное время.

Ну вот тебе компилируемый пример на C++ с защитой набора разделяемых данных мьютексом:

int global_shared=1;

int main()
{
    int local_shared=1;
    vector<thread> pool;
    mutex m;
    for(int i=0; i<30; i++) pool.emplace_back([&]{
        lock_guard<mutex> lock(m);
        auto sum=global_shared+local_shared;
        global_shared=local_shared;
        local_shared=sum;
        cout<<global_shared<<' ';
    });
    for(auto& t: pool) t.join();
}

Можно увидеть его точный аналог на Rust, с размещением данных внутри мьютекса? )

_>>Ну открой код Rust'а и посмотри — просто контейнер, агрегирующий некий объект и возвращающий ссылку на него по функции Lock, в случае языков без RAII. А в случае наличия RAII в языке, будем возвращать специальный объект для автоматического отпускания мьютекса, точно так же, как и в Rust.
WH>Да причем тут вообще RAII?
WH>Я не понимаю, как ты работу с мьютексами организуешь. RAII это мелкие детали реализации.
WH>Сначала я подумал, что ты предлагаешь засунуть мьютекс в объект и в каждом методе его захватывать. Так очень часто делают.
WH>Можешь без юления объяснить, что ты делаешь?

Мьютекс в защищаемый объект — это в случае динамических языков. В статических мьютекс хранится в объекте-контейнере, рядом с защищаемыми данными. Ну и захватывать в каждом методе несколько неэффективно — для захвата не проблема предусмотреть два метода (в случае наличия RAII достаточно одного) типа Lock/Unlock. А в вызове методов достаточно проверять факт захвата (для динамических языков).

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

Здравствуйте, WolfHound, Вы писали:

_>>Ну этого естественно нет ни в каком из существующих языков. Более того, гонки могут возникнуть даже в однопоточном коде, причём развивающаяся популярность использования сопрограмм, существенно умножает этот ранее редкий случай. И никакими средствами, кроме использования мозга, эти проблемы не решить. Ну во всяком случае во всех существующих сейчас концепциях промышленного ПО.
WH>Ты начал очень широко трактовать гонки.

Это как раз стандартная трактовка. Причём что самое интересное, даже если мы будем говорить например о реализации зелёных потоков в рамках одного системного (скажем сопрограммы в C++ или async/await в C# в рамках GUI потока), то применение модели акторов позволяет убрать проблемы гонок и здесь. Как раз потому, что модель акторов формулируется не в терминах системных потоков.

WH>Тут речь шла про доступ к разделяемой памяти из нескольких потоков без надлежащей синхронизации.

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

_>>Да, это есть. Точно так же как и в 90% используемых сейчас языков. За исключением разве что совсем древних, типа Fortran, C и т.п.
WH>Не забывай про С++.
WH>Там часто хрен поймешь, кто память должен освобождать, не читая документацию.

В C++ память в большинстве случаев управляется автоматически. Ручное управление обычно требуется при взаимодействие с чужим кодом (C библиотеки, OS API и т.п.) или чем-то совсем низкоуровневым (драйверы, микроконтроллеры). Точно так же как и в Rust'е, в котором все библиотеки (включая стандартную), работающие с внешним API, насквозь пропитаны unsafe.

Да, и я вот не пойму чего ты всё время переключаешься на C++, хотя мы тут обсуждаем Rust? У тебя болит C++? )))

WH>>>Сможешь показать, как нарушить их без unsafe?
_>>А откуда взялось это требование, про "без unsafe"?
WH>Оттуда что ты отключаешь контроль компилятора. А если ты его отключил то, какие вопросы к компилятору?

Ну ОК, но это же и для других языков тогда тоже должно работать не так ли? Чтобы не было двойных стандартов... Т.е. вполне нормально рассматривать какое-то административно ограниченное подмножество любого языка, правильно? )

_>>Ведь оно же по сути ничем не отличается скажем от аналогичного запрета на использование в C++ проекте (ну или опять же в большей его части) голых указателей и т.п.. И то и то является административным запретом, который контролируется ревью кода или даже возможно статическими анализаторами. Но в любом случае в своей первооснове это административное ограничение на использование опасных (но иногда нужных) техник языка. Так в чём ты видишь тут концептуальное отличие именно Rust'а?
WH>В том что даже если в С++ запретить голые указатели он всё равно ничего не гарантирует.

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

WH>А rust без unsafe безопасен.

По памяти — да. Точно так же как и правильно используемый C++.

_>>Я смотрю ты кажется понял ошибочность своего спора с моим тезисом и пытаешься понемногу сместить акцент в другую сторону. Смотри, мой тезис был: "если следовать модели акторов (это предусловие, не важно как достигаемое!), то это устранит все классические проблемы многопоточности (результат)".
WH>"если следовать модели мьютексов (это предусловие, не важно как достигаемое!), то это устранит все классические проблемы многопоточности (результат)"
WH>

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

_>>Ты с этим начал спорить, но похоже что сейчас до тебя дошло, что ты не прав. И теперь ты пытаешься перевести разговор на то, можно ли гарантировать на уровне компилятора следование модели акторов в разных языках или нет. Как будто бы это кто-то обещал или вообще обсуждал.
WH>Я всегда именно это и говорил.

Что ты всегда говорил? Ты начал спорить с моим конкретным утверждением о свойстве модели акторов.

WH>Либо глубокое копирование. Erlang.
WH>Либо кучерявая система типов. Rust, pony.
WH>Либо язык ничего не гарантирует. Почти все остальные языки.
WH>Вот с чего всё началось:
WH>

WH>>>>>В большинстве языков эта модель ничего не гарантирует. А в тех, где гарантирует там либо копирование каждого сообщения. Либо типы ещё веселее, чем в rust. Pony передаёт привет.

Хы, интересно как ты себе вообще представляешь гарантию языком следования модели акторов? Потому как например тоже самое использование разделяемых данных (пускай и защищённых мьютексом), уже является нарушением и при этом доступно в большинстве языков (включая Rust). Следование данной модели — это исключительно самоограничение программиста и всё. Никаких гарантий от компилятора ты тут добиться не сможешь (ну если конечно не брать язык, в котором модель акторов — это единственный доступный способ взаимодействия между задачами).

_>>С учётом того, что на протяжение большого числа сообщений в дискуссии с so5team, ты так и не смог ничего показать, думаю мне не стоит продолжать этот очевидный спор. )))
WH>У тебя проблемы с пониманием написанного?
WH>

WH>>При том что ни он ни С++ не защищают от того что пользователь сделат это случайно.
WH>Соответственно, SObjectizer вообще не причем, т.к. он не может привнести в C++ качества, которых в C++ нет и не может быть в принципе.

WH>(С)

Автор: so5team
Дата: 08.05.19

WH>Вполне конкретное признание того что SObjectizer от проблем не защищает.

Конечно. Только от таких проблем не защищает никто.

_>>Я вот к примеру реализовывал полноценную модель акторов на банальных системных потоках (createthread) и системных очередях (postmessage) винды. Причём занимало это десяток строчек (естественно это была не универсальная внешняя библиотека и даже не выделенный модуль внутри приложения, а просто определённая архитектура), но при этом обладало всеми гарантиями корректности многопоточности. Да, и никаких копирований там не наблюдалось.
WH>Как минимум часть этих утверждений ложна.
WH>Скорей всего не было там никаких гарантий и всё держалось на внимательности программиста.

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

_>>Вообще говоря при использование модели акторов, подобные штуки не нужны в принципе. Они появляются только в том случае, если нам начинает нехватать быстродействия модели акторов и есть желание перейти неким глобальным мутабельным данным (причём управляемые не мьютексами, а через CAS).
WH>В случае с rust нам ничто не мешает использовать и то и другое.

Ха. Очередное глубочайшее непонимание. ) Т.е. естественно и Rust и другие языки позволяют использовать и модель акторов и разделяемые мутабельные данные. Но если ты попробуешь смешать это, то в большинстве случаев получишь нарушение всех гарантий.

_>>Нет, получаются короче. Потому как минимум один уровень "контейнеров" в Rust'е возникает обычно из-за BC.
WH>Только не нужно рассказывать это тому, кто на обоих языках писал. В С++ без контейнеров вообще жить нельзя. А в rust в большинстве случаев голые ссылки.

Угу, прямо сплошные голые типы в Rust'е в объявлениях функций, ну да, ну да.

WH>А твои претензии к Option вообще абсурдны. Nullable типов вообще быть не должно. Они сами по себе большая проблема.

Что за мои претензии к Option? Это ты откуда вообще такое взял? )))

_>>Только вот благодаря некому повышенному хайпу на тему Rust'а, вокруг него начали появляться различные мифы, завышающие его реальные способности. Т.е. лично я бы был только рад такому идеальному мифическому языку, но на практике ничего такого нет. Так что приходится развенчивать эти мифы.
WH>Что-то у тебя пока не получается.

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

Здравствуйте, alex_public, Вы писали:

_>Ну открой код Rust'а и посмотри — просто контейнер, агрегирующий некий объект и возвращающий ссылку на него по функции Lock, в случае языков без RAII. А в случае наличия RAII в языке, будем возвращать специальный объект для автоматического отпускания мьютекса, точно так же, как и в Rust.

RAII -- это не самое интересное (хоть и важное). Интересная часть -- это borrow checker. После захвата мьютекса, ты можешь получить обычную ссылку на внутренние данные -- и распоряжаться ей как тебе вздумается. Например, сохранить в какой-то структуре и отправить куда-нибудь. Можно даже взять ссылку на часть данных, засунуть в другую структуру и вызвать какую-нибудь функцию. Но только соблюдая условия заимствования -- ты не можешь заимствовать дольше, чем будет захвачен мьютекс.

Например.

Первый комментарий -- я использовал Rc, который небезопасен в многопоточном коде. Второй комментарий -- поток может жить дольше, чем обрамляющий main.

Здравствуйте, alex_public, Вы писали:

_>Ну вот тебе компилируемый пример на C++ с защитой набора разделяемых данных мьютексом:
_>

_>int global_shared=1;

_>int main()
_>{
_>    int local_shared=1;
_>    vector<thread> pool;
_>    mutex m;
_>    for(int i=0; i<30; i++) pool.emplace_back([&]{
_>        lock_guard<mutex> lock(m);
_>        auto sum=global_shared+local_shared;
_>        global_shared=local_shared;
_>        local_shared=sum;
_>        cout<<global_shared<<' ';
_>    });
_>    for(auto& t: pool) t.join();
_>}
_>

_>Можно увидеть его точный аналог на Rust, с размещением данных внутри мьютекса? )

Что произойдёт в этом коде, если поток номер 15 выбросит исключение на "t.join()" (вернее, "t.join" для потока №15 выбросит исключение)? Для драматичности давай считать, что "main" -- это какая-то функция внутри большой системы.

Или, например, "emplace_back" не сможет выделить память для последнего потока и тоже выбросит исключение.

Здравствуйте, alex_public, Вы писали:

_>Это как раз стандартная трактовка. Причём что самое интересное, даже если мы будем говорить например о реализации зелёных потоков в рамках одного системного (скажем сопрограммы в C++ или async/await в C# в рамках GUI потока), то применение модели акторов позволяет убрать проблемы гонок и здесь. Как раз потому, что модель акторов формулируется не в терминах системных потоков.
Но и у rust'а тут не будет никаких проблем.

_>Потоки то тоже разные бывают... ) Ну да ладно, даже если мы ограничимся только системными потоками, то даже тут автоматическая расстановка мьютексов абсолютно не гарантирует корректности получаемого кода. Даже скорее наоборот, без умения применять этот инструмент, есть солидные шансы получить взаимные блокировки.
Взаимные блокировки можно получить на чём угодно. Я видел распределённые взаимные блокировки на пуле потоков.

_>В C++ память в большинстве случаев управляется автоматически. Ручное управление обычно требуется при взаимодействие с чужим кодом (C библиотеки, OS API и т.п.) или чем-то совсем низкоуровневым (драйверы, микроконтроллеры). Точно так же как и в Rust'е, в котором все библиотеки (включая стандартную), работающие с внешним API, насквозь пропитаны unsafe.
Внутри пропитаны. Это ключевое.
А снаружи у них safe интерфейс. И при использовании про память думать уже не нужно.
Разработчик обёртки уже за нас подумал.
А в С/С++ библиотеки с небезопасным интерфейсом обычное дело.
Я даже использовал библиотеку для работы, с которой было необходимо использовать setjump/longjump.
В случае с rust найти библиотеку с небезопасным интерфейсом не просто.

_>Да, и я вот не пойму чего ты всё время переключаешься на C++, хотя мы тут обсуждаем Rust? У тебя болит C++? )))
Так rust это замена для С/С++. С чем же его ещё сравнивать?

_>Ну ОК, но это же и для других языков тогда тоже должно работать не так ли? Чтобы не было двойных стандартов... Т.е. вполне нормально рассматривать какое-то административно ограниченное подмножество любого языка, правильно? )
Запрет одного ключевого слова и здоровенный талмуд, описывающий что можно и что нельзя сильно разные вещи.

_>По памяти — да. Точно так же как и правильно используемый C++.
Только С++ за этим не следит.

WH>>"если следовать модели мьютексов (это предусловие, не важно как достигаемое!), то это устранит все классические проблемы многопоточности (результат)"
WH>>
_>Вот в том то и дело, что не устранит, а скорее всего только их умножит. Ты сейчас хорошо показал, что вообще не в теме проблемы.
Ты уверен, что я? Если я правильно использую мьтексы то, какие могут возникнуть проблемы? Я же их использую правильно.

_>>>Ты с этим начал спорить, но похоже что сейчас до тебя дошло, что ты не прав. И теперь ты пытаешься перевести разговор на то, можно ли гарантировать на уровне компилятора следование модели акторов в разных языках или нет. Как будто бы это кто-то обещал или вообще обсуждал.
WH>>Я всегда именно это и говорил.
_>Что ты всегда говорил? Ты начал спорить с моим конкретным утверждением о свойстве модели акторов.
Я начал говорить о том, что большинство языком эти свойства не гарантируют.

_>Хы, интересно как ты себе вообще представляешь гарантию языком следования модели акторов?
Erlang и pony построены вокруг акторов.

_>Потому как например тоже самое использование разделяемых данных (пускай и защищённых мьютексом), уже является нарушением и при этом доступно в большинстве языков (включая Rust). Следование данной модели — это исключительно самоограничение программиста и всё. Никаких гарантий от компилятора ты тут добиться не сможешь (ну если конечно не брать язык, в котором модель акторов — это единственный доступный способ взаимодействия между задачами).
В случае с rust имеем. Причем в случае с evmap гарантированно проблем не будет.

WH>>Вполне конкретное признание того что SObjectizer от проблем не защищает.
_>Конечно. Только от таких проблем не защищает никто.
Rust, pony, erlang,...

_>Гарантии корректности многопоточности — это значит, что если ты делаешь всё правильно (да, да, внимательно следишь за своими руками), то получишь корректную многопоточную работу.
Если ты делаешь всё правильно то у тебя и на С код отлично работать будет. Вот только обычно не работает.

WH>>В случае с rust нам ничто не мешает использовать и то и другое.
_>Ха. Очередное глубочайшее непонимание. )
У тебя.

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

_>Угу, прямо сплошные голые типы в Rust'е в объявлениях функций, ну да, ну да.
Я открыл свой код на rust и там почти исключительно голые типы.

WH>>А твои претензии к Option вообще абсурдны. Nullable типов вообще быть не должно. Они сами по себе большая проблема.
_>Что за мои претензии к Option? Это ты откуда вообще такое взял? )))
Ты же на вот этот тип возбудился Option<Box<Data>>
Причём я у тебя долго спрашивал, что за проблемы с типами в rust.
Ты молчал как рыба об лёд. Видимо понимал, что за такую ерунду засмеют.

_>Вообще говоря на этом форуме особо и развенчивать не надо, т.к. большинство в курсе реальности — всё же уже много лет назад обсудили все особенности Rust. Иногда вот только возникают восторженные фанаты, которые прочитали в какой-то компьютерной жёлтой прессе, что Rust помогает не только воспитать правильный подход к управлению памятью (через владение), но и решает проблемы многопоточности. Тогда приходится им пояснять, что это просто слухи...
В отличие от тебя я изучаю языки, начиная с высокоуровневых концепций и заканчивая низкоуровневой реализацией.
Rust действительно даёт гарантии, о которых я говорю.
Твои постоянные апелляции к unsafe говорят о том, что ты это понимаешь, но очень хочешь поспорить.

Здравствуйте, alex_public, Вы писали:

WH>>Код в студию. Покажи, как без unsafe получить доступ к памяти без надлежащей синхронизации.
_>А для того, чтобы получить проблемы с многопоточностью совсем не обязательно получать доступ к памяти мимо мьютекса. Более того, как раз мьютексы и вызывают довольно большую часть проблем (например https://users.rust-lang.org/t/using-rayon-in-code-locked-by-a-mutex/20119 — ты помнится прямо эту библиотечку тут хвалил?) в многопоточном коде. Так что твои смешные идеи в стиле "просто поменяем последовательный запуск кода на параллельный и компилятор отследит все некорректности" — это очевидно фантастика.
1)Показать доступ к памяти без надлежащей синхронизации ты не можешь.
2)Устроить дедлок можно почти на чём угодно. Например, если актор может синхронно обратиться к другому актору, жди дедлоков. А если ты реализовал акров на пуле потоков, то дедлоки тебя найдут ещё быстрее.
3)Отлаживать дедлоки гораздо проще, чем гонки. Ибо в случае с дедлоком видно кто на ком висит. А в случае с гонками программа иногда разлетается на куски и кто виноват совершенно не ясно.
4)По той ссылке написано как можно решить эту проблему на уровне библиотеки, не меняя пользовательский код.
5)Нормальные люди ничего тяжёлого под мьтексом не делают. Так что тут чувак намеренно проблемы искал.

_>Не "Питон это делает", а такое можно сделать на Питоне. И я вполне подробно описывал как в сообщениях выше — просто модифицируем код (грубо говоря вешаем декораторы на всех его членов, плюс добавляем пару новых методов типа lock/unlock) того объекта , доступ к которому надо защитить мьютексом. Естественно это не программист руками будет делать, а всё произойдёт автоматически при подключение защиты к данному объекту — у динамических языков есть свои преимущества.
1)Это можно делать на любых языках с метарограммированием. Динамическая типизация тут не нужна. Да и руками написать такое не сложно.
2)Никогда не видел, чтобы так делали.

WH>>Давай про свою практику рассказывай подробнее. Ибо в моей практике такое не встречалось вообще ни разу. Всегда разделяемые данные естественным образом оказывались в одном объекте.
_>Звучит как фантастика.
Может просто нужно немного задумываться о дизайне кода, прежде чем начинать его писать?

WH>>Особенно интересует пример, в котором объекты под мьютексом живут разное время.
_>Ну вот тебе компилируемый пример на C++ с защитой набора разделяемых данных мьютексом:
Мне не нужен кусок говнокода, который ничего не делает.
Мне нужна реальная задача, при решении которой такое нужно.

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

_>Ну и кстати говоря у Rust'а точно такая же реализация, только там контейнер и мьютекс изначально объединены в одну сущность.
Так я и не понял реализация в rust плохая, ибо не позволяет написать код, который ты привёл выше или хорошая по тому, что так и нужно делать. Плюс у rust'а все проверки на этапе компиляции.