Здравствуйте, Aleх, Вы писали:
A>Интересно, а где можно почитать про систему типов в Rust, а то в документации самые интересные главы References and Borrowing, Lifetimes ещё не написаны.
Актуального описания я не видел, тут нужно код смотреть. Но проще всего почитать заметки Niko Matsakis, он вроде как главный архитектор/идейный вдохновитель системы типов в Rust. Например вот эту, эту и вот эту.
Здравствуйте, Aleх, Вы писали:
A>Интересно, а где можно почитать про систему типов в Rust, а то в документации самые интересные главы References and Borrowing, Lifetimes ещё не написаны.
Прямо сейчас по ссылке вполне себе есть текст. Или подразумевается, что там мало информации?
Помимо предложенных ссылок, можно посмотреть "бета-версию" книги — там информация вполне актуальная, в новом мануале просто расширили и иначе структурировали. Есть ещё книга "Rust by example" — её пишет комьюнити.
Ну и блог можно посмотреть. Например, статья про многопоточность, но там как раз рассказывается как с этим семантика владения помогает.
Здравствуйте, DarkEld3r, Вы писали: DE>Прямо сейчас по ссылке вполне себе есть текст. Или подразумевается, что там мало информации?
Когда писался пост, текста не было.
Здравствуйте, kaa.python, Вы писали:
KP>Но не обошлось и без ложки дегтя. Дело в том, что разработчики не осилили зеленые потоки и асинхронную сеть.
Без зеленых потоков при наличии качественного fork/join фреймворка вполне можно обойтись. А вот отсутствие асинхронного IO по нынешним временам — почти приговор.
... << RSDN@Home 1.0.0 alpha 5 rev. 0 on Windows 8 6.2.9200.0>>
Здравствуйте, AndrewVK, Вы писали:
AVK>Без зеленых потоков при наличии качественного fork/join фреймворка вполне можно обойтись. А вот отсутствие асинхронного IO по нынешним временам — почти приговор.
"Всё что мы не успели стабилизировать до 1.0 ушло под нож". Правда есть mio, который на данный момент UNIX-only, но поддержку Windows обещают, хотя для языка уровня Rust это вообще не критичное требование.
AVK>А вот отсутствие асинхронного IO по нынешним временам — почти приговор.
Оно на уровне языка должно быть штоле?
IMO, один из лучших асинхронных библиотечных интерфейсов что я видел на данный момент имеется в libmicrohttpd. Там пользователь должен передавать библиотеке callback, который вызвается при accept-е нового клиента, клиент должен реализовывать конечный автомат и правильно реагировать на вызовы этого callback-а (он может быть вызван много раз для одного и того же клиента, например когда пришли post данные и потом для того, чтобы получить response). Это все выглядит страшно (callback-с десятком параметров, AFAIR), но зато позволяет прозрачно переключаться между синхронным и асинхронным режимами работы сервера. А всякие асинхронные языковые расширения (вроде async в C#) такой роскоши не позволяют, библиотеки вроде boost.asio — тоже, там ты либо используешь callback лапшу и одни ф-ии, либо пишешь синхронный код с другими ф-ями. В общем, все правильно делают чуваки, IMO.
DE>Ну шареная память — ладно, но unsafe чем не угодил? Имхо, совсем без этого язык был бы никому не нужен. Ведь даже FFI через unsafe делается и это выглядит вполне логично.
AFAIK unsafe неугодил тем, что в расте его нужно вызывать неоправданно часто, для того, чтобы обходить ограничения накладываемые системой типов, например intrusive структуры данных сложно без unsafe сделать на нем, могу ошибаться насчет этого, если не прав — поправьте.
Здравствуйте, ELazin, Вы писали:
EL>например intrusive структуры данных сложно без unsafe сделать на нем, могу ошибаться насчет этого, если не прав — поправьте.
Да, это так. Но иначе и не получилось бы предоставить имеющиеся гарантии для безопасного кода. Ну а структуры данных можно написать один раз и предоставить к ним безопасный интерфейс.
Здравствуйте, kaa.python, Вы писали:
KP>"Всё что мы не успели стабилизировать до 1.0 ушло под нож". Правда есть mio, который на данный момент UNIX-only, но поддержку Windows обещают, хотя для языка уровня Rust это вообще не критичное требование.
По отзывам у людей вообще много проблем под Windows. Некоторые мол даже hello world не смогли скомпилировать. У меня под рукой нет Windows, просто интересно, как там обстоят дела с поддержкой Windows платформы?
Здравствуйте, DemonsInside, Вы писали:
DI>По отзывам у людей вообще много проблем под Windows. Некоторые мол даже hello world не смогли скомпилировать. У меня под рукой нет Windows, просто интересно, как там обстоят дела с поддержкой Windows платформы?
У меня на Win 8.1 hello world собирается без проблем, причем даже не удивление быстро — за полсекунды. А вот какую-то программку, использующую помимо стандартной библиотеки пару-тройку крейтов с crates.io, собрать уже не получилось, ибо они потянули какие-то сишные зависимости, для их сборки нужен был gcc для 64 бит, а его в моем mingw не оказалось. Т.е. одного инсталлятора с rust-lang (и еще одного с LLVM) явно недостаточно для полноценной работы, нужно еще немного повозиться с настройкой окружения для сборки сишных запчастей.
Здравствуйте, DemonsInside, Вы писали:
DI>По отзывам у людей вообще много проблем под Windows. Некоторые мол даже hello world не смогли скомпилировать.
Ну это скорей всего от того, что они IDE не наши в комплекте. Типичный виндузятник от такого в ступор впадает же
Здравствуйте, ELazin, Вы писали:
AVK>>А вот отсутствие асинхронного IO по нынешним временам — почти приговор. EL>Оно на уровне языка должно быть штоле?
На уровне языка должна быть удобная асинхронность, а не борьба с ней при помощи этажерки из объектов или лямбд.
EL>Там пользователь должен передавать библиотеке callback, который вызвается при accept-е нового клиента,
Они чуть менее чем все такие.
EL> клиент должен реализовывать конечный автомат и правильно реагировать на вызовы этого callback-а
Вот вот, о том и речь.
EL>А всякие асинхронные языковые расширения (вроде async в C#) такой роскоши не позволяют
Конкретно async в C# (а точнее не async, а TPL, async просто лапшу из кода убирает) это позволяет штатными средствами. Меняешь контекст на синхронный и вперед. Если, конечно, явно не скажешь, что тебе надо в отдельном потоке.
... << RSDN@Home 1.0.0 alpha 5 rev. 0 on Windows 8 6.2.9200.0>>
Здравствуйте, Iso12, Вы писали:
I>Microsoft планирует поддержку языка Rust в Visual Studio. I>Подробноcти можно почитать здесь.
По ссылке много бреда, похоже это просто сторонний плагин, а автор почему-то заявляет, что делает майкрософт. А я уже успел удивиться и обрадоваться.
Здравствуйте, DarkEld3r, Вы писали:
DE>Здравствуйте, kaa.python, Вы писали:
KP>>Главная фича, из тех "что не выкинули". Но благодаря всемогущему unsafe её крайне легко похерить. DE>Я тоже давно следил за языком и периодически изменения изначально расстраивали. Но после чтения их аргументации, как правило, соглашался с доводами. Скажем, по зелёным потокам особо не грущу. По моему, язык всё-таки чаще преподносится как "безопасный С/С++" — с этой точки зрения всё правильно сделали.
Здравствуйте, omgOnoz, Вы писали:
O>Может тогда лучше С#?
Что значит "тогда"? Я в расте не разочаровывался, наоборот кажется, что он идёт в правильном направлении — развивая, в том числе, всякие низкоуровневые вещи.
С# — это совсем другое.
Статью удалили, скорее не договорились или был просто "пустой выхлоп".
Поэтому я просто выложу здесь линки (этот и этот), где можно скачать расширение VS для Rust.
Visual Studio extension for Rust :
1)Поддержка проекта
2)Поддержка синтакса
3)Интегрирование компилятора
