Rust 0.12

Тебе должен понравиться Cobol.

Ты про stacktrace не знаешь что-ли, петушок?

Btw, а я правильно понимаю, что в язык и не собираются запиливать поддержку виртуальных функций и исключений? Вообще это даже скорее хорошо.

Исключения пытаются изобразить макросами, виртуальные функции обсуждаются в рамках предложений по ООП.

Понятно, спасибо.

Хм, тут много раз вызывается малюсенькая процедура... А если #[no_stack_check] перед fib добавить?

#[no_stack_check]
fn fib(n: int) -> int {
    if n <= 1 { n } else { fib(n - 1) + fib(n - 2) }
}
fn main() {
    let n = 45i;
    println!("fib({}) = {}", n, fib(n));
}

Или #[no_split_stack], если компилятор «старый».

... виртуальных функций ...

Эм, а куда их впиливать, если в языке нет наследования? И зачем они нужны, если трейты примерно то же самое могут?

И зачем они нужны, если трейты примерно то же самое могут?

Dynamic dispatch же.

Эм, а куда их впиливать, если в языке нет наследования?

Это пока...

http://is.gd/RTzXpy ?

Нет, это лишь статик. Засунь ты указатели на фигуры в вектор и посчитай площадь в foreach, вот тогда это было бы динамик.

Трейты могут и dynamic dispatch

Нет, это лишь статик.

Эээм, почему? Статическая диспечеризация была бы в этом случае:

fn print_area_static<T: HasArea>(shape: T) {
    println!("This shape has an area of {}", shape.area());
}

Засунь ты указатели на фигуры в вектор и посчитай площадь в foreach, вот тогда это было бы динамик.

Ну ок, вот:

http://is.gd/t6RyaR

let v: Vec<&HasArea> = vec![&c as &HasArea, &s as &HasArea];
for &shape in v.iter() {
    print_area(shape);
}

Хм, не знал. Это меняет дело. А где можно почитать о том как это устроено?

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

http://www.rustforrubyists.com/book/book.html

Или, внезапно, http://doc.rust-lang.org/0.12.0/guide.html и http://doc.rust-lang.org/0.12.0/reference.html

Ну в случае первого примера оф. гайд говорит, что применяется статическая: When we use this trait with Circle and Square, Rust ends up generating two different functions with the concrete type [...] But as you can see, there's no overhead of deciding which version to call here, hence 'statically dispatched.' А за второй пример спасибо, не знал.

Every trait item (see traits) defines a type with the same name as the trait. This type is called the object type of the trait. Object types permit «late binding» of methods, dispatched using virtual method tables («vtables»). Whereas most calls to trait methods are «early bound» (statically resolved) to specific implementations at compile time, a call to a method on an object type is only resolved to a vtable entry at compile time. The actual implementation for each vtable entry can vary on an object-by-object basis.

Ок, вопрос отпал.

Есть разница между:

fn print_area(shape: &HasArea) { /*не важно*/ }

и

fn print_area_static<T: HasArea>(shape: T) { /*не важно*/ }

В руководстве рассматривается второй вариант, а у меня по обоим ссылкам на play.rust-lang.org был первый.

посоны, дабы не плодить сущности - если вот просто для себя для расширения кругозора - что выбрать, ocaml или sml?

Второй вариант помог (0.12.0). Даже чуток перегнал clang, не знаю, как там с gcc дело будет. Вера в язык укрепилась, спасибо :)

В руководстве рассматривается второй вариант, а у меня по обоим ссылкам на play.rust-lang.org был первый.

Да, я не заметил, ты прав. Однако уже при -O2 на деле всё же применяется статическая (заодно и инлайнится всё, что можно). Круто, что сказать.

#[no_stack_check]

Где ты его надыбал?
Что-то не нашёл у них в доке этот атрибут.

Потому что мне писать программы и я не хочу продираться через тучи скобок.

Ты же в курсе, что в сишном синтаксисе скобок не сильно меньше, просто они не так расположены, да?

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

Нифига себе, успокойся) Вроде никто к тебе не лез с «единственно правильном путем» в стиле уличных проповедников в этой теме. Ты у меня спросил, как я себе представляю запись выражения без инфиксных операторов - я тебе два варианта написал и аноним про лиспы сказал (пускай и не в самой вежливой форме, но мы же на лоре).

Я выразил своё отношение к лиспу и больше дискутировать на эту тему не хочу.

Ок, перестаю развивать эту тему.

А почему бы тогда не писать на брейнфаке?

Хм, главное тут, думаю, это отсутствие нормальных средств построения абстракций. Так-то он мне изувеченный Форт всегда напоминал - тоже конкатенативный, пускай и не стековый - а Форты - очень интересное семейство языков.

... APL ...

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

Да видел в чужом коде давно еще - https://github.com/search?l=rust&q=no_split_stack&type=Code , пару раз в irc мелькало - https://botbot.me/mozilla/rust/search/?q=no_split_stack и есть парочка задач на гитхабе, типа https://github.com/rust-lang/rust/issues/8345 .

А документация про него не помешала бы, я бы сам нормальному объяснению был бы рад - не до конца понимаю, что оно делает. Как я понял - в начало каждой функции вставляется небольшая проверка, что стек не кончился и вызов функции обработчика, если это все-таки произошло. Но я не уверен)

upd: Вот еще эту ссылку нашел http://www.reddit.com/r/rust/comments/1t1s1k/this_week_in_rust_16_dec_2013/ce... . Выглядит более-менее актуально.

Конечно же нет, толстяк, никому такое не нужно :) .

Но, кстати, с неделю назад произошли довольно интересные изменения с глобальными переменными: https://github.com/rust-lang/rfcs/blob/bacdc4129/text/0246-const-vs-static.md . Наконец-то нормально разделили глобальные переменные (с реальным адресом в памяти) и глобальные константы (которые просто значение):

This change is an implementation of RFC 69 (ха-ха) which adds a third kind of global to the language, const. This global is most similar to what the old static was, and if you're unsure about what to use then you should use a const.

The semantics of these three kinds of globals are:

* A const does not represent a memory location, but only a value. Constants are translated as rvalues, which means that their values are directly inlined at usage location (similar to a #define in C/C++). Constant values are, well, constant, and can not be modified. Any «modification» is actually a modification to a local value on the stack rather than the actual constant itself.

Almost all values are allowed inside constants, whether they have interior mutability or not. There are a few minor restrictions listed in the RFC, but they should in general not come up too often.

* A static now always represents a memory location (unconditionally). Any references to the same static are actually a reference to the same memory location. Only values whose types ascribe to Sync are allowed in a static. This restriction is in place because many threads may access a static concurrently. Lifting this restriction (and allowing unsafe access) is a future extension not implemented at this time.

* A static mut continues to always represent a memory location. All references to a static mut continue to be unsafe.

Э-э-э. а какой третий?
const, static, ...?

Э-э-э. а какой третий? const, static, ...?

и static mut.

A static mut continues to always represent a memory location. All references to a static mut continue to be unsafe.

А. Ясно.

все-таки в ржавчине поощряется явная проверка ошибок

Насчёт длины спорить не буду, хотя как минимум в некоторых места, по моему, раст должен выигрывать (речь про сложные шаблоны). Но сам аргумент мне кажется странным. Если а плюсах забивают на обработку ошибок, то код (в большинстве случаев) будет работать неправильно (ну или «плохо»). А зачем сравнивать рабочий код с нерабочим?

Думаешь, в этом языке что-то магическое, что привлекает особенно «увлеченных»?

А разве нет? Лисп часто позиционируют как «очень гибкий и не ограничивающий язык». А это ведь лестно для впечатлительных личностей. Мол - могу любые навороты делать, а не писать «бойлерплейт на джаве/плюсах». Другое дело, что они это использовать не будут.

Про профессионалов, которые действительно всё это используют ничего плохого не скажу.

Ну и подобная фигня не только лиспа касается. Точно так же, есть люди, которые «признают только С/С++» - типа на других языках они не смогут «выжать всю производительность» и виртуальные машины и сборка мусора тормозят. И аналогично, люди использующие такие аргументы, могут писать какую-нибудь фигню, где всё это и не нужно.

На сколько помню после 0.12 должна идти 1.0, а тут 0.13. То есть до релиза ещё ~6 месяцев. Или я ошибаюсь?

Я про 0.13 ничего не знаю, только многократно видел заявления, что планируют выпуск стабильной версии в начале 2015ого. Чего-то в духе «если все будет ок, то в начале 2015 выкатываем бету и вскоре, если в бете не найдется больших косяков, выпускаем стабильную версию».

Как не знаешь? 0.13 сейчас Nightly.

Ну хорошо, только что оно «0.13.0-nightly» и знаю. Только это ничего не значит: может, около декабря и правда выпустят 0.13 версию, может, 0.13 не выпустят до января, а там ее переобзовут в 1.0 RC. Или еще что, я без малейшего понятия про судьбу 0.13)

А откуда ты про шесть месяцев взял?

Выпуск одного релиза происходит за ~3 месяца => 3 месяца(0.13) + 3 месяца (1.0) = 6. Как-то так)