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.
Между тем,что я думаю,тем,что я хочу сказать,тем,что я,как мне кажется,говорю,и тем,что вы хотите услышать,тем,что как вам кажется,вы слышите,тем,что вы понимаете,стоит десять вариантов возникновения непонимания.Но всё-таки давайте попробуем...(Э.Уэллс)
Здравствуйте, 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 писать если и начнут, то очень-очень не скоро. Это явно не его ниша и есть гора языков на которых это делать в разы удобнее.
Здравствуйте, C.A.B, Вы писали:
CAB> В целом язык (пока и на первый взгляд) выглядит довольно неуклюже, как горка разнообразных, слабосвязанных фичь. Нету некоторой центральной/корневой/объединяющей всё концепции(й), такой как например pure OOP в Scala. Хотя, вероятно для низкоуровневого ЯП это и не особо важно.
А зачем она нужна? И какой в Scala ещё pure OOP?
CAB> Я не фанат смешиваний ежей с ужами, и считаю что в ЯП с указателями на память не место ООП, и наоборот. Для первого есть замечательные языки asm и C, для второго не менее замечательные Python и Scala. Потому, думаю, автору Rust'а стоило выбрать "какую то одну строну".
Смешались в кучу кони, люди...
Причём тут указатели и ООП???
CAB> Понравилась идея с задачами, такой себе Erlang-style, но тут обнаружилась ложка дёгтя: какая-то очень сильная магия с памятью, не знаю как, но уверен, это можно было сделать проще.
Нельзя.
Здравствуйте, 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.
Да, относительно библиотек. Есть страница в Wiki на GitHub, где перечисленны основные сторонние библиотеки для Rust имеющиеся на данный момент. В принципе, там и для создания UI есть кое что; из интересного я заметил биндинги к ncurses, wxWidgets и GTK+.
Здравствуйте, alex_public, Вы писали: CAB>> В Rust есть хорошо проработанные и полезные ФП фичи(строгая типизация, паттерн матчинг, ФВП). В тоже время ООП похоже на какой-то костыль, типа "у всех есть и у нас будет", лучше бы автор сконцентрировал усилия на метапрограммировании. _>А что там не так по сравнению с обычными реализациями ООП?
Реализаций ООП много и все они разные. Я считаю, наиболее Ъ ООП в ЯП Scala, потому сравниваю с ним.
По моему скромному мнению, если уж вы решили добавить ООП в язык, вам не стоит туда добавлять ещё и отдельные функции, примитивные типы, структуры etc. Это оверкил. И наоборот, если вы решили что у вас будет язык низкого уровня, и там будут функции и п. типы, не стоит туда прикручивать ООП, структур вполне достаточно.
Между тем,что я думаю,тем,что я хочу сказать,тем,что я,как мне кажется,говорю,и тем,что вы хотите услышать,тем,что как вам кажется,вы слышите,тем,что вы понимаете,стоит десять вариантов возникновения непонимания.Но всё-таки давайте попробуем...(Э.Уэллс)
Здравствуйте, C.A.B, Вы писали:
CAB>Реализаций ООП много и все они разные. Я считаю, наиболее Ъ ООП в ЯП Scala, потому сравниваю с ним.
Скала — это такой недоязычок с freestanding-методами? Сжечь еретика!
Настоящий Ъ-ООП — это только Smalltalk!
CAB>По моему скромному мнению, если уж вы решили добавить ООП в язык, вам не стоит туда добавлять ещё и отдельные функции, примитивные типы, структуры etc. Это оверкил. И наоборот, если вы решили что у вас будет язык низкого уровня, и там будут функции и п. типы, не стоит туда прикручивать ООП, структур вполне достаточно.
Ну что за бред...
Здравствуйте, C.A.B, Вы писали:
CAB>По моему скромному мнению, если уж вы решили добавить ООП в язык, вам не стоит туда добавлять ещё и отдельные функции, примитивные типы, структуры etc. Это оверкил. И наоборот, если вы решили что у вас будет язык низкого уровня, и там будут функции и п. типы, не стоит туда прикручивать ООП, структур вполне достаточно.
ООП – это не более чем подход к программированию, философия. Вполне себе такой ООП-шный ООП можно замутить на чистом Си (чем частенько и развлекаются). Так вот, если упросить реализацию этой философии в языке, как это сделанно в Rust, то выйдет всяко лучше и удобнее, чем если не упрощать, как например в Си. Де-факто, структур и POD-типов обычно не достаточно и для увеличения скорости разработки нужно больше чем просто их хорошая поддержка. К тому же, ООП в Rust реализован довольно необычно, если сравнивать с языками типа C++, Python или Java и присутсвующее в Rust решение действительно хорошо подходит для системных нужд.
Так как Rust язык системный, в нем безусловно есть структуры, POD-типы и указатели. Но можно ли это считать весткой причиной усложнять жизнь разработчикам? ООП не имеет "единственно верного решения" и может выглядить по-разному, не переставая при этом быть ООП.
Здравствуйте, C.A.B, Вы писали:
CAB>Реализаций ООП много и все они разные. Я считаю, наиболее Ъ ООП в ЯП Scala, потому сравниваю с ним.
Концепция типа "всё есть объект" — это как бы не фича, а наоборот ограничение возможностей. А я спрашиваю как раз про фичи. Ну такие как наследование (множественное или нет или с интерфейсами), полиморфизм, абстрактные классы, уровни инкапсуляции, статические методы, перегрузка операторов, обобщённые классы и т.п.
С удовольствием увидел бы табличку сравнения ООП фич между Scala, Rust'ом и скажем C++ (т.к. Rust пытается стать заменой именно ему, хотя пока я не вижу чтобы тянул на это).
CAB>По моему скромному мнению, если уж вы решили добавить ООП в язык, вам не стоит туда добавлять ещё и отдельные функции, примитивные типы, структуры etc. Это оверкил.
А чем оно мешает то?
CAB>И наоборот, если вы решили что у вас будет язык низкого уровня, и там будут функции и п. типы, не стоит туда прикручивать ООП, структур вполне достаточно.
Да, всё правильно. Но зачем нам в 21-ом веке ещё один язык низкого уровня? Нам наоборот нужен язык очень высокого уровня, но при этом с сохранением полноценного доступа к системе/железу.
KP>ООП – это не более чем подход к программированию, философия. Вполне себе такой ООП-шный ООП можно замутить на чистом Си (чем частенько и развлекаются).
Можно, но зачем? Для этого есть языки с его, ООП, хорошей поддержкой. А в НЯП ты всё равно работаешь с адресами, структурами и функциями
KP>Так как Rust язык системный, в нем безусловно есть структуры, POD-типы и указатели. Но можно ли это считать весткой причиной усложнять жизнь разработчикам?
ИМХО, авторы Rust как раз усложнили жизнь разработчикам добавлением ООП.
Между тем,что я думаю,тем,что я хочу сказать,тем,что я,как мне кажется,говорю,и тем,что вы хотите услышать,тем,что как вам кажется,вы слышите,тем,что вы понимаете,стоит десять вариантов возникновения непонимания.Но всё-таки давайте попробуем...(Э.Уэллс)
C>Скала — это такой недоязычок с freestanding-методами?
Nope. Там нету freestanding-методов (что это?), насколько мне известно.
Между тем,что я думаю,тем,что я хочу сказать,тем,что я,как мне кажется,говорю,и тем,что вы хотите услышать,тем,что как вам кажется,вы слышите,тем,что вы понимаете,стоит десять вариантов возникновения непонимания.Но всё-таки давайте попробуем...(Э.Уэллс)
