История изменений

1. Макросы усложнили жизнь и принесли избыточность?

Ну в чём-то усложнили, в чём-то упростили. По-мне в расте нормальные макросы, уж явно лучше, чем C/C++.

Я бы вообще предпочёл подход, когда программа компилируется в два этапа: сначала компилируется первая часть (условно назовём её макросами), эта первая часть генерирует вторую часть в виде AST и потом генерируется вторая часть, уже как финальная часть. Т.е. если не понятно - я предлагаю заменять макросы обычными подпрограммами на том же ЯП, которые будут выполняться во время компиляции. Но такой подход я пока нигде не видел кроме, разве что, лиспа. но там уже всё совсем другое.

В общем нормальные в расте макросы, не кипишуй.

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

Идиотский тезис. Если компилятор не может скомпилировать какой-то код идеально, зачем вообще писать не на ассемблере - так что-ли? Глупость же. Если вывод типов работает в 90% случаев, ну и славно. А он работает.

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

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

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

Впрочем в любом случае медленная компиляция сегодня это норма. Любой продвиинутый ЯП компилируется долго. Rust, Swift, TypeScript, C++. Rust тут никак особо не выделяется. Да, могли бы сделать упор на скорость компиляции, как это сделали в Go, но это был бы совсем другой язык.

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

Чего?

5. Про сборщик мусора – он всё-таки есть, и даже не один?

Нет.

6. Раст – это параллелизм, прежде всего?

Нет.

7. Получаемый после компиляции машинный код действительно больше, чем аналоггичный на плюсах?

Нет.

8. Ну, про то, что сторонники Раста самые счастливые люди он ничего не объяснил. Каждый кулик своё болото хвалит. А вот как куликов сравнить объективно по уровню счастья – это уже сложнее.

Ты серьёзно задаёшь этот вопрос после «Информатика – это ведь не философия. Это наука вполне конкретная. Если есть сигнал, значит это единичка, и никак не нолик. И двух мнений тут быть не может.»

И какого ты ответа ждёшь? Ну пусть будет единичка.

Резюмируя. По-мне Rust самый интересный ЯП за последние лет 30.

1. Макросы усложнили жизнь и принесли избыточность?

Ну в чём-то усложнили, в чём-то упростили. По-мне в расте нормальные макросы, уж явно лучше, чем C/C++.

Я бы вообще предпочёл подход, когда программа компилируется в два этапа: сначала компилируется первая часть (условно назовём её макросами), эта первая часть генерирует вторую часть в виде AST и потом генерируется вторая часть, уже как финальная часть. Т.е. если не понятно - я предлагаю заменять макросы обычными подпрограммами на том же ЯП, которые будут выполняться во время компиляции. Но такой подход я пока нигде не видел кроме, разве что, лиспа. но там уже всё совсем другое.

В общем нормальные в расте макросы, не кипишуй.

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

Идиотский тезис. Если компилятор не может скомпилировать какой-то код идеально, зачем вообще писать не на ассемблере - так что-ли? Глупость же. Если вывод типов работает в 90% случаев, ну и славно. А он работает.

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

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

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

Впрочем в любом случае медленная компиляция сегодня это норма. Любой продвиинутый ЯП компилируется долго. Rust, Swift, TypeScript, C++. Rust тут никак особо не выделяется. Да, могли бы сделать упор на скорость компиляции, как это сделали в Go, но это был бы совсем другой язык.

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

Чего?

5. Про сборщик мусора – он всё-таки есть, и даже не один?

Нет.

6. Раст – это параллелизм, прежде всего?

Нет.

7. Получаемый после компиляции машинный код действительно больше, чем аналоггичный на плюсах?

Нет.

8. Ну, про то, что сторонники Раста самые счастливые люди он ничего не объяснил. Каждый кулик своё болото хвалит. А вот как куликов сравнить объективно по уровню счастья – это уже сложнее.

Ты серьёзно задаёшь этот вопрос после «Информатика – это ведь не философия. Это наука вполне конкретная. Если есть сигнал, значит это единичка, и никак не нолик. И двух мнений тут быть не может.»

И какого ты ответа ждёшь? Ну пусть будет единичка.