Да, для таких применений golang по-моему "сам Бог велел". Но проц, конечно желателен какой-то специфический, если не делать свой, а использовать существующий типа MediaTek, Realtek, Broadcom. Мой опыт показывает, что самому такое железо "с нуля" (со своей схемотехникой/трассировкой) можно сделать только при "адских количествах" устройств в сотни тысяч, или использовать готовые решения/SOM модули от дизайн хаусов. Спасибо за информацию!
Спасибо :) помимо SIGSEGV есть еще много чудес типа memory leak, mempry corrupt и прочего:) попробую в следующий раз делать короткий пересказ вначале или в выводах :)
мне кажется, что несопоставимое сравнение. RSS Google Reader это коммерческий проект/продукт, который стал убыточным, поэтому его закрыли. На golang написан Docker и Kubernetis, я думаю не надо объяснять какое количество облачных сервисов будет готово финансово поддержать команду Google для поддержки языка. Ну и вообще количество широко использующих golang компаний немаленькое. Кроме того, на golang инструмент, который Google широко использует и для внутреннего применения. Я расцениваю вероятность приблизительно такую же, как если бы Microsoft отказалась от сопровождения C#, то есть "крайне невелика".
Но форс мажоры всё равно нельзя исключать, но и к безумству я уже давно не склонен, чтобы писать на ассемблере/машинных кодах, чтобы ни от чего не зависеть - жизнь слишком коротка :)
Это так кажется. предыдущая попытка была с мелкой архитектурой на базе OpenWRT 64МБ NOR Flash + 128MB RAM и вот python + mysql оказалось смертельным для такой конфигурации. Так как для безотказного обновления надо поделить Flash пополам(2х22МБ) и выделить раздел для БД/данных(20МБ). И вот linux kernel+rootfs+python с зависимостями легко потратил 20МБ даже со сжатием OpenWRT. Про Java с его runtime и прожорливостью к ОЗУ я вообще молчу. А флэш - просто расходник, если Вы делаете A/B обновление, бэкапы и глубокое логгирование. Можно и гигабайт флэша вместо 8 GB взять, то в 8 раз быстрее убьёте. Поэтому "можно писать на любом языке" это слишком громко сказано. Если у вас не 512МБ ОЗУ и специфические требования к устройству, то всё равно надо быть аккуратным :)
Будут нарисованы (для примера) микросервисы мониторинга, управления настройками, обновления с резервированием, некоторые приложения верхнего уровня. Там где наносекунды имеют значение будет С. На примере светодиодов - "ШИМмить" golang'ом светодиод бессмысленно - надо писать компонент на C/C++, который будет принимать на вход паттерн мигания/плавного зажигания/затухания светодиодом, а golang как gRPC/или сервис REST API, реализует интерфейс общения с внешними клиентами/работу с конфигом(БД, если надо)/логику обновления приложения, взаимодействие с другими компонентами в системе и прочее. P.S. очевидно, что мониторинг/настройки/обновления уже есть готовые, но некоторые в linux обладают непозволительным(моё оценочное суждение :) ) количеством зависимостей.
Ага, теперь точка зрения кристально понятна. Спасибо :)
Да, для таких применений golang по-моему "сам Бог велел". Но проц, конечно желателен какой-то специфический, если не делать свой, а использовать существующий типа MediaTek, Realtek, Broadcom. Мой опыт показывает, что самому такое железо "с нуля" (со своей схемотехникой/трассировкой) можно сделать только при "адских количествах" устройств в сотни тысяч, или использовать готовые решения/SOM модули от дизайн хаусов.
Спасибо за информацию!
Благодарю!
Спасибо :) помимо SIGSEGV есть еще много чудес типа memory leak, mempry corrupt и прочего:)
попробую в следующий раз делать короткий пересказ вначале или в выводах :)
мне кажется, что несопоставимое сравнение. RSS Google Reader это коммерческий проект/продукт, который стал убыточным, поэтому его закрыли.
На golang написан Docker и Kubernetis, я думаю не надо объяснять какое количество облачных сервисов будет готово финансово поддержать команду Google для поддержки языка. Ну и вообще количество широко использующих golang компаний немаленькое.
Кроме того, на golang инструмент, который Google широко использует и для внутреннего применения. Я расцениваю вероятность приблизительно такую же, как если бы Microsoft отказалась от сопровождения C#, то есть "крайне невелика".
Но форс мажоры всё равно нельзя исключать, но и к безумству я уже давно не склонен, чтобы писать на ассемблере/машинных кодах, чтобы ни от чего не зависеть - жизнь слишком коротка :)
Спасибо за комментарий! если не секрет, а что за конфигурация железа? CPU/ROM/RAM и что в целом за задачки приходится решать ею?
Это так кажется. предыдущая попытка была с мелкой архитектурой на базе OpenWRT 64МБ NOR Flash + 128MB RAM и вот python + mysql оказалось смертельным для такой конфигурации. Так как для безотказного обновления надо поделить Flash пополам(2х22МБ) и выделить раздел для БД/данных(20МБ). И вот linux kernel+rootfs+python с зависимостями легко потратил 20МБ даже со сжатием OpenWRT.
Про Java с его runtime и прожорливостью к ОЗУ я вообще молчу. А флэш - просто расходник, если Вы делаете A/B обновление, бэкапы и глубокое логгирование. Можно и гигабайт флэша вместо 8 GB взять, то в 8 раз быстрее убьёте.
Поэтому "можно писать на любом языке" это слишком громко сказано. Если у вас не 512МБ ОЗУ и специфические требования к устройству, то всё равно надо быть аккуратным :)
Если Вы про defer - согласен
Если есть требование к кроссплатформенности, и есть много сил и воли, то можно еще обратить внимание на flutter (dart). Его, вроде как, выбрали дефолтной технологией для ubuntu приложений. Но он очень своеобразный :)
Спасибо. Если ещё остались такие проблемы, то в следующей статье напишу.
Будут нарисованы (для примера) микросервисы мониторинга, управления настройками, обновления с резервированием, некоторые приложения верхнего уровня. Там где наносекунды имеют значение будет С. На примере светодиодов - "ШИМмить" golang'ом светодиод бессмысленно - надо писать компонент на C/C++, который будет принимать на вход паттерн мигания/плавного зажигания/затухания светодиодом, а golang как gRPC/или сервис REST API, реализует интерфейс общения с внешними клиентами/работу с конфигом(БД, если надо)/логику обновления приложения, взаимодействие с другими компонентами в системе и прочее.
P.S. очевидно, что мониторинг/настройки/обновления уже есть готовые, но некоторые в linux обладают непозволительным(моё оценочное суждение :) ) количеством зависимостей.