LINUX.ORG.RU

Rust 1.34

 ,


3

8

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

Ключевое-долгожданное:

  • Начиная с этого выпуска, Cargo может поддерживать альтернативные реестры. (Эти реестры сосуществуют с crates.io, так что вы можете писать программы, которые зависят и от crates.io и от вашего реестра.)
  • Трейты TryFrom и TryInto были стабилизированы для поддержки ошибок при преобразовании типов.

>>> Полный анонс



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

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

Идея, что добрый дядя модератор решит все наши проблемы утопична по сути

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

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

Так почему нельзя так же сделать расту?

Зачем это делать расту если это уже делают дяди в убунту и других дистрибутивах?

Не лучше ли просто дать им удобные инструменты?

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

раст за явные косяки сразу лупит палкой по рукам.

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

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

Динамичность ограничена циклом релизов. Это только для стабильных компонент прокатывает. Предложение от дядь модераторов хорошее, но 100% потребностей закрыть не может. Поэтому в убунте есть ppa, который регулярно выручает.

В дебиане пытаются публиковать нодовские модули. Ни разу не видел чтобы ими кто-то реально пользовался из разработчиков.

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

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

Зачем это делать расту если это уже делают дяди в убунту и других дистрибутивах?

Хмм, а что растовые либы уже можно ставить через apt, как хаскельные или перловые? По слову rust apt ни одного крейта не находит...

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

Ну пока с пакетами там вообще жидко. Язык молодой, нормальное дело. Рассосется со временем. В ноде поначалу тоже с пакетами был полный ад, со временем наладилось.

IMHO это все-таки больше особенности экосистемы любого молодого языка, а не следствие технических фич.

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

Вопрос в том, кто за это будет платить :). Никто не мешает тебе нанять модераторов или искателей пакетов, чтобы делали все лично под тебя.

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

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

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

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

Ну значит либо разработчик попотеет, либо возникнут форки. Так весь опенсорс же устроен. Просто нужно время, чтобы устаканилось. Такие процессы - более общие вещи, не особенность языка.

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

Никто не мешает тебе нанять модераторов или искателей пакетов

Да тут скорее самому форкать все нужные мне пакеты надо. Но пока я на этапе прототипирования своей фигни, как нибудь потерплю то, что есть.

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

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

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

ХЗ. В ноде вроде справляются, а там зависимостей не меньше, и язык на месте не стоит. Хаскеля не знаю, комментировать не могу.

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

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

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

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

Другое дело, что в npm нельзя задать своего ранжирования сразу. Ну дык я именно про это и написал для крейтов. Надо просто делать нормальный поиск. Ну и где-то просто подождать, пока качество пакетов наладится.

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

Как продвинутый нодоюзер

Так там не бывает конфликтов по зависимостям? В смысле когда одному нужна конкретная версия либы, а второму - конкретно другая версия той же либы?

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

А, вот ты о чем. Там дерево зависимостей, а потом одинаковые протаскиваются наверх как общие. Те что разные - остаются на месте. В общем, у каждого свои зависимости + дедупликация.

А раст так не умеет? Вроде мозиловцы с нодой хорошо знакомы.

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

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

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

Для этого уже несколько лет как есть решение. Из-за того что semversioning в отдельных случаях не хватало, фейсбуковцы написали yarn, который генерит конфиг для жествого шпилинга версий как у разработчика. Потом фичу и в npm подтянули.

В общем, я не знаю, какие там используют алгоритмы под капотом, но оно работает. Тупо в лоб дедупликацию абсолютно точно никто не делает. Как минимум с учетом версий, причем с той точностью которую захотел разработчик исходного пакета. Ну и можно совсем заморозить, если у тебя зависимостей вагон и нужны гарантии чтобы точно никто ничего не сломал.

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

А раст так не умеет?

Умеет. Можно хоть 10 разных версий одной либы использовать. И оно не даст их смешивать.

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

И эта привязка всех к cargo. Смерть руби из за своего пакетных менеджера их ничему не научила.

А что ж питон не сдох из-за своих ПМ? А перл?

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

Ты прочитай всю цепочку комментариев. Я как раз утверждал что это так, но тебе (или другому анону) это за аргумент не прокатило.

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

Почему же тогда программировать на современном C++ проще, чем на C++ двадцатилетней давности?

чукча не читатель же

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

И JS туда же. И у Java тоже была какая-то нёх с манифестами, которая сама всё тащила, а то и не одна. Тысячи их.

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

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

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

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

обычно нужно не более трех вариантов: self, &self, и &mut self

нужно поглощать копию - пусть будет явный .clone() при передаче аргументов.

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

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

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

раст еще не настолько хорош чтобы заменить божественный яваскрипт :)

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

Да у них кто-то из студентов с кодом реестра экспериментировал, и отрапортовался об успехе. Но речь была о серверной части, и меняли какой-то один модуль.

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

не знаю насчет студентов, баба, читавшая доклад, «sits on the board of directors of the Node Foundation», что бы это не значило. но звучит внушающе

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

«На постоянной основе пишет 10 человек на весь мир» - ложь, пока нет пруфов обратного.

Конечно ложь, и десяти не наберётся.

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

#define ПОСТОЯННАЯ_ОСНОВА

Основной ЯП

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

Только компилятор rust больше 100 человек разрабатывают

А ядро linux тысячи, вот только НЕ на постоянной основе.

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

Потому что ты программируешь на нём уже 20 лет? Основная проблема ЦПП как раз в том, что для получения более-менее приличного программиста даже из способного человека нужно 5-7 лет граблебоя. Причём с усложнением ЦПП, увеличением числа стандартных библиотек и уровней абстракции проблема только усугубляется, поскольку все старые варианты остаются в строю и продолжают активно использоваться предыдущими поколениями программистов, а также теми нубами, которые ещё не разгребли свои грабли.

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

Основная проблема всех подобных агиток, заготовками из которых ты пользуешься в том, что проблемы решаемые при помощи С++ в десятки, тысячи раз сложнее, нежели проблемы решаемые на любых других недоязычках. Ни на одном недоязычке не существует софта уровня С/С++.

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

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

Методичка так же не работает. У всяких растов нету никакого старого, а значит я могу сразу и сходу выносить всё старое за скобки.

Как только ты начнёшь решать задачи решаемые С/С++ - ты получишь те же проблемы на любых недоязычках. Хотя нет, ты их не получишь, ведь они попросту не могут эти задачи решать.

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

каминг-аут же один раз совершается?

Поверю тебе на слово, ты лучше знаешь. А мы с Кирком джонсоном каждый день его совершаем.

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

чё, каждый день публично признаётесь, что геи?

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

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

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

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

Потому что ты программируешь на нём уже 20 лет?

Это поэтому я теперь могу вместо:

for(my_vector::const_iterator it = cnt.begin(), it_end = cnt.end(); it != it_end; ++it) {
   ...
}
написать всего лишь:
for(const auto & v : cnt) {
   ...
}
Наверное, если бы программировал всего 5 лет, мне это магия была бы недоступна.

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

Но это просто цикл foreach обхода последовательности, генерируемой стандратным итератором, который в D или go или Python (в последних двух называется он for) давно уже есть. И тем более в функциональных языках. Он также подразумевает невозможность изменения её элементов, что логично. Это хорошо, что можно теперь так писать, но в этом ничего революционного нет. Плохо то, что по-прежнему можно писать по-старому и многие продолжат так делать.

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

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

Он также подразумевает невозможность изменения её элементов, что логично.

Не подразумевает.

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

Подводные камни C++ никуда не делись. Современный C++ не защищает, например, от вот таких граблей:

const std::string &
get_or(const std::string & key, const std::string & default_value) {
   ...;
   return default_value;
}
Но при всем при этом на современном C++ писать проще. Как раз за счет всего того, что добавили за последние 15 лет.

А вот страшилки на счет «если ты один и если новый код, а вот если старый...» еще непонятно, насколько соответствуют действительности. Дебилов, которые не могут освоить новый foreach, auto, overload или делегирующие конструкторы хватает. Но их везде хватает, может быть даже в Java таких еще больше будет. Делают ли они погоду?

ИМХО, разве что в LOR-овских срачах.

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

Переодически хочу всякие форичи и типизированые контейнеры в сях. Открываю c++. Блюю. Дизассемблю крестовую программу. Блюю ещё.

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

Я не спорил с тем, что C++ стал сложнее. Речь о том, что не смотря на возрастающую сложность, использование C++ оказывается все проще и проще. Поэтому тезис о том, что увеличивающаяся сложность похоронит C++ является спорным, по меньшей мере.

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