Коллеги, за 10 лет в бэкенде я перевидал кучу фреймворков и подходов. Не так давно взял pet-проект на Go — микросервис для агрегации логов. Думал, что GC и горутины решат все проблемы. Через месяц столкнулся с дикими паузами на сборку мусора под нагрузкой в 100k rps на 4 ядрах. Переписал на Rust с async/await и ареной аллокаций — профит по latency 40%, по памяти — в 2.5 раза.
Я не хочу разводить холивар, но смотрю на текущие тренды: все пилят на Go и Kotlin, не задумываясь о цене абстракций. Вопрос к сообществу: стоит ли экономить время разработки за счет GC, если финальная производительность упирается в железо? Или я просто параноик, который застрял в low-level 2010-х? Жду аргументированных мнений, без «язык X просто удобнее».
👎 3
Слушай, тема жирная, но я тут скорее заступлюсь за подход «не выстрели себе в ногу» 😅
Я сам перерыл кучу либ на Rust для ESP32-C3, и да — чувство контроля над памятью кайфовое, особенно когда на батарейках каждые 100нА на счету! Но смотри: в embedded-мире мы чаще боремся с паразитными емкостями и дребезгом контактов, чем с GC-паузами. Go со своей горутиной и GC в 99% IoT-задач на ESP32 просто не взлетит по RAM — там 512кб всего! А Rust — да, красивый, но сколько раз я плевался, когда borrow checker ругался на простую инициализацию периферии, где надо было взять mut ссылку на UART и SPI одновременно… В итоге накидал костылей с unsafe блоками, а потом месяц искал race condition на прерываниях.
Так что я бы сказал так: если железка слабая (8-битные AVR или ESP с 2МБ флеша) — только C/Rust, иначе GC сожрет весь бюджет. Но если у тебя ARM Cortex-M4 с 512кб RAM и FreeRTOS — Go на TinyGo вполне себе вариант, GC там оптимизирован под реальное время, и код пишется в 3 раза быстрее, чем на Rust. Лично я для умного улья на STM32 переписал логику с Rust на Go (через TinyGo) — профит по скорости разработки колоссальный, а просадки по памяти уложились в 5% 🔧⚡
