Вышла новая версия языка Rust с номером 0.3. Несмотря на то, что говорить о каком бы то ни было коммерческом использовании языка рано, он обретает все более и более четкие формы, появляется понимание куда же он движется. Лично меня то что я вижу очень и очень радует.
С официальным анонсом можно ознакомиться тут. Кроме того, я сделал перевод обзора основных нововведений несколько дополнив его, относительно официальной версии.
P.S. в моем переводе есть пара мест, помеченных "(как это перевести?)". Буду очень благдарен за идеи как это лучше сделать
Здравствуйте, VladD2, Вы писали:
VD>Такой язык сразу идет в топку, в наше время. Надеюсь, что авторы передумают через некоторое время.
Приятно прочесть и принять к сведению мнение специалиста по языкам, сразу идущим в топку...
Спасибо, что предупредил, не буду даже и смотреть на этот ...раст!
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Re: Local variables may shadow earlier declarations
let monster_size = monster_factor * 10.0;
let monster_size: int = 50;
Local variables may shadow earlier declarations, as in the previous example: monster_size was first declared as a float, and then a second monster_size was declared as an int.
Рекурсии используются редко;
Рекурсии затрудняют понимание кода;
Всегда надо думать о том, поддерживается ли хвостовая рекурсия данным конкретным компилятором;
В конце концов кто-нибудь добавит поддержку данной не шибко полезной оптимизации и в Rust.
Синтаксис у него что-то уж слишком дикий и такой же страшный как в С++, поэтому непонятно накой оно вообще) По мне так D более симпатичный и жизнеспособный.
Здравствуйте, VladD2, Вы писали:
VD>Думаешь многие будут ждать и надеяться на изменение точки зрения авторов? Основная масса просто забьет на язык.
Язык версии 0.6 без хвостовой рекурсии заинтересовал две мощные корпорации (Мозилла и Самсунг). Наверное Немерле, с его великолепной поддержкой хвостовой рекурсии, может похвастаться не меньшими успехами, да?
Здравствуйте, kaa.python, Вы писали:
KP>Вышла новая версия языка Rust с номером 0.3. Несмотря на то, что говорить о каком бы то ни было коммерческом использовании языка рано, он обретает все более и более четкие формы, появляется понимание куда же он движется. Лично меня то что я вижу очень и очень радует. KP>С официальным анонсом можно ознакомиться тут. Кроме того, я сделал перевод обзора основных нововведений несколько дополнив его, относительно официальной версии.
KP>P.S. в моем переводе есть пара мест, помеченных "(как это перевести?)". Буду очень благдарен за идеи как это лучше сделать
Сформулирую поажалуй, почему я не верю в успех rust. Несмотря на всю движуху, не видать ему ничего более примечательного, нежели статус нишевого языка для сетевых приложений или приложений, не требующих высокой производительности.
Причина №1 — модель памяти. Rust это data ownership, как и в erlang. Data ownership это хорошо, это когда каждый объект в памяти принадлежит определенному потоку, ну и может иногда менять хозяина. Проблема в том, что это совсем не соответствует тому, как работает железо. Там как раз нет никакого ownership-а и любой поток может обращаться к любому вирт. адресу. В этом нет проблемы, если модель памяти rust ложится на архитектуру приложения хорошо, а что если нет? Что, если например у вас есть хэш таблица, в которой лежат пользовательские сессии и вам нужно из разных потоков часто ее читать и обновлять? Положить ее в общую кучу, забирать по очереди, читать/писать и потом класть обратно? А что если один из потоков получил owned pointer и помер? А что если он получил owned pointer на таблицу сессий и был вытеснен? Чем это лучше обычного lock-а? На Си я могу написать хэш таблицу с fine-grained синхронизацией или взять готовую и все это будет быстро работать. В rust я наверное тоже это смогу, но мне придется обойти как-нибудь его модель памяти. Ну и с появлением hardware lock elision в процессорах с архитектурой haswell все становится еще интересней, так как мне больше не нужно заморачиваться, я могу просто взять и использовать coarse grained lock, просто завернуть свою хэш таблицу в крит. секцию и все будет работать также, как и с fine grained locking.
Причина №2 — сборка мусора. Я за сборку мусора или за то, чтобы ее небыло, но не за то, чтобы она была опциональной. Если я хочу, чтобы мое приложение на rust не использовало сборщик мусора, то я буду управлять памятью вручную, но при этом какая-нибудь библиотека может от него зависеть и в итоге, мой сетевой сервис будет периодически лагать. Я подозреваю что тут будет ситуация как с shared_ptr в С++, в том смысле, что все используют shared_ptr даже там, где он не нужен. Т.е. написать нетривиальный код не использующий GC будет крайне сложно. Помимо этого, я не нашел нигде инфы о том, какой GC там планируется. Тип GC очень сильно влияет на написание расширений на Си, вот скажем в Go прямо говорят, что там будет консервативный GC, который будет сканировать память, выделеную сишным кодом, поэтому можно спокойно передавать туда указатели. Ну а в D рекомендуется указтели pin-ить, перед тем как передавать во внешнюю среду.
Причина №3 — таски. Насколько я понял, rust позволяет использовать как обычные потоки, так и "зеленые", при этом, опять же, насколько я знаю, генератор кода ничерта не знает, где будет выполняться код ф-ии — в нормальном потоке или в зеленом таске. Это означает жопу со всякими Си-шными расширениями. Если Си-шный код использует TLS, то его нельзя исполнять в зеленом потоке, в этом случае Go, например, выполняет код в специально выделенном потоке, а таск ждет, когда этот код отработает. Я довольно долго читал их список рассылки и все это время они придерживались мнения, что это все забота программиста.
Здравствуйте, C.A.B, Вы писали:
XC>>Эта LiteIDE написана на Qt, кода мало так что разобраться реально, может быть попробовать в нее добавить поддержку Rust? CAB>Почему бы и нет, если есть желание и время. Хотя я бы дождался "устаканивания" Rust'а.
Нашел весьма неплохой способ работать с Rust из под винды. Ничего не нужно компилировать (а значит и нарываться на ошибки, связанные с тем что линуксовые программы под виндой как правило сходу не собираются)
Требуется виндовые сборки mingw, gtk2, geany, ну и собственно сам rust.
2. mingw/bin, gtk/bin и rust/bin должны быть прописаны в path.
3. для geany нужен собранный exe и также исходники с гитхаба, из которых нужно взять папку data и целиком скопировать вместо папки data которая была при exe. Там куча настроек для разных языков, на самом деле чего там только нет, так что вероятно этот редактор можно использовать и для других интересных целей.
После этого создаем проект, в нем файл с расширением .rs, сохраняем (возможно еще нужно выбрать document->set filetype->programming languages->rust) — становятся активными кнопки compile и build, код подсвечивается, дерево символов, вывод ошибок во встроенный лог, щелчок по ошибке открывает ее в коде, кнопка "выполнить" запускает откомпилированное приложение. А для экспериментов что еще надо?
Re[5]: Local variables may shadow earlier declarations
Здравствуйте, WolfHound, Вы писали:
WH>А сколько кода ты написал с такой фичей?
Мне несколько раз компилятор давал по рукам за такое и каждый раз это был реальный баг. Мне сложно представить ради каких мнимых удобств нужна такая дыра в безопасности. Расскажешь?
Здравствуйте, VladD2, Вы писали:
VD>А до тех пор основная масса людей понимающих толк в ФА будет считать зык не шибко полезным. Точнее полностью бесполезным.
Это язык для людей с хорошим знанием C и С++. И им, в 9 из 10 случаем, на хвостовую рекурсию глубоко все равно. Ну а то что апологеты Nemerle будут считать Rust полностью бесполезным, думаю не является очень уж большой проблемой. Точнее совсем не является проблемой
Здравствуйте, kaa.python, Вы писали:
KP>Здравствуйте, VladD2, Вы писали:
VD>>А до тех пор основная масса людей понимающих толк в ФА будет считать зык не шибко полезным. Точнее полностью бесполезным.
KP>Это язык для людей с хорошим знанием C и С++. И им, в 9 из 10 случаем, на хвостовую рекурсию глубоко все равно. Ну а то что апологеты Nemerle будут считать Rust полностью бесполезным, думаю не является очень уж большой проблемой. Точнее совсем не является проблемой
Почему только апологетов Nemerle? Вообще всех, считающих странным неприветствие функционального стиля в околофункциональном языке.
Re[7]: Local variables may shadow earlier declarations
Здравствуйте, VladD2, Вы писали:
MTD>>Мне несколько раз компилятор давал по рукам за такое и каждый раз это был реальный баг. Мне сложно представить ради каких мнимых удобств нужна такая дыра в безопасности. Расскажешь?
VD>Даю точное предсказание. Язык не поддерживал неизменяемых переменных и ты косячил с изменяемыми. Так?
В современных мейнстримовых языках (например, С++, Java) компилятор не дает накосячить таким образом — это привычно для многих, поэтому мне не понятно ради каких удобств надо так конфьюзить разработчиков? Ну вот кто нибудь в состоянии привести внятный пример?
Re[9]: Local variables may shadow earlier declarations
Здравствуйте, Don Reba, Вы писали:
MTD>>Ну вот кто нибудь в состоянии привести внятный пример?
DR>Например, аргумент требуется внутри функции в других еденицах. Чтобы случайно не использовать изначальное значение, заводим локальную переменную с тем же именем.
DR>
Здравствуйте, alex_public, Вы писали: CAB>> В Rust есть хорошо проработанные и полезные ФП фичи(строгая типизация, паттерн матчинг, ФВП). В тоже время ООП похоже на какой-то костыль, типа "у всех есть и у нас будет", лучше бы автор сконцентрировал усилия на метапрограммировании. _>А что там не так по сравнению с обычными реализациями ООП?
Реализаций ООП много и все они разные. Я считаю, наиболее Ъ ООП в ЯП Scala, потому сравниваю с ним.
По моему скромному мнению, если уж вы решили добавить ООП в язык, вам не стоит туда добавлять ещё и отдельные функции, примитивные типы, структуры etc. Это оверкил. И наоборот, если вы решили что у вас будет язык низкого уровня, и там будут функции и п. типы, не стоит туда прикручивать ООП, структур вполне достаточно.
Между тем,что я думаю,тем,что я хочу сказать,тем,что я,как мне кажется,говорю,и тем,что вы хотите услышать,тем,что как вам кажется,вы слышите,тем,что вы понимаете,стоит десять вариантов возникновения непонимания.Но всё-таки давайте попробуем...(Э.Уэллс)
Здравствуйте, C.A.B, Вы писали:
CAB>Реализаций ООП много и все они разные. Я считаю, наиболее Ъ ООП в ЯП Scala, потому сравниваю с ним.
Скала — это такой недоязычок с freestanding-методами? Сжечь еретика!
Настоящий Ъ-ООП — это только Smalltalk!
CAB>По моему скромному мнению, если уж вы решили добавить ООП в язык, вам не стоит туда добавлять ещё и отдельные функции, примитивные типы, структуры etc. Это оверкил. И наоборот, если вы решили что у вас будет язык низкого уровня, и там будут функции и п. типы, не стоит туда прикручивать ООП, структур вполне достаточно.
Ну что за бред...
Здравствуйте, kaa.python, Вы писали:
KP>Здравствуйте, PSV100, Вы писали:
PSV>>Как я понимаю (на основе высказываний от авторов проекта на счёт ликвидации GC), у разработчиков есть идеи отказаться от встроенных "@"-указателей.
KP>А может они просто решили закопать так и не родившийся GC? Изначально был расчет что GC вот-вот появится и он даже пилился в параллельной ветке, но, видимо, не срослось
PSV>> На оwned-указатели ("~") возлагают основную роль (или подталкивают к максимальному их использованию для аллокации объектов в хипе), на роль shared-указателей предполагают реализацию custom-типов как решения для конкретных потребностей (где-то нужен именно GC, в таких-то случаях лучше RC, кому-то нужно взаимодействие с COM, GObject и т.д. и т.п.). Но, для custom-указателей нет поддержки со стороны языка как для встроенных (автоматическое их приведение к borrowed-ссылкам, например, в параметрах при вызове функции, оператор разыменования "*" и т.д.). Вероятно, возникнет потребность в поддержке какого-нибудь протокола (как для "for") через спец-trait, чтобы custom-указатели выглядели как встроенные.
KP>А вот намеков на такое я не заметил. Хотя, не сказать что очень уж внимательно слежу за обсуждениями, скорее по выходу очередного релиза смотрю что поменяли
Ну, а я в сторону Rust смотрю очень редко, за сплетнями вокруг него, фактически, не слежу. Но, на основе той статьи на счёт GC, её обсуждения, в т.ч. и в некоторых форумах (лишь немного посмотрел), складывается впечатление, что вроде как GC выкидывать не будут (имхо, пока, скорее всего, не хватает ресурсов для качественной реализации). Основной посыл, как я понимаю, в том, что как бы не комильфо в системном языке иметь только одну встроенную политику shared-объектов, через custom-типы есть смысл реализовать разные smart-указатели, как аналог уже имеющимся Rc, ARC и т.д.
По поводу "... вероятно, возникнет потребность в поддержке какого-нибудь протокола (как для "for") через спец-trait, чтобы custom-указатели выглядели как встроенные" — это именно мое предположение. В самом деле, как-то муторно (по "сишному") писать всё "в лоб" а-ля:
Имхо, не хватает протокола для автоматического приведения custom-указателей к аналогам встроенных. При этом пусть останется "@"-указатель как реализация shared-указателя по умолчанию, которую можно будет настраивать через опции компиляции (на основе аннотаций "#[...]", возможно даже в разрезе модулей), если вдруг появятся разные варианты. И custom-указатели должны быть совместимыми по типу с "@"-box (а также и с "~"-box для соответствующих типов). Т.е. как-то так:
let p1 : @Point = @Point{ x: 3.0, y: 4.0 }; // нечто встроенное
let p2 : Rc<Point> = rc::new( Point{x: 5.0, y: 1.0} ); // какой-то RC-указатель
let p3 : Gc<Point> = gc::new( Point{x: 7.0, y: 9.0} ); // указатель под контролем некоего GC
let p1 = mut rc::new( Point{x: 5.0, y: 1.0} ); // функция rc::new() для mut-объектов возвращает RcMut<T> вместо Rc<T>
...
*p1 = ...; // поддержка разыменования
Но для этого нужна перегрузка функций по её результату, где разница определяется в зависимости от "mut" возвращаемого объекта.
Тогда и custom-аллокаторы а-ля "арены" можно тоже подогнать под одну гребёнку:
let arena = Arena();
...
let p1 = arena.new( Point{x: 5.0, y: 1.0} ); //арена возвращает какой-то custom-указатель, совместимый с "@"
PSV>>Ну, а основной положительный момент в том, что такие фундаментальные вещи как аллокаторы, указатели, управление task-ами и др. не вбиты насмерть в компилятор (имхо, всё-таки, гибкости ещё добавят), и, вроде как, есть возможность для реализаций под конкретные потребности.
KP>Управление тасками (я только в этом детально копался) зарыто глубоко в C++ части стандартной библиотеки. Что на мой взгляд самое что ни на есть "прибито гвоздями".
Пока да, прибито. Имхо, после первых релизов, если язык всё-таки получит признание, то разработчики однозначно вынужденны будут ваять такие ключевые вещи как плагины для компилятора, развитые полноценные compile-time вычисления и пр. (вроде как, если не ошибаюсь, были заявлены такие плюшки). К примеру, я не спец в области реализации "зелёных" потоков, их планировщиков и т.д., но вроде как для поддержки какого-нибудь soft-realtime через custom-scheduler для задач (task-ов) придётся в бинарном коде разбрасывать инструкции для дёргания scheduler-а (т.к. нет VM). Имхо, подобные трюки должны делаться через плагин к компилятору. Или потребуются реализации современных модных тенденций, как компиляция в JavaScript и т.п.
На счёт compile-time вычислений. Имхо, имеющиеся макросы слишком ограничены и какие-то муторные для их написания. И как-то нехорошо в сегодняшнее время затевать новый язык с претензиями на промышленность, когда вокруг уже можно насмотреться на много чего, при этом продолжать тянуть в runtime кучу RTTI и активно там же (в runtime) направо-налево её дергать. Например, в MetaLua есть наработки, которые применимы и для такого языка как Rust (имхо, пока лучше без поддержки расширения базового синтаксиса языка), те же удобные квазицитаты как +{} и -{}. И, к примеру, функцию alloc для тех же "арен" (которая должна быть "сверх-быстрой") можно было бы реализовать как-то так:
impl Arena {
...
#[inline]
pub fn alloc<'a, T>(&'a self, op: &fn() -> T) -> &'a T {
unsafe {
let this = transmute_mut(self);
-{
if intrinsics::needs_drop::<T>() +{ // проверку, имеет ли тип деструктор, делаем в compile-time
this.alloc_nonpod(op)
} else +{
this.alloc_pod(op)
}
}
}
}
...
}
Имхо, если и будут компиляторные плагины и выше подобные выкрутасы (а они должны быть, если замахиваться на современную промышленность, причём именно конкурентно), то, скорее всего, где-то в Rust 2.0 или выше.
Здравствуйте, minorlogic, Вы писали:
M>Кратко, как это работает? какие отличия от С ? сенкс .
Память делится на 3 типа: стек, разделяемые указатели, уникальные указатели. Стековая память и разделяемые указатели не могут быть переданны за пределы текущего потока. Уникальные указатели могут передаваться другому потоку в режиме "только чтение". Так же есть понятие ссылки (в Rust они называются регионами), которые могут работать с любым типом указателя и по поведению схожие с сылками в C++, основное отличие состоит в том, что они могут безопасно работать не только с lvalue, но и rvalue, так как при необходимости создается копия объекта.
Сегодня вышел, на мой взгляд, интереснейший релиз Rust 0.10. Ломающих изменений в нем не очень много, зато был проведен просто грандиозный рефакторинг: две основные библиотеки libstd и libextra были разделены на полтора десятка библиотек "одной функции" в процессе чего libextra перестала сущестовать. Это хорошо в первую очередь тем, что появилась реальная возможность начать использовать Rust практически в пределах libstd (все же необходимо еще немного порезать libstd для отключения работы с задачами), а не только самого компилятора, на низком уровне, к примеру в драйверах. Сейчас как раз занимаюсь подобным экспериментом, выглядит ну очень заманчиво!
Здравствуйте, C.A.B, Вы писали:
CAB> Наигравшись за пару вечеров Rust'ом версии 0.8, спешу поделиться впечатлениями М-да, после уютненькой Scala, Rust - воды нет, растительности нет, населён роботами выглядит довольно пустынным и бедным.
В этом месяце будет 0.9
CAB> Захожу на оф. сайт, скачиваю инсталлер, устанавливаю без проблем — "урраа!". Неудачно пытаюсь собрать hello_world — "блииин...". Открываю инструкцию — "oh s~" 11 шагов установки. Риторический вопрос: почему бы, не сложит всё нужное в одну папку и не распространять это одним архивом?
По моим ощущениям, в основном, Rust пишут и худо-бедно использую *NIX разработчики. Поэтому процесс: загрузил исходники, вызвал ./configure; make; make install кажется самым что ни на есть очевидным способом установки чего-либо.
CAB> Rust (внезапно) поддерживает довольно много редакторов исходного кода, из которых я выбрал Eclipse (чего вам делать не рекомендую). Плагин для Eclipse судя по всему так-же ещё в разработке, нету проверки ошибок, автодополнения и прочих IDE плюшек. Есть кнопки сборки и запуска, но мне так и не удалось заставить их работать. Ну да ладно, есть подсветка синтаксис и на том спасибо.
Я бы посоветовал либо Vim (что сильно на любителя), либо Sublime Text 2 (шикарный редактор). Само собой, автоподстановок и прочих фишечек IDE нет, но по причине того, что продукт развивают в основном *NIX разработчики... ну, ты понял, да?
CAB> Документации очень мало. А та, что есть не полная, я минут 20 искал, как преобразовать "int" в "str", и оказывается, у int'а есть секретный метод "to_str()". Несмотря на это всё безобразие, есть неплохой туториал и мануал.
Еще есть хорошая документация по модулям std и extra. Там как раз про преобразование можно найти. И вот еще что, у int'а нет метода преобразования в строку. Есть трэйт ToStr, который реализован для кучи типов, в том числе и для int'a
CAB> Ооочень слабая поддержка сторонних библиотек. Собственно я хотел написать на Rust простенькое оконное приложение, но необходимость ручного написания обёрток с преобразованием типов сделала меня грустным, и дальше MessageBox я не продвинулся.
Думаю что оконные приложения на Rust писать если и начнут, то очень-очень не скоро. Это явно не его ниша и есть гора языков на которых это делать в разы удобнее.
Да, относительно библиотек. Есть страница в Wiki на GitHub, где перечисленны основные сторонние библиотеки для Rust имеющиеся на данный момент. В принципе, там и для создания UI есть кое что; из интересного я заметил биндинги к ncurses, wxWidgets и GTK+.
Re[8]: Local variables may shadow earlier declarations
Здравствуйте, vpchelko, Вы писали:
V>Так интересно чем же отличается стековая память от разделяемых указателей?
Первое на стеке, второе в куче.
V> Тут сам язык обеспечивает синхронизацию при обращении к объекту из другого потока?
А не нужно, два потока один объект не могут менять одновременно: при передаче уникального указателя из одного потока во второй первый поток его "теряет" и не может больше использовать.
Здравствуйте, Mr.Delphist, Вы писали:
MD>Мне почему-то это напоминает попытки "reinventing C++, но с перловым преферансом и функциональными девушками"
Да, начинает напоминать. Но вот плохо ли это? По большому счету, в Rust куда более грамотно отрезали опасные вещи связанные с работой с памятью, чем, к примеру, это было сделано в Java. Для написания многопоточных серверных приложений, Rust обещает быть именно тем самым языком, который и работу упростит, и просадку по скорости и по памяти не сделает особо уж чудовищной. Но, это все будущее, и наступит ли оно, пока не известно. Так что на данный момент, можно смотреть как язык развивается и помогать ему, если есть на то желание, родиться и окрепнуть
MTD>Local variables may shadow earlier declarations, as in the previous example: monster_size was first declared as a float, and then a second monster_size was declared as an int.
MTD>Не нужен.
Судя по опыту Немерле, удобная фича.
Ce n'est que pour vous dire ce que je vous dis.
Re[3]: Local variables may shadow earlier declarations
Здравствуйте, kaa.python, Вы писали:
KP>Это язык для людей с хорошим знанием C и С++.
Для людей хорошо знающих C и С++ есть новые версии C и С++. Rust на C и С++ ни разу не похож. Даже D куда больше на них похож.
KP>И им, в 9 из 10 случаем, на хвостовую рекурсию глубоко все равно.
Глупо переходить на язык поддерживающий ФП не планируя начать использовать ФП. А как только это случится, то отношение изменится.
KP>Ну а то что апологеты Nemerle
Ты думаешь, что задев оппонента ты станешь правее? Причем тут немерл? Я его называл? Немерл унаследовал данную оптимизацию у ML/OCaml. А до них были тонны языков включая Lisp. По твоей логике авторы этих языков — немерлисты?
KP>будут считать Rust полностью бесполезным, думаю не является очень уж большой проблемой.
Его будут считать ущербным. А отказываться от него будут на основании неадекватности авторов. Одно решение еще не приговор. Но 3-4 подобных решений и многие задумаются над тем можно ли доверять таким авторам.
И поверь на слово, те кто будет от него отказываться, почти наверняка, будут не немерлистами.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, FR, Вы писали:
FR>Во времена когда космические корабли даже компиляторы С++ легко FR>откручивают хвост околофункциональный язык курит в сторонке .
У них lifetime анализ для borrowed указателей неслабо так увеличивает сложность реализации хвостовых вызовов, так что неудивительно.
Здравствуйте, C.A.B, Вы писали:
CAB> В целом язык (пока и на первый взгляд) выглядит довольно неуклюже, как горка разнообразных, слабосвязанных фичь. Нету некоторой центральной/корневой/объединяющей всё концепции(й), такой как например pure OOP в Scala. Хотя, вероятно для низкоуровневого ЯП это и не особо важно.
А зачем она нужна? И какой в Scala ещё pure OOP?
CAB> Я не фанат смешиваний ежей с ужами, и считаю что в ЯП с указателями на память не место ООП, и наоборот. Для первого есть замечательные языки asm и C, для второго не менее замечательные Python и Scala. Потому, думаю, автору Rust'а стоило выбрать "какую то одну строну".
Смешались в кучу кони, люди...
Причём тут указатели и ООП???
CAB> Понравилась идея с задачами, такой себе Erlang-style, но тут обнаружилась ложка дёгтя: какая-то очень сильная магия с памятью, не знаю как, но уверен, это можно было сделать проще.
Нельзя.
Здравствуйте, C.A.B, Вы писали:
CAB>Реализаций ООП много и все они разные. Я считаю, наиболее Ъ ООП в ЯП Scala, потому сравниваю с ним.
Концепция типа "всё есть объект" — это как бы не фича, а наоборот ограничение возможностей. А я спрашиваю как раз про фичи. Ну такие как наследование (множественное или нет или с интерфейсами), полиморфизм, абстрактные классы, уровни инкапсуляции, статические методы, перегрузка операторов, обобщённые классы и т.п.
С удовольствием увидел бы табличку сравнения ООП фич между Scala, Rust'ом и скажем C++ (т.к. Rust пытается стать заменой именно ему, хотя пока я не вижу чтобы тянул на это).
CAB>По моему скромному мнению, если уж вы решили добавить ООП в язык, вам не стоит туда добавлять ещё и отдельные функции, примитивные типы, структуры etc. Это оверкил.
А чем оно мешает то?
CAB>И наоборот, если вы решили что у вас будет язык низкого уровня, и там будут функции и п. типы, не стоит туда прикручивать ООП, структур вполне достаточно.
Да, всё правильно. Но зачем нам в 21-ом веке ещё один язык низкого уровня? Нам наоборот нужен язык очень высокого уровня, но при этом с сохранением полноценного доступа к системе/железу.
KP>ООП – это не более чем подход к программированию, философия. Вполне себе такой ООП-шный ООП можно замутить на чистом Си (чем частенько и развлекаются).
Можно, но зачем? Для этого есть языки с его, ООП, хорошей поддержкой. А в НЯП ты всё равно работаешь с адресами, структурами и функциями
KP>Так как Rust язык системный, в нем безусловно есть структуры, POD-типы и указатели. Но можно ли это считать весткой причиной усложнять жизнь разработчикам?
ИМХО, авторы Rust как раз усложнили жизнь разработчикам добавлением ООП.
Между тем,что я думаю,тем,что я хочу сказать,тем,что я,как мне кажется,говорю,и тем,что вы хотите услышать,тем,что как вам кажется,вы слышите,тем,что вы понимаете,стоит десять вариантов возникновения непонимания.Но всё-таки давайте попробуем...(Э.Уэллс)
Здравствуйте, x-code, Вы писали:
XC>Эта LiteIDE написана на Qt, кода мало так что разобраться реально, может быть попробовать в нее добавить поддержку Rust?
Надо лучше начать добавлять поддержку в IDEA
Это не так сложно. Но очень хотелось бы, чтобы сначала устоялась грамматика.
Здравствуйте, Lazin, Вы писали:
L>Джулия не заточена под одну задачу а JavaScript есть в каждом браузере.
Если говорить о Julia, то сложно не согласиться с ее авторами "high-performance dynamic programming language for technical computing". В первую очередь это не язык общего назначения, а язык для мат. расчетов.
Что следует из наличия JavaScript в каждом бразузере я не очень понял. Особенно с учетом того, что это самый каждый браузер может на компьюетре и не стоять, или быть чем-то типа Links
Взялся поиграться с языком. И появился вопрос — почему математические функции сделали методами, а не отдельными функциями?
Т.е. x.sqrt() вместо привычного sqrt(x). И если с функцифми одного параметра это еще хоть как-то смотрится, то x.atan2(y) или a.mul_add(b,c) выглядит совсем уж инопланетно.
Причем в некоторых старых примерах еще можно найти варианты с внешними функциями, но у меня (свежий nightly) они уже не компилируется. Зачем это поменяли?
Выделенное — это временное чудище. Идет обкатка концепции и пока то, как этот концепция выглядит, не критично.
P>Новые типы массивов о_О
Вот как раз модель памяти Rust очень удобная (особенно если ты много писал на C/C++ и надо писать параллельный код). Как минимум попортить чужую память будет сложно.
P>а что будет если так написать? P>let x: ~[int] = &[0];
Здравствуйте, kaa.python, Вы писали:
KP>Вот как раз модель памяти Rust очень удобная (особенно если ты много писал на C/C++ и надо писать параллельный код). Как минимум попортить чужую память будет сложно.
Кратко, как это работает? какие отличия от С ? сенкс .
Тут все же правильнее с Ц++ сравнивать.
KP>Память делится на 3 типа: стек, разделяемые указатели, уникальные указатели. Стековая память и разделяемые указатели не могут быть переданны за пределы текущего потока.
Так интересно чем же отличается стековая память от разделяемых указателей? Если я не ошибаюсь в Ц++ локальная память выделялась на стеке...
KP>Уникальные указатели могут передаваться другому потоку в режиме "только чтение". Так же есть понятие ссылки (в Rust они называются регионами), которые могут работать с любым типом указателя и по поведению схожие с сылками в C++, основное отличие состоит в том, что они могут безопасно работать не только с lvalue, но и rvalue, так как при необходимости создается копия объекта.
Что-то тут намудрили. Тут сам язык обеспечивает синхронизацию при обращении к объекту из другого потока?
Здравствуйте, D. Mon, Вы писали:
V>> Тут сам язык обеспечивает синхронизацию при обращении к объекту из другого потока?
DM>А не нужно, два потока один объект не могут менять одновременно: при передаче уникального указателя из одного потока во второй первый поток его "теряет" и не может больше использовать.
Я не уверен точно, но вроде в случае уникального указателя, передающий поток не теряет владения им, в то время как получающий поток имеет доступ только-чтение и при попытке модификации создается копия объекта. См. пример из пункта "квалификатор const"
KP>Я не уверен точно, но вроде в случае уникального указателя, передающий поток не теряет владения им, в то время как получающий поток имеет доступ только-чтение и при попытке модификации создается копия объекта. См. пример из пункта "квалификатор const"
Здравствуйте, kaa.python, Вы писали:
KP>Вышла новая версия языка Rust с номером 0.3. Несмотря на то, что говорить о каком бы то ни было коммерческом использовании языка рано, он обретает все более и более четкие формы, появляется понимание куда же он движется. Лично меня то что я вижу очень и очень радует. KP>С официальным анонсом можно ознакомиться тут. Кроме того, я сделал перевод обзора основных нововведений несколько дополнив его, относительно официальной версии.
KP>P.S. в моем переводе есть пара мест, помеченных "(как это перевести?)". Буду очень благдарен за идеи как это лучше сделать
Идеи хорошие, но синтаксис в стиле J и уйма сокращений немного напрягают. В данном случае это именно экономия на спичках. Насчёт модели памяти и ссылок ничего умного сказать не могу, т.к. опыта маловато. Может, и можно было бы сделать попроще. Хотя в том же D, который все регулярно вспоминают, обошлись собственно управляемой кучей и placement new.
Здравствуйте, kaa.python, Вы писали:
KP>Я не уверен точно, но вроде в случае уникального указателя, передающий поток не теряет владения им, в то время как получающий поток имеет доступ только-чтение и при попытке модификации создается копия объекта. См. пример из пункта "квалификатор const"
То, что вы описали — borrowing. У них же вроде в мане написано, что unique pointers — как раз передача указателя новому владельцу с потрохами, так, что старый таск его теряет и не может использовать. Они так избавились от необходимости копирования данных между тасками.
Здравствуйте, Мишень-сан, Вы писали:
МС>То, что вы описали — borrowing. У них же вроде в мане написано, что unique pointers — как раз передача указателя новому владельцу с потрохами, так, что старый таск его теряет и не может использовать. Они так избавились от необходимости копирования данных между тасками.
Загляни в пример из из пункта "квалификатор const".
Здравствуйте, Мишень-сан, Вы писали:
МС>Идеи хорошие, но синтаксис в стиле J и уйма сокращений немного напрягают. В данном случае это именно экономия на спичках. Насчёт модели памяти и ссылок ничего умного сказать не могу, т.к. опыта маловато. Может, и можно было бы сделать попроще. Хотя в том же D, который все регулярно вспоминают, обошлись собственно управляемой кучей и placement new.
В D забили на многопоточность.
Здравствуйте, Мишень-сан, Вы писали:
МС>Насчёт модели памяти и ссылок ничего умного сказать не могу, т.к. опыта маловато. Может, и можно было бы сделать попроще. Хотя в том же D, который все регулярно вспоминают, обошлись собственно управляемой кучей и placement new.
В D по дефолту потоки не шарят память. Там есть модификаторы immutable (никто не меняет) и const (тебе нельзя менять), потоки обмениваются immutable сообщениями.
Здравствуйте, Cyberax, Вы писали:
C>В D забили на многопоточность.
Как это? Разверни мысль, пожалуйста. Из того, что я видел, там наоборот много мыслей ей посвящено и многое уже удобно сделано (кое-какая изоляция потоков, посылка-прием сообщений а-ля эрланг, удобные конструкции для параллельной обработки данных).
Здравствуйте, D. Mon, Вы писали:
C>>В D забили на многопоточность.
DM>Как это? Разверни мысль, пожалуйста. Из того, что я видел, там наоборот много мыслей ей посвящено и многое уже удобно сделано (кое-какая изоляция потоков, посылка-прием сообщений а-ля эрланг, удобные конструкции для параллельной обработки данных).
Он, видимо, имеет ввиду, что GC там глобальный. И модель памяти не запрещает шаринг данных.
Здравствуйте, kaa.python, Вы писали:
KP> Кроме того, я сделал перевод обзора основных нововведений несколько дополнив его, относительно официальной версии.
Так что в блоге то? Давай у нас, в виде статьи, опубликуем.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Синтаксис — няшка (сравнительно с Си-подобными ЯП).
Аннотации чистоты в том виде, в котором они есть сейчас (без полиморфизма эффектов) — не очень. Вообще, проблема с системами эффектов в том что они либо недостаточно выразительны, либо синтаксически тяжеловесны.
Отсутствие разделяемой между потоками памяти — большой минус, это можно сделать безопасно если ограничить такие данные иммутабельными.
Здравствуйте, SilentNoise, Вы писали:
SN>Отсутствие разделяемой между потоками памяти — большой минус, это можно сделать безопасно если ограничить такие данные иммутабельными.
Здравствуйте, kaa.python, Вы писали:
KP>Здравствуйте, SilentNoise, Вы писали:
SN>>Отсутствие разделяемой между потоками памяти — большой минус, это можно сделать безопасно если ограничить такие данные иммутабельными.
KP>Так это есть же.
Здравствуйте, kaa.python, Вы писали:
KP>Здравствуйте, SilentNoise, Вы писали:
SN>>Отсутствие разделяемой между потоками памяти — большой минус, это можно сделать безопасно если ограничить такие данные иммутабельными.
KP>Так это есть же.
Возможно, я что-то не так понял, но как мне сделать иммутабельную структуру данных разделяемую между разными потоками (не отдельные копии для каждого потока, а просто указатель на эту структуру в каждом потоке), если разделяемые указатели не могут быть переданы в другой поток?
Здравствуйте, kaa.python, Вы писали:
KP>Да там синтаксис постоянно меняется, вроде говорят что в последнем релизе он "почти окончательный", так что буду писать
Ну, дык, можешь хоть раз в месяц описывать. Что нам жалко что ли?
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, SilentNoise, Вы писали:
SN>Возможно, я что-то не так понял, но как мне сделать иммутабельную структуру данных разделяемую между разными потоками (не отдельные копии для каждого потока, а просто указатель на эту структуру в каждом потоке), если разделяемые указатели не могут быть переданы в другой поток?
Иммутабельные структуры (Const) передаются между потоками без копирования.
Здравствуйте, kaa.python, Вы писали:
KP>Здравствуйте, jazzer, Вы писали:
J>>Ух ты! А куда, если не секрет?
KP>По ряду причин мы вернулись в Мск. KP>Так что я со следующей недели буду сотрудником ЛК во второй раз, тут это практически без альтернативный вариант
А под Windows какая-нибудь простенькая среда разработки для него есть?
(для D я приспособился юзать Code::Blocks, есть также нормальный плагин для Студии, для Go — специальная сборка LiteIDE, а вот для Rust ничего пока не встречал... все что нужно — простейшая подсветка синтаксиса, компиляция из ide с логом ошибок и запуск программ)
Здравствуйте, include2h, Вы писали:
I>(для D я приспособился юзать Code::Blocks, есть также нормальный плагин для Студии, для Go — специальная сборка LiteIDE, а вот для Rust ничего пока не встречал... все что нужно — простейшая подсветка синтаксиса, компиляция из ide с логом ошибок и запуск программ)
Vim, Emacs, Sublime Text 2. Просто синтаксис еще не устоялся, и поэтому IDE сейчас далеко не главное. Ну и, насколько я понимаю, у Мозилы нет ресурсов на это.
Так что, лично я использую Vim
MTD>Local variables may shadow earlier declarations, as in the previous example: monster_size was first declared as a float, and then a second monster_size was declared as an int.
MTD>Не нужен.
Жесть. Похоже, что при добавлении этой фичи авторы думали не головой, а задом. Что странно, т.к. другие решения выглядят разумными.
Re[4]: Local variables may shadow earlier declarations
Здравствуйте, MTD, Вы писали:
DR>>удобная фича. MTD>Чтобы багов понаделать? Да, безусловно.
А сколько кода ты написал с такой фичей?
Или обычное "не читал, но осуждаю"?
... << RSDN@Home 1.2.0 alpha 5 rev. 62>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[6]: Local variables may shadow earlier declarations
Здравствуйте, MTD, Вы писали:
MTD>Мне несколько раз компилятор давал по рукам за такое и каждый раз это был реальный баг. Мне сложно представить ради каких мнимых удобств нужна такая дыра в безопасности. Расскажешь?
У тебя ведь переменные были изменяемые? Правда?
А тут про неизменяемые.
Так что нет никакой дыры.
... << RSDN@Home 1.2.0 alpha 5 rev. 62>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[7]: Local variables may shadow earlier declarations
Здравствуйте, WolfHound, Вы писали:
WH>Здравствуйте, MTD, Вы писали:
MTD>>Мне несколько раз компилятор давал по рукам за такое и каждый раз это был реальный баг. Мне сложно представить ради каких мнимых удобств нужна такая дыра в безопасности. Расскажешь? WH>У тебя ведь переменные были изменяемые? Правда? WH>А тут про неизменяемые. WH>Так что нет никакой дыры.
int val = 33;
....
string val = "USA";
...
Run(val); // Осуществили пуск ядерных ракет вместо слива унитаза - вызван перегруженный по string метод
Здравствуйте, kaa.python, Вы писали:
Кё>>Скачивается, собирается и ставится в /usr/bin/local KP>С таким же успехом можно скачать tar с сайта и собрать ручками Я же хочу именно что инсталлятор.
Ну... boost, git, python3, ruby или что-нбудь подобное ты тоже инсталлятором ставишь? А удалять или апгрейдить чем будешь? Есть стандартное понятие в UNIX-системах — пакет-менеджер, Homebrew (или MacPorts) этим и являются. Не могу представить зачем кому-то надо будет собирать Rust руками, если родной пакет-менеджер системы все поставит или проапгрейдит автоматом.
Нет.
Кё>, git, python3, ruby или что-нбудь подобное ты тоже инсталлятором ставишь?
Да. Не буду же я все подрят собирать из исхдников. Если бы хотел собрать все и вся, то пользовался бы Gentoo.
Кё> А удалять или апгрейдить чем будешь? Есть стандартное понятие в UNIX-системах — пакет-менеджер, Homebrew (или MacPorts) этим и являются.
Они не являются менеджерами пакетов типа apt. Они ближе к идеологии Gentoo, что лично мне и кучи народа который я знаю совершенно не вперлось.
Кё> Не могу представить зачем кому-то надо будет собирать Rust руками, если родной пакет-менеджер системы все поставит или проапгрейдит автоматом.
Затем что у меня на работе MacPorts вообще не работает так как закрыт rsync. Поверх чего работает Homebrew не знаю, но подозреваю что тоже rsync, что было бы логично. Как следствие, я и 2000 моих коллег могут смело игнорировать этот/эти менеджеры пакетов
Здравствуйте, MTD, Вы писали:
MTD>Мне несколько раз компилятор давал по рукам за такое и каждый раз это был реальный баг. Мне сложно представить ради каких мнимых удобств нужна такая дыра в безопасности. Расскажешь?
Даю точное предсказание. Язык не поддерживал неизменяемых переменных и ты косячил с изменяемыми. Так?
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, kaa.python, Вы писали:
KP>Я считаю что это пофигу, так как:
KP>*] Рекурсии используются редко;
Когда ты пишешь в императивном стиле. В функциональном очень часто.
KP>*] Рекурсии затрудняют понимание кода;
Просто домыслы. На практике все наоборот. Это циклы затрудняют изучение кода.
KP>*] Всегда надо думать о том, поддерживается ли хвостовая рекурсия данным конкретным компилятором;
Любой язык претендующий на звание "поддерживает ФП" декларирует оптимизацию хвостовой рекурсии в своем описании. Так что компилятор ее не поддерживающий не будет компилятором этого зыка.
KP>*] В конце концов кто-нибудь добавит поддержку данной не шибко полезной оптимизации и в Rust.
А до тех пор основная масса людей понимающих толк в ФА будет считать зык не шибко полезным. Точнее полностью бесполезным.
Короче, странно, что ты обратил внимание на язык с ФП-основой, раз так мыслишь. Попробуй по программировать на любом ФЯ и тот час же поменяешь мнение. Я когда писал на С и Шарпе тоже не понимал зачем это нужно.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
V>Простота залог успеха. Тут намутили так, что надо разбираться.
Я думаю этим Растом застраховали себя от бОльшего числа ошибок которые приходится править сейчас.
Типа вот эта передача уник. указателя или передача в поток обхекта на стеке.
Здравствуйте, kaa.python, Вы писали:
KP>Здравствуйте, VladD2, Вы писали:
VD>>Думаешь многие будут ждать и надеяться на изменение точки зрения авторов? Основная масса просто забьет на язык.
KP>Язык версии 0.6 без хвостовой рекурсии заинтересовал две мощные корпорации (Мозилла и Самсунг). Наверное Немерле, с его великолепной поддержкой хвостовой рекурсии, может похвастаться не меньшими успехами, да?
Про мозиллу агрумент невалидный, ибо они его писать начали
Здравствуйте, kaa.python, Вы писали:
KP>Язык версии 0.6 без хвостовой рекурсии заинтересовал две мощные корпорации (Мозилла и Самсунг). Наверное Немерле, с его великолепной поддержкой хвостовой рекурсии, может похвастаться не меньшими успехами, да?
Языка пока нет. Интересовать он может разве что тех кому хочется во что-то поиграться. Не расскажешь о разработках Самсунга на этом языке?
В общем, можешь говорить все что угодно. Но, ФЯ без поддержки оптимизации хвостовой рекурсии — это нонсенс. Не более.
Аргументация авторов просто смехотворна. На сегодня почти все уважаемые компиляторы С++ поддерживают оптимизацию хвостовой рекурсии. А они то ИЯ. Писать циклы в них — норма.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[8]: Local variables may shadow earlier declarations
Здравствуйте, MTD, Вы писали:
MTD>Здравствуйте, VladD2, Вы писали:
MTD>>>Мне несколько раз компилятор давал по рукам за такое и каждый раз это был реальный баг. Мне сложно представить ради каких мнимых удобств нужна такая дыра в безопасности. Расскажешь?
VD>>Даю точное предсказание. Язык не поддерживал неизменяемых переменных и ты косячил с изменяемыми. Так?
MTD>В современных мейнстримовых языках (например, С++, Java) компилятор не дает накосячить таким образом
Это откровенное заблуждение. В С++ перекрытие переменных в норме вещей. Попробуй скоммпилировать что-то типа этого:
int i = 42;
{
int i = 15;
printf("i=%d\n", i);
}
MTD> — это привычно для многих, поэтому мне не понятно ради каких удобств надо так конфьюзить разработчиков?
Твоя проблема в том, что ты всю жизнь использовал языки семантика которых сходна. По этом тебе трудно представить что могло бы быть будь семантика несколько иная.
MTD>Ну вот кто нибудь в состоянии привести внятный пример?
Пример чего? Привести пример где того, что неизменяемые переменные приводят к каким-то реальным ошибкам я не могу. Уже 6 лет использую ФЯ в разработке и постоянно пользуюсь переопределением неизменяемых переменных. Ни разу не имел ни единой проблемы. Что я делаю не так?
Если тебе интересует пример того когда это удобно, то таких примеров масса. Например, нам нужно произвести ряд фильтраций некоторого списка. Чтобы не городить одну длинную строчку и меть возможность посмотреть в отладчике на промежуточные результаты я разбиваю одно выражение на несколько:
def result = source.Filter(некоторое длинное условие фильтрации);
def result = result.Filter(некоторое длинное условие фильтрации);
def result = result.Filter(некоторое длинное условие фильтрации);
def result = result.Filter(некоторое длинное условие фильтрации);
result
Это позволяет и код записать довольно красиво и в отладчике видеть промежуточные результаты.
А иногда промежуточными результатами надо еще что-то сделать.
При этом мы гарантированно не можем изменить переменную после объявления.
И, при этом, нам не нужно выдумывать совершенно синтетические имена (которые мешаются при рефакторинге и копипасте).
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[9]: Local variables may shadow earlier declarations
Здравствуйте, VladD2, Вы писали:
VD>Это откровенное заблуждение. В С++ перекрытие переменных в норме вещей. Попробуй скоммпилировать что-то типа этого: VD>
VD> int i = 42;
VD> {
VD> int i = 15;
VD> printf("i=%d\n", i);
VD> }
VD>
Здесь нет перекрытия — это две разных переменных в разных областях видимости.
VD>Твоя проблема в том, что ты всю жизнь использовал языки семантика которых сходна. По этом тебе трудно представить что могло бы быть будь семантика несколько иная.
Я бы не сказал, что сходна, насколько, например, она сходна у C++ и Python? Просто Rust, насколько я понял, претендует на замену С++, тогда не понятно зачем смущать разработчиков с опытом плюсов?
MTD>>Ну вот кто нибудь в состоянии привести внятный пример?
VD>Пример чего?
Пример того насколько удобно перекрытие объектов.
VD>Привести пример где того, что неизменяемые переменные приводят к каким-то реальным ошибкам я не могу.
Конечно, неизменяемые переменные сокращают количество ошибок.
VD>Если тебе интересует пример того когда это удобно, то таких примеров масса. Например, нам нужно произвести ряд фильтраций некоторого списка. Чтобы не городить одну длинную строчку и меть возможность посмотреть в отладчике на промежуточные результаты я разбиваю одно выражение на несколько: VD>
VD>def result = source.Filter(некоторое длинное условие фильтрации);
VD>def result = result.Filter(некоторое длинное условие фильтрации);
VD>def result = result.Filter(некоторое длинное условие фильтрации);
VD>def result = result.Filter(некоторое длинное условие фильтрации);
VD>result
VD>
VD>Это позволяет и код записать довольно красиво и в отладчике видеть промежуточные результаты.
Плохой пример — копипаста, так лучше:
def result = source.filter(
некоторое длинное условие фильтрации,
некоторое длинное условие фильтрации,
некоторое длинное условие фильтрации,
некоторое длинное условие фильтрации);
VD>А иногда промежуточными результатами надо еще что-то сделать.
Слишком большая ответственность для одного метода, похоже надо рефакторить.
VD>И, при этом, нам не нужно выдумывать совершенно синтетические имена (которые мешаются при рефакторинге и копипасте).
В нормальном коде нет потребности в синтетических именах.
Re[10]: Local variables may shadow earlier declarations
MTD>Здесь нет перекрытия — это две разных переменных в разных областях видимости.
Ох-ох-ох. Так как категорично, столь неверное утверждение...
При перекрытии имен всегда создаются два разных символа (переменных в данном примере). И, возможно тебя это удивит, в языках позволяющих переопределять переменные локальные переменные без внутри одного блока (если оно там вообще есть), то для новой переменной всегда вводится новая область видимости (обычно располагающаяся со стейтемента/выражения следующего за объявлением и заканчивающаяся ближайшим блоком.
В C# перекрытие имен для локальных переменных запрещено. Это записано в стандарте.
VD>>Твоя проблема в том, что ты всю жизнь использовал языки семантика которых сходна. По этом тебе трудно представить что могло бы быть будь семантика несколько иная.
MTD>Я бы не сказал, что сходна, насколько, например, она сходна у C++ и Python?
С точки зрения обсуждаемого вопроса, на 100%, так как современные версии C++ и Python поддерживают ФП в одинаковом объеме (поддерживают лямбды). Учитывая что без костылей Python TCO нет, то опыт от его использования нулевой.
Почитай вот ссылочки. На мысли должно наводить хотя бы то, что ссылок довольно много.
MTD>Просто Rust, насколько я понял, претендует на замену С++,
Ага. Сейчас все это говорят. Только из целей дизайна, описанных на сайте Rust-а, следует, что это скорее замена Яве. Эдакая нативная Ява с блэкджеком и шлюхами.
Как массовая замена C++ — это 100% провальная затея.
MTD>тогда не понятно зачем смущать разработчиков с опытом плюсов?
В Rust весь дизайн — это полнейшее смущение для разработчиков с опытом одних лишь плюсов. А вот как раз
MTD>Плохой пример — копипаста, так лучше:
MTD>
MTD>def result = source.filter(
MTD> некоторое длинное условие фильтрации,
MTD> некоторое длинное условие фильтрации,
MTD> некоторое длинное условие фильтрации,
MTD> некоторое длинное условие фильтрации);
MTD>
Ты читаешь не внимательно. Я же тебе сказал, что одна из проблем, что не видно промежуточных результатов.
Приведенный же тобой пример это пример мышления импративщика, потому как в ФП принято просто соединять выхлоп одной функции со входом другой (или вообще соединять сами функции). Фильтрацию я для примера пример. Сами запросы бывают куда хитрее и на все сочетания функций не наделаешь.
MTD>Слишком большая ответственность для одного метода, похоже надо рефакторить.
Ладно. Я мог бы с тобой поспорить очень долго и развенчать каждый из твоих домыслов, но вижу что в этом нет смысла. Свое Имею Мнение Хрен Оспоришь ты имеешь. Опыта в обсуждаемом вопросе у тебя явно — ноль. Учиться на чужом опыте это не для тебя. Могу сказать только одно. Попробуй то что критикуешь, тогда сам все поймешь.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[8]: Local variables may shadow earlier declarations
Здравствуйте, MTD, Вы писали:
MTD>Ну вот кто нибудь в состоянии привести внятный пример?
Например, аргумент требуется внутри функции в других еденицах. Чтобы случайно не использовать изначальное значение, заводим локальную переменную с тем же именем.
Здравствуйте, VladD2, Вы писали:
VD>Ты думаешь, что задев оппонента ты станешь правее? Причем тут немерл? Я его называл? Немерл унаследовал данную оптимизацию у ML/OCaml. А до них были тонны языков включая Lisp. По твоей логике авторы этих языков — немерлисты?
Нет. Это толстый намек на тот факт, что хоть ты и принял далеко не последнее участи в написании интересного с правильного с архитектурной точки зрения языка, язык оказался совершенно безуспешным с комерческой точки зрения. Как следствие, твое мнение в вопросе успешности язков вызывает серьезные сомнения, особенно с учетом поддержки еще не родившегося языка двумя серьезными корпорациями. Как-то так.
Re[11]: Local variables may shadow earlier declarations
Здравствуйте, VladD2, Вы писали:
VD>Ох-ох-ох. Так как категорично, столь неверное утверждение...
Покури пример
VD>Ты читаешь не внимательно. Я же тебе сказал, что одна из проблем, что не видно промежуточных результатов.
А это ты для отладки такой жуткий код написал? Тогда понятно, ибо в продакшн код такой ужас вряд ли кто в своем уме писать будет.
VD>Приведенный же тобой пример это пример мышления импративщика, потому как в ФП принято просто соединять выхлоп одной функции со входом другой (или вообще соединять сами функции). Фильтрацию я для примера пример. Сами запросы бывают куда хитрее и на все сочетания функций не наделаешь.
[VladD2 mode on]
Если бы ты был знаком с Unix, то знал что это Unix-way соединять вывод одного процесса с входом другого. Это используют даже сишники с незапятных времен.
[VladD2 mode off]
VD>Ладно. Я мог бы с тобой поспорить очень долго и развенчать каждый из твоих домыслов, но вижу что в этом нет смысла. Свое Имею Мнение Хрен Оспоришь ты имеешь. Опыта в обсуждаемом вопросе у тебя явно — ноль. Учиться на чужом опыте это не для тебя. Могу сказать только одно. Попробуй то что критикуешь, тогда сам все поймешь.
Ок. Засчитано.
Re[3]: Local variables may shadow earlier declarations
Здравствуйте, AlexRK, Вы писали:
ARK> ARK>Жесть. Похоже, что при добавлении этой фичи авторы думали не головой, а задом. Что странно, т.к. другие решения выглядят разумными.
Да не такое уж и плохое решение. Как минимум позволяет не вводить лишних имен без надобности. Типичный пример при работе с задачами, когда с одинм потоком будут работать несколько задач и Chan надо конвертировать в SharedChan.:
let (out,in): (Port<int>, Chan<int>) = stream();
let in = SharedChan(in);
Re[12]: Local variables may shadow earlier declarations
(*
аналог reinterpret_cast<int> из C++ для ссылочных типов
выдаст физический адрес объекта.
*)let reinterpret_cast x : int = Obj.magic (Obj.repr x)
let x = ref 0
let _ = Printf.printf "%d\n" (reinterpret_cast x)
let x = "test"let _ = Printf.printf "%d\n" (reinterpret_cast x)
результат
>./get_addr
69987975547676
69987974498292
то есть как и в C++ эти объекты физически расположены в разных участках памяти.
По сути в ML языках let в сишных терминах просто неявно вводит скопе.
Ну и учитывая что let выражения в этих языках как раз и есть замена сишных
скопе через {} все логично и не вызывает никаких неоднозначностей и неудобств.
Про удобство выше уже писали.
Re[13]: Local variables may shadow earlier declarations
Здравствуйте, FR, Вы писали:
FR>то есть как и в C++ эти объекты физически расположены в разных участках памяти.
Это не главное.
FR>По сути в ML языках let в сишных терминах просто неявно вводит скопе. FR>Ну и учитывая что let выражения в этих языках как раз и есть замена сишных FR>скопе через {} все логично и не вызывает никаких неоднозначностей и неудобств.
Во-первых сишных или плюсовых? Это два очень разных языка.
Во-вторых, с точки зрения С++ пример вообще о другом. Вот поведение в стиле С++: пример
FR>Про удобство выше уже писали.
Но не привели не одного убедительного примера, только пару wtf
Re[14]: Local variables may shadow earlier declarations
Здравствуйте, MTD, Вы писали:
MTD>Во-первых сишных или плюсовых? Это два очень разных языка.
Большой разницы нет, вроде поведение в этом почти одинаковое, учитывая
конечно большую ограниченность си.
MTD>Во-вторых, с точки зрения С++ пример вообще о другом. Вот поведение в стиле С++: пример
Понятно что в С++ соблюдается вложенность, в ML этого нет, новое объявление полностью
отменяет старое.
FR>>Про удобство выше уже писали.
MTD>Но не привели не одного убедительного примера, только пару wtf
Для языков с си образным синтаксисом + эта фича (типа немерли или руста) я к сожалению
ничего привести не могу ни писал на подобных.
let же из OCaml или F# это все же не объявление переменной в смысле сиобразных
языков это просто привязка (у нее и полное название соответствующее let binding)
имени к выражению и соответственно и семантика и проблемы у него другие.
Re[4]: Local variables may shadow earlier declarations
Здравствуйте, kaa.python, Вы писали:
KP>Да не такое уж и плохое решение. Как минимум позволяет не вводить лишних имен без надобности. Типичный пример при работе с задачами, когда с одинм потоком будут работать несколько задач и Chan надо конвертировать в SharedChan.:
Фиг знает. В данном вопросе я солидарен с коллегой MTD — на мой взгляд эта фича скорее ведет к путанице, чем к ясности кода.
Вот, честно, не понимаю — как вообще можно серьезно обсуждать такое средство запутывания кода. Писать может и легче (хотя придумать имя переменной, ИМХО, не адски сложная задача), а вот читать...
Здравствуйте, Lazin, Вы писали:
L>У них lifetime анализ для borrowed указателей неслабо так увеличивает сложность реализации хвостовых вызовов, так что неудивительно.
Зачем там вообще какой-то анализ? Концевая рекурсия переписывается в цикл. Все параметры тупо становятся переменными.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Зачем там вообще какой-то анализ? Концевая рекурсия переписывается в цикл. Все параметры тупо становятся переменными.
А как же указатели? Не все так просто, если функция получает или возвращает указатели, но тут еще нужно обеспечить, чтобы результат не менял время их жизни. В Си и С++ TCO реализуется далеко не тривиально а здесь должно быть еще сложноей.
Здравствуйте, Lazin, Вы писали:
VD>>Зачем там вообще какой-то анализ? Концевая рекурсия переписывается в цикл. Все параметры тупо становятся переменными.
L>А как же указатели?
Точно так же. Там без разницы какое значение. Просто была функция, стал цикл.
L>Не все так просто, если функция получает или возвращает указатели, но тут еще нужно обеспечить, чтобы результат не менял время их жизни. В Си и С++ TCO реализуется далеко не тривиально а здесь должно быть еще сложноей.
Сложности возникают только в случае когда рекурсия устраняется на не одной функции, а на множестве. На одной — это элементарное занятие.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
L>>У них lifetime анализ для borrowed указателей неслабо так увеличивает сложность реализации хвостовых вызовов, так что неудивительно. VD>Зачем там вообще какой-то анализ? Концевая рекурсия переписывается в цикл. Все параметры тупо становятся переменными.
Borrowed-check анализ обеспечивает compile-time memory safety указателей без использования GC, абстракций и любых прочих накладных расходов, в чем и заключается главная фишка и инновационность всего языка. Разумеется это важнее чем какой-то минорный фетиш из функционального программирования, поэтому если концевая рекурсия его усложняет — на нее тупо забили.
Здравствуйте, McSeem2, Вы писали:
MS>Здравствуйте, IT, Вы писали:
KP>>>Вышла новая версия языка Rust с номером 0.3. IT>>Кто придумал такое название для языка?
MS>Название дикое, но запоминающееся. Надо будет попробовать.
Мне нравится -- Руст.
Re[9]: Local variables may shadow earlier declarations
Здравствуйте, VladD2, Вы писали:
VD>Если тебе интересует пример того когда это удобно, то таких примеров масса. Например, нам нужно произвести ряд фильтраций некоторого списка. Чтобы не городить одну длинную строчку и меть возможность посмотреть в отладчике на промежуточные результаты я разбиваю одно выражение на несколько: VD>
VD>def result = source.Filter(некоторое длинное условие фильтрации);
VD>def result = result.Filter(некоторое длинное условие фильтрации);
VD>def result = result.Filter(некоторое длинное условие фильтрации);
VD>def result = result.Filter(некоторое длинное условие фильтрации);
VD>result
VD>
VD>Это позволяет и код записать довольно красиво и в отладчике видеть промежуточные результаты.
Выглядит как использование изменяемой переменной. А в каких случаях удобно менять тип такой переменной? (Без изменения типа проще иметь возможность указать, что переменная изменяемая, а не делать такие переопределения).
Здравствуйте, Grundik2, Вы писали:
MS>>Название дикое, но запоминающееся. Надо будет попробовать. G>Мне нравится -- Руст.
Однажды, в эмоциональной беседе на работе я высказал такую метафору, что эта софта напоминает ржавые шестеренки (rusty gears), они еще как-то вертятся, но с такими диким скрежетом и в таком диком data binding скоро станут совсем неуправляемыми (язык C#). Но тот программист погиб и спросить уже не с кого. Даже и не знаю, что делать — переделывать или так и продолжать копаться. Переделать — очень большой объем работы, а копаться — тошно.
Но меня просто название языка прикололо, а так я убежденный ретроград. Вообще, не очень важно, каков язык, важна грамотная инженерная идеология в проектировании. В электронике она выработалась, а в программизме до сих пор как-то не очень.
McSeem
Я жертва цепи несчастных случайностей. Как и все мы.
Здравствуйте, kaa.python, Вы писали:
KP>А ничего так, быстро развивают язык. Сегодня вышел Rust 0.7. Революционных изменений я не заметил, просто идет хорошая такая эволюция.
“basically, any question of the form ‘is there a reason for this stupid and terrible thing’ is ‘no, sorry, we’re working on it’ ”.
...
The compiler is still buggy and inefficient. Lots of things work, but lots of things don’t.
...
It would be silly to use Rust for something important
Здравствуйте, Кодёнок, Вы писали:
Кё>Borrowed-check анализ обеспечивает compile-time memory safety указателей без использования GC, абстракций и любых прочих накладных расходов, в чем и заключается главная фишка и инновационность всего языка. Разумеется это важнее чем какой-то минорный фетиш из функционального программирования, поэтому если концевая реткурсия его усложняет — на нее тупо забили.
Попробуй еще раз (последний, так как времени жалко) объяснить...
Любая функция с концевой рекурсией может быть очень легко преобразована в аналогичную функцию содержащую цикл. Преобразование делается еще на нетипизированном АСТ. Соответственно все проверки (включая memory safety) делаются на преобразованной функции.
Циклы их алгоритм умеет проверять? Ну, вот, значит, и тут у них проблем не будет.
Сложнее с взаимнорекурсиными функциями. Но на них как раз можно забить, так как они на практике не часто используются.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Lazin, Вы писали:
L>А как же указатели? Не все так просто, если функция получает или возвращает указатели, но тут еще нужно обеспечить, чтобы результат не менял время их жизни. В Си и С++ TCO реализуется далеко не тривиально а здесь должно быть еще сложноей.
Хм..., на Rust смотрю редко, и всё как-то откладывал на потом разобраться с его системой Typestate. И только сейчас заметил, что её ликвидировали. Заметка по этому поводу: Typestate Is Dead, Long Live Typestate!. В принципе, предложенная там альтернатива — "branding pattern" — не плоха и проста (что, имхо, самое главное). Но есть справедливо подмеченный в статье минус — требуется создание нового объекта с новым типом. Имхо, в системном языке однозначно нужны способы для аллокации "по месту", и, в целом, без custom-аллокаторов не обойтись. С учётом "Removing Garbage Collection From the Rust Language", имхо, в языке ещё явно не устаканена семантика модели памяти, и изменения ещё будут, и, скорее всего, в синтаксисе тоже, хотелось бы с поддержкой "пересоздания" объектов и своих аллокаторов.
Здравствуйте, PSV100, Вы писали:
PSV> имхо, в языке ещё явно не устаканена семантика модели памяти, и изменения ещё будут, и, скорее всего, в синтаксисе тоже, хотелось бы с поддержкой "пересоздания" объектов
Основные концепции, такие как разделение на общую память и память задачи, а так же особенности работы с указателями, мне думается, уже устаканились. Хотя, что-то еще будет меняться, само собой.
PSV>и своих аллокаторов.
Здравствуйте, kaa.python, Вы писали:
KP>Здравствуйте, PSV100, Вы писали:
PSV>> имхо, в языке ещё явно не устаканена семантика модели памяти, и изменения ещё будут, и, скорее всего, в синтаксисе тоже, хотелось бы с поддержкой "пересоздания" объектов
KP>Основные концепции, такие как разделение на общую память и память задачи, а так же особенности работы с указателями, мне думается, уже устаканились. Хотя, что-то еще будет меняться, само собой.
Как я понимаю (на основе высказываний от авторов проекта на счёт ликвидации GC), у разработчиков есть идеи отказаться от встроенных "@"-указателей. На оwned-указатели ("~") возлагают основную роль (или подталкивают к максимальному их использованию для аллокации объектов в хипе), на роль shared-указателей предполагают реализацию custom-типов как решения для конкретных потребностей (где-то нужен именно GC, в таких-то случаях лучше RC, кому-то нужно взаимодействие с COM, GObject и т.д. и т.п.). Но, для custom-указателей нет поддержки со стороны языка как для встроенных (автоматическое их приведение к borrowed-ссылкам, например, в параметрах при вызове функции, оператор разыменования "*" и т.д.). Вероятно, возникнет потребность в поддержке какого-нибудь протокола (как для "for") через спец-trait, чтобы custom-указатели выглядели как встроенные.
PSV>>и своих аллокаторов.
KP>Я не уверен, но вот это не то?
Ага, типа оно. Вскользь (без детальных разбирательств) глянул на внутреннюю реализацию этой "арены". Первое, что обращает на себя внимание, это то, что внутри используются массивы байтов как @[u8], т.е. как "shared"-данные, при этом, фактически, массивы есть "приватные" данные, вроде как, ни с кем не разделяемые, плюс компилятором наверняка создаётся оверхед в виде неявного объекта а-ля "RC" (или чего-то иного), т.е. как для всех встроенных @-указателей. Видимо, есть причины для этого из-за особенностей используемых там низкоуровневых хаков. К тому же стандартная библиотека тоже подталкивает к @-box, например, те же используемые там стандартные списки, которые объявлены, соответственно и реализованы как "@":
enum List<T> {
Cons(T, @List<T>),
Nil,
}
Теоретически, списки должны быть более абстрактны, т.е. как-то по таким мотивам:
Т.е. через регионы (или lifetime) компилятор должен отслеживать корректность жизни создаваемых списков, и есть возможность через потенциальные shared-указатели (речь о которых была выше) реализовать списки с произвольной аллокацией объектов. Имхо, с устаканиванием основных концепций библиотеки вероятно будут преобразованы к нужному виду.
И второе, в этой "арене" используется RTTI (в частности, выясняется, есть ли явный деструктор у типа аллоцируемых данных), причём именно в рантайме. Т.е., как я понимаю, в создаваемых бинарниках, фактически, всегда создаётся куча RTTI-данных, которые в 99% прикладного кода, скорее всего, не будут использоваться. При этом внутри стандартной библиотеки (о которой создаётся впечатление, что RTTI задействована на всю катушку) основная масса операций с RTTI, теоретически, должна выполняться во время компиляции. К примеру, эта "арена" для объектов с деструкторами и без использует разные блоки памяти для оптимизации, но, формально, ведь всё известно во время компиляции, и для рантайма не нужно создавать лишнего кода.
Имхо, вроде как заявлено, что в будущем возможны плагины для компилятора и пр. Короче говоря, вроде как есть надежды на продвинутые compile-time вычисления, м.б. даже на полноценное метапрограммирование, с квазицитированием (хотелось бы, во всяком случае).
Ну, а основной положительный момент в том, что такие фундаментальные вещи как аллокаторы, указатели, управление task-ами и др. не вбиты насмерть в компилятор (имхо, всё-таки, гибкости ещё добавят), и, вроде как, есть возможность для реализаций под конкретные потребности.
Здравствуйте, kaa.python, Вы писали:
KP>Здравствуйте, kaa.python, Вы писали:
KP>Слайды с выступления Nicholas Matsakis "Guaranteeing memory safety in Rust". Познавательно.
Спасибо. Полезно то, что в одном месте указаны основные принципы вокруг ссылок и указателей. Уж для полноты картины не хватает описания "move/copy"-семантики передачи объектов при вызове функций, описание моментов, когда происходит неявный вызов "clone()" и "deep_clone()" и т.п.
Здравствуйте, PSV100, Вы писали:
PSV>Как я понимаю (на основе высказываний от авторов проекта на счёт ликвидации GC), у разработчиков есть идеи отказаться от встроенных "@"-указателей.
А может они просто решили закопать так и не родившийся GC? Изначально был расчет что GC вот-вот появится и он даже пилился в параллельной ветке, но, видимо, не срослось
PSV> На оwned-указатели ("~") возлагают основную роль (или подталкивают к максимальному их использованию для аллокации объектов в хипе), на роль shared-указателей предполагают реализацию custom-типов как решения для конкретных потребностей (где-то нужен именно GC, в таких-то случаях лучше RC, кому-то нужно взаимодействие с COM, GObject и т.д. и т.п.). Но, для custom-указателей нет поддержки со стороны языка как для встроенных (автоматическое их приведение к borrowed-ссылкам, например, в параметрах при вызове функции, оператор разыменования "*" и т.д.). Вероятно, возникнет потребность в поддержке какого-нибудь протокола (как для "for") через спец-trait, чтобы custom-указатели выглядели как встроенные.
А вот намеков на такое я не заметил. Хотя, не сказать что очень уж внимательно слежу за обсуждениями, скорее по выходу очередного релиза смотрю что поменяли
PSV>Ну, а основной положительный момент в том, что такие фундаментальные вещи как аллокаторы, указатели, управление task-ами и др. не вбиты насмерть в компилятор (имхо, всё-таки, гибкости ещё добавят), и, вроде как, есть возможность для реализаций под конкретные потребности.
Управление тасками (я только в этом детально копался) зарыто глубоко в C++ части стандартной библиотеки. Что на мой взгляд самое что ни на есть "прибито гвоздями".
Здравствуйте, sysenter, Вы писали:
S>Можно подробнее, чем Rust лучше D?
Что бы подробнее, надо хорошо знать оба языка. А я слегка знаю Rust и почти вообще не знаю D
Моих знаний достаточно для того, что бы сказать следующее: у Rust модель памяти лучше подходит для написания многопоточный приложений (думаю, когда они дойдут до распределенных, модель памяти тоже окажется удачной), чем модель памяти D; у Rust хорошо продуманная модель взаимодействия между потоками (сказать лучше ли она имеющихся в D альтернатив я не могу). Ну и самое главное, у языка есть поддержка со стороны больших корпораций, в отличие от D.
Здравствуйте, kaa.python, Вы писали:
KP>Здравствуйте, kaa.python, Вы писали:
KP>Слайды с выступления Nicholas Matsakis "Guaranteeing memory safety in Rust". Познавательно.
можно ли делать ассемблерные вставки в код руста как в C++?
Здравствуйте, D. Mon, Вы писали:
DM>Здравствуйте, Grundik2, Вы писали:
G>>можно ли делать ассемблерные вставки в код руста как в C++?
DM>Он через LLVM компилится, так что вставки если и были бы, то только IR LLVM. Да и то вряд ли.
Здравствуйте, Grundik2, Вы писали:
DM>>Он через LLVM компилится, так что вставки если и были бы, то только IR LLVM. Да и то вряд ли.
G>ничего не понял почти.
Компилятор раста генерит не ассемблер, а чуть более высокоуровневый и типизированный его аналог — Intermediate Representation (IR) библиотеки LLVM, которая уже генерит машинный код для разных архитектур.
Rust уже не торт. Недавно его разработчики решили отказаться от сегментированного стека, мотивируя это тем, что современные операционные системы позволяют создавать множество корутин, без всяких сегментированых стеков. Проблема только в том, что это не масштабируется. Вот например, разработчики Golang пошли другим путем, там стек изначально маленький, но по мере роста он копируется (примерно как std::vector в с++). Поэтому Go — торт, а Rust — уже не торт
Здравствуйте, Lazin, Вы писали:
L>Rust уже не торт. Недавно его разработчики решили отказаться от сегментированного стека, мотивируя это тем, что современные операционные системы позволяют создавать множество корутин, без всяких сегментированых стеков. Проблема только в том, что это не масштабируется. Вот например, разработчики Golang пошли другим путем, там стек изначально маленький, но по мере роста он копируется (примерно как std::vector в с++). Поэтому Go — торт, а Rust — уже не торт
Я может быть что-то путаю, но в Rust есть такая штука как __morestack, которая фигурирует повсеместно. Так вот, эта штука занимается динамическим увеличением стека в процессе работы приложения. Я на нее чисто случайно наткнулся, когда Rust в OSX драйвер затаскивал
Здравствуйте, kaa.python, Вы писали: KP>Вышла новая версия языка Rust ...
Наигравшись за пару вечеров Rust'ом версии 0.8, спешу поделиться впечатлениями М-да, после уютненькой Scala, Rust - воды нет, растительности нет, населён роботами выглядит довольно пустынным и бедным.
Об инфраструктуре:
Захожу на оф. сайт, скачиваю инсталлер, устанавливаю без проблем — "урраа!". Неудачно пытаюсь собрать hello_world — "блииин...". Открываю инструкцию — "oh s~" 11 шагов установки. Риторический вопрос: почему бы, не сложит всё нужное в одну папку и не распространять это одним архивом?
Rust (внезапно) поддерживает довольно много редакторов исходного кода, из которых я выбрал Eclipse (чего вам делать не рекомендую). Плагин для Eclipse судя по всему так-же ещё в разработке, нету проверки ошибок, автодополнения и прочих IDE плюшек. Есть кнопки сборки и запуска, но мне так и не удалось заставить их работать. Ну да ладно, есть подсветка синтаксис и на том спасибо.
Документации очень мало. А та, что есть не полная, я минут 20 искал, как преобразовать "int" в "str", и оказывается, у int'а есть секретный метод "to_str()". Несмотря на это всё безобразие, есть неплохой туториал и мануал.
Об языке:
В целом язык (пока и на первый взгляд) выглядит довольно неуклюже, как горка разнообразных, слабосвязанных фичь. Нету некоторой центральной/корневой/объединяющей всё концепции(й), такой как например pure OOP в Scala. Хотя, вероятно для низкоуровневого ЯП это и не особо важно.
Порадовала краткость синтаксиса, в особенности имена базовых типов, например "u16" вместо "unsigned short int" (пальцы можно сломать), не обязательность return'ов и конечно же паттерн матчинг. Весьма неплохая идея использовать "let" для определения переменных, благодаря этому код читается легче. Особенно хочу отметить прикольный синтаксис для функций и лямбд, видно что автор поклонник функционального программирования. Не понравились обязательные ";" (для меня не очевидно, зачем они нужны вообще).
Я не фанат смешиваний ежей с ужами, и считаю что в ЯП с указателями на память не место ООП, и наоборот. Для первого есть замечательные языки asm и C, для второго не менее замечательные Python и Scala. Потому, думаю, автору Rust'а стоило выбрать "какую то одну строну".
В Rust есть хорошо проработанные и полезные ФП фичи(строгая типизация, паттерн матчинг, ФВП). В тоже время ООП похоже на какой-то костыль, типа "у всех есть и у нас будет", лучше бы автор сконцентрировал усилия на метапрограммировании.
Понравилась идея с задачами, такой себе Erlang-style, но тут обнаружилась ложка дёгтя: какая-то очень сильная магия с памятью, не знаю как, но уверен, это можно было сделать проще.
Ооочень слабая поддержка сторонних библиотек. Собственно я хотел написать на Rust простенькое оконное приложение, но необходимость ручного написания обёрток с преобразованием типов сделала меня грустным, и дальше MessageBox я не продвинулся.
Ну да ладно, критиковать легко, а делать тяжело. Ждём версии 1.0.
Между тем,что я думаю,тем,что я хочу сказать,тем,что я,как мне кажется,говорю,и тем,что вы хотите услышать,тем,что как вам кажется,вы слышите,тем,что вы понимаете,стоит десять вариантов возникновения непонимания.Но всё-таки давайте попробуем...(Э.Уэллс)
Здравствуйте, Cyberax, Вы писали: CAB>> В целом язык (пока и на первый взгляд) выглядит довольно неуклюже, как горка разнообразных, слабосвязанных фичь. Нету некоторой центральной/корневой/объединяющей всё концепции(й), такой как например pure OOP в Scala. Хотя, вероятно для низкоуровневого ЯП это и не особо важно. C>А зачем она нужна?
Она соединяет все костыли фичи ЯП в одну стройную и логичную систему. Что упрощает и ускоряет освоение и использование ЯП, людьми не обделёнными системным и логичным мышлением, в частности программистами.
C>И какой в Scala ещё pure OOP? Самый что ни наесть pure.
CAB>> Я не фанат смешиваний ежей с ужами, и считаю что в ЯП с указателями на память не место ООП, и наоборот. Для первого есть замечательные языки asm и C, для второго не менее замечательные Python и Scala. Потому, думаю, автору Rust'а стоило выбрать "какую то одну строну". C>Смешались в кучу кони, люди... C>Причём тут указатели и ООП???
Вот и я о том-же: не стоит их смешивать.
Между тем,что я думаю,тем,что я хочу сказать,тем,что я,как мне кажется,говорю,и тем,что вы хотите услышать,тем,что как вам кажется,вы слышите,тем,что вы понимаете,стоит десять вариантов возникновения непонимания.Но всё-таки давайте попробуем...(Э.Уэллс)
Здравствуйте, C.A.B, Вы писали:
C>>А зачем она нужна? CAB>Она соединяет все костыли фичи ЯП в одну стройную и логичную систему. Что упрощает и ускоряет освоение и использование ЯП, людьми не обделёнными системным и логичным мышлением, в частности программистами.
Что такого стройного в pure OOP?
C>>И какой в Scala ещё pure OOP? CAB>Самый что ни наесть pure.
Да? И функций там нет, а только методы?
C>>Смешались в кучу кони, люди... C>>Причём тут указатели и ООП??? CAB>Вот и я о том-же: не стоит их смешивать.
Я говорю про то, что между наличием указателей и их арифметики и чистой OOP нет совершенно НИКАКОЙ связи.
C>Да? И функций там нет, а только методы?
Хмм.. а ведь функций там и правда нету
Между тем,что я думаю,тем,что я хочу сказать,тем,что я,как мне кажется,говорю,и тем,что вы хотите услышать,тем,что как вам кажется,вы слышите,тем,что вы понимаете,стоит десять вариантов возникновения непонимания.Но всё-таки давайте попробуем...(Э.Уэллс)
Здравствуйте, C.A.B, Вы писали:
CAB>Об языке: CAB> В целом язык (пока и на первый взгляд) выглядит довольно неуклюже, как горка разнообразных, слабосвязанных фичь. Нету некоторой центральной/корневой/объединяющей всё концепции(й), такой как например pure OOP в Scala. Хотя, вероятно для низкоуровневого ЯП это и не особо важно.
Только низкоуровневость разная бывает. Бывает язык позволяющий очень высокий абстракции, но при этом сохраняющий доступ к железу (как C++ или D). А бывает что и сам язык низкоурвневый (типа C или вообще Asm). По поводу Rust'а я пока не очень понял. По ощущениям он застрял где-то посередине.
CAB> Я не фанат смешиваний ежей с ужами, и считаю что в ЯП с указателями на память не место ООП, и наоборот. Для первого есть замечательные языки asm и C, для второго не менее замечательные Python и Scala. Потому, думаю, автору Rust'а стоило выбрать "какую то одну строну".
Согласен, хотя немного в другом смысле. Мне кажется что вообще очень странно в 21-ом веке создавать язык базирующийся в основном на указателях. В текущих системных языках от них наоборот стараются уходить, пряча внутрь каких-то других сущностей. Естественно совсем без них в системном языке нельзя, т.к. с их помощью осуществляется доступ системным api и железу. Но это же не повод ставить их в основу языка...
CAB> В Rust есть хорошо проработанные и полезные ФП фичи(строгая типизация, паттерн матчинг, ФВП). В тоже время ООП похоже на какой-то костыль, типа "у всех есть и у нас будет", лучше бы автор сконцентрировал усилия на метапрограммировании.
А что там не так по сравнению с обычными реализациями ООП?
CAB> Понравилась идея с задачами, такой себе Erlang-style, но тут обнаружилась ложка дёгтя: какая-то очень сильная магия с памятью, не знаю как, но уверен, это можно было сделать проще.
Безусловно можно. Я видел реализацию модели акторов в разных языках. Если мы возьмём C++ (здесь это у нас в виде сторонних библиотек), то здесь действительно надо самим следить что куда мы посылаем. Т.е. есть возможность нечаянно нарушить правила библиотеки и получить баг. Если возьмём реализацию в D (там она входит в базовую библиотеку), то фичи D (разделение памяти по потокам, immutable и т.п.) позволяют полностью предотвратить подобные ошибки. Но при этом остаётся возможность специально обойти систему через самый низкий уровень. В Rust'е как я понимаю сложно уже даже специально обойти. Но на мой взгляд это уже сильный перебор, типа защиты от сознательного вредительства. Т.е. естественно никто не был бы против такого, если оно бесплатно. Но тут мы получаем заметное усложнение системы памяти. В то время как например D спокойно обошёлся без этого.
CAB> Ооочень слабая поддержка сторонних библиотек. Собственно я хотел написать на Rust простенькое оконное приложение, но необходимость ручного написания обёрток с преобразованием типов сделала меня грустным, и дальше MessageBox я не продвинулся.
Теоретически можно поискать фреймворки выдающий интерфейс на C (а не на C++) — вроде бы можно будет вызывать напрямую. Но конечно же использование даже такого интерфейса будет весьма грустным из нормального ООП языка.
CAB> Ну да ладно, критиковать легко, а делать тяжело. Ждём версии 1.0.
Пока от Rust'а возникает ощущение как от попытки замены языка C. А вот на замену C++ как-то уже не совсем тянет, даже в узких областях.
Ну что, осталась одна версия до выхода Rust 1.0! Ждем лета 2014
Если говорить о самых интересных изменениях в 0.9, то они довольно серьезные:
Удалены managed boxes (@) и вместо них необходимо использовать `Gc` или `Rc` из стандартной библиотеки. Решение временное, скоро будет добавлены некий синтаксический сахар для того что бы сложность использования относительно @ не возрастала.
Добавленна поддержка статических библиотек, В OSX поддерживаются фрэймворки.
Начался крупномасштабный рефакторинг IO подсистемы, теперь есть две библиотеки libgreen и libnative, отличающиеся использованием libuv и нативных потоков.
Ну и еще много чего, в итоге разломано все сильно и нашу статью про Rust однозначно надо править При этом, следующий релиз будет последним ломающим изменения релизом:
We plan on not breaking code after Rust 1.0, except for gated features. That said, we reserve the right to change things in potentially breaking ways if type/memory unsoundness is discovered. We also might change small, inconsequential things if we're reasonably sure nobody is relying on them--the bar for this is high, however.
Здравствуйте, C.A.B, Вы писали:
CAB>По моему скромному мнению, если уж вы решили добавить ООП в язык, вам не стоит туда добавлять ещё и отдельные функции, примитивные типы, структуры etc. Это оверкил. И наоборот, если вы решили что у вас будет язык низкого уровня, и там будут функции и п. типы, не стоит туда прикручивать ООП, структур вполне достаточно.
ООП – это не более чем подход к программированию, философия. Вполне себе такой ООП-шный ООП можно замутить на чистом Си (чем частенько и развлекаются). Так вот, если упросить реализацию этой философии в языке, как это сделанно в Rust, то выйдет всяко лучше и удобнее, чем если не упрощать, как например в Си. Де-факто, структур и POD-типов обычно не достаточно и для увеличения скорости разработки нужно больше чем просто их хорошая поддержка. К тому же, ООП в Rust реализован довольно необычно, если сравнивать с языками типа C++, Python или Java и присутсвующее в Rust решение действительно хорошо подходит для системных нужд.
Так как Rust язык системный, в нем безусловно есть структуры, POD-типы и указатели. Но можно ли это считать весткой причиной усложнять жизнь разработчикам? ООП не имеет "единственно верного решения" и может выглядить по-разному, не переставая при этом быть ООП.
C>Скала — это такой недоязычок с freestanding-методами?
Nope. Там нету freestanding-методов (что это?), насколько мне известно.
Между тем,что я думаю,тем,что я хочу сказать,тем,что я,как мне кажется,говорю,и тем,что вы хотите услышать,тем,что как вам кажется,вы слышите,тем,что вы понимаете,стоит десять вариантов возникновения непонимания.Но всё-таки давайте попробуем...(Э.Уэллс)
CAB>>Реализаций ООП много и все они разные. Я считаю, наиболее Ъ ООП в ЯП Scala, потому сравниваю с ним. _>Концепция типа "всё есть объект" — это как бы не фича, а наоборот ограничение возможностей.
Внезапно, почему?
_>А я спрашиваю как раз про фичи. Ну такие как наследование (множественное или нет или с интерфейсами), полиморфизм, абстрактные классы, уровни инкапсуляции, статические методы, перегрузка операторов, обобщённые классы и т.п.
Не копал Rust глубоко, потому про фичи не могу ничего сказать. Я заметил только концептуальную проблему.
_>С удовольствием увидел бы табличку сравнения ООП фич между Scala, Rust'ом и скажем C++ (т.к. Rust пытается стать заменой именно ему, хотя пока я не вижу чтобы тянул на это). И я бы тоже (на заметку kaa.python ).
CAB>>По моему скромному мнению, если уж вы решили добавить ООП в язык, вам не стоит туда добавлять ещё и отдельные функции, примитивные типы, структуры etc. Это оверкил. _>А чем оно мешает то?
Увеличивает сложность и риск прострелить себе ногу.
CAB>>И наоборот, если вы решили что у вас будет язык низкого уровня, и там будут функции и п. типы, не стоит туда прикручивать ООП, структур вполне достаточно. _>Да, всё правильно. Но зачем нам в 21-ом веке ещё один язык низкого уровня? Нам наоборот нужен язык очень высокого уровня, но при этом с сохранением полноценного доступа к системе/железу.
Я бы предпочёл два языка с хорошей интеграцией, как например C и Python.
Между тем,что я думаю,тем,что я хочу сказать,тем,что я,как мне кажется,говорю,и тем,что вы хотите услышать,тем,что как вам кажется,вы слышите,тем,что вы понимаете,стоит десять вариантов возникновения непонимания.Но всё-таки давайте попробуем...(Э.Уэллс)
Здравствуйте, alex_public, Вы писали:
_>Безусловно можно. Я видел реализацию модели акторов в разных языках. Если мы возьмём C++ (здесь это у нас в виде сторонних библиотек), то здесь действительно надо самим следить что куда мы посылаем. Т.е. есть возможность нечаянно нарушить правила библиотеки и получить баг. Если возьмём реализацию в D (там она входит в базовую библиотеку), то фичи D (разделение памяти по потокам, immutable и т.п.) позволяют полностью предотвратить подобные ошибки. Но при этом остаётся возможность специально обойти систему через самый низкий уровень. В Rust'е как я понимаю сложно уже даже специально обойти. Но на мой взгляд это уже сильный перебор, типа защиты от сознательного вредительства. Т.е. естественно никто не был бы против такого, если оно бесплатно. Но тут мы получаем заметное усложнение системы памяти. В то время как например D спокойно обошёлся без этого.
Rust благодаря такому жесткому разделению может позволить себе thread-local сборку мусора, как в Эрланге. А когда систему типов можно обойти простым cast'ом (что в D и приходится делать с shared частенько), то фиг, приходится страдать с общей кучей и глобальным GC.
Здравствуйте, C.A.B, Вы писали:
C>>Скала — это такой недоязычок с freestanding-методами? CAB>Nope. Там нету freestanding-методов (что это?), насколько мне известно.
object Hi {
def main(args: Array[String]) = println("Hello, world!")
}
Так вот тут println() — это не объект! :закатывание глаз и падение в обморок:
Вот в православном Smalltalk любое действие — это посылка сообщения, которое можно перехватить, изменить, отменить и т.д. Не говоря уж про мультиметоды. Не то что в этом убогом недоязычке, где даже мультиметодов нет.
Вообще, какая либо ассоциация ООП и безопасности языка — это кретинический бред. Лисп является безопасным, точно так же как и ML. На обоих можно написать вполне себе процедурный код, но для Лиспа есть CLOS, который куда как более мощный, чем ООП в той же Java/Scala.
object Test {
val refToPL:(String)=>Unit = println //> refToPL : String => Unit = <function1>
refToPL.apply("Hi") //> Hi
}
C>:закатывание глаз и падение в обморок:
C>Вот в православном Smalltalk любое действие — это посылка сообщения, которое можно перехватить, изменить, отменить и т.д.
Scala это такой Smalltalk с функциональщиной и Java библиотеками.
C>Не говоря уж про мультиметоды. Не то что в этом убогом недоязычке, где даже мультиметодов нет.
Их есть там, и ещё много чего. Рекомендую наконец приобщится и посмотреть самостоятельно.
C>[parsing failure]...но для Лиспа есть CLOS, который куда как более мощный, чем ООП в той же Java/Scala.
Спасибо, на досуге посмотрю.
Между тем,что я думаю,тем,что я хочу сказать,тем,что я,как мне кажется,говорю,и тем,что вы хотите услышать,тем,что как вам кажется,вы слышите,тем,что вы понимаете,стоит десять вариантов возникновения непонимания.Но всё-таки давайте попробуем...(Э.Уэллс)
Здравствуйте, C.A.B, Вы писали:
C>>Вот в православном Smalltalk любое действие — это посылка сообщения, которое можно перехватить, изменить, отменить и т.д. CAB>Scala это такой Smalltalk с функциональщиной и Java библиотеками.
Scala похожа на Smalltalk чуть менее, чем никак.
C>>Не говоря уж про мультиметоды. Не то что в этом убогом недоязычке, где даже мультиметодов нет. CAB>Их есть там, и ещё много чего. Рекомендую наконец приобщится и посмотреть самостоятельно.
Я писал на Скале ещё до того, как она стала популярной
И мультиметодов там нет — они точно так же могут эмулироваться с помощью визиторов, как и в Java или с помощью других подобных средств.
C>>>Не говоря уж про мультиметоды. Не то что в этом убогом недоязычке, где даже мультиметодов нет. CAB>>Их есть там, и ещё много чего. Рекомендую наконец приобщится и посмотреть самостоятельно. C>И мультиметодов там нет — они точно так же могут эмулироваться с помощью визиторов, как и в Java или с помощью других подобных средств.
Или с помощью ПМ:
def collide(x:Thing, y:Thing) = (x,y) match{
case (x:Asteroid,y:Asteroid) => {
//астероид сталкивается с астероидом
}
case (x:Asteroid,y:Spaceship) => {
//стероид сталкивается с космическим кораблем
}
case (x:Spaceship,y:Asteroid) => {
//космический корабль сталкивается с астероидом
}
case (x:Spaceship,y:Spaceship) => {
//космический корабль сталкивается с космическим кораблем
}
}
Между тем,что я думаю,тем,что я хочу сказать,тем,что я,как мне кажется,говорю,и тем,что вы хотите услышать,тем,что как вам кажется,вы слышите,тем,что вы понимаете,стоит десять вариантов возникновения непонимания.Но всё-таки давайте попробуем...(Э.Уэллс)
Здравствуйте, C.A.B, Вы писали:
CAB>(пример от сюда)
Ну так можно и вообще дойти до того, что классический Бэйсик — это полный ООП, так как там можно с помощью if-else эмулировать виртуальные методы.
Вопрос чисто практический. У меня плагин к эклипсу rusty cage не работает Кто нибудь им пользуется?
Все делал по инструкции http://reidarsollid.com/2012/03/27/rustycage-a-rust-lang-ide-plugin-for-eclipse/
(за исключением того что Винда, но пути к компилятору в настройках пробовал самые разные начиная с очевидного c:/Rust/bin)
Не компилируется, похоже компилятор даже не запускается. Выводится сообщение
Здравствуйте, x-code, Вы писали:
XC>Вопрос чисто практический. У меня плагин к эклипсу rusty cage не работает Кто нибудь им пользуется?
Судя по активности в БагТрекере, кто-то все же пользуется. Я нет, но я и C++ код в Vim пишу
XC>Само по себе это "L" очень странное, у меня проект лежит в D:/MyProjects/_Eclipse/rust_project, похоже баг в плагине?
"L" очень похожа на "широкую строку"
P.S. глянь на Sublime Text 2, это почти как как Vim по возможностям, только с привычными клавишами и без режима "бибкать и все портить"
XC>и все.
У меня была та же ерунда. Это скорей всего баг. Для его обхода я просто написал небольшой 'run.bat' и, с помощью External tools повесил его на F9 (которая 'Run' у меня во всех проектах).
Между тем,что я думаю,тем,что я хочу сказать,тем,что я,как мне кажется,говорю,и тем,что вы хотите услышать,тем,что как вам кажется,вы слышите,тем,что вы понимаете,стоит десять вариантов возникновения непонимания.Но всё-таки давайте попробуем...(Э.Уэллс)
Здравствуйте, Cyberax, Вы писали:
C>Вот в православном Smalltalk любое действие — это посылка сообщения, которое можно перехватить, изменить, отменить и т.д. Не говоря уж про мультиметоды. Не то что в этом убогом недоязычке, где даже мультиметодов нет.
Возможно, я не так понял фразу, но в Smalltalk нет мультиметодов, насколько мне известно.
Здравствуйте, C.A.B, Вы писали:
CAB>У меня была та же ерунда. Это скорей всего баг. Для его обхода я просто написал небольшой 'run.bat' и, с помощью External tools повесил его на F9 (которая 'Run' у меня во всех проектах).
Посмотрел — баг висит, но он закрыт по причине того что у автора плагина нет винды
очень маленькая и компактная ide для Go (в отличие от монструозного эклипса, в который нужно еще и Скалу ставить... Скала конечно сам по себе интересный язык, но столько зависимостей ради простой подсветки синтаксиса и компиляции с запуском ИМХО перебор).
Эта LiteIDE написана на Qt, кода мало так что разобраться реально, может быть попробовать в нее добавить поддержку Rust?
XC>Эта LiteIDE написана на Qt, кода мало так что разобраться реально, может быть попробовать в нее добавить поддержку Rust?
Почему бы и нет, если есть желание и время. Хотя я бы дождался "устаканивания" Rust'а.
Между тем,что я думаю,тем,что я хочу сказать,тем,что я,как мне кажется,говорю,и тем,что вы хотите услышать,тем,что как вам кажется,вы слышите,тем,что вы понимаете,стоит десять вариантов возникновения непонимания.Но всё-таки давайте попробуем...(Э.Уэллс)
Есть ещё что-то по Rust кроме tutorial и Reference Manual?
А то вот только по косвенному тексту нашёл, что возвращаемое значение в функции без return должно быть и без ";", а так не мог понять, что за ошибка "not all control paths return a value"
Здравствуйте, cl-user, Вы писали:
CU>Есть ещё что-то по Rust кроме tutorial и Reference Manual?
Есть разбросанные заметки по блогам, но в них все быстро устаревает. Сами же Tutorial и Reference Manual, пока еще, очень сырые. Лично я, когда мне нужна какая-либо информация, открываю исходники и смотрю в src/test. Если там ничего подходящего не нашлось, то смотрю тесты в соответствующих компонентах из src/libstd, src/libextra и src/librustuv. Позволяет найти ответы на большинство вопросов, понятно что не очень удобно, но с учетом очень простого и читабельного кода работает хорошо.
P.S. если хочется быть в курсе последних событий, но ломает следить за рассылкой и коммитами, то очень рекомендую подписаться на This Week in Rust.
Здравствуйте, Cyberax, Вы писали:
C>Надо лучше начать добавлять поддержку в IDEA
О даа! Очень бы хотелось иметь такую поддержку! Vim + Sublime – это, безусловно, прекрасно, но для популяризации языка среди не юниксоидов IDE жизненно необходима.
Здравствуйте, kaa.python, Вы писали:
C>>Надо лучше начать добавлять поддержку в IDEA KP>О даа! Очень бы хотелось иметь такую поддержку! Vim + Sublime – это, безусловно, прекрасно, но для популяризации языка среди не юниксоидов IDE жизненно необходима.
Я честно думаю начать делать как только язык более-менее подойдёт к версии 1.0. Мы делали поддержку в IDEA для нашего языка, получалось совсем несложно — можно попробовать ещё раз.
Здравствуйте, Cyberax, Вы писали:
C>Я честно думаю начать делать как только язык более-менее подойдёт к версии 1.0. Мы делали поддержку в IDEA для нашего языка, получалось совсем несложно — можно попробовать ещё раз.
Версия 1.0 должна быть ближе к концу осени, насколько я понимаю планы "растовцев". Пиши тут, как начнете, постараюсь подключиться.
Данное приведение типов создавалось с оглядкой на стандартные перечисления из языка Си. При этом, значения входящие в перечисление в Си, как впрочем и в Rust, не должны идти последовательно, одно за другим. Поэтому, объявляем перечисление TestData приводимым при помощи FromPrimitive (1) и делаем две конверсии, одну для существующего в перечислении значения 1 (2), а вторую для не существующего значения 2 (3). В консоли у нас окажется, как и ожидалось:
Some(Val2), None
А теперь к твоему примеру с "x as MyType". В твоем примере предполагается, что все конверсии должны проходить успешно. Но что делать, если конверсия не удалась и нам вернулся None из примера выше (3)? Попытка "добыть" значение из None приведет к следующим последствиям:
val2.unwrap();
task '<main>' failed at 'called `Option::unwrap()` on a `None` value'
В то время как гарантировать преобразование от числового значения к нашему типу мы не можем.
Здравствуйте, cl-user, Вы писали:
CU>Тогда ещё вопрос: почему в примерах используется именно такая запись:
let val1: Option<MyType> = FromPrimitive::from_int(1);
вместо
let val1 = MyType.from_int(1);
Ведь так несколько короче. Или они не равноценны?
Запись вида "MyType.from_int(1)" предполагает что делается вызов функции from_int применительно к объекту (именно объекту, а не типу) MyType, а у тебя такого объекта нет.
Вот засада, а так написать и не получается... Т.е. from_int "привязана" к FromPrimitives, а не к MyType? Как же тогда написать FromPrimitive::from_int(1) внутри выражения, чтобы оно вернуло именно MyType? Т.е. как его "типизировать"?
Здравствуйте, kaa.python, Вы писали:
KP>Ага, в Rust-стиле: add_int, add_uint и т.д.
Ок. Появились ещё вопросы:
1. Взаимозаменяемость функций и замыканий есть или нет? получаю сообщения
mismatched types: expected `fn(int) -> f32` but found `|int| -> f32` (expected extern fn but found fn)
mismatched types: expected `|int| -> f32` but found `fn(int) -> f32` (expected fn but found extern fn)
Как-нибудь можно привести одно к другому?
2. Не могу вставить в структуру замыкание: получаю "missing lifetime specifier" — что с этим делать?
CU>1. Взаимозаменяемость функций и замыканий есть или нет? получаю сообщения CU>
mismatched types: expected `fn(int) -> f32` but found `|int| -> f32` (expected extern fn but found fn)
CU>mismatched types: expected `|int| -> f32` but found `fn(int) -> f32` (expected fn but found extern fn)
CU>Как-нибудь можно привести одно к другому?
Полагаю что нет, т.к. Rust довольно придирчев к типам данных, при этом замыкание и функция имеют разные типы. Больше того, на уровне ядра языка для распределния памяти для замыкания используется специальная функция. Так что я думаю что без вариантов.
CU>2. Не могу вставить в структуру замыкание: получаю "missing lifetime specifier" — что с этим делать?
Добавить спецификацию времени жизни для замыкания, скороей всего
Здравствуйте, kaa.python, Вы писали:
KP>А вообще, лучше бы ты код того что пытаешься сделать привел.
рано ещё
Задолбался с разными типами указателей на строку
Вот так нельзя: 'struct S1 { name: &str }' — "missing lifetime specifier", а на кой он мне?
Вот так можно: 'struct S1 { name: ~str }' — Ok
Теперь надо в функции создать структуру и передать имя в сишную функцию:
fn f1(_name: &str) {
let s = S1 { name: _name }; // так нельзя, надо ~str а не &str
...
name.with_c_str(|s| ... // так можно, но если тип параметра функции изменить на ~str, то опять получим ошибку
Вот перепробовал уже 48 вариантов, но ни как не могу получить из &str -> ~str или ~str -> &str
Из-за большой ломки в версии 0,9 большая часть мануалов в сети "не совсем точна". Плюс к этому сам str какой-то очень особый тип
CU>Вот перепробовал уже 48 вариантов, но ни как не могу получить из &str -> ~str или ~str -> &str
Таки я бы начал с чтения документации Смотри: &str – ссылка на "какую-то строку". Эта строка может быть размещена на стеке, в локальной куче или куче обмена, т.е. компилятор не имеет ни малейшего представления о том, что ты передал и ожидает некой подсказки. Так как все эти 3 хранилища разделены физически, тебе необходимо сделать явное преобразование, как в примере ниже:
struct S1 { name: ~str }
fn foo(name: &str) {
let val = name.into_owned();
let s = S1 { name: val };
}
Вот так всегда, опять поторопился...
С ~str всё работает, просто значение надо клонировать перед повторным использованием, о чём компилятор недвусмысленно и сообщает
Здравствуйте, kaa.python, Вы писали:
KP>Вообще, я тебя обманул, функции и замыкания вполне себе взаимозаменяемые, и в действительности просто ключевое слово в очередной раз переименовали
Спасибо! Сейчас попробую. Я видел в доках proc, но меня смутило, что такое замыкание может вызываться "единожды". Или имелось в виду — только в одном месте?
KP>struct S1 { name: ~str }
KP>fn foo(name: &str) {
KP> let val = name.into_owned();
KP> let s = S1 { name: val };
KP>}
KP>
ааааа, into_owned()!!!... пойду ещё раз гляну документацию
И сразу ещё вопрос:
внутри функции создаю структуру и передаю указатель на неё в сишную либу (а-ля регистрация клбэков):
После завершения этой функции rcs дропнется? Судя по аварийному завершению при попытке в другой функции восстановить структуру из пришедшего указателя, это так.
Как "заморозить" структуру?
Пытаюсь создать static вектор верхнего уровня модуля для "хранения" подобных структур — не получается Как?!
Здравствуйте, cl-user, Вы писали:
CU>}[/code] После завершения этой функции rcs дропнется? Судя по аварийному завершению при попытке в другой функции восстановить структуру из пришедшего указателя, это так. CU>Как "заморозить" структуру?
Ожидаемо. Ты вышел и скоупа f1, количество ссылок на rcs стало равным нулю. Попробуй хранить ее где-то выше.
Здравствуйте, kaa.python, Вы писали:
KP>Ожидаемо. Ты вышел и скоупа f1, количество ссылок на rcs стало равным нулю. Попробуй хранить ее где-то выше.
Вот пытаюсь создать хеш, вставить структуру. Извлечь получается только 1 раз. Как исправить? И как должна выглядеть функция get_callback — у меня что-то не получается
Здравствуйте, cl-user, Вы писали:
CU>Здравствуйте, kaa.python, Вы писали:
KP>>Ожидаемо. Ты вышел и скоупа f1, количество ссылок на rcs стало равным нулю. Попробуй хранить ее где-то выше.
CU>Вот пытаюсь создать хеш, вставить структуру. Извлечь получается только 1 раз. Как исправить? И как должна выглядеть функция get_callback — у меня что-то не получается
Не связывайся с unsafe и static, это хаки которых, по идее, в коде быть не должно. Вызывается у тебя дважды толи из за того, что в структурах присутсвуют уникальные указатели, толи из за ошибки компилятора который спотыкается об уникальные указатели в статических переменных.
Я дошел вот да такого эксперементального кода, который довольно хорошо иллюстрирует ситуацию:
Здравствуйте, cl-user, Вы писали:
CU>Вот пытаюсь создать хеш, вставить структуру. Извлечь получается только 1 раз. Как исправить? И как должна выглядеть функция get_callback — у меня что-то не получается
В рассылке появился правильный ответ, если интересно – почитай. Краткий вывод: писать unsafe можно только тогда, когда понимашь модель памяти Rust очень-очень хорошо.
Здравствуйте, kaa.python, Вы писали:
KP>Не связывайся с unsafe и static, это хаки которых, по идее, в коде быть не должно.
Без static не получается задекларировать хэш, ибо замыкание требует lifetime specifier.
А со static приходится писать unsafe, ибо use of mutable static requires unsafe function or block
KP>А если заменить Option<~MyStruct> на Option<MyStruct>, то все становится хорошо:
к своему примеру как это прицепить не понимаю
KP>И на последок: зря ты пытаешься писать на Rust так, будто ты с Си работаешь.
хм, а можно конкретнее?
KP>В рассылке появился правильный ответ, если интересно – почитай.
пойду пороюсь, но может ты дашь прямую ссылку на ветку?
Здравствуйте, cl-user, Вы писали:
CU>Здравствуйте, kaa.python, Вы писали:
CU>Без static не получается задекларировать хэш, ибо замыкание требует lifetime specifier. CU>А со static приходится писать unsafe, ибо use of mutable static requires unsafe function or block
Без статика все получится замечательно, просто сделай переменную не статической, а принадлежащей какой-то задаче. В крайнем случае, запихай ее в RWARC, или как его там сейчас звать.
KP>>А если заменить Option<~MyStruct> на Option<MyStruct>, то все становится хорошо: CU>к своему примеру как это прицепить не понимаю
Легко. Сопоставление с образцом в Rust разрушающее, от этого и такой занятный эффект вышел. Я немного упорядочил свои мысли об этом тут.
KP>>И на последок: зря ты пытаешься писать на Rust так, будто ты с Си работаешь. CU>хм, а можно конкретнее?
В Rust не должно быть глобальных данных кроме тех случаев, когда без них ну совсем при совсем никак. И если уж совсем никак, то стоит взять готовые механизмы типа ARC-а. В твоем случае без глобальных данных обойтись можно.
CU>пойду пороюсь, но может ты дашь прямую ссылку на ветку?
Тут, я их вчера спросил когда осознал что не понимаю что происходит.
Здравствуйте, kaa.python, Вы писали:
KP>Без статика все получится замечательно, просто сделай переменную не статической, а принадлежащей какой-то задаче. В крайнем случае, запихай ее в RWARC, или как его там сейчас звать.
Если просто оставлять "в цепочке вызовов" — угу, работает! С ARC-ом и подобным не так всё просто (мне): замыкания не клонируются, а как указывать, что надо оперировать исключительно ссылками на замыкания, я ещё "не догоняю"
Есть структура, которая "живёт" на всём протяжении жизни программы. Пытаюсь хранить там — опять приходится задавать lifetime parameter. Остановился вот на таком:
lib.rs:38:15: 38:17 error: use of undeclared lifetime name `'a`
lib.rs:38 impl Drop<'a> for MyStruct {
Вот теперь ищу как в объявлении
impl Drop for MyStruct {
fn drop(&mut self) {
задать этот самый lifetime parameter.
KP>В Rust не должно быть глобальных данных кроме тех случаев, когда без них ну совсем при совсем никак. И если уж совсем никак, то стоит взять готовые механизмы типа ARC-а. В твоем случае без глобальных данных обойтись можно.
Здравствуйте, cl-user, Вы писали:
CU>Если просто оставлять "в цепочке вызовов" — угу, работает! С ARC-ом и подобным не так всё просто (мне): замыкания не клонируются, а как указывать, что надо оперировать исключительно ссылками на замыкания, я ещё "не догоняю"
Ты бы приводил кусок компилируемого кода, потому как по кусочку не возможно понять что у тебя в действительности происходит.
Почти всё заработало. Остался один косяк.
Сейчас есть вот такой код:
pub type Callback<'a> = 'a |~[~str]|: -> ~str;
...
pub fn registr_callback(&mut self, name: ~str, callback: Callback<'a>) {
self.callbacks.insert(name.clone(), callback); // вставка в хеш-таблицуunsafe {
let callback = self.callbacks.find(&name); // а здесь достаём указатель...
match callback {
Some(cc) => {
name.with_c_str(|s| {
// чтобы вот здесь передать
_ext_createcommand(to_unsafe_ptr(cc),...);
});
}
None => {}
}
}
}
И никак не могу из этого костыля сделать так:
pub fn registr_callback(&mut self, name: ~str, callback: Callback<'a>) {
self.callbacks.insert(name.clone(), callback); // вставка в хеш-таблицуunsafe {
name.with_c_str(|s| {
// вот здесь передаём ссылку на регистрацию
_ext_createcommand(to_unsafe_ptr(&callback),...);
});
}
}
всё время получаю
note: `callback` moved here because it has type `'a |~[~str]| -> ~str`, which is
a non-copyable stack closure (capture it in a new closure, e.g. `|x| f(x)`, to override)
И будет ли правильным, если я не буду клонировать ~str, а получу &str и вставлю в хеш-таблицу name.into_owned()?
Думаю эта новость многих заинтересует. Для Rust были созданы инсталляторы и необходимость в сборки из исходников отпадает. На данный момент доступны следующие инсталляторы:
Здравствуйте, kaa.python, Вы писали:
KP>Думаю эта новость многих заинтересует. Для Rust были созданы инсталляторы и необходимость в сборки из исходников отпадает. На данный момент доступны следующие инсталляторы:
Для винды инсталлятор вроде уже давно был. Сейчас судя по всему сделали для всех операционных систем.
Мне вот интересно, что они там сделали в итоге с @-указателями, Gc и Rc? Введут еще какой-то символ, или вообще удалят?
Здравствуйте, x-code, Вы писали:
XC>Мне вот интересно, что они там сделали в итоге с @-указателями, Gc и Rc? Введут еще какой-то символ, или вообще удалят?
Не, останется как и было, просто будет возможность использовать разные типы сборзщиков мусора. Да и сейчас @-указатели есть, на них же куча кода базируется:
managed_boxes — Usage of @ pointers is gated due to many planned changes to this feature. In the past, this has meant "a GC pointer", but the current implementation uses reference counting and will likely change drastically over time. Additionally, the @ syntax will no longer be used to create GC boxes.
Здравствуйте, kaa.python, Вы писали:
KP>Не, останется как и было, просто будет возможность использовать разные типы сборзщиков мусора. Да и сейчас @-указатели есть, на них же куча кода базируется: KP>
KP>managed_boxes — Usage of @ pointers is gated due to many planned changes to this feature. In the past, this has meant "a GC pointer", but the current implementation uses reference counting and will likely change drastically over time. Additionally, the @ syntax will no longer be used to create GC boxes.
KP>Так что директивы компилятору будет достаточно: KP>
#[feature(managed_boxes)]
Ну вот это и непонятно: для разных типов сборщиков мусора по идее нужны разные указатели. Или они как-то будут использовать значок @ для разных типов одновременно?
Здравствуйте, x-code, Вы писали:
XC>Ну вот это и непонятно: для разных типов сборщиков мусора по идее нужны разные указатели. Или они как-то будут использовать значок @ для разных типов одновременно?
Значка может не остатся. Будет специальная операция разыменования, с разными указателями, имеющими разные типы.
Мне так кажется, что это будет полный аналог умных указателей из С++.
Здравствуйте, x-code, Вы писали:
XC>Ну вот это и непонятно: для разных типов сборщиков мусора по идее нужны разные указатели. Или они как-то будут использовать значок @ для разных типов одновременно?
Как мне кажется, авторы еще сами не знают ответа на этот вопрос. В крайнем случае мне не попадалась на глаза информация о том, как они собираются разруливать разные типы указателей, при том что значек только один.
Здравствуйте, Aртём, Вы писали:
KP>>Ну, все изучать Rust!
Aё>Можно вкратце (списком) преимущества Rust перед Node.JS и Julia?
Честно говоря, не смогу ответить на твой вопрос, все же вообще не сталкивался с Node.JS или Julia. Да и выглядят они как узкоспециализированные решения, так что сравнивать вроде как и нечего
Общего между тремя как минимум использование LLVM и libuv для асинхронного ввода-вывода, поддержка функциональной парадигмы (функция как объект).
Вики о Rust:
Rust is a general purpose, multi-paradigm, compiled programming language... Known as rustc, it successfully compiled itself in 2011. The self-hosted compiler uses LLVM as its backend.
Со странички libuv:
libuv is a multi-platform support library with a focus on asynchronous I/O. It was primarily developed for use by Node.js, but it's also used by Mozilla's Rust language, Luvit, Julia, pyuv, and others.
Вики о Julia:
Julia is a high-level dynamic programming language designed to address the requirements of high-performance numerical and scientific computing while also being effective for general purpose programming. Julia's core is implemented in C and C++, its parser in Scheme, and the LLVM compiler framework is used for just-in-time generation of machine code. The standard library is implemented in Julia itself, using the Node.js's libuv library for efficient, platform-independent I/O.
Здравствуйте, Aртём, Вы писали:
Aё>Здравствуйте, kaa.python, Вы писали:
Aё>Общего между тремя как минимум использование LLVM и libuv для асинхронного ввода-вывода, поддержка функциональной парадигмы (функция как объект).
Мне кажется несколько неправильным сравнивать статически типизированный язык общего назначения с динамически типизированными языками разработанными под конкретные задачи. При этом я не вижу никакого превосходства со стороны Node.JS, но вот встроенная математика в Julia явно (особенно, когда допилят хотя бы до уровня Rust) посильнее (но, она в свою очередь проигрывает Python с библиотеками).
Здравствуйте, kaa.python, Вы писали:
KP>Здравствуйте, Aртём, Вы писали:
Aё>>Здравствуйте, kaa.python, Вы писали:
Aё>>Общего между тремя как минимум использование LLVM и libuv для асинхронного ввода-вывода, поддержка функциональной парадигмы (функция как объект).
KP>Мне кажется несколько неправильным сравнивать статически типизированный язык общего назначения с динамически типизированными языками разработанными под конкретные задачи. При этом я не вижу никакого превосходства со стороны Node.JS, но вот встроенная математика в Julia явно (особенно, когда допилят хотя бы до уровня Rust) посильнее (но, она в свою очередь проигрывает Python с библиотеками).
Джулия не заточена под одну задачу а JavaScript есть в каждом браузере.
Последнее время замечаю желания людей сравнить Rust с каким-либо языком. Совсем уж экзотических сравнений типа тех, что хотел бы видеть Артем (Rust с Julia и Node.JS
) у меня нет, а вот сравнение Rust с Go на прошлой неделе появилось.
Сам оценить качество этого сравнения я не могу в силу незнания Go, так что было бы интересно выслушать и замечания
Здравствуйте, kaa.python, Вы писали:
KP>Последнее время замечаю желания людей сравнить Rust с каким-либо языком. Совсем уж экзотических сравнений типа тех, что хотел бы видеть Артем (Rust с Julia и Node.JS
) у меня нет, а вот сравнение Rust с Go на прошлой неделе появилось.
А что экзотического в Node.JS который JScript на сервере, т.е. позволяет писать автономные и достаточно производительные приложения? Если Node.JS+Julia покрывает 100% гипотетических применений языка общего назначения Rust- почему бы не спросить сравнение?
Здравствуйте, Aртём, Вы писали:
Aё>А что экзотического в Node.JS который JScript на сервере, т.е. позволяет писать автономные и достаточно производительные приложения? Если Node.JS+Julia покрывает 100% гипотетических применений языка общего назначения Rust- почему бы не спросить сравнение?
Кстати Node.JS компилируемый или это какой-то особый интерпретатор без браузера? (Julia знаю что на llvm)
Я как-то привык что javascript это браузер. Какие у Node.JS библиотеки для работы, например, с оконными виджетами, графикой, файловой системой, сетью, мультимедиа, базами данных, низкоуровневыми API операционной системы, есть ли там интеграция с другими языками?
Здравствуйте, x-code, Вы писали:
XC>Кстати Node.JS компилируемый или это какой-то особый интерпретатор без браузера? (Julia знаю что на llvm)
JIT- не интерпретатор.
XC>Я как-то привык что javascript это браузер. Какие у Node.JS библиотеки для работы, например, с оконными виджетами, графикой, файловой системой, сетью, мультимедиа, базами данных, низкоуровневыми API операционной системы, есть ли там интеграция с другими языками?
Node.js is a platform built on Chrome's JavaScript runtime for easily building fast, scalable network applications. Node.js uses an event-driven, non-blocking I/O model that makes it lightweight and efficient, perfect for data-intensive real-time applications that run across distributed devices.
Здравствуйте, kaa.python, Вы писали:
KP>Здравствуйте, Lazin, Вы писали:
L>>Джулия не заточена под одну задачу а JavaScript есть в каждом браузере.
KP>Если говорить о Julia, то сложно не согласиться с ее авторами "high-performance dynamic programming language for technical computing". В первую очередь это не язык общего назначения, а язык для мат. расчетов.
We want something as usable for general programming as Python, as easy for statistics as R, as natural for string processing as Perl, as powerful for linear algebra as Matlab, as good at gluing programs together as the shell. Something that is dirt simple to learn, yet keeps the most serious hackers happy. We want it interactive and we want it compiled.
KP>Что следует из наличия JavaScript в каждом бразузере я не очень понял. Особенно с учетом того, что это самый каждый браузер может на компьюетре и не стоять, или быть чем-то типа Links
То, что JS есть в каждом браузере это превосходство. Огромное количество людей уже умеют программировать на нем, есть огромное количество инструментов и всего такого. Это язык будущего, несмотря на всю говнистость. А rust конечно крут, но он даже не начался еще и не факт что он станет чем-то большим, чем очередной язык программирования для энтузиастов.
L>We want something as usable for general programming as Python, as easy for statistics as R, as natural for string processing as Perl, as powerful for linear algebra as Matlab, as good at gluing programs together as the shell. Something that is dirt simple to learn, yet keeps the most serious hackers happy. We want it interactive and we want it compiled.
А ты сейчас используешь Julia для каких-нибудь задач? Если да, то для каких (предметная область, размер проектов, роль Julia в проекте)?
Мне интересно, до какого уровня язык уже поднялся, насколько можно на него полагаться.
Здравствуйте, Nuzhny, Вы писали:
N>А ты сейчас используешь Julia для каких-нибудь задач? Если да, то для каких (предметная область, размер проектов, роль Julia в проекте)? N>Мне интересно, до какого уровня язык уже поднялся, насколько можно на него полагаться.
я его только для экспериментов с ML пытался использовать, очень поверхностно
Здравствуйте, Lazin, Вы писали:
L>Причина №1 — модель памяти. Rust это data ownership, как и в erlang. Data ownership это хорошо, это когда каждый объект в памяти принадлежит определенному потоку, ну и может иногда менять хозяина. Проблема в том, что это совсем не соответствует тому, как работает железо. Там как раз нет никакого ownership-а и любой поток может обращаться к любому вирт. адресу.
Это давно не совсем так. Хотя бы из-за NUMA, проблем с разделением линий кэша и т.п. Ну и ещё можно вспомнить GPU, конечно же. На модель Rust оно вообще ложится идеально.
L>В этом нет проблемы, если модель памяти rust ложится на архитектуру приложения хорошо, а что если нет? Что, если например у вас есть хэш таблица, в которой лежат пользовательские сессии и вам нужно из разных потоков часто ее читать и обновлять?
Это больше из серии: "Доктор, у меня болит, когда я так делаю. Значит, не делайте так!". Классический вариант — это отдельная задача, которая работает сервером сессий. Остальные задачи посылают серверу задач запросы типа "взять элемент"/"положить элемент".
Ну и если очень хочется, то в Rust есть ARC: http://winningraceconditions.blogspot.ch/2012/09/rust-3-typesafe-shared-state.html
L>Причина №2 — сборка мусора. Я за сборку мусора или за то, чтобы ее небыло, но не за то, чтобы она была опциональной.
Как раз в Rust это будет скоро возможно.
L>Причина №3 — таски. Насколько я понял, rust позволяет использовать как обычные потоки, так и "зеленые", при этом, опять же, насколько я знаю, генератор кода ничерта не знает, где будет выполняться код ф-ии — в нормальном потоке или в зеленом таске.
Ну так и надо. TLS вообще должен умереть, как кривой хак.
Здравствуйте, Lazin, Вы писали:
L>Сформулирую поажалуй, почему я не верю в успех rust. Несмотря на всю движуху, не видать ему ничего более примечательного, нежели статус нишевого языка для сетевых приложений или приложений, не требующих высокой производительности.
Во многом согласен с приведенным ниже. Кстати, а что считать высокой производительностью? Выжимание всех резервов на чистом Си? Все же писать медленный код на C++ проще-простого.
L>Причина №1 — модель памяти. Rust это data ownership, как и в erlang. Data ownership это хорошо, это когда каждый объект в памяти принадлежит определенному потоку, ну и может иногда менять хозяина. Проблема в том, что это совсем не соответствует тому, как работает железо. Там как раз нет никакого ownership-а и любой поток может обращаться к любому вирт. адресу. В этом нет проблемы, если модель памяти rust ложится на архитектуру приложения хорошо, а что если нет?
Видимо в этом случае Rust не лучший выбор? Хотя, мне кажется, что в такой ситуации просто нужно проектировать архитектуру исходя из ограничений накладываемых языком, они же не с проста появились.
L>Что, если например у вас есть хэш таблица, в которой лежат пользовательские сессии и вам нужно из разных потоков часто ее читать и обновлять? Положить ее в общую кучу, забирать по очереди, читать/писать и потом класть обратно? А что если один из потоков получил owned pointer и помер?
Как вариант, ее можно положить в отдельный Таск и через него работать. Либо взять RWArc (или как там его сейчас звать) и получить классическую модель общей памяти. Пусть это и перечеркивает на корню идею с моделью памяти в Rust.
L>Причина №2 — сборка мусора. Я за сборку мусора или за то, чтобы ее небыло, но не за то, чтобы она была опциональной. Если я хочу, чтобы мое приложение на rust не использовало сборщик мусора, то я буду управлять памятью вручную, но при этом какая-нибудь библиотека может от него зависеть и в итоге, мой сетевой сервис будет периодически лагать. Я подозреваю что тут будет ситуация как с shared_ptr в С++, в том смысле, что все используют shared_ptr даже там, где он не нужен. Т.е. написать нетривиальный код не использующий GC будет крайне сложно.
Думаю, так и будет. Хотя если хочется полностью ручного управления памятью – то Rust не лучший выбор. Либо его стоит использовать как "более удобный Си" отрубив все, кроме std с собственными аллокаторами и GC (там это довольно элементарно делается).
L>Причина №3 — таски. Насколько я понял, rust позволяет использовать как обычные потоки, так и "зеленые", при этом, опять же, насколько я знаю, генератор кода ничерта не знает, где будет выполняться код ф-ии — в нормальном потоке или в зеленом таске. Это означает жопу со всякими Си-шными расширениями. Если Си-шный код использует TLS, то его нельзя исполнять в зеленом потоке, в этом случае Go, например, выполняет код в специально выделенном потоке, а таск ждет, когда этот код отработает. Я довольно долго читал их список рассылки и все это время они придерживались мнения, что это все забота программиста.
Да, это забора программиста. Но, казалось бы, программист при использовании низкоуровневого языка, зная такие аббревиатуры TLS должен умет выбрать между зелеными и обычными потоками? Если нет, то лучше использовать все в конфигурации "по умолчанию".
В целом, да, язык очень нишевый, сетевой направленности, написания сложной бизнес-логики критичной к производительности (не на столько, что бы микросекунды выжимать, но на уровне "среднего C++"), возможно язык для драйверов и другого низкоуровневого кода. Просто лично для меня, это именно то что нужно. Как раз нужные области, достаточная скорость, ограничение возможности подложить очень уж пакостную бомбу в Си/С++ стиле.
Здравствуйте, Cyberax, Вы писали:
L>>Причина №1 — модель памяти. Rust это data ownership, как и в erlang. Data ownership это хорошо, это когда каждый объект в памяти принадлежит определенному потоку, ну и может иногда менять хозяина. Проблема в том, что это совсем не соответствует тому, как работает железо. Там как раз нет никакого ownership-а и любой поток может обращаться к любому вирт. адресу. C>Это давно не совсем так. Хотя бы из-за NUMA, проблем с разделением линий кэша и т.п. Ну и ещё можно вспомнить GPU, конечно же. На модель Rust оно вообще ложится идеально.
Возникает несколько вопросов:
1. Планировщик задач в rust NUMA node aware? Я ни разу ни о чем подобном не слышал. Тут нужны аллокатор (из CRT например) и планировщик (планировщик ОС) знающие о NUMA нодах и соответствующая архитектура. Ни разу не слышал о том, что N:M модель упоминалась в контексте NUMA
C>Классический вариант — это отдельная задача, которая работает сервером сессий. Остальные задачи посылают серверу задач запросы типа "взять элемент"/"положить элемент".
Это будет медленнее чем самый обычный lock.
L>>Причина №2 — сборка мусора. Я за сборку мусора или за то, чтобы ее небыло, но не за то, чтобы она была опциональной. C>Как раз в Rust это будет скоро возможно.
А что если 3rd party код на rust, который использует мой код на rust использует GC, а мой код не использует? Опциональный GC это нифига не модульно.
C>Ну так и надо. TLS вообще должен умереть, как кривой хак.
Эм... это как раз не кривой хак, а необходимость, альтернатив нет. Где функции вроде errno должны хранить свое состояние? Очень часто всякие навороченные параллельные алгоритмы используют TLS.
Здравствуйте, Lazin, Вы писали:
L>1. Планировщик задач в rust NUMA node aware? Я ни разу ни о чем подобном не слышал. Тут нужны аллокатор (из CRT например) и планировщик (планировщик ОС) знающие о NUMA нодах и соответствующая архитектура. Ни разу не слышал о том, что N:M модель упоминалась в контексте NUMA
Речь идёт об изолировании данных. Нынче NUMA — все cache coherent, так что оно всё будет само работать, если к одним и тем же данным не будет обращений из разных NUMA-сегментов.
Более умный планировщик на уровне Rust помог бы, но не является обязательным.
C>>Классический вариант — это отдельная задача, которая работает сервером сессий. Остальные задачи посылают серверу задач запросы типа "взять элемент"/"положить элемент". L>Это будет медленнее чем самый обычный lock.
И не будет иметь никакого значения в типичном случае использования — в сетевых серверах, например.
C>>Как раз в Rust это будет скоро возможно. L>А что если 3rd party код на rust, который использует мой код на rust использует GC, а мой код не использует? Опциональный GC это нифига не модульно.
Должно работать. Ну и по идее, есть естественная граница — пределы задачи.
C>>Ну так и надо. TLS вообще должен умереть, как кривой хак. L>Эм... это как раз не кривой хак, а необходимость, альтернатив нет.
Есть.
L>Где функции вроде errno должны хранить свое состояние? Очень часто всякие навороченные параллельные алгоритмы используют TLS.
Функций вроде errno не должно быть. И какие навороченные алгоритмы используют TLS?
Здравствуйте, kaa.python, Вы писали:
KP>Видимо в этом случае Rust не лучший выбор? Хотя, мне кажется, что в такой ситуации просто нужно проектировать архитектуру исходя из ограничений накладываемых языком, они же не с проста появились.
Т.е. нужно делать все хорошо с самого начала? Ооооок
KP>Как вариант, ее можно положить в отдельный Таск и через него работать. Либо взять RWArc (или как там его сейчас звать) и получить классическую модель общей памяти. Пусть это и перечеркивает на корню идею с моделью памяти в Rust.
Отдельный таск это как lock только хуже. RWArc — это то о чем я говорил, когда писал о том, что придется обходить эту модель памяти в каждом нетривиальном случае.
KP>Да, это забора программиста. Но, казалось бы, программист при использовании низкоуровневого языка, зная такие аббревиатуры TLS должен умет выбрать между зелеными и обычными потоками? Если нет, то лучше использовать все в конфигурации "по умолчанию".
Проблема в том, что программист не знает заранее что использует TLS а что нет. Придется делать аудит всего стороннего кода, который может к тому же меняться. Многие программисты вообще не в курсе таких проблем и будут потом писать в интернете отчеты о том, какой этот rust глючный. Лучше бы делали что-то одно, либо как в Go — всегда зеленые потоки и при вызовах стороннего кода таск pin-ится, а весь рантайм, в том числе все I/O знает о планировщике (эдакий erlang с OTP), либо вообще ничего подобного в рантайме нет.
KP>В целом, да, язык очень нишевый, сетевой направленности, написания сложной бизнес-логики критичной к производительности (не на столько, что бы микросекунды выжимать, но на уровне "среднего C++"), возможно язык для драйверов и другого низкоуровневого кода. Просто лично для меня, это именно то что нужно. Как раз нужные области, достаточная скорость, ограничение возможности подложить очень уж пакостную бомбу в Си/С++ стиле.
Для того, чтобы "не подложить бомбу" a-la с++ достаточно отказаться от арифметики указателей в пользу slice-ов (a-la Go) и неявных преобразований типов, IMO. Вот это вот все — overengineering на мой неискушенный вкус. Ну и непонятно зачем сетевым сервисам настолько сложная бизнес логика, что без DST и type classes никуда
Здравствуйте, Lazin, Вы писали:
L>Отдельный таск это как lock только хуже. RWArc — это то о чем я говорил, когда писал о том, что придется обходить эту модель памяти в каждом нетривиальном случае.
Вообще-то, в теории task может быть соптимизирован до того же lock'а.
KP>>Да, это забора программиста. Но, казалось бы, программист при использовании низкоуровневого языка, зная такие аббревиатуры TLS должен умет выбрать между зелеными и обычными потоками? Если нет, то лучше использовать все в конфигурации "по умолчанию". L>Проблема в том, что программист не знает заранее что использует TLS а что нет.
А вообще, какие реальные библиотеки используют TLS?
L>Для того, чтобы "не подложить бомбу" a-la с++ достаточно отказаться от арифметики указателей в пользу slice-ов (a-la Go) и неявных преобразований типов, IMO.
Не хватит. Слайсы будут требовать обязательный GC, чтобы слайс не пережил его родителя. Ну и они не решают проблему с гонками — одна из основных фич Rust.
По поводу errno — можно конечно обойтись без TLS, но часто это усложняет архитектуру и перекладывает на программиста ответственность, так как состояние, вынесенное из TLS в переменную и которым теперь управляет программист — не должно передаваться от одного потока другому. Т.е. тут придется либо следить за дисциплиной, либо runtime checks, либо на уровне системы типов это контролировать, это все сложнее чем TLS и еще нужно посмотреть, что из перечисленного больший хак.
Здравствуйте, Lazin, Вы писали:
C>>Есть. L>И что же?
Исключения, коды возврата и т.д.
C>>И какие навороченные алгоритмы используют TLS? L>Сложно найти то что не использует TLS, вот пара примеров на вскидку
Странные примеры.
L>https://github.com/jemalloc/jemalloc
Будет прекрасно работать с Rust (собственно, УЖЕ работает), так как там TLS для внутренних нужд.
L>https://github.com/facebook/folly/blob/72c2a0d3b47de74dd56b6750922e54ef333b4cbd/folly/ThreadCachedInt.h
И где оно есть?
L>По поводу errno — можно конечно обойтись без TLS, но часто это усложняет архитектуру и перекладывает на программиста ответственность, так как состояние, вынесенное из TLS в переменную и которым теперь управляет программист — не должно передаваться от одного потока другому.
errno должен умереть, это кривой хак для С, не поддерживающего множественные результаты возврата. Он прекрасно заменяется исключениями или кодами возврата.
Здравствуйте, Cyberax, Вы писали:
C>>>Есть. L>>И что же? C>Исключения, коды возврата и т.д.
Часто TLS используется для уменьшения количества взаимодействий между потоками, тот же jemalloc, при вызове malloc сначала лезет в арену, адрес которой берется из TLS, а уже потом, если там нет памяти — в общий пулл. Просто TLS быстрее чем contended lock, поэтому часто алгоритмы строят таким образом. Ни исключения ни коды возврата тут использовать не получится. И таки да, в случае с errno, использование TLS это хак, но это нестандартное использование.
C>Странные примеры.
Ты просил пример навороченного параллельного алгоритма — параллельный allocator это и есть такой алгоритм, что не так?
Здравствуйте, rusted, Вы писали:
R>Зачем это поменяли?
Подобные изменения, той или иной степени идиотзма, там появляются регулярно, так же регулярно исчезают. На мой взгляд авторы просто экспериментируют, т.к. после релиза обещали заморозить API.
Здравствуйте, MTD, Вы писали:
MTD>Ну надо же что-то делать (С) А вообще думаю еще один пшик будет, я уже перестал понимать логику разработчиков.
Ну, с учетом текущей реализации C++11 и планов на C++14/17 смыслу в Rust становится все меньше и меньше. Но, его плюшек всяко нигде больше нет и не будет в ближайшем будущем.
.
Если нам не помогут, то мы тоже никого не пощадим.
Смотри: &str – ссылка на "какую-то строку". Эта строка может быть размещена на стеке, в локальной куче или куче обмена, т.е. компилятор не имеет ни малейшего представления о том, что ты передал и ожидает некой подсказки. Так как все эти 3 хранилища разделены физически, тебе необходимо сделать явное преобразование, как в примере ниже:
