Как и обещал когда-то, написал обзорный пост посвященной модели памяти Rust. Модель довольно сложная, я бы даже сказал наиболее сложная из всех, с которыми я на данный момент имел дело. Тем не менее, мне, как C и C++ разработчику, она представляется довольно многообещающей. Выложил у себя в блоге, так как форматер RSDN-a о синтаксисе Rust не подозревает.
В конце заметки есть список терминов, имеющих хождение только в Rust и их перевод, который мне кажется наиболее близким. Был бы очень благодарен за предложения по доработке вариантов перевода.
Здравствуйте, kaa.python, Вы писали:
KP>Как и обещал когда-то, написал обзорный пост посвященной модели памяти Rust. Модель довольно сложная, я бы даже сказал наиболее сложная из всех, с которыми я на данный момент имел дело. Тем не менее, мне, как C и C++ разработчику, она представляется довольно многообещающей. KP>Выложил у себя в блоге, так как форматер RSDN-a о синтаксисе Rust не подозревает.
KP>В конце заметки есть список терминов, имеющих хождение только в Rust и их перевод, который мне кажется наиболее близким. Был бы очень благодарен за предложения по доработке вариантов перевода.
Это что? Теоретическая можели, самостоятельная штука которую можно привинтить или часть языка?
Здравствуйте, kaa.python, Вы писали:
KP>Как и обещал когда-то, написал обзорный пост посвященной модели памяти Rust. Модель довольно сложная, я бы даже сказал наиболее сложная из всех, с которыми я на данный момент имел дело.
Не столько сложная сколько запутанная из-за огромного количества сущностей. KP>Тем не менее, мне, как C и C++ разработчику, она представляется довольно многообещающей.
А чего там такого что нельзя сделать в c++? KP>Выложил у себя в блоге, так как форматер RSDN-a о синтаксисе Rust не подозревает.
Из статьи непонятно ради чего все это затеивалось. Каково назначение этого языка?
Здравствуйте, cvetkov, Вы писали:
KP>>Тем не менее, мне, как C и C++ разработчику, она представляется довольно многообещающей. C>А чего там такого что нельзя сделать в c++?
В C++ нельзя обеспечить контроль за тем как обращаются к памяти. В Rust можно.
C>Из статьи непонятно ради чего все это затеивалось. Каково назначение этого языка?
Язык общего назначения:
Основная задача Rust — быть удобным языком для написания больших клиент-серверных приложений, работающих в сети Интернет. Такое позиционирование привело к возникновению набора функциональности с акцентом на безопасность, контролем за использованием памяти и параллельным выполнением задач. Производительность приложения на Rust должна быть сравнимой с производительностью C++ приложений[6]. Rust намеренно не включает в себя каких-то новых и непроверенных идей. Проект нацелен на сбор лучших возможностей из уже существующих языков и решений.
Здравствуйте, kaa.python, Вы писали:
KP>Здравствуйте, batu, Вы писали:
B>>Это что? Теоретическая можели, самостоятельная штука которую можно привинтить или часть языка?
KP>Я не уверен что правильно понял вопрос, но если "можели" означает модель, то ответом будет часть языка Rust.
Ты правильно понял.. Новый год.. клавиши рядом . И, несморя на это, я тоже правильно понял.. Просто тема интересует.. Хотелось бы подробнее.. и даже код..
Здравствуйте, kaa.python, Вы писали:
KP>>>Тем не менее, мне, как C и C++ разработчику, она представляется довольно многообещающей. C>>А чего там такого что нельзя сделать в c++? KP>В C++ нельзя обеспечить контроль за тем как обращаются к памяти. В Rust можно.
Какой именно контроль нереализуем в c++? C>>Из статьи непонятно ради чего все это затеивалось. Каково назначение этого языка?
KP>Язык общего назначения:
KP>
KP>Основная задача Rust — быть удобным языком для написания больших клиент-серверных приложений, работающих в сети Интернет. Такое позиционирование привело к возникновению набора функциональности с акцентом на безопасность, контролем за использованием памяти и параллельным выполнением задач. Производительность приложения на Rust должна быть сравнимой с производительностью C++ приложений[6]. Rust намеренно не включает в себя каких-то новых и непроверенных идей. Проект нацелен на сбор лучших возможностей из уже существующих языков и решений.
помоему слишком сложно получается, а плюсов с точки зрения производительности по сравнению с c++ нет.
а с точки зрения безопасности управления памятью до java далеко.
Здравствуйте, cvetkov, Вы писали:
KP>>В C++ нельзя обеспечить контроль за тем как обращаются к памяти. В Rust можно. C>Какой именно контроль нереализуем в c++?
Во-первых, в C++ не возможно запретить совместный доступ на чтение куска памяти из разных потоков, что приводит к огромному количеству ошибок. Собственно говоря та же ситуация характерна для большинства языков программирования, которые изначально небыли нацелены на разработку многопоточных приложений, в отличает от специальных языков (того же Erlang), которые реализуют схожий подход.
Во-вторых, C++ не проверяет валидность указателей перед их использованием и ты с легкостью можешь столкнуться с указателем в никуда. А компилятор Rust это отслеживает, причем не в рантайм, что довольно дорого, а на этапе компиляции.
C>помоему слишком сложно получается, а плюсов с точки зрения производительности по сравнению с c++ нет.
Нет и не будет. Лично я в заявление разработчиков о том, что язык будет не медленнее C++ не очень верю, скорей всего будет слегка медленнее.
C>а с точки зрения безопасности управления памятью до java далеко.
Ты не мог бы пояснить, в чем далеко? Данное утверждение совершенно голословно. Дело в том, что с точки зрения безопасности, работа с памятью в Rust превосходит Java, так как осуществляется не только контроль за тем, используется ли память или нет, но еще есть изолирование памяти между потоками.
Здравствуйте, batu, Вы писали:
B>Ты правильно понял.. Новый год.. клавиши рядом . И, несморя на это, я тоже правильно понял.. Просто тема интересует.. Хотелось бы подробнее.. и даже код..
Напишу подробнее, не все сразу. По Rust документации не много, приходится информацию из того что есть выскребать + из их же юнит-тестов
Здравствуйте, kaa.python, Вы писали:
KP>Здравствуйте, cvetkov, Вы писали:
KP>>>В C++ нельзя обеспечить контроль за тем как обращаются к памяти. В Rust можно. C>>Какой именно контроль нереализуем в c++?
KP>Во-первых, в C++ не возможно запретить совместный доступ на чтение куска памяти из разных потоков, что приводит к огромному количеству ошибок. Собственно говоря та же ситуация характерна для большинства языков программирования, которые изначально небыли нацелены на разработку многопоточных приложений, в отличает от специальных языков (того же Erlang), которые реализуют схожий подход.
erlang использует immutable объекты, так что он не подходит. а копирование обектов есть в com (single thread appartment) но оно не очень эффективное и удобное. KP>Во-вторых, C++ не проверяет валидность указателей перед их использованием и ты с легкостью можешь столкнуться с указателем в никуда. А компилятор Rust это отслеживает, причем не в рантайм, что довольно дорого, а на этапе компиляции.
угу, как только прикрутят гарбадж коллектор получится ява только сложнее.
а производительность за которую борются сразу пропадет. C>>помоему слишком сложно получается, а плюсов с точки зрения производительности по сравнению с c++ нет.
KP>Нет и не будет. Лично я в заявление разработчиков о том, что язык будет не медленнее C++ не очень верю, скорей всего будет слегка медленнее.
так зачем тогда велосипед, используйте яву. C>>а с точки зрения безопасности управления памятью до java далеко.
KP>Ты не мог бы пояснить, в чем далеко? Данное утверждение совершенно голословно. Дело в том, что с точки зрения безопасности, работа с памятью в Rust превосходит Java, так как осуществляется не только контроль за тем, используется ли память или нет, но еще есть изолирование памяти между потоками.
эта изоляция только головную боль принесет, так как достигается копированием, проще уж сразу immutable делать было.
Здравствуйте, cvetkov, Вы писали:
C>эта изоляция только головную боль принесет, так как достигается копированием, проще уж сразу immutable делать было.
Ты таки даже не прочитал то, о чем я написал в заметке...
Здравствуйте, cvetkov, Вы писали:
KP>>Во-первых, в C++ не возможно запретить совместный доступ на чтение куска памяти из разных потоков, что приводит к огромному количеству ошибок. Собственно говоря та же ситуация характерна для большинства языков программирования, которые изначально небыли нацелены на разработку многопоточных приложений, в отличает от специальных языков (того же Erlang), которые реализуют схожий подход. C>erlang использует immutable объекты, так что он не подходит. а копирование обектов есть в com (single thread appartment) но оно не очень эффективное и удобное.
Копирования в COM нет, вообще. Там есть однопоточные апартаменты, когда каждая группу объектов получает по "своему" потоку. При этом при кросс-апартаментных вызовах происходит блокировка.
KP>>Во-вторых, C++ не проверяет валидность указателей перед их использованием и ты с легкостью можешь столкнуться с указателем в никуда. А компилятор Rust это отслеживает, причем не в рантайм, что довольно дорого, а на этапе компиляции. C>угу, как только прикрутят гарбадж коллектор получится ява только сложнее.
Он там есть.
C>а производительность за которую борются сразу пропадет.
Нет. В Rust можно в значительной части случаев обойтись без синхронизации, при этом работая с мутируемыми объектами.
C>эта изоляция только головную боль принесет, так как достигается копированием, проще уж сразу immutable делать было.
Каким копированием? Ты о чём?
Здравствуйте, kaa.python, Вы писали:
C>>эта изоляция только головную боль принесет, так как достигается копированием, проще уж сразу immutable делать было. KP>Ты таки даже не прочитал то, о чем я написал в заметке...
я таки прочитал.
"Предотвращение возникновения гонок в памяти, так как каждая из задач имеет собственный хип и передаваемые между задачами данные должны копироваться."
или копирование предполагается делать в ручную?
Здравствуйте, Cyberax, Вы писали:
C>>erlang использует immutable объекты, так что он не подходит. а копирование обектов есть в com (single thread appartment) но оно не очень эффективное и удобное. C>Копирования в COM нет, вообще. Там есть однопоточные апартаменты, когда каждая группу объектов получает по "своему" потоку. При этом при кросс-апартаментных вызовах происходит блокировка.
там есть такое слово "маршалинг"
KP>>>Во-вторых, C++ не проверяет валидность указателей перед их использованием и ты с легкостью можешь столкнуться с указателем в никуда. А компилятор Rust это отслеживает, причем не в рантайм, что довольно дорого, а на этапе компиляции. C>>угу, как только прикрутят гарбадж коллектор получится ява только сложнее. C>Он там есть.
"Внимание: на данный момент, для управления разделяемыми указателями используется подсчет ссылок, но в будущем планируется переработка данного функционала и использование полноценного сборщика мусора."
это всетаки не настоящий гарбадж коллектор.
или предпологается сделать гарбадж коллектор который не двигает объекты в памяти?
C>>а производительность за которую борются сразу пропадет. C>Нет. В Rust можно в значительной части случаев обойтись без синхронизации, при этом работая с мутируемыми объектами.
Из статьи я не понял как, можно подробнее. C>>эта изоляция только головную боль принесет, так как достигается копированием, проще уж сразу immutable делать было. C>Каким копированием? Ты о чём?
"Предотвращение возникновения гонок в памяти, так как каждая из задач имеет собственный хип и передаваемые между задачами данные должны копироваться"
или вы про " Наличие хипа обмена для избежания лишних операций копирования с семантикой владения" так я не представляю как этим можно пользоваться чтобы было удобно. а в статье про это ни слова.
Здравствуйте, cvetkov, Вы писали:
C>>>эта изоляция только головную боль принесет, так как достигается копированием, проще уж сразу immutable делать было. KP>>Ты таки даже не прочитал то, о чем я написал в заметке... C>я таки прочитал. C>"Предотвращение возникновения гонок в памяти, так как каждая из задач имеет собственный хип и передаваемые между задачами данные должны копироваться." C>или копирование предполагается делать в ручную?
мда
там где-то написано, что разделяемые указатели -- единственный способ передавать данные между потоками?
Здравствуйте, cvetkov, Вы писали:
C>Здравствуйте, kaa.python, Вы писали:
C>>>эта изоляция только головную боль принесет, так как достигается копированием, проще уж сразу immutable делать было. KP>>Ты таки даже не прочитал то, о чем я написал в заметке... C>я таки прочитал.
Там после введения еще текст есть.
C>"Предотвращение возникновения гонок в памяти, так как каждая из задач имеет собственный хип и передаваемые между задачами данные должны копироваться." C>или копирование предполагается делать в ручную?
Здравствуйте, AlexRK, Вы писали:
ARK>Там после введения еще текст есть.
вы не поверите... C>>"Предотвращение возникновения гонок в памяти, так как каждая из задач имеет собственный хип и передаваемые между задачами данные должны копироваться." C>>или копирование предполагается делать в ручную?
ARK>Для обмена между задачами есть уникальные ссылки.
да, но как их использовать там не сказано (за исключением тривиального однопоточного примера).
вот я и прошу разъяснить
Здравствуйте, night beast, Вы писали:
C>>"Предотвращение возникновения гонок в памяти, так как каждая из задач имеет собственный хип и передаваемые между задачами данные должны копироваться." C>>или копирование предполагается делать в ручную?
NB>мда NB>там где-то написано, что разделяемые указатели -- единственный способ передавать данные между потоками?
из вас плохой телепат, но продолжайте старатся.
если-же это был тролинг, то он тоже плохой, не годный
Здравствуйте, cvetkov, Вы писали:
NB>>мда NB>>там где-то написано, что разделяемые указатели -- единственный способ передавать данные между потоками? C>из вас плохой телепат, но продолжайте старатся.
новый год не прошел без последствий? бывает
C>если-же это был тролинг, то он тоже плохой, не годный
