В официальной группе по расту в телеграмме(https://t.me/rustlang_ru), есть Никита Кузнецов(@kalloc). Они в Iconic вроде как с HFT работают. Используя при этом Rust. Можешь у него поспрашивать интересующие тебя вопросы.
Я согласен с PsyHaSte. У меня было 3 AST дерева. Одно общие, другие являются конвертируемым в третье. И вот нужно проверить определенные вещи. И я использовал сначала первый подход. И пусть я даже в цикле печатал в случае ошибки дополнительную информацию о том какое дерево сейчас конвертируется. Я все ровно натыкался иногда на то что случайно думал что я еще фикшу первый баг, когда ошибка уже возникает в другом месте. Просто я вижу assert вижу результат он примерно тот который я ожидаю, но он для другого дерева, в котором я не думал что будет проблема. По этому решение когда запускается 100 тестов из которых 12 упало, лучше, чем когда у тебя всегда один который всегда не проходит, пока ты внедряешь новую фичу.
Но за это я раст и люблю, что в нем есть макросы, которые позволяют решить все раздражающие моменты. Нужен сахар, вот тебе макрос, пиши какой хочешь)))
Могу поделиться собственным опытом. Делал переход с шарпа на раст. Уже больше полугода пишу в основном только на расте. Первый раз в 16 году попробовал данный язык. Единственная сложность была с лайфтаймами. И судя по общению в чатах у всех новичков проблемы с этим, так как данная особенность существует пока только у раста и не сразу въезжаешь что к чему. Но к счастью явно прописывать время в программе на практике практически не приходится(во всяком случае в прикладных задачах точно можно без этого обходится).
Так же хочется отметить что на расте архитектура кода получается менее перегруженной, чем в той же java или c#. Но к этому нужно придти, потому что в начале я по привычке все равно городил сложные абстракции кода. Но со временем приходит понимание как нужно писать на расте. В итоге решения на расте как правило получаются более читаемые и более тестированные. Я не говорю что данные вещи возможны только на расте, просто на других языках как правило больше возможностей в плане решения задачи. В итоге прописываешь первое попавшиеся и идешь дальше. Хотя данное решение может быть не самым оптимальным. А в расте приходится в некоторых моментах задумываться.Хочешь ли ты кучу лайфтаймов прописать или можно решить как то задачу более изящным способом. Но как я выше сказал это мой опыт, и может я только писал столько не оптимальный код в других язык))) И по этому возможно для Вас разницы ни какой не будет, после перехода на раст(Ну кроме лайфтаймов)
Да, в принципе под все существующие библиотеки есть обертки. Я на данный момент тесно работаю с rust-qt-binding-generator. Он генерирует необходимую обертку для работы с qml. Пример TODO
Но за это я раст и люблю, что в нем есть макросы, которые позволяют решить все раздражающие моменты. Нужен сахар, вот тебе макрос, пиши какой хочешь)))
полуживые примеры паттернов
Интересные проекты(Awesome Rust)
Так же хочется отметить что на расте архитектура кода получается менее перегруженной, чем в той же java или c#. Но к этому нужно придти, потому что в начале я по привычке все равно городил сложные абстракции кода. Но со временем приходит понимание как нужно писать на расте. В итоге решения на расте как правило получаются более читаемые и более тестированные. Я не говорю что данные вещи возможны только на расте, просто на других языках как правило больше возможностей в плане решения задачи. В итоге прописываешь первое попавшиеся и идешь дальше. Хотя данное решение может быть не самым оптимальным. А в расте приходится в некоторых моментах задумываться.Хочешь ли ты кучу лайфтаймов прописать или можно решить как то задачу более изящным способом. Но как я выше сказал это мой опыт, и может я только писал столько не оптимальный код в других язык))) И по этому возможно для Вас разницы ни какой не будет, после перехода на раст(Ну кроме лайфтаймов)
Список существующих GUI библиотек для RUST