Последнее вермя меня просто неописуемо прет от Rust, посути — это тот язык которого мне давно не хватало. Так вот, к чему я это. На данный момент я затеял перевод руководства пользователя, полагаю что его проще перевести пока оно еще не очень большое (около 24 страниц). Собственно вопрос в том, не хочет ли кто-то присоедениться к переводу руководства?
Если хочется посмотреть на то, что из себя представляет Rust, то можно почитать заметки про него.

Здравствуйте, kaa.python, Вы писали:

Чем же он так зацепил?

Здравствуйте, VoidEx, Вы писали:

VE>Чем же он так зацепил?

Я вот тут

Автор: kaa.python
Дата: 12.04.12

, немного писал на эту тему. Если хочется еще подробностей — руководство пользователя тебя ждет

Здравствуйте, kaa.python, Вы писали:

KP>Я вот тут

Автор: kaa.python
Дата: 12.04.12

, немного писал на эту тему. Если хочется еще подробностей — руководство пользователя тебя ждет

Если честно, то не очень ясно. Т.е. примеры эти вполне ясны, но в них не видно никаког преимущества (разве что юнит тесты).

Т.е. можно провести какое-то сравнение (пусть даже по личным впечатлениям) с C++, D, Go?

Лично мне больше всего нравится D, но пока не могу его нигде использовать в связи с отсутствием инфраструктуры. Поэтому пока C++ как основное. Go кажется интересным только своей простотой, но она не всегда полезна. Возможно для серверных скриптов Go может быть интересен (вместо java/python/ruby), но это всё в будущем. Rust не пробовал.

Здравствуйте, alex_public, Вы писали:

_>Если честно, то не очень ясно. Т.е. примеры эти вполне ясны, но в них не видно никаког преимущества (разве что юнит тесты).

Как ты понимаешь, я еще далеко не по всем возможностям Rust примеры написал.

_>Т.е. можно провести какое-то сравнение (пусть даже по личным впечатлениям) с C++, D, Go?

Что мне больше всего нравится в Rust по сравнению с C++. С D не сравниваю, почему — напишу ниже:

• Туплы, входящие в сам язык, а прикрученные сбоку;
  
• Сравнение с образцом;
  
• Полноценные замыкания;
  
• Расширенная версия перечислений;
  
• Возможность передавать данные в функцию by-copy или by-move;
  
• Простые и очевидные шаблоны (хотя да, за лет 5-7 я к плюсовым тоже привык);
  
• Встроенная в язык система сборки и система модульного тестирования;
  
• Интерфейсы, позволяющие добавлять функции к существующим типам. Полиморфные интерфейсы;
  
• Ну и конечно же система тасков, с портами и каналами.

_>Лично мне больше всего нравится D, но пока не могу его нигде использовать в связи с отсутствием инфраструктуры. Поэтому пока C++ как основное. Go кажется интересным только своей простотой, но она не всегда полезна. Возможно для серверных скриптов Go может быть интересен (вместо java/python/ruby), но это всё в будущем. Rust не пробовал.

D — мертвый язык, ты его ни сейчас ни потом не сможешь использовать. С практической точки зрения он интересен не более чем латынь, хотя с теоретической, он не менее интересен, а с учетом того что он уже имеет неплохой набор библиотек, даже более интересен чем Rust.
Если говорить о плюсах — язык, за счет огромного багажа кода, не может себе позволить какого-то более менее серьезного развития или изменения. Go — глянул и он меня ну совсем ничем не зацепил, так что я его не использовал и не планирую использовать в принципе.
Если же говоить про Rust, он еще только формируется и, вполне возможно, и не взлетит вовсе. Но, за Rust стоит корпорация, и это не просто развлекуха пары чуваков (как в случае с D), так что это дает некие надежды на его дальнейшее практическое использование. Ну а текущий задел языка, лично меня, после 12 лет работы с C++, очень радует.

Здравствуйте, kaa.python, Вы писали:

KP>Последнее вермя меня просто неописуемо прет от Rust, посути — это тот язык которого мне давно не хватало. Так вот, [...]

Да, не хватает адекватной альтернативы для С++, но Rust несколько настораживает.

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


Как-то неоднозначна ситуация с обработкой ошибок. Нет никаких перехватов fail. Всё сделано по мотивам Эрланга: пусть таск упадёт, раскрутим стэк, всё удалим, плюнем в лог, потом разберёмся, контролирующий таск заново перезапустит упавший поток, если нужно. Якобы нет гарантий, что состояние таска можно восстановить корректно при fail. Но всё-таки Rust это не Эрланг, а язык общего назначения, без спец. заточенной ВМ, да ещё с намеком на системную разработку. Да и в Эрланге вроде не сразу ввели конструкции для аналогов try-catch, но всё-таки вынуждены были ввести. Имхо, механизмы его брата языка Go — defer и recover — как раз бы точно не помешали: это, фактически, один блок catch на функцию (оптимизация), возможность остановить раскрутку стэка и корректно указать результат функции, и нет управляющих специнструкций вида try-catch/except/finally. При этом наличие в языке деструкторов, в отличие от Go, не вынуждает часто писать defer, фактически, он нужен будет только для перехвата fail. К тому же, в Rust как-то нет сейчас массовой привычки возвращать код ошибки в функциях, в рамках стандартной библиотеки. Это подталкивает как бы к одному способу обработки всех проблем, т.е. через fail (в отличие от Go, где есть некоторое смешение способов, навязанное авторами: panic и коды возврата).
А так, приятно, что борятся с ошибками: пытаются убрать null-ссылки, есть тип option, ввели RAII (ресурсы), есть пока мутный typestates (плохо ещё описан), и пр.


И есть опасение, что язык могут переусложнить, причём из-за стремления "к идеальности". Вот отрывок из твоего сообщения из соседней темы (вырезка из документации):

KP>Then there is the by-copy style, written +. This indicates that the function wants to take ownership of the argument value. If the caller does not use the argument after the call, it will be 'given' to the callee. Otherwise a copy will be made. This mode is mostly used for functions that construct data structures. The argument will end up being owned by the data structure, so if that can be done without a copy, that's a win.

KP>

KP>type person = {name: str, address: str};
KP>fn make_person(+name: str, +address: str) -> person {
KP>    ret {name: name, address: address};
KP>}
KP>

KP>Finally there is by-move style, written -. This indicates that the function will take ownership of the argument, like with by-copy style, but a copy must not be made. The caller is (statically) obliged to not use the argument after the call; it is de-initialized as part of the call. This is used to support ownership-passing in the presence of non-copyable types.

Имхо, современные компиляторы должны сами всё оптимизировать по самое не могу, и нужно как бы им не мешать. Вот они собираются ещё ввести классы (что, имхо, уже излишне), как в "продвинутом" языке они захотят иметь декларации и для контр/ковариантности для типов. Т.е. эти плюсы и минусы будут рядом ещё и с типами, где ещё уже есть указания kind-а (copy, send). И это всё ещё разбавлено отдельным указанием мутабельности, константности, а также указателями, "боксовостью" и "уникальностью", причём и для указателей, и для лямбд, а также ещё есть желание и регионы для указателей ввести. Т.е. в языке есть такой "огород":

fn SHA1(src: *u8, sz: uint, out: *u8) -> *u8
fn mk_appender(suffix: str) -> fn@(str) -> str 
call_twice(fn@() { "I am a boxed closure"; });
fn box<T>(x: T) -> @T { @x }
fn increase_contents(pt: @mut int)
fn for_each(v: [mut @int], iter: fn(@int)) 
fn vec_push(&v: [int], elt: int) 
fn plus1(&&x: int) -> int
fn head<T: copy>(v: [T]) -> T
fn pure_foldl<T, U: copy>(ls: list<T>, u: U, f: fn(&&T, &&U) -> U) -> U
fn proc_tree<T>(t: ~tree<T>)
fn foo(&t: T, v: @const int)
let x: @int = @10;
let x: ~int = ~10;

// и планируемые регионы:

fn pick_one(a: A& T, b: A& T) -> A& T

type tree<D, R&> = {
    left: R& option<R& T<R&>>;
    right: R& option<R& T<R&>>;
    data: D;
};

Это простейшие примерчики из туториалов, что будет в реальной жизни, как-то очковато.

Да, все эти фичи дадут не мало пищи для фана многим энтузиастам, особенно в рамках своих любительских проектов. Но, имхо, для массовой промышленности это как-то опасно. Тут можно и запросто не доглядеть, что где-то какая-то закорлючка пропущена, а также утяжеляет и процесс разработки. Непросто и программистам, и компиляторам для оптимизаций.
В языке здравые концепции: неизменность объектов по умолчанию, явное указание мутабельности и передача прав владения объектов (вместо их копирования). Имхо, нужно как-то уже избегать в языке всех этих супер-указателей, например, ввести какие-то блоки для явного указания того, что мы хотим править "по месту", как по мотивам Кложуры, что ли: transient v: [T] {... правим v без копий}. Аналогично и для "send"-блока, т.е. после того, как мы передали объект куда-то внутри этого блока, мы уже не владеем объектом. Причём как-то нужно в языке подводить к тому, чтобы таким могли заниматься только владельцы объектов. Тут и компиляторы смогут сами догадаться, когда что-то возможно по ссылке передать (или вообще заинлайнить), когда не нужны лишние барьеры/блокировки между потоками и т.д.

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


Всё выше перечисленное сугубо личное имхо.

Здравствуйте, alex_public, Вы писали:

_>Т.е. можно провести какое-то сравнение (пусть даже по личным впечатлениям) с C++, D, Go?
Самое классное — это многопоточность в Erlang-стиле (т.е. shared-nothing по умолчанию).

Здравствуйте, PSV100, Вы писали:

PSV>Да, не хватает адекватной альтернативы для С++, но Rust несколько настораживает.

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

Здравствуйте, kaa.python, Вы писали:

KP>Здравствуйте, PSV100, Вы писали:

PSV>>Да, не хватает адекватной альтернативы для С++, но Rust несколько настораживает.

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

Да, написать то можно, но нет почвы для "любовных писем". Я лично не могу что-то сказать, что мол вы ребята ошибаетесь, нужно делать так-то, наоборот, они меня во многом смогут поучить. А почему они делают именно так, в принципе, в своей документации они объясняют. Совершенно понятно их стремление быть по духу близким к С++, понятно, что Эрланг сильно оказал впечатление, хотя его модель многопоточности не идеальна, например, автор той же вскользь упомянутой здесь Кложуры вполне адекватно её критиковал, поэтому у себя сделал иные подходы, но местами и похожие. Просто есть опасение, что в языке получится, ну, не знаю как сказать, некий эффект Хаскеля: сначала придумывают жёсткую и максимально контролирующею систему типов, но народ ленивый, как и Хаскель, хочет писать универсально и гибко, поэтому вынуждены затем придумывать средства по "безопасному" обходу этих ограничений. Если базовые концепции (да и синтаксис) в Хаскеле просты как валенок, но как дело доходит до монадных вычислений (но это ещё не смертельно), полиморфизма фиг знает какой степени, семейств типов и пр., то среднепаршивый программист начинает уже себя чувствовать валенком.

Будет грустно, если язык в чём-то окажется проще, чем С++ (как те же шаблоны, ты верно подметил, хотя всё-таки эти угловые скобки неудобны), а в чём-то на два кг опаснее и тяжелее.

Здравствуйте, PSV100, Вы писали:

PSV>Здравствуйте, kaa.python, Вы писали:

KP>>Здравствуйте, PSV100, Вы писали:

PSV>>>Да, не хватает адекватной альтернативы для С++, но Rust несколько настораживает.

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

PSV>Да, написать то можно, но нет почвы для "любовных писем". Я лично не могу что-то сказать, что мол вы ребята ошибаетесь, нужно делать так-то, наоборот, они меня во многом смогут поучить. А почему они делают именно так, в принципе, в своей документации они объясняют. Совершенно понятно их стремление быть по духу близким к С++, понятно, что Эрланг сильно оказал впечатление, хотя его модель многопоточности не идеальна, например, автор той же вскользь упомянутой здесь Кложуры вполне адекватно её критиковал, поэтому у себя сделал иные подходы, но местами и похожие. Просто есть опасение, что в языке получится, ну, не знаю как сказать, некий эффект Хаскеля: сначала придумывают жёсткую и максимально контролирующею систему типов, но народ ленивый, как и Хаскель, хочет писать универсально и гибко, поэтому вынуждены затем придумывать средства по "безопасному" обходу этих ограничений. Если базовые концепции (да и синтаксис) в Хаскеле просты как валенок, но как дело доходит до монадных вычислений (но это ещё не смертельно), полиморфизма фиг знает какой степени, семейств типов и пр., то среднепаршивый программист начинает уже себя чувствовать валенком.

А касательно Хики и Эрланга нет ссылки случаем?

Здравствуйте, Курилка, Вы писали:

К>А касательно Хики и Эрланга нет ссылки случаем?

Clojure: Identity and State — здесь поверхностно описывается модель многопоточности в clojure и там же есть немного про акторов, какие есть с ними нюансы.

Здравствуйте, kaa.python, Вы писали:

KP>D — мертвый язык, ты его ни сейчас ни потом не сможешь использовать.

А... держите меня семеро. И это говорит новоиспеченный фанат еще не рожденного языка.

Мил человек. D живет уже около 10 лет. Дай бог, чтобы этот Раст столько же прожил.

Здравствуйте, Cyberax, Вы писали:

_>>Т.е. можно провести какое-то сравнение (пусть даже по личным впечатлениям) с C++, D, Go?
C>Самое классное — это многопоточность в Erlang-стиле (т.е. shared-nothing по умолчанию).

А тебе не кажется, что подобные вещи должны в библиотеках лежать, а не в язык хардкодиться?

Здравствуйте, VladD2, Вы писали:

VD>А тебе не кажется, что подобные вещи должны в библиотеках лежать, а не в язык хардкодиться?
Только ты их без жестокого метапрограммирования в библиотеку не положишь.
А оно есть только в лиспе и сам знаешь где.

Здравствуйте, WolfHound, Вы писали:

WH>Только ты их без жестокого метапрограммирования в библиотеку не положишь.
WH>А оно есть только в лиспе и сам знаешь где.

Это чёто? Если в языке есть паттерн-матчинг, то можно и в библиотеку положить. По сути это типизированные очереди.

Здравствуйте, VladD2, Вы писали:

VD>Мил человек. D живет уже около 10 лет. Дай бог, чтобы этот Раст столько же прожил.

Живой язык — это язык употребляющийся для коммерческой разработки. Rust еще не родился даже, и, возможно, и не родиться. Но вероятность рождения есть. В случае с D такой вероятности уже нет, хотя, лично я, долгое время на это очень надеялся.

Здравствуйте, VladD2, Вы писали:

_>>>Т.е. можно провести какое-то сравнение (пусть даже по личным впечатлениям) с C++, D, Go?
C>>Самое классное — это многопоточность в Erlang-стиле (т.е. shared-nothing по умолчанию).
VD>А тебе не кажется, что подобные вещи должны в библиотеках лежать, а не в язык хардкодиться?
Чтобы полный профит от Эрланговского стиля получить — не должны.

В Rust и Erlang нет глобальной кучи, к примеру. Так что GC можно очень шустро собирать мусор в одном лёгком потоке, не мешая остальным.

Здравствуйте, kaa.python, Вы писали:

KP>Здравствуйте, VladD2, Вы писали:

VD>>Мил человек. D живет уже около 10 лет. Дай бог, чтобы этот Раст столько же прожил.

KP>Живой язык — это язык употребляющийся для коммерческой разработки.

Из этого определения следует, что Rust мертвый язык, а D живой.

KP>Rust еще не родился даже, и, возможно, и не родиться.

И это, видимо, куда перспективнее реально используемого языка.

KP>Но вероятность рождения есть.

Вероятность того, что на тебя сейчас упадет астероид тоже есть.

KP>В случае с D такой вероятности уже нет, хотя, лично я, долгое время на это очень надеялся.

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

Но это твой выдуманный мир. А в реальном мире D уже есть около 10 лет. И где-то лет 5 он вполне стабилен для реального использования.

Твое же преклонение перед Rust закончится точно так же. Тысячи таких же как ты будут сидеть и ждать чуда которое превратит Rust в "живой" язык, в их глазах.

Так что не фига думать. Бери и используй. И вот когда при использовании появятся какие-то непреодолимые трудности, а авторы языка откажутся их исправлять, вот тогда язык и будет мертвым.

Здравствуйте, VladD2, Вы писали:

VD>>>Мил человек. D живет уже около 10 лет. Дай бог, чтобы этот Раст столько же прожил.

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

VD>Из этого определения следует, что Rust мертвый язык, а D живой.

На данный момент они оба в одинаковом положении. Но то, что не взлетело за 10 лет, не взлетит и дальше. То что новое, и довольно логичное, очень может даже взлететь.

VD>И это, видимо, куда перспективнее реально используемого языка.

Где используемый? Кем используемый? Линки приведи, кроме "ну я его использовал в исследовательской разработке и ...".

VD>Вероятность того, что на тебя сейчас упадет астероид тоже есть.

Есть. И? Ты чего так разошелся-то? Я же даже не Немерле мертворожденным назвал, а какой-то D

VD>Ты один из упертый которые сидят и ждут какого-то волшебного чуда которое должно случиться, чтобы ты и такие как ты признали, что язык есть и им можно пользоваться.

Я один из упертых, который 12 лет сидит на C++ и его почти все устраивает. Но, иногда, хочется какого-то разнообразия (для системной разработки).

VD>Но это твой выдуманный мир. А в реальном мире D уже есть около 10 лет. И где-то лет 5 он вполне стабилен для реального использования.

про реальный мир см. выше.

VD>Твое же преклонение перед Rust закончится точно так же. Тысячи таких же как ты будут сидеть и ждать чуда которое превратит Rust в "живой" язык, в их глазах.

То что ты называешь чудом, я называю "использованием в коммерческой разработке".

Здравствуйте, Cyberax, Вы писали:

C>Чтобы полный профит от Эрланговского стиля получить — не должны.

Да? Обоснуй!

C>В Rust и Erlang нет глобальной кучи, к примеру. Так что GC можно очень шустро собирать мусор в одном лёгком потоке, не мешая остальным.

GC вообще никак не связан с языком. Вот для той же риалтайм-явы сделали и потоки со своим GC, и даже потоки вообще без GC.

А уж для компилируемого языка не имеющего своего рантайма, как Rust, тут и говорить не о чем. Можно реализовать все что в голову придет.