А, про concat забыл. Вдруг format! не хочется трогать?

fn main() {
    let s1 = "s1";
    let s2 = "s2";
    let s3 = "s3";
    let s = [s1, " ", s2, " ", s3].concat();
    println!("s = {}", s);
}

Но s тут все равно будет String.

что-то чуть более высокоуровневое, чем C, но не такое толстое, как C++

Да, комплимент для Nim по поводу красивого кода :)
О строках и работе с ними: 2 типа строк это по любому преобразования, шаманизм с бубном. В Java это тоже есть, правда за кулисами, там ведь тоже строки иммутабельные, и "adfasdf" + "asdfasd" + "aaaaaaaaaz" создаёт временный StringBuffer.
Ну а здесь, почему бы не подставить где нужно to_string() на этапе компиляции? Зачем использовать атавизмы с 60-х годов в виде format!() concat!() printf() и проч. если язык, по своей сути рождён, чтоб заменить всю эту муть?
Неужели кому-то действительно нравится вместо

print!(«asdfasdfas»+«asdfasdfasdfa»)

писать

printf!(«{}{*&2q3}{0o}{0)))}», «adsfadsfas», asdfasd, 123, «asdfasa»)?

Или системный язык обязательно должен быть таким сложным и мозговыносящим?

#[allow(non_snake_case)], само собой, есть. Для ffi, например, используется.

Вот за это спасибо. Я то уже расстроился был.
Если бы ещё в to_string() и аналогичных функциях это использовали...

Это же не просто массив символов, это именно строка, потому что дает кое-какие гарантии насчет содержимого.

Но ведь «вектор символов» обещает, что внутри будут только символы, какие ещё гарантии нужны?)
Хотя я уже прочитал, что char в Rust это слегка не то...
Но почему не StrBuf | StrVec ?

ответ непрограммиста

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

Важными чертами я считаю наличие строгой типизации и возможность запросто создавать GUI.

А если уж совсем идеализировать, хотелось бы, чтобы ЯП был чем-то вроде удобных, понятных «кирпичиков» для построения своего ПО на основе уже банальных алгоритмов (скачивание файлов, листинг директории, создание GUI-виджета).

тебе нужен visual basic :)

Lazarus тоже неплохая штука, только вот вероятность того, что получившимся приложением будет пользоваться кто-то, кроме меня, с такими чудищами ещё ближе к нулю :)

Кстати, чисто из интереса, кто-нибудь тут пускал под Mono приложения на VB.NET? Как оно?

... Ну а здесь, почему бы не подставить где нужно to_string() на этапе компиляции? ...

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

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

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

А to_string или аналог это всегда выделение памяти на куче.

printf!(«{}{*&2q3}{0o}{0)))}», «adsfadsfas», asdfasd, 123, «asdfasa»)?

Это претенция именно к методу печати? Там же просто {} в форматной строке обычно нужен, не драматизируй))

Зачем использовать атавизмы с 60-х годов в виде format!() concat!() printf() и проч. если язык, по своей сути рождён, чтоб заменить всю эту муть?

Так, concat - это просто функция склейки, он вечен и устареть не может. А форматный вывод в ржавчине я нахожу чертовски удобным, почему это он атавизм? )

Вроде как, дивиз ржавчины «Rust is a systems programming language that runs blazingly fast, prevents nearly all segfaults, and guarantees thread safety» - я тут ничего про удобную работу со строками не вижу))

Или системный язык обязательно должен быть таким сложным и мозговыносящим?

В каком-то смысле, да) Это унаследованная сложность предметной области. Хотя прям «мозговыносящего», повторюсь, я в ржавчине ничего не вижу. После плюсов так и вообще все просто))

И документации хорошей теперь завались. Полтора года назад все это дело изучать было сильно сложнее))

Если бы ещё в to_string() и аналогичных функциях это использовали...

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

Но почему не StrBuf | StrVec ?

Вот какое-то обсуждение по этому поводу - https://github.com/rust-lang/rfcs/pull/60.

Там долгая история с этой многострадальной владеющей строкой) Раньше оно StrBuf`ом называлось, да. А до этого, когда были динозавры и владение обозначалось тильдой, это был ~str (что выглядело логичным дополнением к &str и @str).

Эх, когда вижу код, который активно работает с box`ами, иногда скучаю по ~-нотации.

явно просишь об обратном

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

А to_string или аналог это всегда выделение памяти на куче.

Она и так выделяется, только мне нужно писать больше кода для этого.

Это претенция именно к методу печати?

Да и к нему тоже. Между прочим, понять, что создаётся временный буфер гораздо проще, чем понять что создают вот эти вот {}{:?}{1} крякозябры. Как оно может быть удобнее, если и кода больше, и учить сложнее, и наверняка найти соответствующий placeholder в строке и заменить его на строку из аргумента операция более дорогостоящая, чем просто две строки склеить.

А форматный вывод в ржавчине я нахожу чертовски удобным

Первая вещь от которой я расстроился при изучении Rust.
В чем профит, по сравнению с «склеить —> распечатать»?

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

Да, но мы как-бы о идеальном языке говорим, а не о Rust.

прям «мозговыносящего», повторюсь, я в ржавчине ничего не вижу
После плюсов

После плюсов...

Аналогичных не так и много в стандартной библиотеке, вроде.

Тем более. Читаемость повысит очень сильно.
Особенно учитвыая то, что в Rust два типа строк, я хотя-бы буду знать какой из них возвращается.

Раньше оно StrBuf`ом называлось, да. А до этого, когда были динозавры и владение обозначалось тильдой, это был ~str (что выглядело логичным дополнением к &str и @str).

Я сначала подумал, что это троллинг такой...

иногда скучаю по ~-нотации.

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

Накатал такой вот псевдокод:

impl Add for &str {
    type Output = String;

    fn add(self, _rhs: &str) -> String {
        String::from(concat!(self, _rhs))
    }
}

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

Написать в доках не сложно. И дописать Add для &str в стандартную библиотеку не сложно.

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

А необходимость явно приводить числовые типы тебя не смущает? Или, например, требование объявления или типа, или трейта в одном крейте для реализации одного для другого? Да или просто необходимость указывать явный mut? Таких моментов, с синтаксической солью или подобным в языке много же.

Выход из ситуации есть, я верю.

«Ситуации» никакой нет, просто у языка такая философия-с. Или она тебя устраивает/привыкаешь/проникаешься, или язык тебе не подходит и кроме страданий ничего не принесет.

А to_string или аналог это всегда выделение памяти на куче.

Она и так выделяется, только мне нужно писать больше кода для этого.

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

понять что создают вот эти вот {}{:?}{1} крякозябры

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

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

Первая вещь от которой я расстроился при изучении Rust.
В чем профит, по сравнению с «склеить —> распечатать»?

У тебя printf-фобия? Чего расстраиваться-то? :)

В рамках дизайна ржавчины, с явным конвертированеим строк, удобство format!/print!/println!, думаю, очевидно.

Если бы в ржавчине были более дружелюбные строки, то да, метод «склеить-распечатать» не был бы хуже\лучше форматной печати в большинстве случаев и выбор между ними был бы чистой вкусовщиной.

На всякий отмечу, что местный format! на порядок удобней сишного printf, само собой, за счет использования трейтов.

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

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

Да и по сравнению с выделением памяти, проход по строчке адекватного размера - сравнительно дешевая операция.

Да, но мы как-бы о идеальном языке говорим, а не о Rust.

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

После плюсов...

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

Читаемость повысит очень сильно.

Ну хз. Мне было бы интересно увидеть комменты к такому RFC. Особенно голосование)

Я сначала подумал, что это троллинг такой...

Синтаксис безумно выглядит? Я не часто «троллю») Ржавчина сильно менялась за время разработки. Если я правильно понял вектор твоей мысли, то изначально она она была ближе к идеальному для тебя языку.

Это за последний год-два из нее выпилили часть синтаксического сахара и впилили порядочно синтаксической соли, что бы форсить определенные подходы к написанию кода.

иногда скучаю по ~-нотации.

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

Я тут, если что, не про строки говорил. Тильда-нотация ничем не помогала с преобразованиями строк - вместо to_string был to_owned/into_owned.

https://doc.rust-lang.org/0.9/std/str/trait.Str.html

Это я про замену ~... на Box<...> писал.

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

Я-то по прежнему считаю, что все со ржавыми строчками норм, а тебе просто хочется язык, в дизайне которого не будет пункта про явность дорогих\опасных операций. Я не вижу в таком языке без этого правила и GC особого смысла, тогда и правда можно использовать D/Nim/т.п. и просто внимательно следить, что бы в критических местах GC не портил жизнь.

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

Масштабно вышло. О.о Наверное, мне стоит завязывать с длинными ответами.

у языка подход другой

ССЗБ называется.
С другой синтаксической солью не стыкался, кроме «let mut». Но с этим то вполне можно жить, хотя-бы смысл такого решения понятен.

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

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

Да обычный printf-подобный синтаксис, чего там понимать?

Например, я не понимаю, зачем так мучаться.

какой вообще смысл в параметрах с цифрами. Которые {2}.

Вот, примерно то же чувство, только относительно всех строк.

У тебя printf-фобия? Чего расстраиваться-то? :)

Неудобноооооооооо

удобство format!/print!/println!, думаю, очевидно.

Для меня — нет. Это нормальные строки не заменит.

местный format! на порядок удобней сишного printf

Здесь стоит упомянуть Эскобара.

Может и большой постоянный буффер просто держать.

Можно и синглтоном каким-то в Add для &'static str пользоваться.

Да и по сравнению с выделением памяти, проход по строчке адекватного размера - сравнительно дешевая операция.

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

ржавчина ж замена плюсам

Как по мне, лучше плюсов; но не замена.

Мне было бы интересно увидеть комменты к такому RFC. Особенно голосование)

Мне тоже
Но RFC ещё написать надо. На инглише. И перед этим посоветоваться с людьми, более опытными (что я собственно и делаю).

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

Нет. Не люблю всякие формальности в коде.

Это за последний год-два из нее выпилили часть синтаксического сахара и впилили порядочно синтаксической соли, что бы форсить определенные подходы к написанию кода.

Может в будущем станет идеальным языком.

тебе просто хочется язык, в дизайне которого не будет пункта про явность дорогих\опасных операций

Мне просто хочется язык, код на котором было бы легко, приятно читать и писать. В этом плане Rust как PHP, в остальном же, он великолепен.

Например, я не понимаю, зачем так мучаться.

Честно слово, я не мучаюсь) Пишу

let a = format!("id: {}, val: {};", id, val);

вместо

let a = "id: " + id + ", val: " + val + ";";

и не задумываюсь об этом.

Ладно, ладно, надоело)) Я понял твою точку зрения про строки и форматный вывод, хз чего по этому поводу еще добавить.

ССЗБ называется.

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

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

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

Когда владеющую строку строку было просто написать - ~"abc" (вместо "abs".to_string и аналогов), очень много людей использовали владеющие строки там, где это было совершенно лишним. После того, как убрали тильду, логически код многих проектов стал реально чище.

Может в будущем станет идеальным языком.

А может сдохнет через год вместе с серво и мозилой. Посмотрим.

Нет. Не люблю всякие формальности в коде.

В ранней ржавчине было больше формальностей чем в современной? В смысле?

но не замена.

Раскрой мысль)

Но RFC ещё написать надо.

Если серьезно, то же понимаешь, что rfc о переименовании to_string точно завернут, потому что это нарушит обратную соместимость, да? До rust 2.0, по крайней мере)

И перед этим посоветоваться с людьми, более опытными (что я собственно и делаю).

Хз насколько это ко мне относится)

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

Можешь тут - https://gitter.im/dev-ua/rust - народ помучать, иногда бывают живые люди.

Или тут - https://groups.google.com/forum/#!categories/rust-russian/qa - там есть Владимир Матвеев, он умный))

let a = format!("id: {}, val: {};", id, val);

вместо

let a = "id: " + id + ", val: " + val + ";";

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

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

В элегантном коде ошибки искать и исправлять легче.

В ранней ржавчине было больше формальностей чем в современной? В смысле?

Больше соли —> больше вариантов, нужно больше следить за тем, чтоб писать правильно.

Раскрой мысль)

• Не готов.
• О готовности людей переходить на Rust я писал выше.
• Документации, книг (чтоб всё было понятно и можно было с нуля учить) — нет.
• Известных и даже новых общих паттернов — нет.
• Местами неудобный, нелогичный.
• Заточеный только под одну область применения.
• || может сдохнуть через год вместе с серво и мозилой.

Если серьезно, то же понимаешь, что rfc о переименовании to_string точно завернут, потому что это нарушит обратную соместимость, да? До rust 2.0, по крайней мере)

Да, понимаю. Но если введут после 2.0 — почему бы и нет?
Вообще, RFC это очень серьёзное задание для меня. Сейчас точно не справлюсь.

Относится)

За ссылки спасибо.

В элегантном коде ошибки искать и исправлять легче.

Боюсь, тут не помешало бы масштабное полноценное исследование) Да и то, к результатам всегда можно будет придраться. Это каждый решает для себя на основании своего опыта. У меня вот было много негативного опыта с внешне элегантным кодом.

В ранней ржавчине было больше формальностей чем в современной? В смысле?

Больше соли —> больше вариантов, нужно больше следить за тем, чтоб писать правильно.

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

... Больше соли —> больше вариантов ...

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

Раскрой мысль) ...

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

доки

Руби Клабник, Ганкаро и еще пачка энтузиастов, думаю, скоро наплодят порядочно приличной документации. После выхода 1.0 они заметно активизировались.

Местами неудобный, нелогичный.

Неудобность - это субъективно. Одному неудобно одно, другому другое. А вот логика - она есть фактически за каждым решением, другой вопрос что ты можешь быть с ней не согласен. «Так-сложилось-исторически» в языке практически нет (пока что).

Черт, мне жутко интересно, когда выйдет версия 2.0 (лет три-пять?) и насколько серьезно в ней решатся ломать совместимость, по итогам полученного опыта.

Заточеный только под одну область применения.

В смысле? В этом пункте есть какие-то отличия от плюсов?

У меня вот было много негативного опыта с внешне элегантным кодом.

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

варианты чего?

Варианты написания кода. Если можно сделать и так ~str и так «aaa».to_string() и ещё как-то — не к добру это.

большая часть претензий - это указание на детские болезни еще не зрелого языка

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

Неудобность - это субъективно

Дело привычки.
Вот людям, которые привыкли к системным языкам — будет удобно, а тем, кто никогда не программировал — нет.
Вот даже те самые строки; почитал сейчас документацию по С++ — всё логично, всё понятно, всё просто! Даже текст не надо читать, всё понятно по примерам. В Rust не понятно ничего, сразу же возникают вопросы, на которые ответы найти совсем не просто.

Rust has two main types of strings: &str and String. Let’s talk about &str first. These are called ‘string slices’. String literals are of the type &'static str:'

мне жутко интересно, когда выйдет версия 2.0

Мне кажется что скоро. Вроде запланировали каждые 6 недель выпускать альфа (или бета) релиз. Чувствую, что в 2.0 или в 3.0 повторится история как с питоном — совсем новый язык выйдет. Ну, посмотрим )

есть какие-то отличия от плюсов?

Да. Плюсы — язык общего назначения, Rust — системный. Rust скорее замена для C, чем для плюсов.

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

Зачем?

Гибкость это уменьшает.

Но везде это вызовет фатальную ошибку.

Да ладно?

х / 0.

Ты серьёзно считаешь что у программистов с++ нет никаких профзаболеваний и зарплату им платят за удовольствие погромировать на хорошем языке?

Слишком толсто. Программисты на С++ в этом плане ничем не отличаются от остальных.

Может и не самый лучший пример, но вот Java пошла примерно таким путём и пришла к успеху.

Джава пошла совсем другим путём.

Есть у меня идея, предложить сделать вот так:

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

И ещё вот так:

Второй пример не понял.

Развитую невелосипедную библиотеку. Ни у одного ЯП такого нет, увы. А вообще, С ближе всех к идеалу.

C# или nemerle

Слишком толсто. Программисты на С++ в этом плане ничем не отличаются от остальных.

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

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

И что языки программирования в этом плане сильно различаются? Какие-то аргументы будут?

Нет, так как в Java я создал строку и сразу работаю с ней

Так в твоём примере ты создал иммутабельную строку в расте - сильно с ней не наработаешь. А для слайсов методов тоже достаточно.

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

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

Ребята, ну где же ваше воображение? Зачем вы мечтаете о языке программирования, когда давно уже следует мечтать о специализированном ИИ, который будет всё писать за вас. Хватит ползать, учитесь летать.

И что языки программирования в этом плане сильно различаются? Какие-то аргументы будут?

Плюсы выедают мозг.

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

Что за наркомания? Легко печатаются оба вида строк:

let a = "test".to_string();
println!("{}, {}", "hello", a);

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

Сравниваются строки тоже без всяких проблем:

let a = "test".to_string();
if a == "test" {...}
    
let b = "eee";
if a == b {...}

Ограничение вроде «нельзя использовать» тоже плохо.

На самом деле можно и предупреждение отключить тоже можно.

А String надо переименовать в CharVec

Это именно строка с набором дополнительных методов. По шее надо давать тем, кто не разобрался, а советовать лезет.

Плюсы выедают мозг.

Разве что хейтерам.

Зачем использовать атавизмы с 60-х годов в виде format!() concat!() printf() и проч. если язык, по своей сути рождён, чтоб заменить всю эту муть?

А ничего, что аналог format! есть и в относительно современном C#?

Неужели кому-то действительно нравится вместо

Передёргиваешь в примере. Ну и да, второй вариант удобнее и имеет больше возможностей для форматирования.

В чем профит, по сравнению с «склеить —> распечатать»?

Как минимум, можно форматировать всякие числа. Как ты это через склейку делать собираешься?

Но на кой черт менять порядок аргументов?

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

С другой синтаксической солью не стыкался, кроме «let mut».

Мега правильное решение, как по мне.

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

Любой С++ джуниор скажет, что память надо освобождать, висячие указатели - это плохо и т.д. Тем не менее, ошибки они будут допускать. Да и не только джуниоры. Потому что код может быть написан сильно по разному, рефакториться разными людьми и т.д.

Вот людям, которые привыкли к системным языкам — будет удобно, а тем, кто никогда не программировал — нет.

Дык, если сделать удобно для тех, кто «никогда не программировал», то «привыкшим к системным язык» (основная целевая аудитория, если что) станет неудобно. Может пусть лучше первые возьмут что-то попроще (как минимум, для начала)?

Плюсы — язык общего назначения, Rust — системный.

Нет.

Плюсы выедают мозг.

Разве что хейтерам.

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

На запятых много не сэкономишь

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

Второй пример не понял.

вместо
fn a(a: B) —> C { C{ a: a } }
пишешь
fn a(a: B) —> C { a: a }
только в функциях без логики, которые всего-лишь что-то возвращают

let a = "test".to_string();
println!("{}, {}", "hello", a);

А хотелось бы так:

println!("hello " + "test");

let a = "test".to_string();
if a == "test" {...}
    
let b = "eee";
if a == b {...}

let (a, b) = ("a", "b");
if a == b { 
    println!(a + " = " + b); 
}

да хватит уже

А ничего, что аналог format! есть и в относительно современном C#?

А ничего, потому что используют его только в случаях когда это необходимо, а не везде

Самое главное здесь — не нужно указывать тип по несколько раз —> больше места на лайфтаймы и проч.

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

Лайфтамы, опять же, будут наоборот мешать такой «оптимизации»:

fn f(a b c: &i32) -> ...

только в функциях без логики, которые всего-лишь что-то возвращают

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

Как минимум, можно форматировать всякие числа

Ну это я упустил, да

println!("hello " + "test");

А мне хотелось бы так (и, внезапно, так можно):

println!("hello test");

let (a, b) = ("a", "b");
if a == b { ... }

Мы же про сравнение строк говорили? Ну оно и работает.

println!(a + " = " + b); 

Фу.

println!("{} = {}", a, b);

Причём чем больше и хитрее вывод, тем это заметнее.

А ничего, потому что используют его только в случаях когда это необходимо, а не везде

Хватит изворачиваться. Сначала говоришь, что printf атавизм. Потом оказывается, что он всё-таки нужен.

И я довольно редко видел форматирование через сложение. Так что это, опять же, субьективно.

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

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

Плюсы — язык общего назначения, Rust — системный.

Нет.

Rust is a systems programming language that runs blazingly fast, prevents nearly all segfaults, and guarantees thread safety.
C++ (pronounced as cee plus plus, /ˈsiː plʌs plʌs/) is a general-purpose programming language.

Им станет непривычно, потому что придётся писать не так как они привыкли.

Если потакать всем твоим хотелкам, то станет не просто непривычно, а именно плохо - потеряются преимущества.

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

А дальше вообще сплошное передёргивание. То выступаешь против подсветки, то наоборот ноешь про отсутствие. А уж пассаж про «компилятор будет решать» в отношении раста просто смешон - там на компилятор как раз много всего возлагается.

C++ (pronounced as cee plus plus, /ˈsiː plʌs plʌs/) is a general-purpose programming language.

Прикольно, про С++ цитата из википедии. Почему про раст не оттуда?

Rust is a general-purpose, multi-paradigm, compiled programming language...

что-то чуть более высокоуровневое, чем C, но не такое толстое, как C++

Objective C

Objective C

...all the memory safety of C combined with all the blazing speed of Smalltalk.

Почему бы тогда уж не новомодный Swift?