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

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

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

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

Так аналог движка лора будет написан на лиспе или форте, а не на брейнфаке

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

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

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

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

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

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

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 без рантайма

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

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

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

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

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

3

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

UEFI

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

Может, это не ответ на именно заданный вопрос, но вспомнилось, как уже сам Стив Клабник признал примитивность и неинтуитивность старого 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

Он вносит Pin, pin projection (crate на очень много строк), PhantomData и ряд других костылей.

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

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

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

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

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

неблокирующие сокеты

Сокеты же код процессить не будут, тебе проц нужен.

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

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

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

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

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

Так что на сложных стуктурах данных Rust заглатывает за обе щеки.

Как и любой компилируемый язык.

Как и любой компилируемый язык.

Толсто.

Толсто.

Тут и не на такое клюют.