А вот теперь представь, Анонимус, что выражения `public static final AbstractБорщFacade` и `$#!'Борщ*` я вижу впервые.
В первом случае: я открываю Google, вписываю «public static final Java» и получаю тысячи развёрнутых ответов, что это, откуда, зачем и почему. Даже совсем не зная языка, я смогу хотя-бы примерно понять что же делает этот код.
Во втором случае, загуглив по «*?:% Rust» самое полезное что я получу это ссылку на документацию.
Пердолясь с ней, я в лучшем случае найду то что мне нужно, но оказывается чтобы это ещё и понять, нужно понять ещё несколько таких же иероглифов, нужно понять теорию типов, нужно изучить стандартную библиотеку, ещё один язык программирования и что угодно, лишь бы не начать работать с тем, что интересовало меня изначально

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

Именно последние языки программирования: Python и C# сподвигли меня на изучение Rust, потому как надоело разгребать ошибки и описки в рантайме. Лучше мы сразу с компилятором наругаемся, разберемся со всеми варнингами, но после компиляции я уже буду __уверен__ в коде. Особенно после Python.

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

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

Увеличиваем порог вхождения из за недостатка в дизайне.

Порог вхождения для тех, кто не может потратить вечер на чтение книжки по основам языка? Серьёзно? Я бы таких из профессии выкидывал, а не порог увеличивал.

Но ведь практиковать тоже в процессе изучения нужно

Изучить за вечер язык программирования по книжке, а тем более Rust — это возможно?

Плюсую, @ на часы похоже, очень логично в данном случае и легче запоминается.
Кстати, зачем их вообще именовать? Это должно быть удобно что-ли?
Я предлагаю примерно вот так:

&Box@1,2 <Trait, OtherTrait>

&Box@2 <Trait, OtherTrait>

struct SomeStruct<Trait, Other> { x: @1 Trait, y @2 Other }

fn somefunction(x: String, y i32) -> u64@1 { ... }

'static переименовать в @0 чтоб логичнее или в @static чтоб не путать

Кстати, зачем их вообще именовать?

Бгг.

Ну и зачем? Почему не нумеровать?
Параметры и так по умолчанию пронумерованы, осталось лишь @1 @2 @3 в теле функции (например) использовать.
Я конечно извиняюсь за непонимание многих принципов в Rust, но изучать то что выглядит настолько отвратительно желания совсем нет

Порог вхождения для тех

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

Ну и зачем?

Затем же, зачем используются символьные идентификаторы.

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

Ну да. А вот задвинуть дурацкую идею об усовершенствовании - это ты всегда рад.

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

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

Предполагает знание брейнфака, видимо?

P.S. брэйнфак - не язык, в данном случае.

Предполагает знание брейнфака, видимо?

Предполагает знакомство с Си++, Ocaml, Cyclone, даже Occam. Может, нужна еще и какая-то экзотика, но я сомневаюсь.

А брейнфак видим только тебе.

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

Не облегчает порог вхождения, даже наоборот.

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

Не облегчает порог вхождения

Порог не облегчается или утяжеляется, а понижается или повышается.

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

Затем же, зачем используются символьные идентификаторы.

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

дурацкую идею

А больше критики, конструктивной можно?

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

Как я могу стать целевой аудиторией раста? Кода нет. Дизайн уродлив. Учиться чтобы учиться?

Но целевая аудитория Rust их знает

Эта целевая аудитория со временем вымрет, сейчас мало кому интересно учить всякую устарелую маргинальщину. А в случае с С++ это как-то абсурдно, два языка одинаковых учить

А больше критики, конструктивной можно?

Критику нужно заслужить. Твое предложение - не заслужило.

Но целевая аудитория Rust их знает

Эта целевая аудитория со временем вымрет

Мы все умрем. И Rust тоже умрет. А что случится раньше - увидим.

Как я могу стать целевой аудиторией раста?

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

Слушай, а тебя не смущает например такая вот запись: a = sum(list[0] + list[1])? Какие-то чёрточки, углы, обрезки ногтей, хрен разберешь ведь. Нет бы писали человеческим языком: SETVARIABLE sum EQUALTO GETELEMENTBYINDEX 0 FROM list ADD GETELEMENTBYINDEX 1 FROM list. Вона как всё чётко и понятно, не то что эти ваши кракозябры.

Нет бы писали человеческим языком: SETVARIABLE sum EQUALTO GETELEMENTBYINDEX 0 FROM list ADD GETELEMENTBYINDEX 1 FROM list.

Не-не-не. Что за sum, какой еще list? Это всё не нужно: SETVARIABLE 0 EQUALTO GETELEMENTBYINDEX 0 FROM 1 ADD GETELEMENTBYINDEX 1 FROM 1.

У Go и у D один и тот же фатальный недостаток — сборка мусора.

Не знаю, как в Go, но в D оно отключается.

У меня дежавю, словно этот тред уже был

Вам случалось любоваться матрицей, мистер Андерсон?)

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

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

Зачем вы поднимаете эту тему ?

Ведь разработчик явно дал понять что линуксятники для него это третий сорт

Чувак, это не про игру..

SETVARIABLE sum EQUALTO GETELEMENTBYINDEX 0 FROM list ADD GETELEMENTBYINDEX 1 FROM list. Вона как всё чётко и понятно, не то что эти ваши кракозябры.

Фейспалм

НОМ поднимали тему голых мужиков в лесу задолго до появления сурвавйвол-игор

Чушь какая-то. В питоне прекрасно можно писать без головняка. А уходить с божественного питона на раст - это вообще феерично. Примерно как с печенек перейти на толчёную соль. В питоне ошибки прут и валятся у людей, которые пишут быстрей-быстрей, не используют статические анализаторы, та же Pycharm прекрасно анализирует ошибки работы с типами и незащищенные операции типа null pointer в java после ветвлений, приводящих к использованию переменной до ее инициализации и т.д. К тому же питон - это ооп язык с классами/тру ооп и довольно простым метапрограммингом, тогда как ржавчина это си на стероидах. Короче, ржавчина не заточена под веб, написание веб-фреймверков и удобной работы с оными. У питона куча батареек, прекрасная пакетная база, где код легко читаем и изменяем, несколько реализаций и т.д. Си# с ржавчиной тоже сравнивать глупо - примерно как грузовую ручную тачку для перевозки угля против самосвала. Начиная от навороченной visual studio и заканчивая самим языком, в котором всё удобно/безопасно и быстро. При этом скорость работы .NET byte code против java byte code чуть ли не в 1.5 раза выше под виндой.

P.S. Хоть мне лично и java больше нравится, но по мне обе платформы - зло.

Поддерживаю.

Мы сейчас про читабельность, а не про логичность.

Ок, замени на «нечитаемые моменты». Совсем недавно видел как кто-то жаловался на list comprehension в питоне. Мол сложные условия коряво выглядят. Только меня в обратном убеждать не надо.

У мозилловцев по части синтаксиса есть вообще какие-нибудь явно сформулированные design goals / criteria, или каждый раз хреначат как попало, полностью стихийно?

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

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

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

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

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

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

Там есть ссылка на работающий препроцессор - https://github.com/mystor/slag )

// This code is editable and runnable!
fn main() =>
    // A simple integer calculator:
    // `+` or `-` means add or subtract by 1
    // `*` or `/` means multiply or divide by 2

    let program = "+ + * - /"
    let mut accumulator = 0

    for token in program.chars() =>
        match token =>
            '+' => accumulator += 1
            '-' => accumulator -= 1
            '*' => accumulator *= 2
            '/' => accumulator /= 2
            _ => ()

    println!("The program \"{}\" calculates the value {}",
              program, accumulator)

Вот и сравни, что легче читается: паблик статик файнал Борщ vs $%^Борщ.

Это не так уж однозначно. Скажем, у меня не возникает проблем с «= 0» против «abstract». Да и импорт/алиасинг имён в духе

using TypeName = ...;

use a::b::c as y;

сейчас ругать раст за «закорючки» смысла мало.

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

Так язык этот для людей разрабатывается, или для парсера?

Дык, такими темпами вполне могут возникнуть ситуации когда парсер однозначно разобрать не сможет. И придётся городить костыли, примерно как в С++. Уж лучше «подстроиться под парсер», но чтобы правила были однозначными.

Пока язык достаточно молодой, на нём кода относительно мало написано, изменения в языке слабо повлияют на экосистему

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

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

Стоит обратить внимание на ObjectPascal vs C/C++ чтоб увидеть как ты притягиваешь за уши этот аргумент.

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

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

Мне просто непонятно, неужели вот так было бы не проще и красивее?

Мне пока что не совсем понятно как это будет выглядеть. В смысле, как показать, что у входмого параметра x и результата y одинаковый лайфтайм.

А это какие задачи конкретно ты имеешь ввиду, куда бы ты засунул Rust?

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

Ну в 2.0 по любому всё должны сломать, если так рано 1.0 выпустили.
Сейчас они гонятся за скоростью компиляции, работают над совместимостью с ХР итд, именно то, что нужно для молодого языка, ага.
А нормальные строки, нормальные bindings в match, нормальная запись лайфтаймов где-то в 4.0 появится и как с версиями Python будет

В первом случае: я открываю Google, вписываю «public static final Java» и получаю тысячи развёрнутых ответов,

Это неплохой аргумент, но не всё так просто. Даже состоящие из слов конструкции не всегда легко гуглятся, тем более, что слова могут использоваться в разных контекстах. Скажем, посмотри на list comprehensions в питоне - там внутри вполне «привычные и читаемые» for и in, но если ты не знаешь самого термина, то нагуглить будет непросто.

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

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

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

Изучить за вечер язык программирования по книжке, а тем более Rust — это возможно?

Смотря что ты вкладываешь в понятие «изучить». Но вообще раст тут явно не самый сложный. И я даже не про всякие хаскели и скалы говорю. Тот же C# так разросся, что за вечер ты и половину нюансов не охватишь, хотя казалось бы - не С++ ведь.

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

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

Мне кажется, что ты «немного» преувеличиваешь. Скажем, Ocaml, Cyclone и Occam я в глаза не видел, но раст худо-бедно освоить смог. Думаю и без специальных знаний не так уж сложно осилить - мануалы по языку вполне доступно обьясняют.