Go против Rust — производительность вне конкуренции

Лично меня очень путала разница = / := (и ещё можно пользоваться var, а можно и нет). А читать мешает то, что тип указывается после переменной/параметра, но без двоеточия. Для меня привычно смотрятся варианты bool a (как в C/Java/PHP) и a: bool (как в Паскале/Python/TypeScript). А вот Go в обоих случаях идёт особым путём.

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

3. Раст, это не про "тяп-ляп и в продакшн", это про вдумчивую расстановку скобочек, точечек, апострофов, чёрточек и двоеточий, но так, чтобы потом работало веками.

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

foo().map(|x| x + 2)

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

Предоставляемые Rust возможности требуют явного синтаксического разделения статических обращений xx::yy::zz и динамических xx.yy.zz, где результат будет зависеть от значения объектов xx, yy и zzво время выполнения. Возможны ситуации, когда программист должен использовать канонический путь для обращения к методу, когда ему нужно явно указать тип или типаж, на котором будет вызван данный метод:

let foo = Foo;
foo.bar();      // вызов метода `bar` из `Foo`

Bar::bar(&foo); // вызов метода `bar` из реализации типажа `Bar` для `Foo`

Такое происходит, когда разные типажи, реализованные для типа, используют одинаковые имена методов, и разрешить конфликт имен необходимо статическим указанием на конкретный типаж или тип, к которому относится метод. Подобная запись вызовов оказывается незаменимой при обобщенном программировании. Если использовать для статического и динамического обращения один и тот же разделитель, то становится невозможно различать подобные вызовы:

Foo::bar(&foo); // вызов метода `bar` из `Foo` у объекта `foo`
Foo.bazz(&foo); // вызов метода `bazz` у созданного на месте объекта `Foo`

Программа, написанная на Rust, не имеет информации о типах во время выполнения, так как при компиляции происходит "стирание типов". Поэтому возникает необходимость различать динамические и статические обращения: механизм их работы сильно отличается, как и последствия, к которым они приводят, так что программист должен видеть это в коде явно.

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

Обычно если надо из Go выжать максимум, к нему биндят Си-библиотеку :)

И это прям беда на самом деле.

:| какой смысл приводить крайние примеры? что они опровергают?

там же итоговый файл, на сколько помню, получается в пару мегабайт, хотите сказать, что на ваш диск он записывается секунд 5-10? то что вы пишете насчёт /dev/null не очень правдоподобно короче :)

"в stdout без буфера" поинт может быть валидный, на сколько помню в java там тоже были проблемы, миллион лишних отдельных системных вызовов тест искажают сильно.

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

"Очень много лишний лишних объектов просто ради объектов" например? в первую очередь программа пишется ради читаемости остальными, в java там тоже объекты vector во всю в коде плодятся и с ними код на много лучше чем к примеру массивами и отдельными методами. А если так повыдёргивать базовые вещи, то смысл тогда в java или go?