![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
amaraoИнтернеты говорят, что во-первых Rc<RefCell> не идиоматично для Rust (деревья правильно держать как банальные вектора, содержащие в себе вектора векторов). Во-вторых, я, в целом, всё правильно сделал.
После некоторого кумекания получилось вот так вот, и я не вижу как его сделать существенно компактнее. Может быть, можно уйти от Enum и бального true/false хватит?
Да, получилось.
Что меня смущает? Изобилие as_ref().cloned(). Ща буду думать...
После некоторого кумекания получилось вот так вот, и я не вижу как его сделать существенно компактнее. Может быть, можно уйти от Enum и бального true/false хватит?
Да, получилось.
fn mktree(source: &[Option<i32>]) -> Tree {
if source.is_empty() || source[0].is_none() {
return None;
}
let tree: Tree = new_tree(source[0].unwrap());
let mut buff = VecDeque::new();
buff.push_back((tree.as_ref().cloned(), false));
for val in source[1..].into_iter() {
let subtree = val.and_then(|val| {
let subtree = new_tree(val);
buff.push_back((subtree.as_ref().cloned(), false));
subtree
});
let (node, is_last) = buff.pop_front().unwrap();
if is_last {
node.unwrap().borrow_mut().right = subtree;
} else {
node.as_ref().unwrap().borrow_mut().left = subtree;
buff.push_front((node.as_ref().cloned(), true));
}
}
tree
}
Что меня смущает? Изобилие as_ref().cloned(). Ща буду думать...
no subject
Date: 2022-12-25 07:34 am (UTC)Чтобы одновременно выполнить следующие условия:
1. Эффективность: дать возможность писать realtime код, без overhead'а в виде GC и прочего рантайма.
2. Достаточно гибкие абстракции, в частности какой-то вариант generics.
3. Возможность писать относительно безопасный код, хотя бы если следовать определённым правилам.
4. Возможность работать с большим объёмом кода, на уровне сотен тысяч и миллионов строк.
Rust и C++ -- единственные языки, которые удовлетворяют всем этим условиям одновременно.
no subject
Date: 2022-12-25 02:18 pm (UTC)В принципе теория ООП или функционального программирования должна была ответить на это требование, но не ответила. Почему это произошло? Буду говорить с высоты своей башни со слоновой кости, так сказать…
В далекой юности я столкнулся с языком IPL https://en.wikipedia.org/wiki/Information_Processing_Language и это было подобно взрыву атомной бомбы. На этом языке достаточно было написать несколько команд в одной строке кода и это заменяло тысячи строк ассемблера и сотни строк FORTRAN, ALGOL или PL/1.
Как оказалось, что это очередной тупик, так как отладить и добиться нужных результатов в этом языке было очень не тривиальной задачей, а самое главное если после отладки надо было внести изменения или добавить функционал, то это было просто невозможно. Я уже и не говорю, что понять, что хотел сделать один программист другому, было просто невозможно.
К чему я это? IPL - это крайность, позволяющая построить очень красивый математический язык, но совершенно не пригодный в реальной жизни. И поэтому другая крайность отлаживать и сопровождать исходный код в миллион или сотни тысяч строк кода. Сколько программистов на это потребуется? Как долго этот динозавр будет жить, пока его не прийдется переписывать из-за того, что он рухнет из-за множества исправлений и заплаток…
Конечно мне могут возразить, что это вопросы архитектуры и разбивая на модули или построив архитектуру на основе микро сервисов, можно эти проблемы решить? Но ведь это путь в некуда, так как миллиарды модулей и микро сервисов нуждаются в управлении и сопровождении и если надо прослеживать зависимости, то тут кроме ИИ никто не разберется. Значит мы приходим к тому, что надо построить ИИ, который заменит миллионы программистов, которые не приходя в сознание латают и исправляют миллиарды строк кода?
no subject
Date: 2022-12-25 06:44 pm (UTC)В возможности имплементировать generic алгоритмы и контейнеры без runtime оверхэда.
> безопасность кода в С++
С++ относительно безопасен если использовать его идеоматически, с RAII и референсами. Гораздо безопаснее C.
Я не очень понял к чему был разговор про IPL. На C++, также как и скажем на Java, есть много проектов с сотнями тысяч и миллионами строк, и с ними вполне возможно работать, хоть с микросервисами, хоть без.
ИИ -- хорошо, но мы пока не научились его использовать для работы с большими массивами кода. Может через пару лет...
no subject
Date: 2022-12-25 06:58 pm (UTC)…сначала надо ответить себе на вопрос зачем было создано структурное программирование, ООП и функциональное программирование, которое закончилось возникновением архитектуры микро сервисов? Когда ответите, тогда и поговорим… кстати, переписать монолитное приложение на микро сервисы, занимает годы и годы! Ну это так к слову…
Когда научат ИИ генерировать и главное сопровождать миллиарды строк кода, все программисты окажутся на улице, как и водители автомобилей и это случиться очень скоро! Ждем-с…
no subject
Date: 2022-12-25 07:01 pm (UTC)> …сначала надо ответить себе на вопрос зачем было создано структурное программирование ...
Я хорошо знаю все слова, которые вы пишете, но не вижу в чём ваш пойнт.
no subject
Date: 2022-12-25 07:06 pm (UTC)no subject
Date: 2022-12-25 07:10 pm (UTC)Но вы просто почти ничего не говорите по существу.
no subject
Date: 2022-12-25 07:47 pm (UTC)Что касается рынка труда, то он очень сильно меняется в этой сфере и вся суть этих изменений направлена на увеличение производительности труда, которая приводит к автоматизации и замене ручного труда. Вот и все, что я хотел вам сказать по существу.
no subject
Date: 2022-12-25 07:08 pm (UTC)no subject
Date: 2022-12-25 07:52 pm (UTC)no subject
Date: 2022-12-25 07:54 pm (UTC)И когда вам в последний раз случалось перезагружать компьютер из-за упавшего процесса в юзерспейсе?
no subject
Date: 2022-12-25 08:31 pm (UTC)no subject
Date: 2022-12-25 08:36 pm (UTC)В случае JVM даже этого не случается. Сам процесс JVM не должен падать, и критическая ошибка -- это просто exception который останавливает работу приложения.
С точки зрения пользователя разницы большой нет. С точки зрения программиста Java защищает от нескольких типов ошибок ценой потери производительности и эффективности использования памяти. Rust совмещает одно с другим.
no subject
Date: 2022-12-25 08:45 pm (UTC)Что касается Rust и Go, то если они смогли избавиться от memory leaking, как это происходит в С++, то я в этом я очень глубоко сомневаюсь и тем более по поводу вашего "смелого" утверждения о "эффективности" использования памяти!
no subject
Date: 2022-12-25 08:50 pm (UTC)Последний раз, когда я искал что-то неизбывно ужасное, я нашёл ангелов от ibm. Страшнее этого врят ли что-то найдётся.
no subject
Date: 2022-12-25 09:09 pm (UTC)no subject
Date: 2022-12-25 08:57 pm (UTC)Хе-хе =)
> Что касается Rust и Go, то если они смогли избавиться от memory leaking, как это происходит в С++
Это звучит довольно смешно после сомнений в моей компетенции.
Во-первых, memory leaking -- это вообще не проблема в современном C++. Это была и остаётся проблемой в C, где нет RAII. Проблема, которая остаётся в C++ и которая решена в Rust -- это use-after-free.
Во-вторых, Java, которую вы ставите в пример, как раз имеет проблему memory leaking потому что с garbage collection слишком легко случайно сохранить ссылку на объекты которые должны были быть удалены.
В-третьих, Go вообще не пересекается с Rust. У них принципиально разные подходы к памяти и прочим вопросам. С этой точки зрения Go работает скорее как Java.
В-четвёртых, да, Rust решает большинство проблем безопасности памяти: memory leaks, use after free, конфликты в одновременной модификации памяти из разных тредов.
no subject
Date: 2022-12-25 09:03 pm (UTC)Молодой человек, я в религиозных войнах не участвую так быть нахалом и тем более идиотом, не намерен…
no subject
Date: 2022-12-25 08:46 pm (UTC)Предлагаю его просто игнорировать. Выглядит как фидошный троллинг образца 2002 года.
no subject
Date: 2022-12-25 08:49 pm (UTC)no subject
Date: 2022-12-25 09:05 pm (UTC)no subject
Date: 2022-12-25 09:07 pm (UTC)no subject
Date: 2022-12-25 09:10 pm (UTC)no subject
Date: 2022-12-25 09:47 pm (UTC)no subject
Date: 2022-12-25 09:04 pm (UTC)Вычеркнул, без всякого сожаления…