В Rust хотят заменить &mut на &uniq и убрать константность по умолчанию

LOR default opinion.

Упоротая мотивация. Иммутабельность из коробки прекрасно соседствует с многопоточностью. Если это убрать, то чуваки рискуют огрести геморроя по-крупному.

Иммутабельность из коробки прекрасно соседствует с многопоточностью.

С этим, вроде, никто не спорит.

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

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

Я хоть и пишу на С++, в основном, и в расте не всё нравится, но по моему, идея дурацкая. Иммутабельность по умолчанию, действительно удобно.

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

Я имел ввиду уже существующий код.

Небольшую часть поста, в которой говорится про &uniq ты пропустил?

Он рассуждает с точки зрения компилятора, а программы пишутся для людей. И предпочтения альтернатив у него откровенно странные - «I definitely prefer #1. It’s the simplest, and right now I am most concerned with how we can simplify Rust while retaining its character. Failing that, I think I prefer what we have right now».

Я имел ввиду уже существующий код.

Разве в существующем коде на Ржавчине чего-то сломается, если в нем изменить «mut» на «only»? Можешь пояснить свою мысль?

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

Почему? Мне кажется наоборот. «&mut» сейчас не единая концепция, а смесь. Это не особо-то просто понять и держать в голове как раз людям. А компилятору и так и сяк нормально :) .

И предпочтения альтернатив у него откровенно странные - «I definitely prefer #1. It’s the simplest, and right now I am most concerned with how we can simplify Rust while retaining its character. Failing that, I think I prefer what we have right now».

Почему откровенно странные? Если он хочет убрать элемент языка, реализующий сразу несколько концепций не самым удачным образом и не переусложнить язык, то этот вариант выглядит разумным. Если будет второй вариант (сразу и uniq и mut) то это, по мне, будет хуже и противоречит духу языка. А третий вариант я толком и осознать не могу, он выглядит очень неудобным)

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

«&mut» сейчас не единая концепция, а смесь

Да причем тут смесь. В реддите правильно сказали: «Losing immutability by default is not just scary, it is unacceptable».

Если будет второй вариант (сразу и uniq и mut) то это, по мне, будет, хуже и противоречит духу языка

Хуже? Противоречит духу? Это как раз семантика языка.

не переусложнить язык

Честно говоря, Rust уже выглядит перегруженным.

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

У них там весеннее обострение?

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

Хотя, наверное, лучше поздно, чем никогда.

Losing immutability by default is not just scary, it is unacceptable

Я уже говорил, что я не сторонник этого возможного изменения. Меня пугает потеря иммутабельности, но мне интересно разобраться как следует в аргументах обеих сторон. Все-таки мне нравится сам язык и я не считаю разработчиков идиотами. «mut» - средство, а не цель и все такое.

Я вообще правильно понимаю, что если оставят только «uniq», то:

- fn x(x: &int) {x++} // ошибка сборки

- fn x(x: &uniq int) {x++} // соберется

?

Честно говоря, Rust уже выглядит перегруженным.

Ну все относительно, конечно. Язык посложнее Форта какого-нибудь будет :) . Но полтора года назад Rust был явно намного больше - с ним открыто экспериментировали и запихивали все, что могли. Потом решили, что это никуда не годится и до сего дня выкидывают всякое, что бы добиться вменяемого баланса функциональности/сложности.

Я не нахожу его перегруженным сейчас - по большей части соблюдается правило «1 сущность - 1 задача».

Можешь тыкнуть пальцем в какие-нибудь конкретности, которые его делают переусложненным?

совершенно не нужен

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

Даже не знаю. Кажется, что с ним произойдёт то же, что и с Д - бесконечная разработка „идеального“ языка.

Даже не знаю. Кажется, что с ним произойдёт то же, что и с Д - бесконечная разработка „идеального“ языка.

Лично я на гитхабе вижу, что очень многие начинания сворачиваются с формулировками типа «может быть сделано после версии 1.0, не критично» или «подождет до 2.0». Так что мне верится, что к концу года язык устаканится и срок выпуска версии 1.0 не сильно сорвут. Хотя, может, я слишком доверчив)

В реддите правильно сказали: «Losing immutability by default is not just scary, it is unacceptable».

Почему так прямо unacceptable? Си, питон и вообще львиная доля популярных языков как-то живут же с мутабельными-по-умолчанию переменными?

Для чего нужна дефолтная иммутабельность? Для удобства чтения/понимания кода человеком, благодаря тому, что факт изменяемости будет явно подсвечен и будет мозолить глаза. Для того, чтобы синтаксическая соль подстегивала кодеров избегать изменяемых переменных, тем самым повышая качество кода. А вот для обеспечения корректности многопоточных программ она, внезапно, оказалась лишней. Так почему unacceptable?

Си, питон и вообще львиная доля популярных языков как-то живут же с мутабельными-по-умолчанию переменными?

Вообще не довод.

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

...компилятору

Так почему unacceptable?

Потому что люди нашли ее достаточно полезной.

Если будет второй вариант (сразу и uniq и mut) то это, по мне, будет, хуже и противоречит духу языка

Хуже? Противоречит духу? Это как раз семантика языка.

Хммм, в принципе, может это и не такой плохой вариант, если получится сделать простые правила взаимодействия этих ключевых слов. Но я себе таких не могу представить. Пускай RFC напишут, там видно будет :) .

Разве в существующем коде на Ржавчине чего-то сломается

Разве существует код на Ржавчине, поломку которого кто-то заметит?

Агрх, после кого score там можно редактировать свои сообщения?

Если будет второй вариант (сразу и uniq и mut) то это, по мне, будет, хуже и противоречит духу языка

Хуже? Противоречит духу? Это как раз семантика языка.

Хммм, в принципе, может это и не такой плохой вариант, если получится сделать простые правила взаимодействия этих ключевых слов. Но я себе таких не могу представить. Пускай RFC напишут, там видно будет :) .

Разве существует код на Ржавчине, поломку которого кто-то заметит?

Кода не много, конечно, но кое-что есть. Тот же Servo. Да и некоторое количество людей точно пробует на нем писать свои личные проектики. Лично я тихонько ковыряю стратегию скромную https://github.com/ozkriff/marauder .

Тот же Servo

И кто его использует, кроме энтузиастов?

Лично я тихонько ковыряю стратегию скромную

Т.е. пишешь в стол. В общем, как я и сказал.

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

Можешь тыкнуть пальцем в какие-нибудь конкретности, которые его делают переусложненным?

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

Потому что люди нашли ее достаточно полезной.

Можно посмотреть на это под другим углом: толпа религиозно дрочит на растущую из ФП иммутабельность. И именно в силу религиозности у толпы возникло возмущение и неприятие, когда кто-то другой посмел обращаться с иммутабельностью не как со святым граалем, а как с одним из возможных средств для решения конкретной прагматической задачи. Эмоций много, а рационального зерна за этими эмоциями — на самом деле мало.

Можно посмотреть на это под другим углом: толпа религиозно дрочит на растущую из ФП иммутабельность. И именно в силу религиозности у толпы возникло возмущение и неприятие

Тупой троллинг теперь называется «углом зрения»? Окей.

Аргументы типа «люди нашли ее» говорят о дефиците аргументов технического характера.

Тупой троллинг теперь называется «углом зрения»? Окей.

Ты думаешь, что разработчики столько времени ковыряли Ржавчину, только что бы троллить толпу энтузиастов внезапными изменениями? :)

Аргументы типа «люди нашли ее» говорят о дефиците аргументов технического характера.

Уже не так тупо, но всё равно недостаточно.

Ты думаешь, что разработчики столько времени ковыряли Ржавчину, только что бы троллить толпу энтузиастов внезапными изменениями? :)

Я просто не понимаю логики Матсакиса. Сначала он рассказывает «на самом деле у нас есть 3 вида ссылок», а потом говорит «поэтому давайте либо оставим 2 вида, либо ничего не будем менять».

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

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

...компилятору

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

Можно, если встроить в IDE компилятор. И даже тогда без явного указания «этой переменной следует быть иммутабельной» большая часть смысла теряется. В той же Scala соотношение var/val то ли 1/3, то ли 1/5.

Кончится тем, что они скажут «use C++, Luke» и сделают всем ручкой.

Ну и? Нормальное решение. Оно, по большому счету, лишь описывает то, что уже итак есть. Ничего не сломается.

Таки расставлять const (столь любимый плюсистами) при мутабельности по умолчанию просто раздражает — всё не расставишь, 1) что-нибудь упустишь (баг словишь), 2) при чтении вообще непонятно подразумевается ли изменение или нет (или это быдлокод). При иммутабельности по умолчанию расставлять не нужно, нужно расставлять mut, 1) тут упустить невозможно (потому что программа не соберётся), 2) при чтении всё сразу понятно. В качестве примера кроме Rust — var/val в Scala (про Haskell вообще молчу).

Оно, по большому счету, лишь описывает то, что уже итак есть

Не так.

http://smallcultfollowing.com/babysteps/blog/2014/05/13/focusing-on-ownership/

«you have three reference types: &, &uniq, and &mut. (As I wrote, this is in fact the type system we have today, at least from the borrow checker’s point of view.)»

Я просто не понимаю логики Матсакиса. Сначала он рассказывает «на самом деле у нас есть 3 вида ссылок», а потом говорит «поэтому давайте либо оставим 2 вида, либо ничего не будем менять».

Как я понял, он считает, что если оставить «mut» и впилить отдельный «uniq», то это порядочно усложнит язык и даст мало пользы.

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

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

Вообще, меня удивило количество людей в комментариях, которые кричат «mut - Это ЛОЖ!11 Его можно обойти! Беспалезен! Удолить!». Такое впечатление, что они не понимают разницы между наследуемой мутабельностью, которую дает «mut», и внутренней мутабельностью, которую дает «unsafe{}», и которая необходима в том или ином виде, что бы на языке вообще чего-то полезное можно было написать.

Кончится тем, что они скажут «use C++, Luke» и сделают всем ручкой.

Чертовски сомнительное и неаргументированное заявление :) .

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

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

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

Можешь тыкнуть пальцем в какие-нибудь конкретности, которые его делают переусложненным?

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

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

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

А кроме этого, в самом языке есть чего-то?

Как я понял, он считает, что если оставить «mut» и впилить отдельный «uniq», то это порядочно усложнит язык и даст мало пользы.

Но «под капотом» оно _уже_ так, объяснить некоторое поведение можно только в терминах 3 видов ссылок - &, &my, &mut. А если &my покрывает большую часть юзкейсов mut, то почему бы и нет.

Но «под капотом» оно _уже_ так, объяснить некоторое поведение можно только в терминах 3 видов ссылок - &, &my, &mut. А если &my покрывает большую часть юзкейсов mut, то почему бы и нет.

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

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

«my», кстати, так себе слово, в любом случае, хоть и короткое. «uniq» или «only» акцентируют внимание на более правильном аспекте.

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

Я понял, о чем ты. Но, если &my - подмножество &mut, я бы не волновался за сложность. Если нет... возможны варианты.

Я пока не могу принять чью-то точку зрения

Я бы хотел увидеть объяснение, почему вариант &, &my и &mut неприемлем.

An alternative take on memory safety (mutability/aliasing)

submitted 12 minutes ago by matthieum

http://www.reddit.com/r/rust/comments/25ma77/an_alternative_take_on_memory_sa...

А Вам платят за такие пеар-новости и защиту этой поделки или Вы просто фанатик?

А Вам платят за такие пеар-новости и защиту этой поделки или Вы просто фанатик?

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