Вышел Rust 1.3

Чем порядковый номер не идентификатор? Его ведь не нужно указывать — сигнатуры будут меньше замусорены всякими крякозябрами.

Так можно и имена параметров повыкидывать, а что - номер-то есть. Но это неудобно. И если функция возвращает нечто с «лайфтаймом номер 5», то это «очень удобно» подсчитывать параметры.

Предполагает знакомство с Си++, Ocaml, Cyclone, даже Occam.

Мне кажется, что ты «немного» преувеличиваешь

Разве что немного.

Скажем, Ocaml, Cyclone и Occam я в глаза не видел

Что, ничего ML-подобного не видел? O_O И да, конечно, можно освоить язык по мануалам - но для этого нужно иметь желание пользоваться чем-то получше Си/Си++. А это желание должно было привести тебя... к {Ocaml,Haskell} и Cyclone.

Что же, баттхерт от синтаксиса не только у меня. Good, good.

Даже состоящие из слов конструкции не всегда легко гуглятся.

Относительно легко. Я так Java примерно за неделю выучил, даже код писать смог — далеко не идеально, но зато можно было учиться на реальных примерах и можно было понимать чужой код.
А вот Haskell так не поучишь, проверено. Даже symbolhound не находил некоторые конструкции — сначала нужно прочитать документацию, книги, затем уже чужой код. И эта литература не так то просто даётся: вот читая справочник по Java, я уже знал с чем имею дело, осталось только знания в порядок привести. А здесь просто абстрактная теория, несколько примеров и делай с этим что хочешь. Сложно

А вот это уже передёргивание.

Никак нет. Документация рассчитана на более продвинутых программистов, там уже предполагается что человек знаком с указателями, макросами, format() | print(), i32 | u64 …, стандартной библиотекой C++ и ещё много с чем. С нуля выучить этот язык просто нереально

Ок, замени на «нечитаемые моменты».

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

Совсем недавно видел как кто-то жаловался на list comprehension в питоне. Мол сложные условия коряво выглядят.

Ну так не пиши слишком сложных условий, никто не заставляет же.

Но всё-таки: ты думаешь, что твои аргументы сильно лучше? Ведь их тоже можно назвать апелляцией к привычкам.

Ничуть не лучше.

Скажем, у меня не возникает проблем с «= 0» против «abstract».

Без final и override оно очень хрупкое, семантически убогое. Вот и попробуй расширь птичью нотацию «=0» на ещё два термина. Дорога в перл.

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

Ссылка интересная, почитаю потом. Спасибо

в D оно отключается

Вместе с остатками батареек, да?

Имена аргументов всё-же важнее чем лайфтаймы, или нет?
Вообще, это был пример с нумерацией, основная же идея — избавиться от &'b <'a, Trait+'a> и тому подобного в сигнатурах.
В таком вот виде оно смотрится ну прям очень уродливо

Да, у языка ещё очень много животрепещущих моментов помимо синтаксиса. Вот пример свежий: https://internals.rust-lang.org/t/implicit-close-for-i-o-objects-revisited/2664

А это желание должно было привести тебя... к {Ocaml,Haskell} и Cyclone.

А что делать тем, кого желание привело прямо к Rust?

Думаю, нам всем нужно держаться вместе

А что делать тем, кого желание привело прямо к Rust?

Перестать задвигать гениальные идеи и начать учиться. В /r/rust и на rust-lang.org достаточно материала.

Другое дело, что если у тебя нет бэкграунда, помогающего изучать Rust - скорее всего, Rust тебе тупо не нужен.

Другое дело, что если у тебя нет бэкграунда, помогающего изучать Rust - скорее всего, Rust тебе тупо не нужен.

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

Перестать задвигать гениальные идеи и начать учиться.

Так я и учусь. Эти «гениальные идеи» как раз таки появились в процессе чтения о лайфтаймах на rust-lang.org.

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

Я сам решаю, что мне нужно, а что нет

Другое дело, что если у тебя нет бэкграунда, помогающего изучать Rust - скорее всего, Rust тебе тупо не нужен.

С таким илитарным подходом не победить.

С каким «таким»? В /r/rust не надо сдавать экзамены - приходишь и учишься.

Rust должен преподаваться если не в школе, то на первом курсе института: как раз там, где сейчас преподают Си.

Ты покорил новую вершину бессмысленного троллинга.

Я сам решаю, что мне нужно, а что нет

Конечно. А я сам решаю, что мне говорить, а что нет.

С таким илитарным подходом не победить.

С каким «таким»?

С подходом, где наличие «бэкграунда» является критерием нужности Rust тому или иному специалисту.

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

В /r/rust не надо сдавать экзамены - приходишь и учишься.

Заглянул в /r/rust... Ты так тролишь или на самом деле считаешь, что это хороший способ изучения языка?

С подходом, где наличие «бэкграунда» является критерием нужности Rust тому или иному специалисту.

Если ты сейчас не пишешь на Си или Си++ - тебе не нужен Rust. Всё просто.

И критерием нужности языка для людей является вовсе не собственный бэкграунд, а наличие вакансий на hh.ru

Твой мозг уже закончил перерождение в жыр?

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

Ссылка, за которую ты благодарил («Learning Rust with too many linked lists») была несколько дней назад в /r/rust. И еще много полезного материала - тоже. Следует ли считать троллингом перегрузку полезной информацией - решай сам, ты же любишь решать сам.

Если ты сейчас не пишешь на Си или Си++ - тебе не нужен Rust. Всё просто.

Я сейчас нанимаю людей, которые хорошо знают C++. И на работе Rust мне не понадобится до тех пор, пока кадровые агенства не смогут десятками присылать мне профессионалов, претендующих на твердое знание Rust. В случае C++, такие профессионалы вырастают из бывших студней, проработав у кого-нибудь 3-5 лет за относительно скромные зарплаты. А в случае Rust откуда, по-твоему, эти профессионалы должны наводнить рынок труда?

А в случае Rust откуда, по-твоему, эти профессионалы должны наводнить рынок труда?

Оттуда же, откуда брались профессионалы Си++ 30 лет назад.

Однако страуструп настаивает на том, что С++ можно изучать как первый ЯП. Никакого бэкграунда не нужно, но в случае новичка нужен преподаватель. Мне кажется, что для становления С++ (как и для становления любого другого языка-победителя) это был критически важный момент.

Однако страуструп настаивает на том, что С++ можно изучать как первый ЯП

Ты спросил откуда - я ответил. Мнение Стауструпа в данном случае мне безразлично.

Пхахаха, я уже представляю, как препод советует студентам изучать Rust по тредам в Reddit. Гениально!
Для изучения мне нужна документация написаная для людей и синтаксис с которым будет приятно работать.
А где почитать что-то интересненькое я и сам могу найти

Пхахаха, я уже представляю, как препод советует студентам изучать Rust по тредам в Reddit

Я тебе не преподаватель. К твоему счастью.

избавиться от &'b <'a, Trait+'a> и тому подобного в сигнатурах. В таком вот виде оно смотрится ну прям очень уродливо

Уродливо смотрится в первую очередь из-за отсутствия подсветки синтаксиса. Так если лайфтаймы сделать блеклыми, то увидим обычный плюсовый код

&.. Box<Trait . ..>

Получим что-то вроде вот этого:
&'a Box<'a, Trait+'a>
Как по мне только хуже, разнообразие символов дополняет разнообразие цветов, сложно сконцентрироваться. А если снизу ещё будет ихний костыль в виде where — вообще адъ.
Опираться на подсветку синтаксиса как по мне плохо

А лайфтаймы - разве бесполезная информация? Чего их блеклыми-то делать?

Уродливо смотрится, потому что &'x Box<Trait+'x> - уродливый искусственный код. Блин, это же ссылка с явным лайфтаймом на владеющую ссылку на трейт с явным лайфтаймом - это совсем не среднестатистический код.

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

уродливый искусственный код

Автоматический вывод лайфтамов на сегодняшний день весьма слаб, если не сказать убог. Я имею ввиду последние два из the three rules of lifetime elision . Явное указание указание лайфтамов в прикладном коде неизбежно будет встречаться.

Ну в 2.0 по любому всё должны сломать, если так рано 1.0 выпустили.

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

А нормальные строки, нормальные bindings в match, нормальная запись лайфтаймов

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

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

На всякий случай - мне далеко не всё в языке нравится, но вот эти жалобы они вообще бестолковые.

Что, ничего ML-подобного не видел? O_O И да, конечно, можно освоить язык по мануалам - но для этого нужно иметь желание пользоваться чем-то получше Си/Си++. А это желание должно было привести тебя... к {Ocaml,Haskell} и Cyclone.

Ну Haskell «видел» и «изучал», если это считается. Но к нему меня привело любопытство, а не желание заменить С++.

Относительно легко.

Это зависит от самих конструкций. Я только хотел сказать, что проблемы можно с обоими вариантами получить.

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

Реально.

Документация рассчитана на более продвинутых программистов

На то она и документация. Или ты хотел чтобы в описании каждой функции были все-все необходимые знания?

Ну так не пиши слишком сложных условий, никто не заставляет же.

Это весьма так себе аргумент. На расте ведь тоже писать по разному можно. Наверняка, ты сможешь переписать «более красиво», пусть и жертвуя производительностью.

Вот и попробуй расширь птичью нотацию «=0» на ещё два термина.

Тут, пожалуй, соглашусь. Но есть места, где «птичья нотация» вполне уместна. Например, лямбды: [&], [=] вполне нормально смотрятся и легко читаются. И расширение ключевым словом тоже не особо выбивается из этого ряда.

С# довольно таки лёгкий язык, в универе проходил.

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

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

Тогда «за вечер» для C# нереально. Взять даже самое банальное - StringBuilder. Если не прочитать или не знать, то на грабли наверняка наступишь.

Опять же, тонкие моменты вполне имеются.

основная же идея — избавиться от &'b <'a, Trait+'a> и тому подобного в сигнатурах.

Дык, оно там нужно. Если ты заменишь «а» индексом, то что изменится?

Вот пример свежий: https://internals.rust-lang.org/t/implicit-close-for-i-o-objects-revisited/2664

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

Или в чём ты проблему видишь?

Опираться на подсветку синтаксиса как по мне плохо

Инструметы становятся всё более важными, как мне кажется. Мало кто сейчас пишет код в блокноте без подсветки синтаксиса и автодополнения.

Кстати, where мне тоже не нравится, но только тем, что это, в некоторой степени, дублирование.

Вот свежая тема с грязными фантазиями обитателей /r/rust насчет синтаксиса

Почему рядом нет rust кода для сравнения?

Или в чём ты проблему видишь?

Вот в этом: «This makes error-ignorant usage the most convenient to write.»

Нужен API, который compile-time *принуждал* бы проверять результат close. Без этого люди пишут говнокод, который ломает персистентные данные при исчерпании места на диске.

Я не уверен, что это не потребует поддержки на уровне языка.

Почему рядом нет rust кода для сравнения?

Держи: https://www.rust-lang.org/

Ну так в современном С++ (впрочем, и в С) появилось много всякого нового чего в паскале нет.

Есть диалекты Pascal/ObjectPascal. Видел тот же fpc, например? Гораздо больше чем в Си - точно. А в сравнении с С++ не возьмусь точно сказать но увидь то что очевидно: в языке, в котором сразу синтаксис стал во главу, новые фичи не помешали ясности и очевидности кода. А в языке, где этого не было - звиздец лишь усугубился.

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

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

Я не уверен, что это не потребует поддержки на уровне языка.

Мне почему-то кажется, что без этого никак. Ну и тебя не смущает, что с нехваткой памяти такая же фигня? А ведь её «всего-лишь» сложнее обработать, а проблема такая же.

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

Видел тот же fpc, например? Гораздо больше чем в Си - точно.

Всё-таки в С многое умышленно не тянут. Скажем, ООП никто туда впихивать не пытается. Да и в целом язык не так активно развивают.

Хотя fpc я близко не смотрел, так что спорить не буду. Хотя мне кажется, что фич там поменьше, чем в С++.

Ну и тебя не смущает, что с нехваткой памяти такая же фигня?

Не смущает. Мне кажется, что исчерпание диска, исчерпание оперативки, и исчерпание адресного пространства — это три абсолютные не похожие друг на друга ситуации:

• Исчерпание диска — это зачастую вина других программ, и хорошая программа должна красиво эту ситуацию обрабатывать, без внезапных падений и без порчи собственных надисковых данных;
• Исчерпание оперативки по чужой вине — хорошие программы обычно о нем и не узнают, поскольку oom killer своевременно ликвидирует виновника и освобождает оперативку;
• Исчерпание собственного адресного пространства или исчерпание оперативки по собственной вине — обычно чрезвычайно трудно адекватно обработать, и типичный способ обработки — это просто издохнуть. Если возникновение таких ситуаций предполагается [что само по себе чрезвычайно странно и плохо пахнет], то «высокорисковый» код исполняют в отдельном процессе ОС.

s/три абсолютные не похожие/три абсолютно не похожие/

и тебя не смущает, что с нехваткой памяти такая же фигня?

С нехваткой памяти другая фигня - ее освобождение не потребует тайм-аута TIME_WAIT2.

мне достаточно, что он хотя бы некоторые вещи делает более безопасными, чем С/С++

Насколько я понимаю, в Си++ ровно такая же проблема.

В 2.0 много ломающих изменений будет, это же очевидно, кэп.
Со строками, хуже всего это to_string. Ну хоть бы to_String написали что-ли... Форматированый вывод, {}, конкатенация и т.д. выглядит некрасиво —> Iron, Nickel и другие веб-фреймворки тоже —> язык не станет популярным в Веб. А мог бы.
Мой ужас с индексами это только пример. А ведь никто так и не сказал толком, зачем лайфтаймам отдельные имена.
Вот есть функция (из Servo):

fn make_shaper<'a>(&'a mut self, options: &ShapingOptions) -> &'a Shaper { ... } 

fn make_shaper(&mut self, options: &ShapingOptions) -> self@Shaper { ... } 

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

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