Альфа-версия Rust 1.0

Go среди новичков самый бесполезный и годен только для примитивных сервисов

а как же NSQ?

let i: usize = FromStr::from_str("5").unwrap();

Вот пострашнее. :)

Коммерческая компания в пылу битвы браузеров силами одного человека за 10 дней пишет язык, в нем куча оплошностей и недоработок. Но надо скорее пихнуть в продакшн ради бабла.. Unix way!!

У го история довольно схожая

другие ресурсы тоже не блещут, никто не задается вопросом «какую задачу я должен решить», скорее «мне нужно выучить с++/haskell/clojure/scala что бы быть cool guy».

docker еще с consul'ом не забываем и iron.io например, что с ходу вспомнил

а как же NSQ?

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

где-то (на хабре?) пошутили, что раст для системщиков, а го для прикладников

но у го пока библиотек маловато для многих прикладных целей

никто не задается вопросом «какую задачу я должен решить», скорее «мне нужно выучить с++/haskell/clojure/scala что бы быть cool guy»

мне кажется тут вопрос в другом: те, кто задается вопросом «какую задачу я должен решить» этот вопрос как правило решают без особого шума, а те, которые kewl guy wannabe, вот от них и стоит галдеж, но по производимому шуму оценивать степень использования той или иной технологии в реальных проектах - большая погрешность получится :)

Пока не смотрел в документацию, но у меня вопрос к тем, кто уже использует Rust: в стандартной библиотеке уже есть Async I/O?

ну уже довольно прилично их, и становится все больше, что характерно

у го пока библиотек маловато для многих прикладных целей

библиотеки - не грибы, сами не растут

А примеры будут?

Надо посмотреть как исходники NSQ и docker будут выглядеть через 5 лет

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

в go нет возможности течь by design

А. То есть ты из тех, кто верит, что в языках с GC невозможны утечки?

профит от использования rust вместо go вплане «скорости» работы на сервере ничтожен и бессмысленен

Если выигрыш в 2 раза бессмысленен...

go рожден для одной цели и ниши

Почти как Руби %)

вход в rust и go абсолютно разный, что увеличивает риски в коде твоей команды в разы

Единственное, с чем можно согласиться.

rust будет лезть в разные направления и нигде не преуспеет

Это не аргумент, а вангование.

совсем забыл про stdlib, в go все в ней направлено на сеть, веб и бекенд опять же, а что там у rust?

А у Rust, как очевидно из новости, только альфа-версия вышла.

А что существенного из нестабильной версии не попало в первою альфу?

Много чего еще не помечено как стабильное в стандартной библиотеке: http://doc.rust-lang.org/std/stability.html

Еще надо учитывать, что за последние три-четыре месяца стандартную библиотеку очень сильно порезали, что бы она не была «с батарейками», которые со временем обязательно протухнут, но их придется всю жизнь таскать с собой. Все вырванные куски лежат в отдельных крейтах и используются через cargo - их стабилизации сейчас уделено намного меньше внимания.

И из самого языка часть вещей временно убрали под feature gate (блин, я хз как это перевести нормально). Хотят еще немного подумать над этими вещами перед заморозкой.

- тот же многострадальный box-синтаксис (http://www.reddit.com/r/rust/comments/2rr990/box_expr_syntax_is_now_behind_a_...);

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

- glob-импорты (которые «use module::*») - может их и успели протолкнуть в альфу, не уверен. Как по мне, вообще это лучше выкинуть было, только усложняет программирование без ide или прыгалки по тегам;

- unsafe_destructor;

- чего-то там еще было, но мне сходу не вспоминается и на глаза не попадается. Но я и не претендую на 100% знание положения дел). Тем более, что за неделю перед алфой было внесено просто дикое количество изменений.

можно посмотреть еще тут https://github.com/rust-lang/rust/issues/19260, тут https://github.com/rust-lang/rust/issues/20761 и тут https://github.com/rust-lang/rust/wiki/Anticipated-breaking-changes-during-1.....

p.s. господи, опять развели rustvsgo срач, как же это уныло :(

невозможность использовать макрос вида println!«Hello» для простых строк

М? Только что попробовал helloworld в playpen:

fn main() -> () {
  println!("Hello, world!");
}

Hello, world!
Program ended.

https://github.com/rust-lang/rust/pull/20944/files

О, что б тебя, нет! НЕЕЕЕТ! Только не Лафкрафта при сегфолтах! Сволочи. Из-за жалких пары килобайт - чертовы демосценеры и любители микроконтроллеров :( .

Не было, но вообще IO планируют сильно переделывать: https://github.com/rust-lang/rfcs/pull/517/

Пора форкать!

здравствуйте люди. Я прибыл к вам с миром. Я - ваш структурный Си.

Не было, но вообще IO планируют сильно переделывать

bummer :(

Асинхронный IO на libuv сравнили с синхронным и решили, что оно того не стоит.

Асинхронный IO на libuv сравнили с синхронным и решили, что оно того не стоит.

ссылочку можно?

...не видно никаких практических причин, мешавших сделать изящнее.

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

Rust: let i = from_str::<uint>(«5»);
D: auto i = to!uint(«5»);

Правильно написали, ты еще обработку Option забыл.

На практике, обычно, ты, когда получаешь этот i, передаешь его в какую-то функцию и компилятор часто сам может вывести тип. Так что очень часто, если где-то рядом есть ... f(i); ..., код можно сократить до let i = from_str("5").expect("err msg"); - уже не так плохо.

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

сделать изящнее

Примеры?

Ну всё, теперь этот язык потерян для сообщества!

http://www.reddit.com/r/rust/comments/2l0a4b/do_rust_web_servers_use_libuv_th...

спасибки

Асинхронный IO на libuv сравнили с синхронным и решили, что оно того не стоит.

ссылочку можно?

Это было размазано по нескольким нитям в rust-dev@, когда он еще функционировал. Вот одна из них: https://mail.mozilla.org/pipermail/rust-dev/2013-November/006550.html

А примеры будут?

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

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

Вот еще ветка обсуждения по этому поводу нагуглилась: https://news.ycombinator.com/item?id=8321427.

Еще подумывают для статиков (и констант, вроде) потом разрешить опускать тип: https://github.com/rust-lang/rfcs/issues/296 - это мне уже кажется не такой уж и плохой идеей, со статиками типы и правда иногда нервируют. Был еще разговор где-то (не могу нагуглить) о разрешении опускать сигнатуры для приватных функций. Но это все обратно-совместимые изменений, так что отложили все до выхода 1.0.

Что пока вместо иде поюзать? Чтоб хоть какая менюшка выпала с подсказкой.

Что пока вместо иде поюзать? Чтоб хоть какая менюшка выпала с подсказкой.

Учитывая, что язык не прибит гвоздями к ide, как всякие явашарпы, то https://github.com/phildawes/racer с любым редактором (с vim, как вариант по-умолчанию).

[troll mode] Явно много пораньше, чем Ректалос ;-) [/troll mode]

По теме: интересно, жду релиза.

Что пока вместо иде поюзать?

Говорят, что большинство разработчиков сидит на Emacs.

Так чем он конкретно лучше чем ним?

Я все хочу вим осилить, но, боюсь, осиливать параллельно язык и блокнот - слишком.

Жалко, что не прибит :/

Только что попробовал helloworld в playpen

Я хочу выбросить скобки для вариантов с одним аргументом, как в D :)

Трололо :) .

Простите, а сколько лет ждать релиза?

http://blog.rust-lang.org/2014/12/12/1.0-Timeline.html

TL;DR: we will transition to a six week release cycle on Jan 9, 2015, and produce Rust 1.0.0 final at least two cycles afterwards:

Rust 1.0.0-alpha – Friday, Jan 9, 2015
Rust 1.0.0-beta1 – Week of Feb 16, 2015
Rust 1.0.0 – One or more six-week cycles later

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

Спасибо. Еще вопросец: можно ли дергать ржавые коллбеки из нержавого треда без колдоства?

Правильно написали, ты еще обработку Option забыл

Нет не забыл, меня напрягает именно базовый синтаксис. То, что требуют явную обработку явных вещей - хорошо. Но почему нельзя выводить тип на основе типа аргумента и использовать сигнатуру вида to::<uint>(«5») ? Зачем вообще этот отвратительный синтаксис вида ::<> для обобщённых аргументов?

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

Во всём этом Option как раз таки самое доброе добро.

Можно. http://doc.rust-lang.org/book/ffi.html

Я хочу выбросить скобки для вариантов с одним аргументом, как в D :)

А чо только с одним? Давай как в Хаскеле - без скобок вообще.

Но почему нельзя выводить тип на основе типа аргумента

Тип аргумента - строка. Что из него можно вывести?

А чо только с одним? Давай как в Хаскеле - без скобок вообще.

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

Тип аргумента - строка. Что из него можно вывести?

Строку? :) Коду конвертера должно быть всё равно по большей части, это &str или String, зачем вообще нужно это явное «_str» в названии функции? Важная информация - целевой тип, а не исходный.

А чо только с одним? Давай как в Хаскеле - без скобок вообще.

Без скобок вообще читать труднее

...но не вслучае одного аргумента? По-моему, делать syntax sugar имеет случай тогда, когда какой-то вариант использования преобладает, а один аргумент - не такой случай.

Тип аргумента - строка. Что из него можно вывести?

Строку? :)

И как это поможет? Если бы выводился int в from_str::<int>, это было бы полезно.

зачем вообще нужно это явное «_str» в названии функции?

Дело вкуса. Или, например, сразу понятно, что foo - строка: from_str::<int>(foo)

Важная информация - целевой тип, а не исходный.

Не вижу, чем эта целевой тип важнее исходного.

Что там в виме осиливать то? Ins Esc и :wq

Дело вкуса. Или, например, сразу понятно, что foo - строка: from_str::<int>(foo)

Не вижу, чем эта целевой тип важнее исходного.

Ну строго формального доказательства важности я предоставить точно не могу :) Это сугубо практические соображние - я пользовался аналогичными инструментами в D (много) и исходный тип не играл значения почти никогда. Более того, его неявный вывод сильно упрощал написание обобщённых функций. Дело вкуса, но я точно знаю, что такой подход со стороны Rust меня будет раздражать очень сильно - а именно такие мелочи и влияют на скорость освоения языка.

библиотеки - не грибы, сами не растут

именно. И именно они определяют «годность» ЯП. Если ЯП не годный → на нём задачи не решают → библиотек нет.

golang релизнулся три года назад (пруфлинк https://golang.org/doc/devel/release.html#go1 ), и до сих пор нет батареек. Очевидно, что

1. golang никому не нужен

2. golang нужен только гуглу, и гугл не желает открывать батарейки.

В любом случае, golang это ненужное говно.

Если все пойдет хорошо, то через три месяца.

хм. Ну ладно. Пойду попробую собрать и посмотреть этот ваш rust…

Очевидно, что

ко-ко-ко...