Пытаемся понять, что хорошего в Расте
- Лис [Вежливый]
- Сообщения: 561
- Зарегистрирован: 08.10.18 13:32
Re: Пытаемся понять, что хорошего в Расте
Чекер. Который проверяет, что на одну область памяти нет нескольких "владеющих" ссылок. Вот он - хорошее.
В других языках такого нет. Это новый механизм, которого раньше нигде не было, так же как в лиспе сборка мусора.
Что тут непонятного, что надо было бы понять?
Я бы переформулировал тему так: пытаемся понять,
как реализовать механизм проверок из Rust в своём языке.
В других языках такого нет. Это новый механизм, которого раньше нигде не было, так же как в лиспе сборка мусора.
Что тут непонятного, что надо было бы понять?
Я бы переформулировал тему так: пытаемся понять,
как реализовать механизм проверок из Rust в своём языке.
Re: Пытаемся понять, что хорошего в Расте
Качество данного механизма вызывает большие сомнения, поскольку попытка написать на нём простой двусвязный список вызывает затруднения. Сама по себе идея прикреплённости одних объектов к другим, а других - к стеку, была реализована ещё в Эль-76.
- Лис [Вежливый]
- Сообщения: 561
- Зарегистрирован: 08.10.18 13:32
Re: Пытаемся понять, что хорошего в Расте
Твоя мысль не ясна (точнее ясна, но её можно было бы изложить более ясно).
1. «идея прикреплённости одних объектов к другим, а других - к стеку»
здесь непонятно, в чём суть этой идеи. Есть два варианта: либо имеется в виду совокупность идей:
Первый вариант:
а) введём понятие "указатель"
б) введём понятие "механизм стека"
в) введём понятие "куча" (и "управление кучей")
г) введём понятие "объект" (и может содержать указатели)
д) научимся хранить объекты "в куче" (и "на стеке")
е) указатели из кучи на объекты могут располагаться на стеке (и в куче)
ё) опишем это всё (способы оперирования памятью через эти понятия), назовём это "идеей прикреплённости".
Второй вариант:
мы имеем в виду, что язык должен знать не только типы полей в объекте, но и само понятие типа нужно расширить,
включив туда не только размер в количестве битов, и список алгоритмов-операций, но и дополнительные данные для управления (какие?)
2. Из простого факта упоминания языка Эль-76 не ясно, что же именно они там реализовали - первый или второй вариант.
3. Какие именно дополнительные данные о типе знает и как обрабатывает компилятор должно быть раскрыто более подробно, иначе создать новую реализацию невозможно по такому куцему описанию.
4. Даже если механизм где-то неудобен, это не отменяет факта того, что он есть. А альтернативы пока нет.
Указатели были изобретены Ющенко Екатериной Логвиновной в Адресном языке программирования (1955 г.)
А не в каком-либо там Эль-76
1. «идея прикреплённости одних объектов к другим, а других - к стеку»
здесь непонятно, в чём суть этой идеи. Есть два варианта: либо имеется в виду совокупность идей:
Первый вариант:
а) введём понятие "указатель"
б) введём понятие "механизм стека"
в) введём понятие "куча" (и "управление кучей")
г) введём понятие "объект" (и может содержать указатели)
д) научимся хранить объекты "в куче" (и "на стеке")
е) указатели из кучи на объекты могут располагаться на стеке (и в куче)
ё) опишем это всё (способы оперирования памятью через эти понятия), назовём это "идеей прикреплённости".
Второй вариант:
мы имеем в виду, что язык должен знать не только типы полей в объекте, но и само понятие типа нужно расширить,
включив туда не только размер в количестве битов, и список алгоритмов-операций, но и дополнительные данные для управления (какие?)
2. Из простого факта упоминания языка Эль-76 не ясно, что же именно они там реализовали - первый или второй вариант.
3. Какие именно дополнительные данные о типе знает и как обрабатывает компилятор должно быть раскрыто более подробно, иначе создать новую реализацию невозможно по такому куцему описанию.
4. Даже если механизм где-то неудобен, это не отменяет факта того, что он есть. А альтернативы пока нет.
Указатели были изобретены Ющенко Екатериной Логвиновной в Адресном языке программирования (1955 г.)
А не в каком-либо там Эль-76
Re: Пытаемся понять, что хорошего в Расте
Подразумевается, что заинтересованные отркоют книжку по Эль-76, прочитают её, найдут остальные, поймут и объяснят мне.
- Лис [Вежливый]
- Сообщения: 561
- Зарегистрирован: 08.10.18 13:32
Re: Пытаемся понять, что хорошего в Расте
https://www.linux.org.ru/forum/developm ... d=15797579
Я тоже умею призывать (с такой же эффективностью), но я призываю делать реализацию языка Синхро.нужно ... делать реализацию Эль-76
Re: Пытаемся понять, что хорошего в Расте
По ссылке текст как бы можно и не читать:
Никакой математикой там, скажем, в терминах односвязных ациклических графов даже не пахнет.Начав читать эту статью, вы хотели избавиться от проблем. На деле все прозаично: надо понять, как в действительности работает владение и заимствование в Rust, а также воспринимать ругающийся компилятор как великое благо.
А где написано, что он для этого предназначен?
Re: Пытаемся понять, что хорошего в Расте
> А где написано, что он для этого предназначен?
Вот пример из SQL:
Как в Расте это представить?
Вот пример из SQL:
Код: Выделить всё
создай таблицу персона (код целое первичный ключ, имя строка);
создай индекс персона_по_имени по персоне (строка);
выбери * из персоны где код = 100500;
выбери * из персоны где имя = 'Вася';
- Лис [Вежливый]
- Сообщения: 561
- Зарегистрирован: 08.10.18 13:32
Re: Пытаемся понять, что хорошего в Расте
В SQL-коде ошибка во второй строке. Надо указывать название поля, по которому строится индекс, а не тип этого поля.
Массив структур, он владеющий. А индексы - на заёмных ссылках (с меньшим временем жизни).
Выборки, соответственно, с ещё меньшим временем жизни.
Я так вижу (на расте не пишу).
Первую строчку я закодил (за исключением создания индекса "первичный ключ"):
закодить остальные три строчки и создать индекс под ключ,
оставляется читателю в качестве упражнения.
Массив структур, он владеющий. А индексы - на заёмных ссылках (с меньшим временем жизни).
Выборки, соответственно, с ещё меньшим временем жизни.
Я так вижу (на расте не пишу).
Первую строчку я закодил (за исключением создания индекса "первичный ключ"):
Код: Выделить всё
use std::fmt;
#[derive(Debug)]
struct Person {
key: i32,
name: String,
}
// To use the `{}` marker, the trait `fmt::Display` must be implemented
// manually for the type.
impl fmt::Display for Person {
// This trait requires `fmt` with this exact signature.
fn fmt(&self, f: &mut fmt::Formatter) -> fmt::Result {
// Write strictly the first element into the supplied output
// stream: `f`. Returns `fmt::Result` which indicates whether the
// operation succeeded or failed. Note that `write!` uses syntax which
// is very similar to `println!`.
write!(f, "{}->{}", self.key, self.name)
}
}
fn main() {
let persons = [
Person {key:1, name:"Tom".to_string()},
Person {key:2, name:"Bob".to_string()},
Person {key:3, name:"Sam".to_string()},
];
for user in persons.iter(){
print!("{} ", user);
println!(); // переходим на следующую строку в консоли
}
}
оставляется читателю в качестве упражнения.
- Лис [Вежливый]
- Сообщения: 561
- Зарегистрирован: 08.10.18 13:32
Re: Пытаемся понять, что хорошего в Расте
Создаём индексы
https://doc.rust-lang.org/std/collectio ... eeMap.html
Теперь надо реализовать выборку по ключу из индекса.
Хотя не, надо переделать второй индекс так, чтобы там были массивы значений (а не штучные значения).
Методом индусокодинга ищем статью
https://evanxg852000.github.io/tutorial ... ul-ds.html
копипастим...
Но в любом случае, пока никаких затруднений не видно.
Из чего следует вывод, что подразумеваются какие-то дополнительные требования,
которые не были написаны явно, но которые должны потребовать создания двусвязного списка.
https://doc.rust-lang.org/std/collectio ... eeMap.html
Код: Выделить всё
use std::collections::BTreeMap;
//...
let mut primary_key = BTreeMap::new();
for user in persons.iter(){
primary_key.insert(& user.key, & user.name);
}
let mut secondary_key = BTreeMap::new();
for user in persons.iter(){
secondary_key.insert(& user.name, & user.key);
}
Хотя не, надо переделать второй индекс так, чтобы там были массивы значений (а не штучные значения).
Методом индусокодинга ищем статью
https://evanxg852000.github.io/tutorial ... ul-ds.html
копипастим...
Но в любом случае, пока никаких затруднений не видно.
Из чего следует вывод, что подразумеваются какие-то дополнительные требования,
которые не были написаны явно, но которые должны потребовать создания двусвязного списка.
- Лис [Вежливый]
- Сообщения: 561
- Зарегистрирован: 08.10.18 13:32
Re: Пытаемся понять, что хорошего в Расте
И вообще, двусвязный список не рекомендуют использовать, потому что кеши плохо с ним работают:
https://doc.rust-lang.org/std/collectio ... dList.html
https://www.educba.com/rust-queue/
«We can add any number of elements inside it, all the implementation is based on the vector data structure»
https://stackoverflow.com/questions/408 ... ns-in-rust
«it still maintains amortized O(1) push_back even when not reserving excess capacity ahead of time»
И для конкретно этого примера однонаправленной достаточно.
https://doc.rust-lang.org/std/collectio ... dList.html
Ещё есть однонаправленная очередь:It is almost always better to use Vec or VecDeque because array-based containers are generally faster, more memory efficient, and make better use of CPU cache.
https://www.educba.com/rust-queue/
«We can add any number of elements inside it, all the implementation is based on the vector data structure»
https://stackoverflow.com/questions/408 ... ns-in-rust
«it still maintains amortized O(1) push_back even when not reserving excess capacity ahead of time»
И для конкретно этого примера однонаправленной достаточно.
Re: Пытаемся понять, что хорошего в Расте
Пока не реализован весь набор операций, сложно судить, есть трудности или нет. Амортизированное O(1) - это О(1) в среднем. Однако если говорить о худшем времени, то это будет O(N). Это решение уже не годится и проигрывает списку, у которого настоящее О(1), т.е. и в среднем, и худшее время будет О(1).
- Лис [Вежливый]
- Сообщения: 561
- Зарегистрирован: 08.10.18 13:32
Re: Пытаемся понять, что хорошего в Расте
Деньги в среднем будут зарабатывать программисты на Rust, а ты только в худшем случае, и то не гарантированно в N раз больше.
Re: Пытаемся понять, что хорошего в Расте
Из этого я понял только то, что Лис не смог решить задачу на Расте, равно как и теорию провалил.
- Лис [Вежливый]
- Сообщения: 561
- Зарегистрирован: 08.10.18 13:32
Re: Пытаемся понять, что хорошего в Расте
Пф. Не всё понял ты, а виноват почему-то я.
Re: Пытаемся понять, что хорошего в Расте
Я точно понял, что ответить на "амортизированность" тебе нечем. Удивительно, что прямо один в один с товарищем с ЛОРа по имени khrudel, который на 10 страницах всех оскороблял - ответить на эту проблему, которую ему человек 5 указали, ему оказалось нечем, но зато он щедро раздавал диагнозы налево и направо.
- Лис [Вежливый]
- Сообщения: 561
- Зарегистрирован: 08.10.18 13:32
Re: Пытаемся понять, что хорошего в Расте
> Я точно понял, что ответить на "амортизированность" тебе нечем.
Верно. Но это проблема только в редких случаях. Для тебя это не ответ, а для рынка - ответ.
Верно. Но это проблема только в редких случаях. Для тебя это не ответ, а для рынка - ответ.
Re: Пытаемся понять, что хорошего в Расте
На основании чего ты говоришь о редкости таких случаев? Если взять рынок труда для программистов, то Раст на нём занимает, наверное, процента 3. Значит, для 3% рынка Раст подходит (если это не дань моде - смотреть нужно не по вложениям усилий, а по полученному результату. Например, Дельфи подходит для рынка, т.к. фирмы на нём живут десятилетями). Как насчёт остальных 97%? Какие значимые программы написаны на Расте без unsafe? Кстати, если заглянуть внутрь тех библиотек, которые ты начал применять в своём примере, то unsafe там тоже есть.
Но в общем можно не тратить время, мой вывод на данный момент, что модель управления памятью в Расте - плохая.
Но в общем можно не тратить время, мой вывод на данный момент, что модель управления памятью в Расте - плохая.