LINUX.ORG.RU

Rust 0.10

 ,


2

8

Вышла новая версия Rust, языка программирования разрабатываемого Mozilla. Релиз несет в себе около 1500 изменений и исправлений ошибок.

Основные изменения:

  • Язык:
    • новый процесс RFC для изменения языка;
    • паттерны с '@'-указателями удалены из языка;
    • паттерны с '~[T]'-векторами удалены из языка;
    • паттерны с '~str'-строками удалены из языка;
    • '@str' удален;
    • '@[T]' удален;
    • '@self' удален;
    • '@Trait' удален;
    • заголовки, содержащие '@'-boxes для подсчета ссылок внутри типа, при '~'-аллокациях удалены;
    • семантика времени жизни временных выражений (temporary expressions) изменена. Подробнее в #3511, #11585;
    • добавлен новый cross-crate синтаксис расширений (доступен через feature gates). Подробнее в #11151. Эта возможность включает в себя макросы 'macro_rules!' и 'format!' как синтаксические расширения;
    • добавлены новые режимы lint, использование старых по умолчанию выдает предупреждения:
      • лишние скобки;
      • static в верхнем регистре;
      • Camel Case типы;
      • переменные в верхнем регистре;
      • приватные типы с публичной видимостью;
      • '#[deriving]' с raw-указателями.
    • unsafe-функции больше не преобразуются к замыканиям;
    • некоторые макросы с неясными названиями, например 'log_syntax!', теперь доступны через feature gates;
    • атрибут '#[simd]' теперь доступен через feature gates;
    • запрещены инструкции 'extern crate' в настройках видимости, модификатор 'priv' запрещен к использованию вместе с 'use' инструкциями;
    • замыкающие запятые запрещены в списках аргументов и шаблонах кортежей;
    • ключевое слово 'do' теперь является резервированным ключевым словом;
    • добавлены параметры типов по умолчанию, доступно через feature gates;
    • изменен механизм захвата borrowed-переменных в замыкания;
    • 'extern mod' изменен на 'extern crate';
    • удален 'Freeze' trait;
    • добавлен 'Share' trait для типов которые могут разделяться между потоками;
    • labels в макросах теперь гигиенические;
    • вызовы макросов теперь могут ограничиваться через '{}';
    • добавлен возможность перегрузки операторов '*' и '.' через 'Deref' и 'DerefMut' traits;
    • '~Trait' и 'proc' больше не реализуют 'Send' по умолчанию;
    • добавлена поддержка partial type hints через маркер типа '_';
    • введен тип 'Unsafe' для внутренней мутабельности. Преобразование '&T' в '&mut T' без использования 'Unsafe' является неопределенным;
    • реализован атрибут '#[linkage]' для внешних функций;
    • внутренний синтаксис атрибутов изменен с '#[foo];' на '#![foo]';
    • 'Pod' переименован в 'Copy'.
  • Библиотеки:
    • 'libextra' более недоступна. Она была разделена на более мелкие компоненты. Подробности в документации;
    • 'std::condition' удален. Все ошибки I/O передаются через тип 'Result'. Изменена работа макроса 'try!', подробности в #12039;
    • std: модуль 'vec' переименован в 'slice';
    • std: добавлен новый тип 'Vec<T>' для DST. В будущем это будет единственный вектор с изменяемым размером;
    • std: увеличено число публичных reexports 'std::io'. Типы, такие как 'BufferedReader' доступны через 'std::io::BufferedReader' вместо 'std::io::buffered::BufferedReader';
    • std: 'print' и 'println' более не доступны в prelude, используйте вместо них макрос 'println!';
    • std: 'Rc' теперь имеет 'Weak' указатель для прерываемых циклов и больше не пытается статически предотвращать циклы;
    • std: в стандартной поставке используется политика обработки ошибок пользователем вместо падения в библиотеках. Многие функции, такие как 'slice::last()' теперь возвращают 'Option<T>';
    • std: 'fmt::Default' переименован в 'fmt::Show', добавлен новый deriving mode: '#[deriving(Show)]';
    • std: 'ToStr' реализован для всех типов, реализующих 'Show';
    • std: trait для форматированного вывода принимает '&self' вместо '&T';
    • std: метод итераторов 'invert()' был переименован в 'rev()';
    • std: добавлена возможности вывода backtrace при падении task'a, если выставлено значение переменной 'RUST_BACKTRACE';
    • std: стандартизованы соглашения по наименованию для итераторов. Подробнее в wiki;
    • std: 'eof()' удален из 'Reader';
    • std: сетевые типы (networking types) теперь cloneable, разрешено одновременное чтение/запись;
    • std: 'assert_approx_eq!' удален;
    • std: добавлены спецификаторы форматирования 'e' и 'E' для вывода чисел с плавающей точкой в экспоненциальном формате;
    • std: удален 'Times';
    • std: добавлен тип 'std::kinds::marker' для выборочного вывода встроенных привязок (bounds);
    • std: 'hash' был переписан, 'IterBytes' удален, доступен '#[deriving(Hash)]';
    • std: 'SharedChan' был удален, 'Sender' теперь cloneable;
    • std: 'Chan' и 'Port' были переименованы в 'Sender' и 'Receiver';
    • std: 'Chan::new' заменен на 'channel()';
    • std: реализован новый тип синхронных каналов;
    • std: макрос 'select!' доступен для выбора 'Receiver'-ов;
    • std: 'hashmap' и 'trie' были перемещены в 'libcollections';
    • std: 'run' перемещен в 'io::process';
    • std: 'assert_eq!' теперь использует '{}' вместо '{:?}';
    • std: реорганизованы механизмы сравнения и проверки на равенство trait-ов;
    • std: 'rand' перемещен в 'librand';
    • std: 'to_{lower,upper}case' реализован для 'char';
    • std: функциональность логгирования перенесена в 'liblog';
    • collections: 'HashMap' переписана для увеличения производительности и уменьшения потребления памяти;
    • native: в качестве рантайма по умолчанию используется 'libnative'. 'libgreen' доступен для загрузки вручную, подробнее в документации;
    • native: реализована весь I/O функционал, за исключением сигналов;
    • green: оптимизировано создание task-ов в 'libgreen';
    • green: task-и, создаваемые через 'libgreen' используют unmapped guard page;
    • sync: модуль 'extra::sunc' был обновлен на современный rust, перемещен в библиотеку 'sync';
    • sync: добавлен новый тип 'Barrier';
    • sync: реализованы эффективные мьютексы для нативных и зеленых task-ов;
    • serialize: улучшен модуль 'base64';
    • fourcc: добавлен макрос 'fourcc!';
    • hexfloat: реализован макрос 'hexfloat!';
  • Инструментарий
    • 'rustpkg' объявлен устаревшим и удален из основного репозитория. Его замена ('cargo') в разработке;
    • доступны ночные сборки;
    • значительно улучшено использование памяти 'rustc';
    • отключена поддержка rpath для rustc в процессе сборки;
    • улучшен механизм кодогенерации;
    • восстановлена совместимость debuginfo с lldb на OSX;
    • флаги вывода централизованы в один флаг '--emit';
    • флаги crate типов централизованы в один флаг '--crate-type';
    • флаги кодогенерации объединены через флаг '-C';
    • улучшены сообщения об ошибках возникающих при линковке с устаревшими crates;
    • сообщения об ошибках с временем жизни теперь часто показывают как объявить функцию чтобы исправить ошибки;
    • значительно расширена документация;
    • улучшения в 'rustdoc':
      • подсветка синтаксиса и блоки кода;
      • генерация standalone markdown файлов;
      • флаг '--test' проверяет все блоки кода по умолчанию;
      • отображение экспортированных макросов;
      • reexported типы имеют встроенную документацию в месте первого reexport;
      • результаты работы по поиску в crate-ах теперь генерируется в выходную директорию.

>>> Подробности

★★★★★

Проверено: JB ()
Последнее исправление: encyrtid (всего исправлений: 1)

Ответ на: комментарий от ozkriff

Зачем мне возвращаться в прошлый век, отказываться от ООП и исключений, и снова использовать структурки, интерфейсы(тогда это были структуры с указателями на функции), коды возврата, меченные объединения и пр.? Ради чего? Писать большие системы с этим всем сложнее, чем в нормальном ООП и нормальном же и придуманном стиле обработки ошибок.

anonymous
()
Ответ на: комментарий от anonymous

Дженерики шаблонами никогда не станут.

И не должны. Ты проигнорировал макросы и процедурные макросы.

Ограничения там совсем другие, чем в плюсах вести хотят(концепты), сравнивать некорректно.

Можно подробнее чем они так радикально отличаются?

Игру свою пили на ржавчене.

Я, вроде, не разрешения спрашивал)

Сейчас и на явах/шарпах с питонами игры пишут

На «явах/шарпах с питонами» пишут не движки игр, а более высокоуровневый код.

ozkriff
()
Ответ на: комментарий от ozkriff

Мобильные игры вполне себе полностью пишут на том же unity на шарпе(сам написан на полюсах и Шарпа). На Питоне(stackless python) вроде как целиком написан клиент eve online, например.

Кстати, про игрушку твою есть информация какая? turn-based интересны.

anonymous
()
Ответ на: комментарий от anonymous

нет ни полноценного ООП(с нормальным наследованием, хотя бы)

А вот в умных книжках про ООП пишут, что предпочтительно использовать композицию вместо наследования. И именно такой подход навязывает rust. Не вижу проблемы.

ни исключений

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

заменить плюсы он не в состоянии

Ржавчина изначально, by design предназначена для многопоточных программ. Если перевести это в человекочасы, то c++ окажется аутсайдером.

Manhunt ★★★★★
()
Ответ на: комментарий от anonymous

ни полноценного ООП, ни шаблонов

Не могли всё как в крузисеC++ сделать!!!!1 Плохо сделали, тупо.
---

Зачем мне возвращаться в прошлый век

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

quantum-troll ★★★★★
()
Ответ на: комментарий от quantum-troll

Мда, перевернули все с ног на голову. Я смотрю на фишки раста и вижу там то, что использовал 20 лет назад, а потом отказался в пользу ООП, исключений и пр. Я помимо плюсов ещё и другие языки использую. И в питоне, руби, скале, яве, шарпе и пр. есть и ООП и исключения. Шаблоны для системного языка предпочтительнее дженериков. Да и вообще для наливных. В том же дотнете виртуальная машина сама нормально с дженериками эффективно работает, для нативных языков это практически невозможно(по крайней мере совместно с раздельной компиляцией и динамической линковкой). Кроме того, шаблоны позволяют специализировать код для более эффективной имплементации. Для высоко уровне кого кода да, дженериков хватает.

anonymous
()
Ответ на: комментарий от quantum-troll

Зачем анонировать на старые теории, когда нужно решать реальные задачи?

anonymous
()
Ответ на: комментарий от anonymous

С макросами, естественно, надо быть осторожным и не использовать просто так направо и налево.

Но это в любом случае меньший трэш, чем плюсовые шаблоны.

ozkriff
()
Ответ на: комментарий от anonymous

Мобильные игры вполне себе полностью пишут на том же unity на шарпе(сам написан на полюсах и Шарпа).

Unity-то не на шарпе сам написан. А я про этот уровень кода говорю.

На Питоне(stackless python) вроде как целиком написан клиент eve online, например.

Прикольно, надо будет почитать про это дело.

Кстати, про игрушку твою есть информация какая? turn-based интересны.

Есть ссылка на гитхаб, которую я выше дал. Играть там пока не во что)

ozkriff
()
Ответ на: комментарий от quantum-troll

Ознакомился. Поэкспериментировал немного, даже попытался на работе использовать(для какой-то простенькой саппортной утилиты), но потом сделал вывод, что не подойдёт. Erlang вполне использую, если что. Я там перечислил то, что применял в реальных задачах, так-то f#, ocaml, лиспы, nemerle и пр. и пр. Но применение не пошло. Недавно с go экспериментировал, тоже понял, что из него профита извлечь пока не получится, чуть позднее ещё посмотрим.

anonymous
()
Ответ на: комментарий от ozkriff

Я бы поспорил. С шаблонами ошибки искать проще (но надо иметь терпения разбирать простыню, да, но там есть вся необходимая информация, а простынки стали понятнее и в clang и в gcc). И последствий серьёзных вряд ли будет. Если собралось - значит работает как надо. Но с нормальными макросами у меня опыт как раз небольшой.

anonymous
()
Ответ на: комментарий от tailgunner

Cousineau G., Mauny M. The functional approach to programming

Спасибо.

unsigned ★★★★
()
Ответ на: комментарий от ozkriff

... только в рамках одного crate`а ...

Имеется ввиду, что в том crate`е должна быть или определена структура, для которой ты хочешь реализовать trait, или должен быть определен trait, который ты хочешь реализовать. Я так понял, это нужно, что бы не было ошибок при линковке.

ozkriff
()
Ответ на: комментарий от ozkriff

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

Да понятно, что можно обходиться. Да и не во всех языках она есть... но скажем, в схеме это объясняется «идеологически»: функция - это тоже переменная. А «перегрузка переменных» уже дико смотрится. Ну и да, эта возможность усложняет язык и чтение исходников (с этим правда у меня никогда проблем не возникало). Стоит ли оно того? На мой взгляд, да. Но очевидно, что на этот счёт могут быть другие точки зрения.

В общем, это одна из немногих вещей, которые мне реально не нравятся в языке.

DarkEld3r ★★★★★
()
Ответ на: комментарий от ozkriff

В ржавчине есть нормальные дженерики, причем с ограничениями.

Можно в двух словах про ограничения и без отсылки в мануалы? (:

DarkEld3r ★★★★★
()
Ответ на: комментарий от ozkriff

Но это в любом случае меньший трэш, чем плюсовые шаблоны.

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

Если в расте дженерики типа kak в С#, то это отстой, а не замена темплейтам.

DarkEld3r ★★★★★
()
Ответ на: комментарий от anonymous

Я смотрю на фишки раста и вижу там то, что использовал 20 лет назад, а потом отказался в пользу ООП, исключений и пр

В каком языке 20 лет назад ты использовал дженерики, трейты и ADT?

tailgunner ★★★★★
()
Ответ на: комментарий от DarkEld3r

Если в расте дженерики типа kak в С#, то это отстой, а не замена темплейтам.

Я знал, что плюсовики в конце концов скажут «хотим Тьюринг-полные шаблоны». Но нужно быть до конца честными: «Хотим всё, как в Си++, только лучше» %)

tailgunner ★★★★★
()
Ответ на: комментарий от tailgunner

В Паскале, Аде и Си. Хотя ты мне сейчас скажешь, что вариантные типы - это не алгебраические типы данных, что в аде убогие дженерики, что структура с указателями на функции - это не трейты, а в си все это нужно делать руками. Но тем не менее, использовал. И ООП даёт именно новую нормальную концепцию, а раст - лишь синтаксический сахар.

anonymous
()
Ответ на: комментарий от anonymous

В каком языке 20 лет назад ты использовал дженерики, трейты и ADT?

В Паскале, Аде и Си

В Паскале и Си нет дженериков, трейтов нет нигде в перечисленных.

Хотя ты мне сейчас скажешь, что вариантные типы - это не алгебраические типы данных

Не скажу. Tagged unions - это, ИМХО, что-то очень близкое (хотя, возможно, не эквивалентное с точки зрения CS), но из перечисленных языков приличные tagged unions разве что в Аде.

структура с указателями на функции - это не трейты

Абсолютно не трейты.

раст - лишь синтаксический сахар

В Rust есть еще и концепция управления памятью, а это ни с какой стороны не синтаксис (да и называть тот же Си++ «синтаксическим сахаром» над Си - это, как бы это помягче, понты).

tailgunner ★★★★★
()
Последнее исправление: tailgunner (всего исправлений: 1)
Ответ на: комментарий от tailgunner

но из перечисленных языков приличные tagged unions разве что в Аде.

В Паскале есть вариантные записи. В Си делается с помощью структурки с тегом и объединением. Да, руками.

Абсолютно не трейты.

Можно пример для того, чтобы прочувствовать разницу? Я уже не говорю о том, что ООП это не мешает(см. Scala).

В Rust есть еще и ...

Мы говорим об ООП, исключениях и др. выпиленных фичах. И якобы замену для них.

anonymous
()
Ответ на: комментарий от anonymous

В Паскале есть вариантные записи.

ЕМНИП, у них очень слабый контроль компилятором.

В Си делается с помощью структурки с тегом и объединением. Да, руками.

Руками можно сделать вообще всё, но это нерелевантно обсуждению.

Абсолютно не трейты.

Можно пример для того, чтобы прочувствовать разницу?

По сравнению с Rust: нет наследования; невозможно указать как границу в дженерике. По сравнению с абстрактным классом Си++: нет проверки типов (по-любому объект - это void *).

Мы говорим об ООП,

Выше уже сказали: современное понимание ООП - это наследование интерфейсов и агрегация при их реализации (и кстати, эти идеи озвучивались уже 25 лет назад).

исключениях и др. выпиленных фичах.

Выпиленных по сравнению с чем? В Си и Паскале никогда не было ООП, в стандартном Си (и стандартном Паскале?) нет исключений и дженериков.

И якобы замену для них.

Мне не нужна замена C++-style ООП и исключений. Если тебе необходимо и то, и другое - Си++ никуда не делся

tailgunner ★★★★★
()
Последнее исправление: tailgunner (всего исправлений: 1)
Ответ на: комментарий от tailgunner

современное понимание ООП - это наследование интерфейсов и агрегация при их реализации (и кстати, эти идеи озвучивались уже 25 лет назад).

Это ограничение и введение лишних сущностей, а не «современное понимание». Можно, кстати, ссылку на литературу. А то как-то что не почитаю про OOP и OOA&D, так все как-то видел «обычное»(«устаревшее», видимо) ООП.

anonymous
()
Ответ на: комментарий от tailgunner

Си++ никуда не делся

Вот именно. И какой смысл в Rust'е, если он не может заменить C++? Есть более удобные и мощные языки, чем Rust. Чем плоха Scala?

anonymous
()
Ответ на: комментарий от tailgunner

Выпиленных по сравнению с чем?

С современными используемыми языками. Там, где используют Си, в основном, исключения и не нужны. Я и для плюсов их не использовал во многих проектах.

anonymous
()
Ответ на: комментарий от anonymous

Это ограничение и введение лишних сущностей

Одновременно ограничение и введение лишних сущностей? Круто.

Можно, кстати, ссылку на литературу

На выпуск журнала «Программирование» за 90-й год, посвященный ООП? %)

Начни здесь, дальше по ссылкам: http://lwn.net/Articles/548560/

как-то что не почитаю про OOP и OOA&D, так все как-то видел «обычное»(«устаревшее», видимо) ООП

В том же COM нет наследования реализаций, только интерфейсы и агрегация. Технологии уже лет 20.

И какой смысл в Rust'е, если он не может заменить C++?

Зачем нужен язык системного программирования с безопасным управлением памятью? Ну я даже не знаю. Но можно почитать сегодняшние новости и подумать.

Чем плоха Scala?

Scala - это такой Си++ 21-го века, работающий только на JVM? Вот этим и плоха.

Выпиленных по сравнению с чем?

С современными используемыми языками

Пример «современного используемого языка» можно? Если это Scala, C# или Java, то Rust не претендует на их место.

tailgunner ★★★★★
()
Последнее исправление: tailgunner (всего исправлений: 1)

Вопрос от другого анонима. Где про их систему traits подробно почитать можно? Просто не пойму, гонят ли они всё через virtual dispatch, или там как-то умнее это сделано.

anonymous
()
Ответ на: комментарий от anonymous

Если я правильно понял вопрос, то https://mail.mozilla.org/pipermail/rust-dev/2012-October/002446.html

Коротко: «use them as a typeclass (i.e. a constraint on a type parameter to a generic function). You can also use them in a first class way, in which case they behave more like a Go interface» - в первом случае статика, во втором динамика.

tailgunner ★★★★★
()
Последнее исправление: tailgunner (всего исправлений: 1)
Ответ на: комментарий от tailgunner

С Com я работал, положительных впечатлений крайне мало. Да и не в том дело. Вопрос в том, ради чего отказываться от ООП? Ведь он умеет и это и много чего другого.

Scala - великолепный язык. Уж всякого лучше rust'а. И если rust не может заменить плюсы, то мне непонятно, кого он со своими возможностями вообще может заменить.

Ссылка твоя ведёт на статью про rust и go, а значит не может являться аргументом в данном контексте.

anonymous
()
Ответ на: комментарий от anonymous

Это ограничение и введение лишних сущностей, а не «современное понимание».

Лишняя сущность - это наследование реализации.

Можно, кстати, ссылку на литературу.

Можно начать отсюда: http://en.wikipedia.org/wiki/Composition_over_inheritance

Вопрос в том, ради чего отказываться от ООП?

Никак не пойму, с какого бодуна ты решил, что в Rust отказались от ООП?

Manhunt ★★★★★
()
Ответ на: комментарий от Manhunt

Против того, что по ссылке ничего не имею, но это не имеет отношение к обсуждению.

Лишняя сущность - это наследование реализации.

Не наследуй реализацию, если не нужно. От этого в «классическом» ООП ничего не изменится. Миксины хоть есть в расте?

Никак не пойму, с какого бодуна ты решил, что в Rust отказались от ООП?

Потому, что там его нет. С таким же успехом можно объявить, что ООП есть в хаскеле.

anonymous
()
Ответ на: комментарий от tailgunner

Жаль. С тем же успехом можно было закончить на вашем голословном негативном утверждении о scala.

anonymous
()
Ответ на: комментарий от anonymous

на вашем голословном негативном утверждении о scala.

WAT. То, что Scala - следующий Си++, это распространенная шутка. То, что она только для JVM - голый факт (и просто для протокола - мне нравится Scala). Закончить надо было, когда ты первый раз противопоставил Scala и Rust, но тогда я подумал, что это просто полемика.

tailgunner ★★★★★
()
Последнее исправление: tailgunner (всего исправлений: 1)
Ответ на: комментарий от DarkEld3r

Я так понимаю, что официальная позиция насчет перегрузки примерно такая: «ненужна, потому что у нас есть трэйты. используйте трэйты и все будет хорошо». Может я не так понял, тогда буду рад разъясняющим ссылкам и цитатам.

Можно в двух словах про ограничения ...

trait Shape {
    fn draw(&self, s: &mut Surface);
}

fn draw_twice<T: Shape>(surface: &mut Surface, sh: T) {
    sh.draw(surface);
    sh.draw(surface);
}

Если ты в обобщенной функции хочешь использовать какой-то метод для объекта типа T, ты ты должен указать трэйт с таким методом (Shape, в данном случае).

... и без отсылки в мануалы? (:

Чего плохого в отсылках к документации? Я чего-то не так мог понять, чего-то не так сказать и ты получаешь испорченный телефон. Пускай будет:

http://static.rust-lang.org/doc/master/rust.html#traits

Темплейты не треш

Это сродни утверждению «С++ не сложный», лучше эту тему не развивать)

Если в расте дженерики типа как в С#, то это отстой, а не замена темплейтам.

Извиняюсь, я очень поверхностно знаком с шарпами. В ржавчине ты стараешься использовать простые и понятные дженерики, а когда их возможностей не хватает, то используешь макросы. А когда и этого мало, то подтягиваешь процедурные макросы.

ozkriff
()
Ответ на: комментарий от tailgunner

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

libuv, используемая как база в libgreen — это тоже хорошо, производительность сетевых приложений должна быть на весьма приличном уровне. В своём проекте писал для этой библиотеки С++ обёртку, ибо Boost.Asio (по крайней мере в Linux) на 3-4 тысячах одновременных подключений просто-напросто колом вставал из-за блокировки мьютексов на каждый чих.

anonymous
()
Ответ на: комментарий от anonymous

libuv, используемая как база в libgreen — это тоже хорошо

...но всё же в последней версии по умолчанию используется native-рантайм.

tailgunner ★★★★★
()
Ответ на: комментарий от tailgunner

Ну раз шутка, то ок=)

Я не противопоставлял. Я просто не понимаю, зачем нужен язык с возможностями rust, если он не может заменить C++. Если не говорить о замене C++, то есть масса нормальных языков, где нет каких-либо подпрыгиваний с временем жизни объектов, возней с памятью и пр.

anonymous
()
Ответ на: комментарий от anonymous

Пока по тестам даже Go проигрывает...

anonymous
()
Ответ на: комментарий от tailgunner

...но всё же в последней версии по умолчанию используется native-рантайм.

Что несколько странно. Я вижу, что они позиционируют libgreen как базу для реализации M:N модели многопоточности, в то время как libnative — это 1:1. Почему у них такое разделение произошло я не понимаю, т.к. на libuv 1:1 модель вполне себе реализуется. Как концепт «наш язык может в несколько рантаймов» это хорошо и правильно. Но. При всём при этом в libgreen асинхронный IO старательно спрятан, а в libnative сейчас вообще все операции блокирующие. А асинхронный ввод/вывод в каком-то виде всё равно нужен будет. И тогда они будут заново изобретать libuv своими силами.

anonymous
()
Ответ на: комментарий от anonymous

в libgreen асинхронный IO старательно спрятан, а в libnative сейчас вообще все операции блокирующие

По-моему, API на уровне Rust (задачи, каналы и пр.) ровно одинаковый.

tailgunner ★★★★★
()
Ответ на: комментарий от tailgunner

А я про то и говорю, что одинаковый.

https://github.com/mozilla/rust/blob/master/src/librustuv/net.rs#L219 — тут спрятали асинхронность, чтобы вести себя как блокирующий вызов. https://github.com/mozilla/rust/blob/master/src/libnative/io/net.rs#L255 — тут вообще retry с проверкой EINTR внутри.

Для альфы 0.10 это нормально. Надеюсь, что в каком-то виде поддержка асинхронного ввода-вывода появится до того, как 1.0 вылупится. А то получится, что язык пролетит мимо той ниши, где он может хорошо прижиться.

anonymous
()
Ответ на: комментарий от anonymous

Мне кажется, там закрепляется Go. И Rust не сможет что-то предоставить. Хотя на фоне go он и выглядит помощнее.

anonymous
()
Ответ на: комментарий от anonymous

Если рассуждать о качествах одного яп на уровне критики второго, то на фоне Go Rust выглядит несостоятельно и несколько догматизированно. Основная задача при построении новых языков (не суть) — найти более приемлемое решение — получить широкий охват: предельно упростить старое, избавиться лишнего, в полной мере организовать и обеспечить наиболее зарекомендовавшие себя концептуальные практики, но, видимо, мера простоты и понимание лучшести у каждого своё.

Лучшесть Роба Пайка и Ко мне ближе.

anonymous
()
Ответ на: комментарий от anonymous

Никак не пойму, с какого бодуна ты решил, что в Rust отказались от ООП?

Потому, что там его нет.

Ну то есть объекты есть, инкапсуляция есть, полиморфизм есть, наследование интерфейсов (точнее, трейтов) есть, а ООП — нет? Не понимаю.

Manhunt ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.