Здравствуйте, Кодёнок, Вы писали:
Кё>Borrowed-check анализ обеспечивает compile-time memory safety указателей без использования GC, абстракций и любых прочих накладных расходов, в чем и заключается главная фишка и инновационность всего языка. Разумеется это важнее чем какой-то минорный фетиш из функционального программирования, поэтому если концевая реткурсия его усложняет — на нее тупо забили.
Попробуй еще раз (последний, так как времени жалко) объяснить...
Любая функция с концевой рекурсией может быть очень легко преобразована в аналогичную функцию содержащую цикл. Преобразование делается еще на нетипизированном АСТ. Соответственно все проверки (включая memory safety) делаются на преобразованной функции.
Циклы их алгоритм умеет проверять? Ну, вот, значит, и тут у них проблем не будет.
Сложнее с взаимнорекурсиными функциями. Но на них как раз можно забить, так как они на практике не часто используются.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Lazin, Вы писали:
L>А как же указатели? Не все так просто, если функция получает или возвращает указатели, но тут еще нужно обеспечить, чтобы результат не менял время их жизни. В Си и С++ TCO реализуется далеко не тривиально а здесь должно быть еще сложноей.
Хм..., на Rust смотрю редко, и всё как-то откладывал на потом разобраться с его системой Typestate. И только сейчас заметил, что её ликвидировали. Заметка по этому поводу: Typestate Is Dead, Long Live Typestate!. В принципе, предложенная там альтернатива — "branding pattern" — не плоха и проста (что, имхо, самое главное). Но есть справедливо подмеченный в статье минус — требуется создание нового объекта с новым типом. Имхо, в системном языке однозначно нужны способы для аллокации "по месту", и, в целом, без custom-аллокаторов не обойтись. С учётом "Removing Garbage Collection From the Rust Language", имхо, в языке ещё явно не устаканена семантика модели памяти, и изменения ещё будут, и, скорее всего, в синтаксисе тоже, хотелось бы с поддержкой "пересоздания" объектов и своих аллокаторов.
Здравствуйте, PSV100, Вы писали:
PSV> имхо, в языке ещё явно не устаканена семантика модели памяти, и изменения ещё будут, и, скорее всего, в синтаксисе тоже, хотелось бы с поддержкой "пересоздания" объектов
Основные концепции, такие как разделение на общую память и память задачи, а так же особенности работы с указателями, мне думается, уже устаканились. Хотя, что-то еще будет меняться, само собой.
PSV>и своих аллокаторов.
Здравствуйте, kaa.python, Вы писали:
KP>Здравствуйте, PSV100, Вы писали:
PSV>> имхо, в языке ещё явно не устаканена семантика модели памяти, и изменения ещё будут, и, скорее всего, в синтаксисе тоже, хотелось бы с поддержкой "пересоздания" объектов
KP>Основные концепции, такие как разделение на общую память и память задачи, а так же особенности работы с указателями, мне думается, уже устаканились. Хотя, что-то еще будет меняться, само собой.
Как я понимаю (на основе высказываний от авторов проекта на счёт ликвидации GC), у разработчиков есть идеи отказаться от встроенных "@"-указателей. На оwned-указатели ("~") возлагают основную роль (или подталкивают к максимальному их использованию для аллокации объектов в хипе), на роль shared-указателей предполагают реализацию custom-типов как решения для конкретных потребностей (где-то нужен именно GC, в таких-то случаях лучше RC, кому-то нужно взаимодействие с COM, GObject и т.д. и т.п.). Но, для custom-указателей нет поддержки со стороны языка как для встроенных (автоматическое их приведение к borrowed-ссылкам, например, в параметрах при вызове функции, оператор разыменования "*" и т.д.). Вероятно, возникнет потребность в поддержке какого-нибудь протокола (как для "for") через спец-trait, чтобы custom-указатели выглядели как встроенные.
PSV>>и своих аллокаторов.
KP>Я не уверен, но вот это не то?
Ага, типа оно. Вскользь (без детальных разбирательств) глянул на внутреннюю реализацию этой "арены". Первое, что обращает на себя внимание, это то, что внутри используются массивы байтов как @[u8], т.е. как "shared"-данные, при этом, фактически, массивы есть "приватные" данные, вроде как, ни с кем не разделяемые, плюс компилятором наверняка создаётся оверхед в виде неявного объекта а-ля "RC" (или чего-то иного), т.е. как для всех встроенных @-указателей. Видимо, есть причины для этого из-за особенностей используемых там низкоуровневых хаков. К тому же стандартная библиотека тоже подталкивает к @-box, например, те же используемые там стандартные списки, которые объявлены, соответственно и реализованы как "@":
enum List<T> {
Cons(T, @List<T>),
Nil,
}
Теоретически, списки должны быть более абстрактны, т.е. как-то по таким мотивам:
Т.е. через регионы (или lifetime) компилятор должен отслеживать корректность жизни создаваемых списков, и есть возможность через потенциальные shared-указатели (речь о которых была выше) реализовать списки с произвольной аллокацией объектов. Имхо, с устаканиванием основных концепций библиотеки вероятно будут преобразованы к нужному виду.
И второе, в этой "арене" используется RTTI (в частности, выясняется, есть ли явный деструктор у типа аллоцируемых данных), причём именно в рантайме. Т.е., как я понимаю, в создаваемых бинарниках, фактически, всегда создаётся куча RTTI-данных, которые в 99% прикладного кода, скорее всего, не будут использоваться. При этом внутри стандартной библиотеки (о которой создаётся впечатление, что RTTI задействована на всю катушку) основная масса операций с RTTI, теоретически, должна выполняться во время компиляции. К примеру, эта "арена" для объектов с деструкторами и без использует разные блоки памяти для оптимизации, но, формально, ведь всё известно во время компиляции, и для рантайма не нужно создавать лишнего кода.
Имхо, вроде как заявлено, что в будущем возможны плагины для компилятора и пр. Короче говоря, вроде как есть надежды на продвинутые compile-time вычисления, м.б. даже на полноценное метапрограммирование, с квазицитированием (хотелось бы, во всяком случае).
Ну, а основной положительный момент в том, что такие фундаментальные вещи как аллокаторы, указатели, управление task-ами и др. не вбиты насмерть в компилятор (имхо, всё-таки, гибкости ещё добавят), и, вроде как, есть возможность для реализаций под конкретные потребности.
Здравствуйте, kaa.python, Вы писали:
KP>Здравствуйте, kaa.python, Вы писали:
KP>Слайды с выступления Nicholas Matsakis "Guaranteeing memory safety in Rust". Познавательно.
Спасибо. Полезно то, что в одном месте указаны основные принципы вокруг ссылок и указателей. Уж для полноты картины не хватает описания "move/copy"-семантики передачи объектов при вызове функций, описание моментов, когда происходит неявный вызов "clone()" и "deep_clone()" и т.п.
Здравствуйте, PSV100, Вы писали:
PSV>Как я понимаю (на основе высказываний от авторов проекта на счёт ликвидации GC), у разработчиков есть идеи отказаться от встроенных "@"-указателей.
А может они просто решили закопать так и не родившийся GC? Изначально был расчет что GC вот-вот появится и он даже пилился в параллельной ветке, но, видимо, не срослось
PSV> На оwned-указатели ("~") возлагают основную роль (или подталкивают к максимальному их использованию для аллокации объектов в хипе), на роль shared-указателей предполагают реализацию custom-типов как решения для конкретных потребностей (где-то нужен именно GC, в таких-то случаях лучше RC, кому-то нужно взаимодействие с COM, GObject и т.д. и т.п.). Но, для custom-указателей нет поддержки со стороны языка как для встроенных (автоматическое их приведение к borrowed-ссылкам, например, в параметрах при вызове функции, оператор разыменования "*" и т.д.). Вероятно, возникнет потребность в поддержке какого-нибудь протокола (как для "for") через спец-trait, чтобы custom-указатели выглядели как встроенные.
А вот намеков на такое я не заметил. Хотя, не сказать что очень уж внимательно слежу за обсуждениями, скорее по выходу очередного релиза смотрю что поменяли
PSV>Ну, а основной положительный момент в том, что такие фундаментальные вещи как аллокаторы, указатели, управление task-ами и др. не вбиты насмерть в компилятор (имхо, всё-таки, гибкости ещё добавят), и, вроде как, есть возможность для реализаций под конкретные потребности.
Управление тасками (я только в этом детально копался) зарыто глубоко в C++ части стандартной библиотеки. Что на мой взгляд самое что ни на есть "прибито гвоздями".
Здравствуйте, sysenter, Вы писали:
S>Можно подробнее, чем Rust лучше D?
Что бы подробнее, надо хорошо знать оба языка. А я слегка знаю Rust и почти вообще не знаю D
Моих знаний достаточно для того, что бы сказать следующее: у Rust модель памяти лучше подходит для написания многопоточный приложений (думаю, когда они дойдут до распределенных, модель памяти тоже окажется удачной), чем модель памяти D; у Rust хорошо продуманная модель взаимодействия между потоками (сказать лучше ли она имеющихся в D альтернатив я не могу). Ну и самое главное, у языка есть поддержка со стороны больших корпораций, в отличие от D.
Здравствуйте, kaa.python, Вы писали:
KP>Здравствуйте, PSV100, Вы писали:
PSV>>Как я понимаю (на основе высказываний от авторов проекта на счёт ликвидации GC), у разработчиков есть идеи отказаться от встроенных "@"-указателей.
KP>А может они просто решили закопать так и не родившийся GC? Изначально был расчет что GC вот-вот появится и он даже пилился в параллельной ветке, но, видимо, не срослось
PSV>> На оwned-указатели ("~") возлагают основную роль (или подталкивают к максимальному их использованию для аллокации объектов в хипе), на роль shared-указателей предполагают реализацию custom-типов как решения для конкретных потребностей (где-то нужен именно GC, в таких-то случаях лучше RC, кому-то нужно взаимодействие с COM, GObject и т.д. и т.п.). Но, для custom-указателей нет поддержки со стороны языка как для встроенных (автоматическое их приведение к borrowed-ссылкам, например, в параметрах при вызове функции, оператор разыменования "*" и т.д.). Вероятно, возникнет потребность в поддержке какого-нибудь протокола (как для "for") через спец-trait, чтобы custom-указатели выглядели как встроенные.
KP>А вот намеков на такое я не заметил. Хотя, не сказать что очень уж внимательно слежу за обсуждениями, скорее по выходу очередного релиза смотрю что поменяли
Ну, а я в сторону Rust смотрю очень редко, за сплетнями вокруг него, фактически, не слежу. Но, на основе той статьи на счёт GC, её обсуждения, в т.ч. и в некоторых форумах (лишь немного посмотрел), складывается впечатление, что вроде как GC выкидывать не будут (имхо, пока, скорее всего, не хватает ресурсов для качественной реализации). Основной посыл, как я понимаю, в том, что как бы не комильфо в системном языке иметь только одну встроенную политику shared-объектов, через custom-типы есть смысл реализовать разные smart-указатели, как аналог уже имеющимся Rc, ARC и т.д.
По поводу "... вероятно, возникнет потребность в поддержке какого-нибудь протокола (как для "for") через спец-trait, чтобы custom-указатели выглядели как встроенные" — это именно мое предположение. В самом деле, как-то муторно (по "сишному") писать всё "в лоб" а-ля:
Имхо, не хватает протокола для автоматического приведения custom-указателей к аналогам встроенных. При этом пусть останется "@"-указатель как реализация shared-указателя по умолчанию, которую можно будет настраивать через опции компиляции (на основе аннотаций "#[...]", возможно даже в разрезе модулей), если вдруг появятся разные варианты. И custom-указатели должны быть совместимыми по типу с "@"-box (а также и с "~"-box для соответствующих типов). Т.е. как-то так:
let p1 : @Point = @Point{ x: 3.0, y: 4.0 }; // нечто встроенное
let p2 : Rc<Point> = rc::new( Point{x: 5.0, y: 1.0} ); // какой-то RC-указатель
let p3 : Gc<Point> = gc::new( Point{x: 7.0, y: 9.0} ); // указатель под контролем некоего GC
let p1 = mut rc::new( Point{x: 5.0, y: 1.0} ); // функция rc::new() для mut-объектов возвращает RcMut<T> вместо Rc<T>
...
*p1 = ...; // поддержка разыменования
Но для этого нужна перегрузка функций по её результату, где разница определяется в зависимости от "mut" возвращаемого объекта.
Тогда и custom-аллокаторы а-ля "арены" можно тоже подогнать под одну гребёнку:
let arena = Arena();
...
let p1 = arena.new( Point{x: 5.0, y: 1.0} ); //арена возвращает какой-то custom-указатель, совместимый с "@"
PSV>>Ну, а основной положительный момент в том, что такие фундаментальные вещи как аллокаторы, указатели, управление task-ами и др. не вбиты насмерть в компилятор (имхо, всё-таки, гибкости ещё добавят), и, вроде как, есть возможность для реализаций под конкретные потребности.
KP>Управление тасками (я только в этом детально копался) зарыто глубоко в C++ части стандартной библиотеки. Что на мой взгляд самое что ни на есть "прибито гвоздями".
Пока да, прибито. Имхо, после первых релизов, если язык всё-таки получит признание, то разработчики однозначно вынужденны будут ваять такие ключевые вещи как плагины для компилятора, развитые полноценные compile-time вычисления и пр. (вроде как, если не ошибаюсь, были заявлены такие плюшки). К примеру, я не спец в области реализации "зелёных" потоков, их планировщиков и т.д., но вроде как для поддержки какого-нибудь soft-realtime через custom-scheduler для задач (task-ов) придётся в бинарном коде разбрасывать инструкции для дёргания scheduler-а (т.к. нет VM). Имхо, подобные трюки должны делаться через плагин к компилятору. Или потребуются реализации современных модных тенденций, как компиляция в JavaScript и т.п.
На счёт compile-time вычислений. Имхо, имеющиеся макросы слишком ограничены и какие-то муторные для их написания. И как-то нехорошо в сегодняшнее время затевать новый язык с претензиями на промышленность, когда вокруг уже можно насмотреться на много чего, при этом продолжать тянуть в runtime кучу RTTI и активно там же (в runtime) направо-налево её дергать. Например, в MetaLua есть наработки, которые применимы и для такого языка как Rust (имхо, пока лучше без поддержки расширения базового синтаксиса языка), те же удобные квазицитаты как +{} и -{}. И, к примеру, функцию alloc для тех же "арен" (которая должна быть "сверх-быстрой") можно было бы реализовать как-то так:
impl Arena {
...
#[inline]
pub fn alloc<'a, T>(&'a self, op: &fn() -> T) -> &'a T {
unsafe {
let this = transmute_mut(self);
-{
if intrinsics::needs_drop::<T>() +{ // проверку, имеет ли тип деструктор, делаем в compile-time
this.alloc_nonpod(op)
} else +{
this.alloc_pod(op)
}
}
}
}
...
}
Имхо, если и будут компиляторные плагины и выше подобные выкрутасы (а они должны быть, если замахиваться на современную промышленность, причём именно конкурентно), то, скорее всего, где-то в Rust 2.0 или выше.
Здравствуйте, kaa.python, Вы писали:
KP>Здравствуйте, kaa.python, Вы писали:
KP>Слайды с выступления Nicholas Matsakis "Guaranteeing memory safety in Rust". Познавательно.
можно ли делать ассемблерные вставки в код руста как в C++?
Здравствуйте, D. Mon, Вы писали:
DM>Здравствуйте, Grundik2, Вы писали:
G>>можно ли делать ассемблерные вставки в код руста как в C++?
DM>Он через LLVM компилится, так что вставки если и были бы, то только IR LLVM. Да и то вряд ли.
Здравствуйте, Grundik2, Вы писали:
DM>>Он через LLVM компилится, так что вставки если и были бы, то только IR LLVM. Да и то вряд ли.
G>ничего не понял почти.
Компилятор раста генерит не ассемблер, а чуть более высокоуровневый и типизированный его аналог — Intermediate Representation (IR) библиотеки LLVM, которая уже генерит машинный код для разных архитектур.
