Что вы хотели бы увидеть в идеальном языке программирования?

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

Так

fn f(@a @b c: &i32) —> Struct { a@a: a, b@b: b, c: c }

fn f(@a @b c: &i32)

На всякий случай. Ты же в курсе, что в ржавчине и let и аргументы в функции - это просто привязки, да?

struct Point { x: i32, y: i32 }

fn f(&Point{x: my_x, y: my_y}: &Point) {
    println!("x: {}, y: {}", my_x, my_y);
}

fn main() {
    f(&Point{x: 1, y: 0});
}

http://is.gd/lYxAr9

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

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

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

Можно подробнее?

Так лучше читается - явно видна форматная строка и аргументы.

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

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

Не спорю. Но при работе с небольшим количеством строк (чаще всего встречается) это очень уродливо

Сначала говоришь, что printf атавизм

Для простых задач — да, это атавизм

потеряются преимущества.

Нет, добавится ещё одно преимущество — красивый синтаксис.

Ну и собственно чем твои привычки лучше?

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

То выступаешь против подсветки, то наоборот ноешь про отсутствие

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

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

Потому что первая ссылка по запросу Rust — на rust-lang.org а по запросу С++ на Wikipedia.

Objective C

гугно этот ваш обжектив си

это просто привязки

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

fn f(a@Point{x: my_x, y: my_y}: &Point) { ... }
    // OR 
fn f(&Point{x: @my_x, y: @my_y}: &Point) { ... } 
    // OR
fn 2,3@f(&Point{x: my_x, y: my_y}: &Point) { ... } 
    // OR
fn my_x,my_y@f(&Point{x: my_x, y: my_y}: &Point) { ... } 

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

Это для неосиляторов сишки, в которую не могут «погроммисты» на Objective C.

Если мочь в сишку, то Objective C будет казаться приятной опцией, в отличие от блоатваре цепепе.

DISCLAIMER: ничего против Swift не имею, даже приветствую.

fn f(@a @b c: &i32) —> Struct { a@a: a, b@b: b, c: c }

не будут

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

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

Ты много «к словам» придираешься.

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

Cчитаю, что в простых случаях разница незначительна, а в сложных форматирование однозначно выигрывает. Когда просил код, то надеялся, что ты как раз покажешь более-менее сложные случаи. Обсуждать «хелло» + «тест» не слишком интересно.

Можно подробнее?

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

Но при работе с небольшим количеством строк (чаще всего встречается) это очень уродливо

Тут можно поспорить и с «очень уродливо» и с «чаще всего встречается».

Для простых задач — да, это атавизм

Нет, это демагогия.

Нет, добавится ещё одно преимущество — красивый синтаксис.

Нет, не добавится.

У меня нет привычек

Чего? У все они есть.

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

// лёгким движением руки ....

fn <'a, 'b>(x: &'a i32, y: &'b i32, z: &i32){} // ...

// превращается...
// в...

fn (@x: &i32, @y: &i32, z: &i32){} // !

Так что на смену я бы не надеялся.

Даже в 2(3|4|5|...).0 ?

Даже в 2(3|4|5|...).0 ?

Так ведь люди будут или привыкать или плеваться от языка и выбирать что-то другое. Вряд ли, наберётся достаточно активных пользователей, который сохранят «отвращение» к синтаксису.

Мне тоже кажется, что ты игнорируешь неудобные аргументы.

Та нет же. Для более-менее сложных случаев у вас есть format!(). Так будьте любезны и для простых случаев конкатенацию предоставить.

Обсуждать «хелло» + «тест» не слишком интересно.

Но об этом изначально же шла речь.

Ведь слайсы можно сравнивать со строками без дополнительных телодвижений

if "вот это" == "скомпилируется" { 
    "тогда всё ок" 
} else {
    "со строками всё печально"
}

Так будьте любезны и для простых случаев конкатенацию предоставить.

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

Максимум могут научить println! научить работать с одиночными переменными. И то уверен, что кто-нибудь был бы против.

Но об этом изначально же шла речь.

Речь шла о неудобстве форматирования. Я очень сомневаюсь, что типичный код похож на «хелло» + «тест», а значит, в реальной жизни, неудобства мало заметны.

let a = if "вот это" == "скомпилируется" { 
    "тогда всё ок" 
} else {
    "со строками всё печально"
};

Устраивает?

http://eax.me/rust/

С другой стороны, меня печалит, что приходится (1) следить за пунктуацией, расставлять запятые и точки с запытой, или (2) помнить о различиях между &str и String и постоянно расставлять to_string() и as_slice(). Возможно, это приходит с опытом. Но вообще-то говоря, мне не хотелось бы думать о таких вещах.

s-exp синтаксис для rust

Поскольку единственное что есть плохого в rust это синтаксис,

http://www.cyberforum.ru/holywars/thread1312381.html

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

https://disqus.com/home/discussion/pirx/rust_andrey_vlasovskikh/oldest/

Насчёт синтаксиса: с одной стороны радуют короткие ключевые слова — fn, ret, с другой — он всё равно выглядит как-то noisy.

http://www.gamedev.ru/flame/forum/?id=162925 мда... Mozilla Labs ну и синтаксис.

Немного о синтаксисе Rust нагуглил

http://eax.me/rust/

Видел, читал и даже оставлял своё (негативное) мнение об авторе на этом форуме. Сплошная демагогия и передёргивания разбавленные очевидными фактами. А уж когда плюсовик пишет про «необходимость всегда помнить» - это просто смешно. Так как раст тебе «напомнит», если забудешь, а в С/плюсах так выстрелить в ногу проще простого.

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

Не говорю, что это однозначно хорошо, взгляд со стороны бывает полезным. Но вот такие вот жалобы с вероятность 99% не повлияют на развитие языка. Особенно, если они оставляются на лоре или левом жж.

"a" =="a"              —> ok
"a" =="a".to_string()  —> ok
"a" + "a".to_string()  —> ok
"a" + "a"              —> error

WTF?? Конечно же не устраивает

Так как раст тебе «напомнит», если забудешь, а в С/плюсах так выстрелить в ногу проще простого.

Это ж каким идиотом нужно быть, чтобы выстрелить себе в ногу конкатенацией строки!

Как думаешь какое отношение будет?

Если разработчики заинтересованы в развитии языка, то мнение человека, чье мышление ещё не деформировалось от программирования на С\С++, должно быть им интересно.
Это пока, Rust интересен в основном только состоявшимся программистам, уже знакомым с понятиями строки, конкатенации, типа и т.д., они видят to_string() и понимают что под этим подразумевается. У них годы опыта, сейчас им лишь бы сесть и начать хреначить, и всёравно как и на чем.
А вот представь сколько ненависти будет если в таком виде этот язык в ВУЗах преподавать начнут!
Студент впервые увидев програму задает кучу вопросов: почему функция называется «main» а не «start», почему оператор сравнения это «==» а не «=», зачем разделять код на модули и т.д. И если на такие вопросы можно дать обьяснения с точки зрения рациональной логики, то с пресловутым to_string() сказать что всё упирается в code conventions, это всёравно что на вопрос ребёнка «почему небо голубое» ответить «не задавай дурацких вопросов. Так Бог сказал».
Для пришельцев из других (не системных) языков «литерал».to_string() это вообще какой-то абсурд, недоразумение.
Ты конечно не согласишься. Тебе всё норм. И плевать, что продолжать в таком же духе — это вставлять палки в колёса новичкам, ломать их психику\логику. Главное чтобы самому не переучиваться, к новому не привыкать.

Но ведь у языка своя ниша ...

Так вот, с таким подходом в лучшем случае получатся безопасные плюсы, в худшем получится ещё один D. Достаточно? А если в плюсы через какое-то время лайфтаймы и другие плюшки введут, что будет с Rust дальше? Никаких гарантий что взлетит и даже Mozilla в качестве движка Servo не обещает.
А много кто мечтает о быстрых и безопасных веб приложениях, много кто мечтает чтобы жаба на Android не тормозила, ещё мечтают о том, чтобы ентерпрайз не был настолько тяжел и неподдерживаем. Дайте только синтаксис и документацию — взлетит!
Но нет, мы не хотим действительно язык общего назначения, мы хотим ещё одни плюсы.

вот такие вот жалобы с вероятность 99% не повлияют на развитие языка. Особенно, если они оставляются на лоре или левом жж.

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

• Экосистему как в Java
• Экспортер AST как в Сlang
• Скорость компиляции, IO, green-threads как в Go
• Возможность в управлении памятью и производительность как в С++/Rust
• Возможности к быстрому формошлепству как в Delphi
• Мощность языка как в Scala
• Легкость порога вхождения и возможность написания однофайловых скриптов как в Python
• Легкость рантайма как в С
• Интегрированностью с принципами Unix, pipes/filters, работой с утилитами как в bash
• Нативную поддержку и скорость работы в браузере как в JS

Нету такого? Ну я пошел тогда кодить дальше на том говне что есть.

Конечно же не устраивает

Ты, по всей видимости, потерял контекст. Я напомню - речь шла о сравнении:

if "вот это" == "скомпилируется" { 
    "тогда всё ок" 
} else {
    "со строками всё печально"
}

Это ж каким идиотом нужно быть, чтобы выстрелить себе в ногу конкатенацией строки!

Ты вырываешь фразу из контекста.

сейчас им лишь бы сесть и начать хреначить, и всёравно как и на чем.

Нет, не всё равно. Иначе раст бы просто не появился. Продолжали бы на С/С++ писать.

А вот представь сколько ненависти будет если в таком виде этот язык в ВУЗах преподавать начнут!

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

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

Это не так. Если такой вот «студент» спросит почему функция называется «main», а не, скажем, «start», то отвечать придётся тоже «потому что так сложилось». И если это кому-то рвёт шаблоны, то может ему рановато в ВУЗе учиться?

Тем более, что в случае to_string даже какие-никакие аргументы есть. Просто они тебе не нравятся.

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

Бедненькие какие. Почти жалко стало.

Вот только те, кто от этого страдают и так на какой-нибудь питон уйдут. Если вообще программистами станут.

А если...

Да, язык может ждать забвение. Но это вообще никак не зависит от того будет ли функция называться to_string или to_String.

А вообще возьми и сделай «идеальный язык». Хотя бы на бумаге. И выложи идею в этом форуме. А потом наслаждайся комментариями. Может после этого и произойдёт переоценка ценностей.

И оно компилируется, что я и показался.

Окей. Увы, мне легче не стало

Ты вырываешь фразу из контекста.

Я говорил изначально только об одном улучшении в code conventions и о нескольких в синтаксисе.
Ты как-то пришел к выводу что нужно всё сломать и сделать небезопасным. Таков контекст?

Нет, не всё равно. Иначе раст бы просто не появился. Продолжали бы на С/С++ писать.

Так и хреначат на Rust как на плюсах и рассматривают его как убийцу плюсов.

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

Ты себе так думаешь

Если такой вот «студент» спросит почему функция называется «main», а не, скажем, «start», то отвечать придётся тоже «потому что так сложилось»

Если перевести «main function» на инглиш получится что-то вроде «главной функции». И это уже многое обьясняет.

в случае to_string даже какие-никакие аргументы есть

То что кучке олдфагов такое наименование не нравится — очень весомый аргумент?

Вот только те, кто от этого страдают и так на какой-нибудь питон уйдут.

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

от того будет ли функция называться to_string или to_String.

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

возьми и сделай «идеальный язык». Хотя бы на бумаге. И выложи идею в этом форуме.

Как приблизить Rust к идеальному языку свои идеи я уже выложил

Увы, мне легче не стало

Так ты сам не знаешь чего хочешь?

Так и хреначат на Rust как на плюсах и рассматривают его как убийцу плюсов.

И правильно делают. Убийцей того же питона расту всё равно не стать.

Если перевести «main function» на инглиш получится что-то вроде «главной функции». И это уже многое обьясняет.

Да ничего это не обьясняет. start или даже какой-нибудь begin был бы ничем не хуже. Так обьяснение будет как раз «так сложилось».

То что кучке олдфагов такое наименование не нравится — очень весомый аргумент?

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

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

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

Lol.

Как приблизить Rust к идеальному языку свои идеи я уже выложил

И они таааак популярны оказались.

start

Такая функция есть в нативных программах, её содержимое определяется реализацией, именно она вызывает main. А begin по мне - не очень подходящее название.

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

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

Так, а синтаксис placement new (PLACE_EXPR <- VALUE_EXPR) тебя устраивает? Ну, пока еще идет обсуждение и можно прискакать на белом коне и показать всем истинный путь.

Не нравится, потому что <- воспринимается как обратная ->.
Вообще, я пока толком не понял, что делает placement new, но первое впечатление: <= или <~ было бы лучше

А чем in не устраивает?

placement new создаёт объект в уже созданном буфере в памяти.

Т.е. принимает на вход указатель и перезаписывает все данные по его адресу?

Нет, конструктор вызывает.

Не нравится, потому что <- воспринимается как обратная ->.
... первое впечатление: <= или <~ было бы лучше

А <= не воспринимается как обратная =>? )

<~

Тильда, родимая. Олдово, теперь полагается <box же)

А чем in не устраивает?

Какой из? Много вариантов же было с «in».

Лично меня любой из предложенных вариантов устраивает, лишь бы когда-нибудь стабилизировали это дело. А почему народу в обсуждении не нравится, это вот, например, сюда - https://github.com/rust-lang/rfcs/pull/809.

Пиши скорей rfc и проталкивай его в массы, пока ржавчину еще можно спасти от закорючеек!11

Ок, создаёт новый «обьект» в уже выделенной памяти.
Более-менее понял, спасибо

А <= не воспринимается как обратная =>? )

Да, воспринимается, я что-то упустил этот оператор.

<box

Ещё один box? Что вообще происходит??!

Много вариантов же было с «in».

let x = 10 in HEAP
let x = 10 in map.entry(n)

Хотя и стрелками было бы неплохо, если бы их можно было в две стороны ставить, примерно так:

let z = 30 ~> map.entry(k)
map.entry(n) <~ 30

Пиши скорей rfc и проталкивай его в массы, пока ржавчину еще можно спасти от закорючеек!11

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

Да, воспринимается, я что-то упустил этот оператор.

В match`е используется. Там же есть и «@», который ты в своих прошлых предложениях использовал.

Ещё один box? Что вообще происходит??!

Просто шучу. Тильда-нотацию владеющих указателей же на боксы заменили когда-то.

Хотя и стрелками было бы неплохо, если бы их можно было в две стороны ставить

А ты еще перл ругаешь) А такая свобода выражения мысли - это скорее его философия.

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

А защищать его еще сложней, ага.

Вообще, я бы правда посмотрел на написанную тобой спецификацию «идеальной ржавчины» (в такой-то теме!), как ты ее видишь)

А begin по мне - не очень подходящее название.

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

но первое впечатление: <= или <~ было бы лучше

Чем?

<- это обратная -> а делают они совсем разные вещи. Почитай последние сообщения в треде

То ли ещё будет.

Что мешает дотозадротам шпилить в дотку и летом?