LINUX.ORG.RU

Rust 0.7

 ,


1

5

3 июля было объявлено о выходе очередной версии Rust — языка программирования, разрабатываемого Mozilla. Новая версия включает в себя около 2000 изменений и исправлений ошибок.

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

  • Изменения в языке:
    • квалификатор видимости больше неприменим к 'impl', только к методам;
    • переписан borrow checker, исправлено множество ошибок;
    • параметр 'self' больше не равен неявно `&'self self` и для него может быть явно определено время жизни;
    • перегружаемые составные операторы ('+=' и пр.) были временно удалены из-за ошибок;
    • циклы 'for' теперь требуют 'for'-итераторов, чтобы вернуть 'bool';
    • 'Durable' trait был заменен `'static`;
    • структуры с атрибутом '#[packed]' выравниваются по байтовой границе;
    • параметры типов, привязываемые посредством 'Copy', должны быть явно скопированы с ключевым словом 'copy';
    • 'Option<~T>' сейчас представляется как nullable-указатель;
    • '@mut' делает динамические borrow checks корректно;
    • функция main теперь ищется только на верхнем уровне. Атрибут '#[main]' валиден в любом месте;
    • поля структур больше не могут быть мутабельными, вместо этого используется унаследованная мутабельность;
    • удалены атрибуты '#[no_send]', '#[no_freeze]';
    • неограниченная рекурсия прерывается при достижении лимита, определенного переменной окружения 'RUST_MAX_STACK' (1gb по умолчанию);
    • удален режим 'vecs_implicitly_copyable', векторы никогда не копируются неявно;
    • атрибут '#[static_assert]' выдает assert'ы о статических булевых переменных во время компиляции;
    • 'argument modes' больше не существует;
    • редко используемая инструкция `use mod` удалена.
  • Расширения синтаксиса:
    • 'fail!' и 'assert!' принимают списки аргументов '~str', '&'static str' или 'fmt!';
    • `Encodable`, `Decodable`, `Ord`, `TotalOrd`, `TotalEq`, `DeepClone`, `Rand`, `Zero` и `ToStr` могут быть автоматически выведены посредством директивы `#[deriving(...)]`;
    • макрос `bytes!` возвращает вектор байтов для string, u8, char и численных литералов.
  • Библиотеки:
    • `core` crate был переименован в `std`;
    • `std` crate был переименован в `extra`;
    • расширена и улучшена документация;
    • добавлен модуль std: `iterator` для внешних итераторов (external iterator objects);
    • std: многие итераторы, написанные в старом стиле, были заменены на реализацию 'Iterator';
    • std: многие внутренние векторы и строковые итераторы (включая 'any', 'all и пр.) удалены;
    • std: prelude теперь не реэкспортирует любые модули, только типы и трейты;
    • std: дополнения в Prelude: `print`, `println`, `FromStr`, `ApproxEq`, `Equiv`, `Iterator`, `IteratorUtil`.

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

★★★★★

Проверено: anonymous_incognito ()
Последнее исправление: cetjs2 (всего исправлений: 4)
Ответ на: комментарий от www_linux_org_ru

Каких еще практик? Освобождения памяти, когда она не нужна?

да, практика освобождения памяти, когда она достаточно очевидным образом не нужна

Мде. Вообще-то пойнт unique pointers совершенно не в этом. Он в том, что у блока памяти _ровно один владелец_.

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

Мде. Вообще-то пойнт unique pointers совершенно не в этом. Он в том, что у блока памяти _ровно один владелец_.

ты думаешь, что я не знаком с этим пойнтом?

можно иметь 3 пойнта:

1. ровно один владелец

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

3. изменение владельца при копировании (или присваивании, как его правильнее назвать)

и в чем проблема?

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

пойнт unique pointers совершенно не в этом. Он в том, что у блока памяти _ровно один владелец_.

ты думаешь, что я не знаком с этим пойнтом?

Не знаю. Я пытаюсь выяснить, какие такие «практики Си» имеют отношение к unique pointers (и linear typing).

и в чем проблема?

Проблема в том, что из практики освобождения ненужной памяти unique pointers не вытекают.

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

Проблема в том, что практики освобождения ненужной памяти [из] unique pointers не вытекают.

вытекают, если мы предположим, что в си память стремятся освободить как можно раньше, *хотя бы* в случае, когда она аллоцирована локально и ее можно освободить тоже локально

дальше компилятор видит unique pointer, вспоминает, что хозяин любит освобождать память пораньше, и грохает память по выходу из блока

тут, в принципе, могут быть исключения из правила «память стремятся освободить как можно раньше, *хотя бы* в случае, когда она аллоцирована локально и ее можно освободить тоже локально», но мне они пока что не видны, хотя это конечно не значит, что их нет

з.ы. хотя ты, возможно, хотел поставить «из» в другом месте?

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

Проблема в том, что практики освобождения ненужной памяти [из] unique pointers не вытекают.

з.ы. хотя ты, возможно, хотел поставить «из» в другом месте?

Естественно: «_из_ практики освобождения ненужной памяти unique pointers не вытекают». Более того, их основное назначение в Rust - поддержка параллельного исполнения; корни же unique pointers - в linear typing, а не мифических «практиках Си».

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

Естественно: «_из_ практики освобождения ненужной памяти unique pointers не вытекают». Более того, их основное назначение в Rust - поддержка параллельного исполнения; корни же unique pointers - в linear typing, а не мифических «практиках Си».

мне совершенно пофиг, где их корни, и к вопросу это скорее всего не относится

суть в том, что есть определенные практики в си (пусть даже такие элементарные, как сделать (или не сделать) free по выходу из блока), и введение unique pointers позволяет делать значительную часть этих практик автоматически

поэтому можно сказать, что unique pointers формализуют че-то там, связанное с этими практиками

и совершенно пофиг, были придуманы unique pointers специально для этого, или просто по накурке, так как скучно было

ну а то, что unique pointers позволяют еще и гонять данные между нитями, и крестиком вышивать — это конечно хорошо

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

мне совершенно пофиг

к вопросу это скорее всего не относится

можно сказать

и совершенно пофиг

*пожимая плечами* Мне тоже уже пофиг.

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

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

вот так можно и с unique pointers... правда остается вопрос, всегда ли деструкторы нужно вызывать и память освобождать как можно быстрее

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

То есть никогда. а я уже надеялся вновь увидеть фортран на пьедестале ЯП..

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

«Перестаю» - значит понимаю в текущий момент, но не даю понятия, что скажу тоже самое в следующий.

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

Firefox к rust никак не относится. На rust пишут «убийцу firefox», только убийца этот еще очень и очень далек от цели.

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

Я к тому, что Rust покрыл мозг мозиллокодеров.

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

Он не убог, к нему это слово просто неприменимо. Это как сказать, что ассемблер убог :) просто язык низкого уровня. И зато простой же очень.

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

Он не убог

Он именно убог.

к нему это слово просто неприменимо

И почему же?

Это как сказать, что ассемблер убог :)

Ассемблер -это просто символические мнемоники для системы команд.

И зато простой же очень.

Большая ошибка так думать.

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

Си был примитивен даже для своего времени, а по сегодняшним меркам он просто убог

По сегодняшним меркам он просто Бог.

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

Си был примитивен даже для своего времени, а по сегодняшним меркам он просто убог

По сегодняшним меркам он просто Бог.

Тебе продали мерки, устаревшие до твоего рождения. Требуй возврата денег.

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

Помимо этого, в отличие от разработчиков языка D, им хватило ума не привязывать всю стандартную библиотеку к сборщику мусора. Есть шанс, что Rust таки можно будет использовать в системном программировании.

anonymous
()

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

Quasar ★★★★★
()

Зачем нужен этот велосипед?

Кто-нибудь внятно объяснить может?

PS. Тормозила мертва. Реально победили Google Chrome и Apple Safari.

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

И почему же?

Потому что при той универсальности и простоте _внутреннего_ устройства об убогости можно будет говорить, только когда будет создана реальная «менее убогая» альтернатива. Такая же простая и универсальная)

Ассемблер -это просто символические мнемоники для системы команд.

Вот поэтому и он не может быть убог или не убог, он просто есть и всё :)

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

об убогости можно будет говорить, только когда будет создана реальная «менее убогая» альтернатива

Ой, какая пафосная чушь. Говно - это говно, вне зависимости от того, есть ли у тебя хлеб.

он не может быть убог или не убог, он просто есть и всё :)

Эталонно бессмысленная фраза, применимая к чему угодно.

tailgunner ★★★★★
()

Супер!!

Давно ждал, спасибо больше!!

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

только когда будет создана реальная «менее убогая» альтернатива. Такая же простая и универсальная)

Оберон и циклон уже давно созданы. Полагаю что есть и другие.

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

Бгггггггг, это так тонко, что даже толсто))

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

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

Сам на плюсах опыта не имею, так что судить могу только по рассказам знакомых плюсарей. Проблемы начинаются сразу же, как только приходится работать с чужим кодом. Чем дальше написанное от «твоих 20%», тем сложнее его понимать. В рамках одной команды этого почти нет, но при переходе в другую команду приходится, грубо говоря, изчать новый язык.

проблему в плюсах представляет совсем другое — «так не пишите, потому что это опасно, и вот так не пишите, потому что это стиль си, и плохо сочетается с stl, и вот так не пишите вот в этом случае, но именно так пишите в том случае, и ...»

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

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

Когда умрёт Си, к тому времени Фортран уже успеют переделать снова.

Да пусть переделывают. А C умрёт очень быстро, как только появится хоть один альтернативный язык целенаправленно спроектированный под эту нишу. Сейчас им довольны только инженеры-электронщики и тролли. Проблема только в том, что ниша настолько узкоспециализирована, что приличным разработчикам языков не интересна вообще :(

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

Там какая-то странная версия Rust. То ли устаревшая, то ли ХЗ что.

Это, мягко говоря, не самая большая проблема той статьи.

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

Проблема только в том, что ниша настолько узкоспециализирована, что приличным разработчикам языков не интересна вообще :(

Как это, как это... вполне интересна. Но обитатели ниши очень уж тупы^Wконсервативны.

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

Все эти дурные попытки найти «современную» с кучей плюшек (сборщик мусора, pattern matching, замыкания, дженерики и т. д.) замену C IMHO обречены потому что для ремесла, а не для творчества. Например,Cyclone - мертв, BitC - смертельно болен, ATS - туда же. И так IMHO будет с каждым, кто сложнее C. Как замена, возможно подошел бы Forth или низкоуровневый Lisp, а не эти «прогрессивные идеи».

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

попытки найти «современную» с кучей плюшек (сборщик мусора, pattern matching, замыкания, дженерики и т. д.) замену C IMHO обречены потому что для ремесла, а не для творчества

Ух ты. Как по мне, так это убогий Си, в котором нет очевидных уже лет 20 вещей вроде дженериков и ADT с pattern matching - для ремесла, а не для творчества. Мля, да там даже typeof в Си11 нет, потому что, видите ли, «полезность не очевидна». Дебилы.

Cyclone - мертв

Насколько я понимаю, это был исследовательский язык. И, снова насколько я понимаю, он повлиял на Rust.

BitC - смертельно болен

Мертв же. Впрочем, чего еще ожидать от Шапиро.

ATS - туда же

ATS тупо переусложнен.

Как замена, возможно подошел бы Forth или низкоуровневый Lisp

Нафига? Профита ровно ноль, головняк очевиден.

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

Ух ты. Как по мне, так это убогий Си, в котором нет очевидных уже лет 20 вещей вроде дженериков и ADT с pattern matching - для ремесла, а не для творчества. Мля, да там даже typeof в Си11 нет, потому что, видите ли, «полезность не очевидна». Дебилы.

Назови, хотя бы примерные задачи которые ты решаешь на C. Я программирую на C/C++ около 12 лет, в основном на C пишут инструменты, такие как универсальные библиотеки, базы данных, embedded. В таких задачах важен в деталях проработанный алгоритм, custom allocator, custom gc, важно понимать какой код генерит компилятор. Высокоуровневый язык навызывает свой подход к решению задачи. Творческие люди не любят когда им что либо навязывают.

Нафига? Профита ровно ноль, головняк очевиден.

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

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

Назови, хотя бы примерные задачи которые ты решаешь на C. Я программирую на C/C++ около 12 лет

Системное программирование - драйверы, embedded; 20 лет.

в основном на C пишут инструменты, такие как универсальные библиотеки, базы данных, embedded

Это не от хорошей жизни. Просто something, somewhere has gone terribly wrong.

В таких задачах важен в деталях проработанный алгоритм, custom allocator, custom gc, важно понимать какой код генерит компилятор.

Чем в этом мешает ADT, pattern matching, generics?

Творческие люди не любят когда им что либо навязывают.

Да что кто и что им навязывает-то? Если кто-то не понимает, чем выгодно использовать generics или ADT - так это лень, косность или просто капризы.

Я знаю программистов-виртуозов на Форте.

В Форте нет ничего, что позволило бы ему потеснить Си в занимаемых нишах. Причем ничего как с точки зрения старперов, так и с точки зрения молодняка (старперы и молодняк - это по духу, не возрасту).

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

Это не от хорошей жизни. Просто something, somewhere has gone terribly wrong.

По моему, у тебя все же своя среда обитания, в моей команде программисты другие, и скорее снизойдут до ассемблера, чем добровольно поднимутся до C++. Это не мешает конторе хорошо зарабатывать на ПО.

Да что кто и что им навязывает-то? Если кто-то не понимает, чем выгодно использовать generics или ADT - так это лень, косность или просто капризы.

Ну это только твое мнение. Generics и ADT это скорее ML, а не C. В C, - void* и Generics и ADT.

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

в моей команде программисты другие, и скорее снизойдут до ассемблера, чем добровольно поднимутся до C++

Это косность и предрассудки. Широко распространенные (см. троллинг Торвальдса в сторону Си++), но от того не более простительные.

Ну это только твое мнение.

О нет, отнюдь не только.

Generics и ADT это скорее ML, а не C

Это полезные инструменты, и пофиг, где именно они родились.

В C, - void* и Generics и ADT.

Поэтому Си и убог. Прикол в том, что и Generics, и примитивные (но полезные) формы ADT реализуются минимальными усилиями со стороны разработчиков компиляторов. И другие вещи, которые существенно облегчили бы жизнь - тоже.

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

В Форте нет ничего, что позволило бы ему потеснить Си в занимаемых нишах. Причем ничего как с точки зрения старперов, так и с точки зрения молодняка (старперы и молодняк - это по духу, не возрасту).

В форте есть доступ к стеку и компилятору, форт банально гибче чем C. Плюс всякие stm32 c 64K ОЗУ. Шитый код компактнее и потоки существенно проще и легче чем в C.

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

В форте есть доступ к стеку и компилятору

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

Плюс всякие stm32 c 64K ОЗУ

Вспоминаются микроконтроллеры PIC с 256 байтами ОЗУ и Си.

Шитый код компактнее и потоки существенно проще и легче чем в C.

Нити (threads)? Они есть в Forth?

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

Поэтому Си и убог. Прикол в том, что и Generics, и примитивные (но полезные) формы ADT реализуются минимальными усилиями со стороны разработчиков компиляторов. И другие вещи, которые существенно облегчили бы жизнь - тоже.

Проблема в том, что реализацией этих концепций не ограничиться. Скорее всего IMHO потребуется и сборка мусора, а это уже революция в системном программировании. Вот google сделал GO, а generics и исключений в нем нет. И все равно GO, не смотря на консерватизм, ни разу не замена C. С void* больше мишуры и проверка типов идет лесом, но при определенном опыте и внимательности приемлемо. В конце концов динамическая типизация тоже игнорирует типы.

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

Прикол в том, что и Generics, и примитивные (но полезные) формы ADT реализуются минимальными усилиями со стороны разработчиков компиляторов. И другие вещи, которые существенно облегчили бы жизнь - тоже.

Проблема в том, что реализацией этих концепций не ограничиться.

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

Скорее всего IMHO потребуется и сборка мусора

Я уже давал эту ссылку, и дам ее еще раз: http://pcwalton.github.io/blog/2013/06/02/removing-garbage-collection-from-th... - прочитай, оно того стоит.

Вот google сделал GO, а generics и исключений в нем нет. И все равно GO, не смотря на консерватизм, ни разу не замена C

Go говно. У него есть два оправдания: его разработал нытик, навсегда оставшийся в 80-х, и Go не предназначен для системного программирования.

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

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

Для большего контроля над железом, как в ассемблере. Есть любители блоху подковать.

Нити (threads)? Они есть в Forth?

В подавляющем большинстве Фортов есть.

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

Требует наличия конструктора без параметров (не всегда есть) и копирования. Простая сцылка с булом или поинтер лишены этого недостатка. А вообще, для дефолт парараметров лучше перегрузка.

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

А вот про динамическую типизацию и void* не надо. Функция: int sum(void *p, void *q) { return *(int *)p + *(int *)q; } Всегда сложит и не поперхнется все что угодно, и инт со строкой и ищи потом. А в динамике тут же ошибка.

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