Road to Rust 1.0

О, где-нибудь через годик можно будет потыкать наконец-то этот ваш Rust

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

Пока они его не причешут для оффтопика

А какие там проблемы?

не наваяют нормальный IDE

Сомневаюсь, что они это будут (в ближайшее время) делать. Да и нафига отдельную ИДЕ? Достаточно поддержки в существующих.

Раз про офтопик заговорил, то вот тебе. Ну и для Intellij IDEA есть. Для Eclipse, вроде, тоже.

Понятно дело, что они сырыми будут, но так и язык ещё на ранней стадии. Зафиксируют его - поддержку в ИДЕ тоже проще будет делать.

Если на то пошло, то y D, например, поддержка тоже весьма так себе, а времени прошло явно больше. По моему, у раста сообщество более активно, особенно с учётом того на какой он стадии.

Не так давно дозрел до изучения языка...

пакетного менеджера Cargo

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

они собираются накачать его фичами до состояния C++11?

Типы переменного размера (DST)

что это и зачем, если есть Vec?

Ассоциативные типы (Associated types)

что это и зачем, если есть HashMap?

Раз про офтопик заговорил, то вот тебе.

Что «вот тебе»? руст под оффтопиком работает чуть лучше, чем никак, не далее как позавчера пробовал. Не хеловорды хватает, да.

Если на то пошло, то y D, например, поддержка тоже весьма так себе, а времени прошло явно больше. По моему, у раста сообщество более активно, особенно с учётом того на какой он стадии.

так у D на этой стадии поболе адептов и комунити было. даже в рунете. И D это Александреску с Брайтом, а не какие-то студенты из мозиллы. Это потом стало понятно, что они изобретают очередной C++, только немного другой.

И если уже про оффтопик заговорили, то dmd там изначально работал как надо, сейчас там gdc работает.

А как впилить зеленые потоки назад?

Crate green

Не хеловорды хватает, да.

Ну я (пока) только хеловорды и пробовал. Сегодня поэкспериментирую под офтопиком. А ссылка должна была показать, что для популярной под офтопиком ИДЕ есть плагин с поддержкой. Да, пока поддержка слабая.

И D это Александреску с Брайтом, а не какие-то студенты из мозиллы.

Тем не менее, за всё это время, Александреску похвастался всего парой строчек кода в продакшене. И это преподносится как мега достижение. А раст мозиловцы именно для реального использования пилят.

И если уже про оффтопик заговорили, то dmd там изначально работал как надо, сейчас там gdc работает.

Нее, речь-то про ИДЕ шла. И как там с этим? Плагин для D щупал - он недалеко ушёл (если вообще ушёл) от аналогичного для раста. И это при том, что раст до сих пор нестабильный.

Но вообще я не хотел холивар начинать. Просто какое-то время сам сильно на D надеялся. Потом разочаровался... А в расте (ещё) нет.

А раст мозиловцы именно для реального использования пилят.

Пилят, но не применяют? А Александреску применяет, но не пилит? Кхм..

Просто какое-то время сам сильно на D надеялся.

ну вот я и говорю, что на такой же стадии у D поболее адептов было и надежд.

разбудите, когда руст в ARM сможет. Пока буду с сишечкой спать.

Пилят, но не применяют? А Александреску применяет, но не пилит? Кхм..

Ну дык, язык немного не дорос до полноценного применения. Насчёт «не пилит» - не в курсе. Но на новости о развитии раста (или С++, скалы и т.д.) натыкаюсь постоянно. Про Д говорят меньше, про новые (пусть и эволюционные, как в С++) версии - вообще не видел. Да, специально не искал.

В общем, не хочу показаться каким-то фанатиком. Но с точки зрения человека, который слегка пощупал оба языка, мне кажется, что раст перспективнее. Пишу, в основном, на С++ и не вижу чем Д мне сильно поможет. Более того, Д уже успел обрасти всякими странностями, депрекейтнутыми фичами и прочими вещами от которых очень хотелось бы (но невозможно) избавиться в С++.

В расте тоже есть непривычные вещи, но есть и реальные плюсы. И главное - он мне (как «энтузиасту программирования») нравится. Достаточно ли этого для завоевания популярности? Хз, время покажет.

ну вот я и говорю, что на такой же стадии у D поболее адептов было и надежд.

На какой такой? Лично я D всерьёз заинтересовался не так уж давно. Казалось бы - было достаточно времени допилить и отполировать фичи, сделать поддержку в ИДЕ и т.д. Но что-то этого всего не видно. Да чего там говорить - на фоне «нового С++» Д уже не так привлекательно выглядит.

Если в расте после 1.0 не будут ломать совместимость, но продолжат расширять стандартную ббиблиотеку, то уже сделают больше, чем было для D сделано.

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

Пилят, но не применяют?

https://github.com/servo/servo

Ассоциативные типы (Associated types)

что это и зачем, если есть HashMap?

Я так понял, что не «ассоциативные», а «ассоциированные». https://github.com/rust-lang/rfcs/pull/195

Я как-то ставил плагин для Го на идею и он мне похерил настройки ждк (банально оставил только go runtime там, где нужно выбирать йава-сдк). С тех пор отношусь к такого рода плагинам с осторожностью.

Алсо, как в гугле относятся к расту на фоне «конкуренции» с го на поприще «низкоуровневой» писанины?

Почему в ответ на вопрос о применении Rust все кидают именно эту ссылку? Других ссылок на код на Rust вообще нету?

В го сборка мусора, о какой низкоуровневой писанине может быть речь?

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

С тех пор отношусь к такого рода плагинам с осторожностью.

Ну я идей почти не пользуюсь. Тем не менее, для скалы плагин нормально работал. Подозреваю, что от корявых плагинов никто не застрахован. Тем не менее, написать плагин намного проще, чем ИДЕ целиком.

Алсо, как в гугле относятся к расту на фоне «конкуренции» с го на поприще «низкоуровневой» писанины?

Хз, я не представитель гугла. (:

Могу только своё (поверхностное) мнение озвучить. Во первых, Го «немного» более высокоуровневый - сборка мусора всё-таки. Во вторых, меня он как-то вообще не заинтересовал.

Упрощение замыканий (Unboxed closures)

С каких пор «Unboxed» переводится как «упрощение»?

Других ссылок на код на Rust вообще нету?

Поищи на гитхабе, например.

Unlike C and other low-level languages, Go has built-in support for garbage collection. This is a feature that usually comes with higher level languages, but then they become slower too. Go gives you the speed of low-level languages as well as the frills of higher level languages.

В го сборка мусора, о какой низкоуровневой писанине может быть речь?

В Rust тоже сборка мусора и невозможность запустить произвольную функцию на Rust не из task'а Rust (что ставит крест на библиотеках для других языков).Подробности http://bluishcoder.co.nz/2013/08/08/linking_and_calling_rust_functions_from_c... последний абзац.

разбудите, когда руст в ARM сможет.

Бужу: https://github.com/neykov/armboot/

В Rust тоже сборка мусора

По-моему, у раста нет сборки мусора. Во всяком случае, не в том смысле что запускается gc и подчищает память.

У раста явная сборка мусора, т.е тип надо оборачивать в Gc<>. Ну как в C++, в общем.
На самом деле, сборка мусора просто не нужна, ибо RAII повсюду.

Во всяком случае, не в том смысле что запускается gc и подчищает память.

Там есть managed pointers. Раньше явно указывалось, что их использование включает GC. Затем написали, что вместо GC будет подсчёт ссылок (но «всё может изменится»).

На самом деле, сборка мусора просто не нужна, ибо RAII повсюду.

Если есть циклические ссылки, то подсчёта ссылок не хватает. Точнее их использование гарантирует наличие утечек памяти.

@-указателей уже давно нет. Ты точно судишь о языке по актуальной информации? Я бы обращал внимание на дату публикации статей, когда речь идет об активно разрабатываемой штуковине.

Нормальной сборки мусора в языке так никогда и не было, даже когда @-указатели еще были. Сейчас их функционал перенесли в тип Gc.

http://doc.rust-lang.org/guide-pointers.html#gc :

The Gc<T> type exists for historical reasons, and is still used internally by the compiler. It is not even a 'real' garbage collected type at the moment.

In the future, Rust may have a real garbage collected type, and so it has not yet been removed for that reason.

Сейчас Gc мертв и никому не нужен, официальная рекомендация - использовать простой подсчет ссылок (Rc) если у объекта больше одного владельца: http://doc.rust-lang.org/guide.html#rc-and-arc. Само собой, у Rc могут возникнуть циклы, которые надо разрешать явным использованием слабых ссылок. Ну и да, использование Rc не особо поощряется и является крайней мерой - почти всегда должно хватать обычных владеющих и не владеющих ссылок (все-таки они являются центральным элементом языка).

Других ссылок на код на Rust вообще нету?

Насколько я знаю, большая часть открытых проектов есть тут: http://rust-ci.org/projects. Это чуть удобней, чем просто по гитхабу шариться - разбиты по тегам и есть данные о «свежести» и активности проекта.

или даже хотяб для андроида

Я недавно собирал и запускал opengles демку из https://github.com/skligys/rusty-cardboard на своем телефончике.

Еще знаю, что Томака в своем велосипеде https://github.com/tomaka/gl-init-rs активно сейчас пилит поддержку андроида и пытается подружить это дело (под андроид все-таки геморройно собирать apk) с cargo.

mylib.rs

#![crate_type = "staticlib"]
#![allow(ctypes)]

#![no_std]

#[no_split_stack]
#[no_mangle]
pub extern fn add(lhs: uint, rhs: uint) -> uint {
    lhs + rhs
}

test.c

#include <stdio.h>

extern unsigned int add(unsigned int lhs, unsigned int rhs);

int main() {
    printf("add(40,2) = %u\n", add(40,2));
    return 0;
}

$ rustc --emit=obj mylib.rs 
$ gcc test.c mylib.o 
$ ./a.out 
add(40,2) = 42

или более правильный способ

$ rustc mylib.rs 
$ gcc test.c libmylib.a
$ ./a.out 
add(40,2) = 42

Я ему в соседней теме уже примерно такое же скинул.

Преемники царей дня сегодняшнего (комментарий)

А зачем тут #[no_split_stack] нужен? Я, видимо, не до конца понимаю, что это.

Чтобы не определять stack_exhausted.

У DST нет RFC, но Стив Клабник говорит, что стоит почитать вот этот пост Нико: http://smallcultfollowing.com/babysteps/blog/2014/01/05/dst-take-5. Боюсь, я тут не очень в теме и мне самому надо внимательно это прочитать, прежде чем пробовать чего-то объяснять))

Про Associated types уже дали ссылку на RFC, это штука для упрощения написания обобщенного кода. И извиняюсь за неточный перевод, не зря я английский вариант оставил :).

Это не перевод «Unboxed closures», а моя попытка коротко пересказать суть изменений. Неудачная, наверное, попытка, но там же правда очень много упрощений.

А где efficient inheritance?

Хорошо что хоть не выкинули. Интерестно, чем отличается работа таких приложений. Не будет ли так что будут библиотеки совместимые только в режиме работы с green или полностью несовместимы?

https://github.com/rust-lang/rfcs/pull/219

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

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

D это Александреску с Брайтом

Когда язык разрабатывают многолетний автор компилятора Си++ и Си++-акробат 90-го уровня, у них может получиться только очередной Си++.

а не какие-то студенты из мозиллы

Они давно уже не студенты.

Они давно уже не студенты.

Читая их переписки уже 2 года, я думаю, что да - не студенты. Скорее школота, с мечтами о «сделать збзь», а как? «да хренего знает. давайте еще чонить добавим/выкинем»

школота, с мечтами о «сделать збзь», а как? «да хренего знает. давайте еще чонить добавим/выкинем»

Мнение профессионала. Уважаю.