Здравствуйте, techgl, Вы писали:
T>Вот интересное сравнение производительности, где Rust обходит C++ на нескольких (не всех) задачах. Интересен он тем, что во-первых, используются неэквивалентные подходы (зачем в первой задаче OpenMP, например), во-вторых код на Rust использует unsafe, что как бы намекает. Думаю, если правильно переписать решения на C++, то порядок будет наведен.
Но давай уж тогда честно скажем, что в решении на C++ там плюсами и не пахнет, там какой-то Си-с-классами
Здравствуйте, kaa.python, Вы писали:
KP>Здравствуйте, techgl, Вы писали:
T>>Вот интересное сравнение производительности, где Rust обходит C++ на нескольких (не всех) задачах. Интересен он тем, что во-первых, используются неэквивалентные подходы (зачем в первой задаче OpenMP, например), во-вторых код на Rust использует unsafe, что как бы намекает. Думаю, если правильно переписать решения на C++, то порядок будет наведен.
KP>Но давай уж тогда честно скажем, что в решении на C++ там плюсами и не пахнет, там какой-то Си-с-классами
M>>Зачем нужен mod name тогда? import "название файла" и вперед.
DE>А в чём принципиальная разница между этими вариантами?
В том, что файл — не модуль. И невозможно объявить, что вот этот конкретный файл — это модуль, который можно импортировать и т.п. Зачем-то вызывающий код должен объявить модуль, а затем его импортировать. Зачем? В чем смысл этого ненужного кода? Который вдобавок надо вручную повторять в каждом коде, который будет вызывать этот модуль.
A.rs
... какой-то код ...
B.rs
mod A
use A::что-то-там
C.rs
mod A
use A::что-то--там
Здравствуйте, Mamut, Вы писали:
M>В том, что файл — не модуль. И невозможно объявить, что вот этот конкретный файл — это модуль, который можно импортировать и т.п. Зачем-то вызывающий код должен объявить модуль, а затем его импортировать. Зачем? В чем смысл этого ненужного кода? Который вдобавок надо вручную повторять в каждом коде, который будет вызывать этот модуль.
Вручную повторять mod A; нужно только в одном месте крейта.
Фактически этим выражением мы просто вставляем в исходник содержимое файла A.rs
на псевдокоде mod A; можно выразить так:
mod A {
include!("A.rs");
}
Зато можно объявлять вложенные модули внутри любого файла, как пример тесты обычно
помещают в отдельный модуль:
fn div_s(a: i32, b: i32) -> Option<i32> {
if b == 0 {
None
} else {
Some(a / b)
}
}
#[cfg(test)]
mod test_main {
use super::*;
#[test]
fn test_1() {
assert_eq!(div_s(4, 2).unwrap(), 2);
}
}
Польза от таких модулей вполне заметная особенно при использовании условной компиляции,
ну и исключаем лишнюю сущность которая есть во многих языках namespace.
Вообще модули перекочевали в rust прямиком из OCaml и сохранили оттуда некоторые
странности, и к сожалению растеряли по пути свою первоклассность.
Здравствуйте, dsorokin, Вы писали:
D>Отвечая на главный вопрос, заданный в теме, нет, лично для меня Rust заменить не может C++ по той простой причине, что Rust не поддерживается на Эльбрусах. Show stopper как он есть.
Тут человек работающий над компилятором си для эльбруса пишет что портируют.
FR>Вручную повторять mod A; нужно только в одном месте крейта.
Во всех местах, где надо использовать mod.
FR>Фактически этим выражением мы просто вставляем в исходник содержимое файла A.rs FR>Польза от таких модулей вполне заметная особенно при использовании условной компиляции, FR>ну и исключаем лишнюю сущность которая есть во многих языках namespace.
Так в том-то и дело, что исходник не вставляем и namespace остается. Потому что нам нужно все равно делать потом use module::что-то-там (вот и namespace). Если бы действительно вставляли (аналог ОКамловского open), то можно было бы пользоваться функциями из модуля безо всякого use.
Условная компиляция к модулям, имхо, вообще не имеет отношения
FR>Вообще модули перекочевали в rust прямиком из OCaml и сохранили оттуда некоторые FR>странности, и к сожалению растеряли по пути свою первоклассность.
Похоже, что авторы Rust'а не поняли, что такое модулив ОКамле, и перетянули часть синтаксических особенностей без единой полезности.
Нет во всех местах где нужно использовать используешь use.
А mod можно (и необходимо) использовать только в ограниченных местах, это файл main.rs (lib.rs)
и файлы определяющие модули в папках (по умолчанию mod.rs).
В остальных местах будет ошибка компиляции.
Логика обязательного и не автоматического указания mod A; от меня тоже ускользает, но что есть
то есть.
FR>>Фактически этим выражением мы просто вставляем в исходник содержимое файла A.rs FR>>Польза от таких модулей вполне заметная особенно при использовании условной компиляции, FR>>ну и исключаем лишнюю сущность которая есть во многих языках namespace.
M>Так в том-то и дело, что исходник не вставляем и namespace остается. Потому что нам нужно все равно делать потом use module::что-то-там (вот и namespace). Если бы действительно вставляли (аналог ОКамловского open), то можно было бы пользоваться функциями из модуля безо всякого use.
open в OCaml это скорее аналог use. Там есть и include, который ближе к mod.
M>Условная компиляция к модулям, имхо, вообще не имеет отношения
Ну как раз с модулями ее и удобно использовать как замену для бедных параметризируемых
модулей.
FR>>Вообще модули перекочевали в rust прямиком из OCaml и сохранили оттуда некоторые FR>>странности, и к сожалению растеряли по пути свою первоклассность.
M>Похоже, что авторы Rust'а не поняли, что такое модулив ОКамле, и перетянули часть синтаксических особенностей без единой полезности.
Ну да потеряли много.
Но в общем то логичность модулей раста ничем ни хуже и не лучше чем в большинстве других
языков. Мелкие кривости есть практически у всех.
Здравствуйте, Mamut, Вы писали:
M>На той странице нет интересных сравнений производительности. Как и на любых синтетических бенчмарках. M>Интересны сравнения типа https://github.com/ixy-languages/ixy-languages
Есть ещё более интересные сравнения, на реальных примерах. Например, есть компрессор Brotli, реализованный Гуглом на С. Есть его копия на Rust от Dropbox. Если верить статье, то реализация на Rust менее эффективна, но безопасней:
So given the safety, determinism and correctness, the final cornerstone is the speed of the Rust-based decompressor. Currently the decompressor runs at 72% of the speed of the vanilla -O3 optimized Brotli decompressor in gcc-4.9 for decompressing 4 megabyte blocks of data. This means it is able to safely decompress Brotli data at 217 MB/s on a Intel(R) Core(TM) i7-4790 CPU @ 3.60GHz.
FR>Логика обязательного и не автоматического указания mod A; от меня тоже ускользает, но что есть FR>то есть.
Вот я про это и говорю. По какой-то непонятной причине модуль указывается не в модуле, а в коде, которые его вызывает.
FR>Но в общем то логичность модулей раста ничем ни хуже и не лучше чем в большинстве других FR>языков. Мелкие кривости есть практически у всех.
Имхо, Java с ее import x.y.z впереди планеты всей по удобству использования
Здравствуйте, Mamut, Вы писали:
M>Имхо, Java с ее import x.y.z впереди планеты всей по удобству использования
Это уже не совсем про модули, но в джаве ведь нет переименования при импорте? Я бы не назвал это удобным.
Здравствуйте, Mamut, Вы писали:
M>В том, что файл — не модуль. И невозможно объявить, что вот этот конкретный файл — это модуль, который можно импортировать и т.п. Зачем-то вызывающий код должен объявить модуль, а затем его импортировать. Зачем? В чем смысл этого ненужного кода? Который вдобавок надо вручную повторять в каждом коде, который будет вызывать этот модуль.
M>
M>A.rs
M>... какой-то код ...
M>B.rs
M> mod A
M> use A::что-то-там
M>C.rs
M> mod A
M> use A::что-то--там
M>
Непонятная проблема. Хорошим стилем было бы объявить модуль A единожды в соответствующем файле mod.rs, а дальше без проблем импортировать его через use в других модулях без лишнего объявления mod. Если объявить как положено, то компилятор Rust без проблем находит модуль.
К модулям это имеет нулевое отношение
DE>Ну и можно притянуть за уши облегчение рефакторинга, когда мы временно комментируем mod a вместо удаления/перемещения/переименования файла.
D>Непонятная проблема. Хорошим стилем было бы объявить модуль A единожды в соответствующем файле mod.rs, а дальше без проблем импортировать его через use в других модулях без лишнего объявления mod.
Сначала придумаем соверщенно неэргонмический способ объявления модулей. А потом вместо того, чтобы это починить, прилепим сверху костыль в виде mod.rs
D>Если объявить как положено, то компилятор Rust без проблем находит модуль.
M>>Имхо, Java с ее import x.y.z впереди планеты всей по удобству использования DE>Это уже не совсем про модули, но в джаве ведь нет переименования при импорте? Я бы не назвал это удобным.
Нет, переименования нет, но я бы не сказал, что это огромная проблема.
Здравствуйте, Михaил, Вы писали:
М>Кстати, любопытно, есть ли в природе серьезные low level проекты на расте? Встречал его только в файрфоксе.
Firecracker VM ( https://firecracker-microvm.github.io/ ).
Честно говоря, не понял. Возможно, потому что представляю, в первую очередь, то как растовые модули сейчас устроены и не понимаю как приведённый пример их чинит.
M>Што? Зачем удалять и т.п. файл?
Сейчас в расте модули в проекте (crate в терминах раста) представляют древовидную структуру, где корнем являет lib.rs/main.rs. Конструкция mod <имя_модуля> добавляет модуль в проект. Я отвечал на комментарий (если правильно его понял) о том, что это можно было бы делать автоматически, просто при наличии файла.
Вообще мне кажется, что мы несколько о разном говорим. Я всё-таки считаю, что mod — это не про импорт, а про построение структуры проекта. Импорт (из библиотек) или других модулей проекта делается вполне очевидно (через use).
