Rust 0.10

А я про то и говорю, что одинаковый.

Тогда кто и зачем будет изобретать libuv? Люди будут писать на стандартном Rust и выбирать тот рантайм, который им подходит.

Надеюсь, что в каком-то виде поддержка асинхронного ввода-вывода появится до того, как 1.0 вылупится

Не припомню в rust-dev@ особых планов относительно асинхронности. Насколько я понимаю, в Rust принята модель Erlang - куча дешевых блокирующихся процессов (задач Rust).

на фоне Go Rust выглядит несостоятельно

А Go уже запускается на микроконтроллере? Да хотя бы на bare iron? Модули ядра на нем уже пишут?

в Rust принята модель Erlang - куча дешевых блокирующихся процессов (задач Rust)

А процессы насколько дешёвые остались? Они же выпилили segmented stacks, значит как минимум по потреблению памяти libgreen нифига не green выходит.

А Go уже запускается на микроконтроллере?

Да кому это нужно. Ну ок, во всяком случае не мне

Модули ядра на нем уже пишут?

Пишут

Эти идеи сами по себе не связаны с ООП. А то у тебя и в Haskell ООП появится с таким подходом. ООП бывает, очень грубо говоря, двух видов - с наследованием(или множественным или одиночным, разбавленным интерфейсами с миксинами) и с прототипами. Разницу между статическими и динамическими подходами к проверке типизации в данном случае можно опустить. То, что почти в любом языке можно писать в ОО-стиле не означает, что ООП поддерживается в языке или, тем более, что язык является ОО.

golang.org/doc/faq#Is_Go_an_object-oriented_language

Rust чем-то сильно отличается в этом плане от Go? Кстати, в документации по rust не нашёл ничего про ООП. Наверное, плохо искал.

static.rust-lang.org/doc/0.10/complement-lang-faq.html#is-it-oo?-how-do-i-do-this-thing-i-normally-do-in-an-oo-language?

0.3 Is it OO? How do I do this thing I normally do in an OO language?

It is multi-paradigm. Not everything is shoe-horned into a single abstraction. Many things you can do in OO languages you can do in Rust, but not everything, and not always using the same abstraction you're accustomed to.

Ещё вопросы?

Я знал, что плюсовики в конце концов скажут «хотим Тьюринг-полные шаблоны».

Причём сдесь Тьюринг-полнота? Все те извращения (как бы «метапрограммирование»), что на шаблонах делают, в идеале делать лучше на специальном инструменте - (нормальных) макросах. Правда не знаю, что из себя они в Расте представляют.

Я несколько про другое. В С# (и джаве, вроде) в генериках можно писать код, который должен быть валиден для ВСЕХ типов. В С++ - нет, в итоге обобщённое программирование гораздо удобнее.

Но нужно быть до конца честными: «Хотим всё, как в Си++, только лучше» %)

Не отказался бы. Впрочем, вариант «совсем не так, но не хуже» тоже подходит.

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

Если ты в обобщенной функции хочешь использовать какой-то метод для объекта типа T, ты ты должен указать трэйт с таким методом (Shape, в данном случае).

То есть подсунуть в метод «что-то» с таким методом, но без данного трейта не получится?

В С++ можно и в этом есть свои преимущества. В D можно даже именно наличие метода проверять. Чем подход раста отличается от обычных интерфейсов мне не очень понятно.

Чего плохого в отсылках к документации?

Ничего, просто я с языком очень слабо знаком. Боялся, что придётся сильно глубоко вникать, а пока на это нет времени.

It is multi-paradigm. Not everything is shoe-horned into a single abstraction. Many things you can do in OO languages you can do in Rust, but not everything, and not always using the same abstraction you're accustomed to.

Ещё вопросы?

Ага. Вот посмотри, что тут пишут: http://stackoverflow.com/questions/3498730/why-is-c-not-an-object-oriented-la...

C++ is usually considered a «multi-paradigm» language. That is, you can use it for object-oriented, procedural, and even functional programming. It is certainly true that C++ isn't OO to the same extent as Smalltalk, Ruby, Self, etc. are, but it is definitely an effective OO language by most standards.

Так что оба языка отступают от канонов фанатичного труЪ ООП. И Rust в плане поддержки ООП ничуть не хуже C++: в нём есть все средства и сахар для того, чтобы писать программы в терминах объектов.

Ну это просто частное мнение. У C++ есть явная поддержка ООП, есть литература и пр. В отличие от.

У C++ есть явная поддержка ООП

У Rust также есть явная поддержка ООП. http://static.rust-lang.org/doc/master/tutorial.html

Rust supports writing code in procedural, functional and object-oriented styles.

Так что оба языка отступают от канонов фанатичного труЪ ООП

Ну это просто частное мнение. У C++ есть явная поддержка ООП

Это «частное мнение» разделяет и сам создатель языка С++ — Бьёрн Страуструп. Например, вот тут он явно противопоставляет «True OO» и «C++»: http://www.youtube.com/watch?v=YQs6IC-vgmo#t=390

А Go уже запускается на микроконтроллере?

Да кому это нужно

Значит, не запускается.

Модули ядра на нем уже пишут?

Пишут

Пруфлинк?

Они же выпилили segmented stacks, значит как минимум по потреблению памяти libgreen нифига не green выходит.

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

В С# (и джаве, вроде) в генериках можно писать код, который должен быть валиден для ВСЕХ типов

Ы? Имеется в виду SFINAE или что?

(с сотен байт до страницы)

Пока страница 4KB, это ещё нормально. Но уже сейчас на серверах с очень много RAM HugePages используют, дабы TLB не насиловать. Там уже страница 2MB. Как дела в Windows и OS X обстоят я не знаю, не интересовался никогда. Получается, что в настоящий момент libgreen очень сильно завязан не только на ОС, но ещё и на особенности настройки этой ОС. libnative — это хорошо и правильно. Но мне лично очень хотелось бы, чтобы Rust мог работать как статически типизированный Erlang, ещё и без VM работающий. А они ещё возьмут и вообще M:N модель выпилят :)

huge_pages без поддержки софта тебе в место 4кбайт никто не сунет.

Да что ты говоришь. А в Red Hat не знали, и в RHEL 6 Transparent Huge Pages есть. Другой вопрос в том, что есть проблемы с производительностью в том же Oracle и есть рекомендация настраивать huge pages вручную. Однако вектор движения ясен. 4KB для текущих объёмов RAM _уже_ мало, в будущем TLB вообще колом встанет со страницами такого размера.

И как это отменяет тот факт, что libgreen очень сильно завязан на особенности ОС? Не должно быть этого.

в RHEL 6 Transparent Huge Pages есть

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

И как это отменяет тот факт, что libgreen очень сильно завязан на особенности ОС?

А с каких пор это стало фактом?

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

Это было ответом на то, что без поддержки со стороны софта huge pages вообще никак нельзя задействовать. Можно, но работает оно пока что хреново :P

А с каких пор это стало фактом?

С тех пор, как в Rust решили всё спихнуть на ОС, которая пусть сама страницами рулит? При странице в 4KB и в 2MB можно таки разное число задач заспаунить при такой схеме, какими бы лёгкими сами задачи ни были. Это уже особенность, зависящая от конкретной настройки конкретной ОС.

При странице в 4KB и в 2MB

Под кроватью нет монстров. Монстры существуют, кровать есть, а вот монстров под ней нет.

Ты вырываешь из контекста. Открой его книги по C++ и сам все поймешь :) Тут же он с теоретиками спорит.

Ы? Имеется в виду SFINAE или что?

Имеется в виду, что если нужных «constraint»-ов не завезли, то облом. Например, «+» в генерике не вызвать.

если нужных «constraint»-ов не завезли, то облом. Например, «+» в генерике не вызвать

А Си++ умеет волшебным образом находить «+»? В общем, пример бы.

А Си++ умеет волшебным образом находить «+»?

Шаблоны раскрываются на этапе компиляции (думаю ты это и так знаешь), соответственно когда типы подставляются, то да - компилятор может посмотреть есть ли для них плюс. Если нет, то будет ошибка компиляции. В случае вложенных шаблонов ошибка будет многословная - за это С++ часто ругают.

Явные ограничения (контракты) часто были бы удобны (может и будут).

В С# следующее просто не скомпилится. «Потому что нельзя».

static T generic_add<T>(T a, T b)
{
  return a + b;
}

Ну и просто список ограничений генериков можно посмотреть.

http://static.rust-lang.org/doc/master/std/ops/index.html

fn s<T: Add<T, T>>(a: T, b: T) -> T {
        a + b
}

fn main() {
        println!("{}", s(1, 2));
}

?

Мне вопрос про дженерики в Ржавчине и шаблоны в С++ чем-то напоминает древние срачи про неконтролируемое использование goto vs нормальное структурное программирование.

Мне вопрос про дженерики в Ржавчине и шаблоны в С++ чем-то напоминает древние срачи про неконтролируемое использование goto vs нормальное структурное программирование.

это было бы так, если б шаблоны С++ не были бы таки более продвинутыми, вот, например, есть ли в rust аналог variadic templates?

Дженерики в Ржавчине и не должны быть такими же навороченными, как плюсовые шаблоны. Дженерики просты, как деревяшка, и подходят для большей части обощенного кода.

А если тебе нужны сложные штуки, то ты используешь макросы, которые в ржавчине на порядок более полезны, чем в Си или С++.

Дженерики просты, как деревяшка, и подходят для большей части обощенного кода.

так это же описание goto ;)

А если тебе нужны сложные штуки, то ты используешь макросы, которые в ржавчине на порядок более полезны, чем в Си или С++.

ну вот, например, мне для тестов нужно было генерировать бинарное представление произвольных данных, завел такой класс (убрал «лишний» код для примера):

/**********************************************************************************************/
struct blob_factory
{
    template<class... Args>
    blob_factory( Args... tail )
    {
        add( tail... );
    }

    template<class T>
    void add( T value )
    {
        size_t sz = buf_.size();
        buf_.resize( sz + sizeof(T) );

        *((T*) &buf_[ sz ]) = value;
    }

    void add( item_type t )
    {
        buf_.push_back( (char) t );
    }

    void add( const char* value )
    {
        while( *value )
            buf_.push_back( *value++ );
    }

    void add( const char16_t* value )
    {
        while( *value )
            add( *value++ );
    }

    template<class T, class... Args>
    void add(
        T       value,
        Args... tail )
    {
        add( value );
        add( tail... );
    }

    std::vector<char> buf_;
};

использую так:

blob_factory(
    '\0',
    item_type::object,
        int32_t( 4 ), u"benv",
        int32_t( 3 ), u"bdc",
        item_type::list, int32_t( 2 ),
            item_type::boolean, (char) false,
            item_type::integer, int64_t( 1 ) )

покажи пример на макросах rust, ну или без них

В общем, пописал на русте неделю-другую - и, честно, не знаю, на что им нужно понамекать, чтобы предельно откровенно представить оценку ненужности этого костыля-велосипеда?

Хм, т.е. нужен серелизатор в бинарный формат? Есть пример для ebml, но он несколько громосткий (стандартная бмлиотека, все-таки, а не домашний костыль): https://github.com/mozilla/rust/blob/master/src/libserialize/ebml.rs

Вызывается так же, как json-серелизатор: http://static.rust-lang.org/doc/master/serialize/json/index.html#using-autose...

Если тебе интересно, то как будет время, попробую расковырять libserialize/ebml.rs и написать чего-то копактное и более близкое к твоему коду на плюсах.

Хм, т.е. нужен серелизатор в бинарный формат?

а как на rust будет выглядеть вызов:

blob_factory(
    '\0',
    item_type::object,
        int32_t( 4 ), u"benv",
        int32_t( 3 ), u"bdc",
        item_type::list, int32_t( 2 ),
            item_type::boolean, (char) false,
            item_type::integer, int64_t( 1 ) )

?

Наверное, чего-то вроде:

let bin_data: Vec<u8> = make_blob!(
    ...
    4u32,
    "benv",
    3u32,
    "bdc",
    ...
);

Наверное, чего-то вроде:

логично, спасибо

И на этом кусочке фекали пишут этот ваш servo… Сильные ребята.

Если этот язчишка о чём-то и говорит, то ни о чём.

Допустим, вот такой вариант:

$ cat test.rs

#![feature(macro_rules)]
#![feature(phase)]

trait ToBin {
    fn to_bin(&self, v: &mut Vec<u8>);
}

impl ToBin for u8 {
    fn to_bin(&self, v: &mut Vec<u8>) {
        v.push(*self);
    }
}

impl ToBin for char {
    fn to_bin(&self, v: &mut Vec<u8>) {
        v.push(*self as u8);
    }
}

impl<'a> ToBin for &'a [u8] {
    fn to_bin(&self, v: &mut Vec<u8>) {
        for c in self.iter() {
            v.push(*c as u8);
        }
    }
}

impl<'a> ToBin for &'a str {
    fn to_bin(&self, v: &mut Vec<u8>) {
        for c in self.as_bytes().iter() {
            v.push(*c as u8);
        }
    }
}

macro_rules! to_blob(
    ($($obj:expr),*) => ({
        let mut v = Vec::new();
        $($obj.to_bin(&mut v);)*
        v
    })
)

fn main() {
    {
        let mut v = Vec::new();
        0u8.to_bin(&mut v);
        'a'.to_bin(&mut v);
        "abcABC".to_bin(&mut v);
        [4, 0, 4].to_bin(&mut v);
        println!("1: {}", v);
    }
    {
        let v = to_blob!(
            0, 'a', "abcABC", [4, 0, 4]);
        println!("2: {}", v);
    }
}

// vim: set tabstop=4 shiftwidth=4 softtabstop=4 expandtab:

$ rustc test.rs && ./test
1: [0, 97, 97, 98, 99, 65, 66, 67, 4, 0, 4]
2: [0, 97, 97, 98, 99, 65, 66, 67, 4, 0, 4]
$ 

Хм, «#![feature(phase)]» тут не нужно.

?

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

goto тут вообще не при делах. Впрочем, ты же ярый противник исключений, так что не удивительно.

Я тут, кстати, на статейку наткнулся, которую недавно накидал Брендан Забарускас, который явно намного лучше меня знает Ржавчину:

https://gist.github.com/bjz/9220415#file-cpp-templates-vs-rust-generics-md

ты же ярый противник исключений

Я не противник идеи исключений вообще. Мне они не нравятся в плюсах и подобных языках. В питоне, допустим, они довольно органично смотрятся.

        0u8.to_bin(&mut v);
        'a'.to_bin(&mut v);
        "abcABC".to_bin(&mut v);
        [4, 0, 4].to_bin(&mut v);

слишком много копипасты

Это пример без макроса, а ниже аналогичный пример с макросом to_blob!, который копипасту и скрывает. Или я тебя не понял.

а ниже аналогичный пример с макросом to_blob!, который копипасту и скрывает

точно, сорри, читаю иногда наискосок и вполглаза, вобщем буду ждать версию rust постабильней, чтоб попробовать

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

Отсюда и твое же не понимание разницы концептов и ограничений на дженерик-параметры в расте. Концепты накладывают ограничения на тип, ограничения дженериков в расте - на объект типа. Та же принципиальная разница между концептами и ОО/go интерфейсами.

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

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

Мне они не нравятся в плюсах и подобных языках. В питоне, допустим, они довольно органично смотрятся.

В чем принципиальная разница между питоновскими и плюсовыми исключениями?

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

Дженерики тоже являются «средством генерации». Не таким гибким, но вполне средством.

Концепты накладывают ограничения на тип, ограничения дженериков в расте - на объект типа.

Type bound в Rust- это ограничения именно на тип.

Кстати, дженерики дороговаты для системного языка

Чем же? То, что дженерики умеют, они умеют насктолько же эффективно, насколько и шаблоны.

Дженерики тоже являются «средством генерации». Не таким гибким, но вполне средством.

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

Type bound в Rust- это ограничения именно на тип.

Только синтаксически. Фактически ты описываешь свойства, связанные с объектом, а не типом. Так, ты не сможешь сказать в bound'е, что тип должен иметь нужный вложенный тип, например. В концептах - можешь.

Чем же? То, что дженерики умеют, они умеют насктолько же эффективно, насколько и шаблоны.

Ссылочностью. По шаблону компилятор создает код для каждого типа, дженерик же работает с ссылкой и пр. В .NET для встроенных типов и структур jit делает тоже самое, кстати. Нативный язык это сделать не сможет, а llvm о дженериках ничего не знает.