Go на устройствах с маленькой памятью

[youROCK]

В программах на Go на самом деле очень хорошо видно, что они не заточены под низкое потребление памяти. Оно, конечно, обычно не такое, как в Java, но все равно примерно на полпорядка больше, чем аналогичные программы на C/C++. Я предполагаю, что это связано с тем, что Google в основном разрабатывает у себя stateless-сервисы, и им много памяти в любом случае не требуется. Для разработки в условиях относительного небольшого доступного количества памяти го подходит очень плохо. Альтернативы, конечно, тоже не огонь (в основном это C/C++, может быть Rust), но работать с ними в таких условиях должно быть сильно проще.

[divan0]

Ну да, Go очень явно дизайнился с расчетом на сервера, и многие компромисы были приняты в сторону большего использования памяти. Фреймворки вроде https://gobot.io и https://github.com/kidoman/embd, по идее, на Go не имели шанса появиться. Тот факт, что Go активно бегает на embedded и устройствах с маленьким количеством ресурсов это комплимент Go

[AutomationD]

Какое отношение имеет gobot.io к запуску go на embeded? Такое же что и artoo.io cylonjs.com, или я ошибаюсь?

[Paul_Nice]

К слову о Rust.
Вот такой есть эксперимент в ещё более жёстких условиях.

[0r4anin]

Мне одному кажется что писать на Go для одноплатных систем с урезанными ресурсами это все равно что шуроповертом гвозди закалачивать?

[Siemargl]

Вот же блин, у моего Зикселя 64Мб памяти.

Какое го- го- горе, Го туда не помещается…

P.S. Скажу проще. Охренели Го-ре разработчики, забыли про единицу измерения в Килобайт

[wing_pin]

Вас забыли спросить, ага.

[kveselkov]

Чего только не придумают, лишь бы не городить парк технологий. Но в любом случае интересно, если бы Go не был open source (не смогли бы чаще память отдавать память системе), то вряд ли бы они его оставили. Больше интересует почему изначально для телеметрии был выбран Go?

[pfihr]

Видимо, из-за встроенной библиотеки работы с сетью.

[remzalp]

Flussonic успешно пишется на Erlang, творит чудеса с потоковым видео в реалтайме. Не смотрели в ту сторону?

[divan0]

Это, наверное, к автору статьи вопрос :)

[monah_tuk]

Ребята работают с Go на MIPS с 32Мб памяти на борту (WiFi точка доступа под свои задачи). Результирующий бинарь 16Мб, потребление памяти — 4Мб. Сборка с вырезанием всего лишнего (символы, дебаг и пр.) и ручное управление GC. Функционал:

• Http server
• DHCP
• DNS cache
• Подсистема руления правилами iptables ipset tc
• Netflow коллектор
• Подсистема руления кишками AP

Ну и логика работы с облаком (своё, часть проекта).

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

[monah_tuk]

Меня поправили, бинарь на MIPS — 3.5Мб.

[bogolt]

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

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