LINUX.ORG.RU
ФорумTalks

Rust модель памяти

 


0

3

Наткнулся на хабре на пост о rust и несколько прифигел:

fn main() {
    let original_owner = String::from("Something");
    let new_owner = original_owner;
println!("{}", original_owner);

}

Афтор пишет, что подобный код вызавет ошибку в rust, а чому так оно же в одном блоке видимости все происходит, чому rust затирает переменную буквально сразу после присваивания? Чего ради это сделано?

Попробовал такое же на java и никакой ошибки нет, код компилируется и выполняется:

    public static void main(String[] args) {
        String original_owner = new String("Something");
        String new_owner = original_owner;
        System.out.println(original_owner);
    }

Отсутствие классов отдельный рофл: давайте получать экземляры объектов не на уровне класса, а на уровне метода, в который напихаем ещё пачку методов и побольше. Зато нет наследования, да.

★★★★★

Последнее исправление: Ygor (всего исправлений: 1)
Ответ на: комментарий от no-such-file

Проблема в том, что в подавляющем большинстве языков let – это объявление псевдонима, а не присваивание, и оно имеет совершенно иную семантику. Было бы странно, если бы я вдруг начал называть Василия Васяном и за это мне запретили бы называть его Василием.

buddhist ★★★★★
()
Ответ на: комментарий от hateWin

движок ЛОРа на brainfuck

На брейнфак можно написать простенький интерпретатор ЛИСПа или ФОРТа. Дальше сложностей нет.

no-such-file ★★★★★
()
Ответ на: комментарий от hateWin

а не на брейнфаке

И что? Результат-то будет на брейнфаке. В этом суть эквивалентности по Тьюрингу. На расте можно написать жабу, а на жабе раст. Если на жабе можно написать раст, то можно написать и всё что написано на расте. Поскольку жаба немного удобнее чем брейнфак или машкоды, то вероятнее всего даже раст писать для этого не потребуется.

PS: вон, школорастофилы не стесняются пилить DSL для UI. Чё на голом расте сильно больно наверное пердохаться.

no-such-file ★★★★★
()
Последнее исправление: no-such-file (всего исправлений: 3)
Ответ на: комментарий от alois

это то же самое что утверждать, что безопасность вызова openssl genpkey ... гарантируется башем

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

Lrrr ★★★★★
()
Ответ на: комментарий от cumvillain

Погоди, ща набегут растаманы и скажут что твои деревья не нужны, потому что есть массивы.

Mumble mumble kernel embedded something something intrusive.
It’s niche. You’re talking about a situation where you’re not even using your language’s runtime. Is that not a red flag that you’re doing something strange?
It’s also wildly unsafe.
But sure. Build your awesome zero-allocation lists on the stack.

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

PPP328 ★★★★★
()
Последнее исправление: PPP328 (всего исправлений: 1)
Ответ на: комментарий от PPP328

Правда выяснилось что все это нужно даже для сраного асинка.

cumvillain
()
Ответ на: комментарий от MOPKOBKA

Java намного проще и безопаснее,

неа - https://wouter.coekaerts.be/2018/java-type-system-broken, а здесь прям статья научная https://raw.githubusercontent.com/namin/unsound/master/doc/unsound-oopsla16.pdf - «безопасно» настолько что даже скалу зацепило.

zurg
()
Последнее исправление: zurg (всего исправлений: 1)

подобный код вызавет ошибку в rust

При чем тут модель памяти?

ya-betmen ★★★★★
()
Ответ на: комментарий от MOPKOBKA

3

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

zurg
()
Ответ на: комментарий от zurg

и что там в яве(и хоть где-нибудь ещё) с низкоуровневой многопоточкой? в рачте, как минимум,статически проверяемая защита от data-racing из коробки

zurg
()
Ответ на: комментарий от Ygor

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

Матерые плюсовики за упоротый синтаксис и невозможность просто так втыкать в код привычные конструкции типа

std::shared_ptr<char> Z[0](static_cast<char*>(malloc(sizeof (char *) * 10)),free);

Сишники за то, что в расте слишком много всего, у них то даже строк нет.

Остальные просто не бегают по инету, чтобы запостить своё мнение.

ya-betmen ★★★★★
()
Последнее исправление: ya-betmen (всего исправлений: 1)
Ответ на: комментарий от ya-betmen

Просто есть два Rust — тот, который был до async, и тот, который стал после async. И в первом розовые пони, а во втором осознание, что текущая система типов отвратительно подходит для нетривиальных действий.

cumvillain
()
Последнее исправление: cumvillain (всего исправлений: 1)
Ответ на: комментарий от cumvillain

Хейтить начали до async.

Да и он ничего принципиально нового не вносит кроме необходимости уметь думать в 4х измерениях используя результат которого ещё нет. Точнее понимать где он уже есть а где ещё нет.

ya-betmen ★★★★★
()
Ответ на: комментарий от zurg

неа - https://wouter.coekaerts.be/2018/java-type-system-broken, а здесь прям статья научная

Рассказывается о выбросе исключений при неправильном касте, что тут небезопасного?

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

Оно еще сложнее, это дополнительная работа при создании, изменении, поддержке, в языке с GC этого не будет вовсе.

MOPKOBKA ★★★★★
()
Ответ на: комментарий от ya-betmen

Сишники за то, что в расте слишком много всего, у них то даже строк нет.

Ты что то перепутал, это в Rust нету, с UEFI приходится все конвертировать туда сюда.

MOPKOBKA ★★★★★
()
Последнее исправление: MOPKOBKA (всего исправлений: 1)
Ответ на: комментарий от MOPKOBKA

UEFI

Да с ним постоянно проблемы, всегда в легаси перетыкаю.

ya-betmen ★★★★★
()

Может, это не ответ на именно заданный вопрос, но вспомнилось, как уже сам Стив Клабник признал примитивность и неинтуитивность старого borrow checker’а:

So originally, lifetimes were lexical only. And when the move towards non-lexical lifetimes was being considered, this aspect was discussed heavily.
It turns out that programmers seem to think about scope in a cfg style, and don’t really think in lexical scope, even though it’s “easier.” Tons of people, even new ones, would look at some code Rust rejects and be like “but obviously this is safe because:” and then state the non-lexical reasoning. People generally find the non-lexical borrow checker to be far easier to use.
I think it is actually one of the larger things Rust has discovered, that doesn’t get talked about very much. And it’s also a great demonstration that simpler doesn’t always mean easier.

https://news.ycombinator.com/item?id=38240642

I describe it as intuition because people talk about these things intuitively. They say things like «the borrow checker finally accepts code I know it should have accepted all along». For example, let’s look at the example used in the very first part of the NLL RFC:

  fn capitalize(data: &mut [char]) {
      todo!()
  }

  fn foo() {
      let mut data = vec!['a', 'b', 'c'];
      capitalize(&mut data[..]); 
      data.push('d');
  }

This code works just fine. But maybe we want to pull the slice out into a variable. So we do this:

  fn foo() {
      let mut data = vec!['a', 'b', 'c'];
      let slice = &mut data[..];
      capitalize(slice); 
      data.push('d');
  }

This code would fail to compile under the old borrow checker. Why? Because you have two &mut references pointing to the same thing. People are, I think, rightfully surprised that this code doesn’t just work. It is very unintuitive that extracting a temporary to a variable causes code to no longer work. But that is exactly it: you are now changing the scope from small to large, thanks to lexical scoping.
But people didn’t talk about this code as like «Oh I understand that I am introducing a lexical scope and that means it conflicts.» They talk about it like «but I don’t use slice anywhere after the capitalize call. This code is safe. There’s no point where these two mutable references are active at the same time. And you know I’m right because the temporary version works just fine, and this is equivalent.» That is, their perception of scope maps closer to a CFG than to lexical rules.

https://news.ycombinator.com/item?id=38242008

gag ★★★★★
()

Это целый подкласс наркоманских и марсианских языков. Да, с точки зрения логики операторы let тут себя ведет неправильно, но забавнее читать как его защищают - юношеский максимализм и протест против общественных устоев

rtxtxtrx ★★
()
Ответ на: комментарий от ya-betmen

Речь не про сам async. Речь про пиннинг и прочие новые для раста концепты, которые оттуда вылезли. И эти концепты нужны в том числе в сложных структурах данных. И они отвратно ложатся на сам язык.

cumvillain
()
Последнее исправление: cumvillain (всего исправлений: 2)
Ответ на: комментарий от MOPKOBKA

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

Camel ★★★★★
()
Ответ на: комментарий от ya-betmen

ну у сокетов два режима: блокирующий и неблокирующий. в втором тебе их нужно в цикле «опрашивать», ожидая когда из них можно читать либо писать в… всякие libevent c колбеками уже поверх этого

rtxtxtrx ★★
()
Ответ на: комментарий от rtxtxtrx

Так я о том самом что внизу будет примерно одно и то же.

ya-betmen ★★★★★
()
Ответ на: комментарий от ya-betmen

Любой async/await это костыли над евентлупом с каллбаками.

Костыли в том смысле, чтобы увечный мог хоть как-то ходить?

red75prim ★★★
()
Ответ на: комментарий от red75prim

В том смысле что можно написать всё руками, но с сахаром слаще.

ya-betmen ★★★★★
()
Закрыто добавление комментариев для недавно зарегистрированных пользователей (со score < 50)