Golang для Embedded Linux |
||||||||||||
МЕНЮ Главная страница Поиск Регистрация на сайте Помощь проекту Архив новостей ТЕМЫ Новости ИИ Голосовой помощник Разработка ИИГородские сумасшедшие ИИ в медицине ИИ проекты Искусственные нейросети Искусственный интеллект Слежка за людьми Угроза ИИ ИИ теория Внедрение ИИКомпьютерные науки Машинное обуч. (Ошибки) Машинное обучение Машинный перевод Нейронные сети начинающим Психология ИИ Реализация ИИ Реализация нейросетей Создание беспилотных авто Трезво про ИИ Философия ИИ Big data Работа разума и сознаниеМодель мозгаРобототехника, БПЛАТрансгуманизмОбработка текстаТеория эволюцииДополненная реальностьЖелезоКиберугрозыНаучный мирИТ индустрияРазработка ПОТеория информацииМатематикаЦифровая экономика
Генетические алгоритмы Капсульные нейросети Основы нейронных сетей Распознавание лиц Распознавание образов Распознавание речи Творчество ИИ Техническое зрение Чат-боты Авторизация |
2021-11-10 11:51 При разработке очередной платформы перед командой АТОЛ встал вопрос выбора языка программирования/стека технологий/железа/фреймворка для создания решений. Железо было выбрано на базе относительно недорогой Linux-платформы STM32MP153/512MB DDR3/8GB eMMC. Эта платформа имеет на несколько порядков больше ресурсов, чем используемые в нашей основной массе решений LPC1768/LPC1778/LPC4078/STM32F207. 100% наработок кода компании для устройств были написаны на C/C++, однако прогресс не стоит на месте, и периодически необходимо актуализировать инструменты и технологии разработки, особенно с учетом новых аппаратных возможностей. Из статьи станет ясно, как мы дошли до жизни такой и почему выбрали Golang для создания очередного набора решений. Выбор стека технологий важен для всех компаний, которые занимаются разработкой железа и перерастают крошечные embedded контроллеры на Cortex M0/M3/M4/M7. Обычно команды при переходе на новую платформу выбирают одно из двух решений: стараются сделать новую версию системы на новом железе/технологиях/архитектуре, превращая решение в нестабильный долгострой, или наоборот — вносят минимальное количество изменений, но иногда вместо совокупности положительных черт разных подходов получают совокупность отрицательных. В статье исследованы особенности различных языков программирования/технологий (Java, Python, C/C++, Rust, Golang), их плюсы и минусы, сформулированы критерии выбора и представлен выбор команды АТОЛ. Для анализа использован метод SWOT-анализа. В качестве источников данных — информация сайтов фреймворков. Помимо этого, косвенная информация о боли и страданиях разработчиков получена на Stackoverflow, и часть субъективных выводов сделана на основе моего экспертного мнения за более чем 30-летний опыт программирования. Почему к C/C++ решили добавить язык высокого уровня? Итак, мы переехали на новое «железо», теперь у нас есть Linux, ресурсов на три порядка больше и целая куча легаси-кода на C/C++, в которых можно напилить нужные уровни абстракции/упаковать в приложение/библиотеку и начать жить по-новому. Однако у такого подхода есть недостатки против применения языков высокого уровня:
При всех указанных минусах, отказ от C/C++ для нас невозможен по двум причинам:
Соответственно, нам нужно было выбрать язык/технологию, который дополнит C/C++. Почему не С#, Ruby, JavaScript, TypeScript, Dart или Julia? Ruby, JavaScript, TypeScript, Dart, Julia и прочие хайповые языки/технологии, имеющие по индексам TIOBE рейтинг менее 1%. Даже не спрашивайте, почему не они. Будем считать, что они просто не подходят на роль кроссплатформенного языка общего назначения под Embedded Linux/desktop/cloud с целью создания различных системных и веб-сервисов:) На чем создавать кроссплатформенные GUI-приложения — это отдельная большая история, которая выходит за рамки данной статьи. C#. Он мне нравится как язык/фреймворк для создания Windows-приложений. Я писал на нем лет 10 «боевые» приложения, и до сих пор «грешу», если нужно быстро накидать GUI-приложение «для себя». Но у него есть, на мой взгляд, несколько фатальных недостатков:
Возможно, какой-нибудь Universal Windows Platform (UWP) впоследствии вырастет до полноценного кроссплатформенного решения Embedded Linux, десктоп (Linux/Windows/MacOS) и облачных сервисов, но я пока в production такого не видел. Кроме того, поработав длительное время и создавая многопоточные кроссплатформенные сервисы Golang и C#, я однозначно делаю выбор в сторону Golang. Таким образом, C# отсеяли. Наши альтернативы: Rust, Python, Golang, Java Целевой ОС для разработки будем считать Linux, однако впоследствии при установке более мощного железа (STM32MP157, NXP серии i.MX и прочие) возможно появление Android, поэтому код должен собираться и туда. Огромным плюсом я считаю возможность собираться под десктоп (для создания эмуляторов устройств и переноса общей логики на выделенную машину в случае работы нескольких одинаковых устройств в сети), а также под облачные сервисы (при отсутствии инфраструктуры у юзера и выносе части логики на нашу или арендуемую клиентом облачную платформу). В качестве языков высокого уровня будем рассматривать следующие альтернативы: Rust, Python, Golang, Java. Есть красивые глубокие исследования по low-level производительности Rust, Python, Golang, Java, например, по микросервисам. Есть показательный benchmark разработанного веб-сервиса с задержкой (Latency) в миллисекундах на шкале слева при доверительной вероятности 99% и общей пропускной способности в запросах в секунду (RPS) на одинаковом железе. Python По большому счету, Python имеет одни из самых высоких задержек при создании системных сервисов и самую низкую производительность при создании pure python кода. То есть самые ответственные операции все равно придется писать на C/C++. Но я не считаю язык Python языком общего назначения, на мой взгляд, он хорош в боевом применении, только если надо писать облачные сервисы (web, AI), заниматься внутренней автоматизацией или создавать open-source код, хотя и имеет крайне низкий порог вхождения. Если отойти от указанных применений влево-вправо, то начинаются разного рода приключения:
Можно поразвлекаться с PyPy, и грести его особенности потом в боевых применениях (так как для железа будет PyPy, а в облаке будет Python, и поведение может различаться). Кроме того, в нескольких предыдущих проектах мне неоднократно приходилось бороться с GIL, которого нет в других языках (но когда-нибудь это уже не будет проблемой). В итоге Python тоже отсеяли. Java С Java ситуация чуть лучше с точки зрения производительности, но не задержек. С первыми двумя минусами Python у Java получше, из-за JRE (входит в minimum requirements для платформы) и обфускаторов коммерческих решений — вагон. Но один фатальный момент сохраняется:
Однако ответственные вещи можно переписывать на C/C++ или использовать низкоуровневые оптимизированные библиотеки, а в некоторых тестах и встроенные средства в Java ведут себя неплохо. Но подход постоянно подкладывать низкоуровневый код лишает преимуществ высокоуровневого языка, и фатальные проблемы никуда не деваются. Rust vs Golang Rust. В сети периодически возникают идеи отказа от C/C++ в пользу Rust (ссылка 1, ссылка 2), но мы все прекрасно понимаем, что поделить бассейн на «писающих» и «не писающих» не получится, так как весь код вокруг остается на C/C++ и его придется сопровождать/развивать AS-IS, поэтому применение C/C++ для нас неизбежно. Однако можно добавить один высокоуровневый язык для понижения сложности сопровождения системы, снижения стоимости масштабирования/новой функциональности. Пару языков добавлять не хочется, чтобы не разводить зоопарк и не повышать сильно порог вхождения в разработку. В итоге основная битва развернулась между Rust (рассматриваем как «язык высокого уровня») и Golang. Глядя на код, на одном и другом языке после C/C++ ничего смертельного не видно. Глядя на плюсы и минусы языков/технологий, я предвзято склонялся к Golang. Поэтому сделал SWOT-анализ для случая, если выберем Golang вместо Rust, чтобы себя проверить. Общие черты типа «memory safety», «быстрый», «компилируемый» в таблице не отражены, показаны только различия:
Если бы надо было выбрать только один язык, то, возможно, я бы и склонился к Rust, но так как надо выбрать язык/технологию, который дополнит C/C++, то слабые стороны Golang теряют вес. Если использовать последние стандарты C++ и умные указатели, то также можно улучшить ситуацию и понизить необходимость в Rust. Кроме того, для компании сейчас важно минимизировать время time to market: вместо стабилизации нового продукта месяцами хочется стабилизировать его неделями. Поэтому выбор пал на Golang. При экспериментах с Golang на конкретном выбранном микроконтроллере STM32MP1 стало ясно, что у нас нет удаленной отладки (Delve remote debugging) из-за 32-bit arm архитектуры. Все новые контроллеры уже 64-bit, поэтому Google, видимо, не особо «напрягается», хотя уже есть x86 и 32-bit mips. Видимо, придется эту задачу решать первой, когда будем подходить к промышленному применению. Понятно, что впереди маячит Go 2, где наконец-то порешают долгожданный вопрос с обработкой ошибок, и очевидно, что мы столкнемся с местами, где Rust подошел бы больше, чем Golang, и их придется написать на C/C++. Но, как гласит старая русская пословица, «багов бояться — код не писать». Источник: habr.com Комментарии: |
|||||||||||