Как надо писать код на расте, я вам на подскажу. Это скорее к @Dmitryuser.
Я могу сказать только две вещи:
1. Чудес не бывает, но бывает явный контроль над происходящим.
2. Borrow checker - это линтер на максималках, сам по себе он только проверяет корректность.

Я к тому, что это не волшебная палочка, которая сразу дает "перформанс". Это тоже инструмент с сильными и слабыми сторонами. И в любом случае он требует куда большей квалификации, чем GC

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

Я бы сказал не именно квалификации, а требует больше времени на то же количество фичей, потому что степеней свободы меньше. При этом раст в целом имеет очень большой порог входа.

Мой поинт, что стек или не стек - это не особо важно

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

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

Так в JVM ровно то же самое. Он может и на стеке разместить и в куче. На свое усмотрение.

Ну и мой тезис про 0.1% никто не закрыл (аллокации и на JVM очень быстрые, все потери в GC)

Ценой хитрого JIT (в т.ч. кусок памяти под разные версии кода) непредсказуемых задержек, и вообще непредсказуемости того, что именно он там оптимизирует, а что - нет.

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

Ну так аллокация и сборка мусора потом связаны. Так-то конечно классно аллоцировать в TLAB, но мусор сам себя не уберёт.

Производительность может быть сопоставимой, если повезёт

Про производительность не надо мне. Я ее меряю. Там есть только две проблемы:
1) Боксинг - это уже на уровне языка. Если пишете все сразу в специализированных типах, то его нет.
2) отсутствие ручного SIMD, что приводит к тому, что иногда он недооптимизирует эту часть. Его завозят в следующей версии JVM/
За исключением этих двух пунктов, перформанс не хуже, чем в нативе

Я не очень понимаю, как можно посчитать, скольцо процессорных циклов уходит на жвм. 0.1% это наверное времени, которое на это тратится. Потому что в фоне фигачит отдельный поток, который жрет батарейку вашего устройства.

Это актуально только если вы биржевого брокера делаете

Скорее да, но надо понимать, что это подходит не всегда

Опять же, про мультиплатформу на LLVM-IR не надо мне рассказывать. Тулинг отбивает охоту с этим работать

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

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