При разработке очередной платформы перед командой АТОЛ встал вопрос выбора языка программирования/стека технологий/железа/фреймворка для создания решений. Железо было выбрано на базе относительно недорогой 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++, в которых можно напилить нужные уровни абстракции/упаковать в приложение/библиотеку и начать жить по-новому.
Однако у такого подхода есть недостатки против применения языков высокого уровня:
Высокая трудоемкость при реализации новой функциональности, особенно если нужны высокоуровневые сущности (веб-сервер, работа с «хитрыми» базами данных, реализация брокера сообщений и прочее). Теоретически это решается созданием зависимости от third-party библиотек и подключением монструозных библиотек, но в любом случае этот код тяжелее читать/сопровождать/писать/отлаживать/профилировать по сравнению с языками высокого уровня.
Разработка и стабилизация функциональности на C/C++ занимает в разы больше времени, чем аналогичные действия на языках высокого уровня (Python, Golang, Java, C# и прочие), так как с указателями существует много взаимодополняющих способов отстрелить себе ноги, типа memory corrupt/memory leak/null pointer operations и прочих «радостей», которые можно улучшить при использовании новых стандартов/умных указателей, но не избавиться от них совсем.
Порог вхождения новых разработчиков выше, с учетом наличия различных стандартов С++, использования множественного наследования, шаблонов, сторонних библиотек boost/qt и прочих, чем для приложения с аналогичной функциональностью на языках высокого уровня (при создании разумной архитектуры).
Получается заметно больше кода, особенно при создании кроссплатформенных решений.
При всех указанных минусах, отказ от C/C++ для нас невозможен по двум причинам:
большое количество legacy-кода, наработанного за 20 лет существования компании;
мы разработчики оборудования, поэтому C/C++ в любом случае останется при разработке библиотек низкого уровня, написании модулей ядра, модификации низкоуровневых библиотек Linux/Android и прочих ОС, которые могут быть натянуты на новое железо.
Соответственно, нам нужно было выбрать язык/технологию, который дополнит C/C++.
Почему не С#, Ruby, JavaScript, TypeScript, Dart или Julia?
Ruby, JavaScript, TypeScript, Dart, Julia и прочие хайповые языки/технологии, имеющие по индексам TIOBE рейтинг менее 1%. Даже не спрашивайте, почему не они. Будем считать, что они просто не подходят на роль кроссплатформенного языка общего назначения под Embedded Linux/desktop/cloud с целью создания различных системных и веб-сервисов:) На чем создавать кроссплатформенные GUI-приложения — это отдельная большая история, которая выходит за рамки данной статьи.
C#. Он мне нравится как язык/фреймворк для создания Windows-приложений. Я писал на нем лет 10 «боевые» приложения, и до сих пор «грешу», если нужно быстро накидать GUI-приложение «для себя». Но у него есть, на мой взгляд, несколько фатальных недостатков:
Фактически он привязывает разработчика к среде разработки Microsoft Visual Studio (если хоть раз попробовал, то слезть почти невозможно), сборочные машины будут «виндовые», что сразу накладывает особенности/ограничения на ci/devops, который в других случаях красиво контейнеризируется в «легонькие» Linux-докеры.
Имеется сильная зависимость от .NET Framework, а он за последние годы стал сильно «пухленький» по сравнению с первыми версиями 1.1/2.0, которые умещались в какие-то жалкие 13-20 МБ. Это сильно осложняет его применение на устройствах с ограниченными ресурсами.
Возможно, какой-нибудь 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 код, хотя и имеет крайне низкий порог вхождения.
Если отойти от указанных применений влево-вправо, то начинаются разного рода приключения:
Важно, но не смертельно — в Python элементарно набиваются зависимости, которые быстро раздувают приложение в 50-100 МБ, если пытаться создать распространяемое кроссплатформенное решение.
Фатально — создание платного ПО, распространяемого по подписке или лицензиям, требует неприемлемых затрат на защиту кода, а иногда выдвигают доп. требования аппаратной защиты (USB-ключи, etc.). Нормальных сторонних обфускаторов тоже нет, а мы — коммерческая компания.
Фатально — при попытке создавать код системных приложений под Embedded Linux получаем жутко непредсказуемое потребление ОЗУ. Хочу, чтобы можно было нормально инкапсулировать логику в отдельные приложения, а не коверкать архитектуру из-за особенностей технологии, отказывая, например, в доступе к БД всему, кроме одного микросервиса, через который нужно пускать в БД остальные, так как работа с БД — это плюс пара десятков МБ ОЗУ, и для пары десятков микросервисов в Embedded Linux потеряем половину ОЗУ.
Можно поразвлекаться с PyPy, и грести его особенности потом в боевых применениях (так как для железа будет PyPy, а в облаке будет Python, и поведение может различаться). Кроме того, в нескольких предыдущих проектах мне неоднократно приходилось бороться с GIL, которого нет в других языках (но когда-нибудь это уже не будет проблемой). В итоге Python тоже отсеяли.
Java
С Java ситуация чуть лучше с точки зрения производительности, но не задержек. С первыми двумя минусами Python у Java получше, из-за JRE (входит в minimum requirements для платформы) и обфускаторов коммерческих решений — вагон.
Но один фатальный момент сохраняется:
Высокие требования к Flash, ОЗУ, а также вычислительной мощности из-за наличия «жирненького» JRE. Если бы у нас был только Android, то ситуация была бы немного лучше, но у нас cross-platform, да еще имеется Embedded Linux в скромной конфигурации.
Однако ответственные вещи можно переписывать на 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», «быстрый», «компилируемый» в таблице не отражены, показаны только различия:
SWOT-анализ, если выбрать Golang вместо Rust | |
Сильное |
Слабое |
|
• Меньше вероятность проблем при кроссплатформенной разработке из-за более широкой популярности (в два раза по индексу TIOBE) • Отличная концепция многопоточности (goroutines) и обмена сообщений (channel) • Много встроенных полезных инструментов (тестирование, управление пакетами), как и в Rust, но дополнительно есть статический анализ, design-time анализ в средах разработки и профайлер • Намного более быстрая сборка (кто часами ждал сборки на C/C++ оценит:) ) • В Golang синтаксис близок к C, и порог вхождения ниже, чем в Rust (steep learning curve линк 1, линк 2), что позволяет легче писать и сопровождать код, но из-за этого нет «zero cost abstractions», которые есть у Rust |
• Не получим такого хорошего детерминированного поведения кода, как у Rust • В большинстве тестов Golang проигрывает Rust, хоть и не так сильно, как другие высокоуровневые языки • Golang использует «garbage collector» (больше потребление ОЗУ) против модели «lifetimes» у Rust, то есть это не язык системного программиста • Golang внутри имеет промежуточные слои абстракции |
Перспективы |
Подводные камни |
|
• Верим больше в технологии развиваемые гигантом Google, что не «помрет», как другие, так как активно используется в массовых решениях (Google Chrome, Google Earth, YouTube, Kubernetes, Docker, GitHub) • Time to market фич/продуктов на Golang будет ниже, чем у Rust |
• Возможно, будем упираться в недетерминированное поведение, повышенный расход ОЗУ/CPU, и это чаще придется переписывать на C/C++ или использовать сторонние оптимизированные библиотеки |
Если бы надо было выбрать только один язык, то, возможно, я бы и склонился к 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++. Но, как гласит старая русская пословица, «багов бояться — код не писать».
Спасибо, что дочитали до конца :)
Комментарии (48)
IGR2014
05.11.2021 20:35+4Почему к C/C++ решили добавить язык высокого уровня?
Как минимум, потому что C++ тоже язык высокого уровня
amarao
06.11.2021 13:54+3Это язык высокого уровня с историческими особенностями поколения garbage in garbage out. Rust - это С++, от которого отрезали "С".
IGR2014
19.11.2021 14:39-1Это никто не оспаривает. Но постановка предложения очень сильно хромает. То что в C++ остались некоторые зависимости C - не делает его низкоуровневым языком. Что в чистом C++, по вашему мнению, мешает ему быть высокоуровневым?
amarao
19.11.2021 15:51+1Путаница с move-семантикой, наличие UB в казалось бы невинных местах (в районе type aliasing'а и параллельного доступа к переменной из разных тредов).
IGR2014
02.12.2021 20:07Многопоточность - std::atomic под разные простые типы данных или std::barrier/std::latch/std::mutex ?
Как путаница с move-семантикой делает язык низкоуровневым? Как раз в низкоуровневых языках нет таких понятий и впомине.
И чем плох type aliasing (при использовании using а не typedef)? Наоборот, позволяет определить короткое имя для типа данных из нескольких шаблонных классов чтоб не путаться в этом спагетти template`ов. Кстати, в GoLang он тоже имеется: https://go101.org/article/type-system-overview.html
Или вы про union? Так есть std::variant который всегда вкурсе что хранит.
NN1
05.11.2021 22:32+4Сегодня на C# прекрасно используем кроссплатформенный Rider.
Прямо сейчас пишу код в macOS, билд сервер собирает в докере Linux, а результат запускаю в Windows.
vitalijs
07.11.2021 16:33+2То что написано в статье про c#/.net с реальностью пересекается слабо
bagumka
09.11.2021 16:15+2коллеги, очень интересна Ваша точка зрения про реальность C#. Чтобы понять насколько это подходит для embedded применений, если есть реальная статистика, подскажите пожалуйта (можно с погрешностью в 20%):
сколько занимает места на диске более-менее современный .net framework под linux?
сколько на диске жрёт минимальное приложение "Hello World!" (RAM+ROM), и вообще прекрасно, если есть статистика по какому-нибудь минимальному http или rpc серверу, чтобы сравнить это с golang
Спасибо!
NN1
17.11.2021 10:22Мой ответ был насчёт несостоятельности .NET для кроссплатформенной разработки.
Насчёт встроенных систем то тут .NET не конкурент.
Во первых размер больше, .NET 6 уже добавил улучшение в удалении неиспользуемого кода но не так как в Go.
Далее в .NET есть JIT, который также занимает место на диске и память, а также время для запуска.
Для этого есть Ready to Run (R2R) , который увеличивает размер файла за счёт предкомпиляции и ускорения запуска.
.NET 7 обещает нам компиляцию в нативный код и тогда это будет полноценным конкурентным сравнением с GoLang.
maxim_ge
05.11.2021 23:06+5Не совсем понятно, что писать собираетесь. Вызовы С<=>Go занимают около сотни наносекунд, что почти на два порядка больше, чем C<=>Rust.
Для некоторых применений это фатально, для других вполне норм.
olafars
06.11.2021 02:48+1Мало того, что они занимают приличное время, так ещё и проблемы могут быть при кросс-компиляции. А если собирать нормально, то там танцы с gonative, что тоже тот ещё секс. Хотя может что с 2015 года и изменилось.
mrbakminster Автор
09.11.2021 16:27Спасибо. Если ещё остались такие проблемы, то в следующей статье напишу.
mrbakminster Автор
09.11.2021 16:27+1Будут нарисованы (для примера) микросервисы мониторинга, управления настройками, обновления с резервированием, некоторые приложения верхнего уровня. Там где наносекунды имеют значение будет С. На примере светодиодов - "ШИМмить" golang'ом светодиод бессмысленно - надо писать компонент на C/C++, который будет принимать на вход паттерн мигания/плавного зажигания/затухания светодиодом, а golang как gRPC/или сервис REST API, реализует интерфейс общения с внешними клиентами/работу с конфигом(БД, если надо)/логику обновления приложения, взаимодействие с другими компонентами в системе и прочее.
P.S. очевидно, что мониторинг/настройки/обновления уже есть готовые, но некоторые в linux обладают непозволительным(моё оценочное суждение :) ) количеством зависимостей.
ciuafm
05.11.2021 23:43+1Я хотел бы ворваться в Линукс GUI. Из опыта Delphi / C#. Есть какие нибудь фреймворки под C(++) или Golang которые не тянут 100500 зависимостей и легко подключить в какую-нибудь IDE? Т.е. желательно комплект IDE+GUI framework и очень хочется чтобы это были сотни мегабайт а не гигабайты. Обращаюсь к автору статьи, но если кто знает - тоже набросайте вариантов. GUI нужен базовый, без наворотов.
xshura
06.11.2021 00:42+1Посмотрите:
https://github.com/gotk3/gotk3
Я на нем писал гуй для малинки. Мне не с чем его сравнивать, т.к. "попробовал и зашло".
А сам гуй я делал в Glade.
mrbakminster Автор
09.11.2021 16:30Если есть требование к кроссплатформенности, и есть много сил и воли, то можно еще обратить внимание на flutter (dart). Его, вроде как, выбрали дефолтной технологией для ubuntu приложений. Но он очень своеобразный :)
sedyh
06.11.2021 00:17+2где наконец-то порешают долгожданный вопрос с обработкой ошибок
Кажется, функционала оборачивания и проверки ошибок из go 13 достаточно для большинства задач.
gameplayer55055
06.11.2021 09:44-3Свои языки программирования использую так:
Линукс: С, можно С++. Из коробки есть gcc make. Нужны библиотеки? Иди в /usr/lib, /usr/include. Тоже думал ой, то же си. Но как практика показала, ничего лучше нету. Но формошлёпы не поймут меня. Пусть познают дзен. Го и раст от лукавого.
Виндовс: С#. Потому что вижуал студия, потому что Майкрософт, потому что виндовс формы, с++ задолбаешся библиотеки подключать, и с PATH игратся.
Автоматизация, если не важна супер скорость то это питон. Там все просто и понятно. Хотя можно ограничиться и башом, если под Линукс.
Делать кроссплатформенные проги под десктоп это все же electron. Потому что виндовс хрен ложил на POSIX, а единственное до чего не добрались лапы индусов это до стандартов браузера. Полгига занимает, но все же бугурт облегчает. Тем более сейчас трендово.
RPG18
06.11.2021 14:10Мой петроджект кроссплатформенный гуй к Apache Kafka на С++. Не играюсь с PATH, зависимости идут через пакетные менеджеры. Под Windows собираю через Visual Studio. Что я делаю не так?
AlexTheLost
06.11.2021 12:12+3STM32MP153/512MB DDR3/8GB. STM32MP153 это microprocessors а не microcontroller.
Это уже ни какой не embedded.))
С такими мощностями можно писать на любом языке, на котором дешевле с точки зрения трудозатрат. Если нет специфических требований.
le2
06.11.2021 19:56у Intel на сайте тоже есть раздел embedded в котором есть i7 и прочие камни. Смотря что вы подразумеваете под этим словом.
Современные нейросети кладут все что угодно на лопатки. Причем задействованы могут быть и векторные расширения и GPU и все ядра.
mrbakminster Автор
09.11.2021 16:46Это так кажется. предыдущая попытка была с мелкой архитектурой на базе 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МБ ОЗУ и специфические требования к устройству, то всё равно надо быть аккуратным :)
amarao
06.11.2021 13:56+8В целом, Rust действительно требует некоторого душевного перерождения. Для С-background это в первую очередь наличие гигиены: нет, мы не едим руками и не моем посуду в унитазе, даже если это удобно прямо здесь и сейчас. Когда вот эта часть преодолена, любой человек, знающий С++ на умеренном уровне, с лёгкостью входит в Rust и ощущает блага цивилизации.
Перейти с Python в Rust куда сложнее, потому что одновременно сваливаются и статические типы, и generic'и, и трейты, и lifetimes, и (изящно замаскированные) указатели.
sandersru
06.11.2021 18:09Samsung/Qualcomm/Broadcom - уже перешли(переходят) на go в своей разработке. Похоже это тенденция.
Но в java вы немного не туда смотрели... Уже есть GraalVM, который умеет компиляться в натив и напрямую вызывать сишные библиотеки. Сама JVM тянет 10мб и бинарник получается не сильно жирнее гоуланг. Правда все это для 64 бит онли.
Если с специалистами Явы проще чем с гоуланг, то посмотрите ещё раз.
le2
06.11.2021 20:02да, вендоры третьего эшелона (ST, Rockchip, Allwinner) экономят не только на нанометрах, но и на лицензиях от ARM используя устаревшие ядра. 32-бита может похоронить развитие линейки оборудования. Можно оказаться в ситуации что бизнес будет требовать жирных внешних библиотек, а поддержки такой не будет.
sandersru
06.11.2021 20:06Allwinner уже на 64 бита перешёл. Даже малинка ща 15$ уже там. Дальше и все остальные уйдут так же как и 15-20 лет назад с 8 бит на 32 ибо окажется более массово и дешевле
le2
06.11.2021 20:10малинка пока ещё официально на 64 бита софверно не перешла. Пидора, или как её там, все еще 32-битная.
64-бита решает в векторных расширениях. Чуть ли не четырехкратный прирост относительно 32-битной ОСи на той же железке.sandersru
06.11.2021 20:14Что значит не перешла? Rasberian уже давно 64 битный есть. 4я малина и 2й zero w уже на 64 битных ядрах. 64х битный graalVM на них прекрасно компиляться и работает.
le2
06.11.2021 20:27Полез смотреть. Это бета-версия, которая полтора года не обновлялась? Официальная версия все еще 32-битная.
Для 64-бит на ARM я убунту использую.
Zuy
06.11.2021 19:57+1Тоже выбрал Go для embedded Linux проектов и автоматизации на них. И это прямо счастье какое-то. Основные плюшки которые мне зашли:
Кросплатформенность из коробки. Одной командой бинарник собирается для Arm и все что надо там внутри. Просто копируешь его на таргет и оно работает. Python тут и рядом не стоит.
Многопоточность. Наконец-то где-то осознали, что в процессорах давно уже не одно ядро и дали нормальный способ этим пользоваться.
Простой, С подобный синтаксис.
Через какое-то время у меня сложилось ощущение,что Go это такой более человеческий Python для тех кто привык к С. Сейчас если в проекте есть Linux то в сторону C/C++ смотрю только в случае крайней необходимости.
mrbakminster Автор
09.11.2021 17:46Спасибо за комментарий! если не секрет, а что за конфигурация железа? CPU/ROM/RAM и что в целом за задачки приходится решать ею?
Zuy
09.11.2021 21:53+1Железо полностью кастомное включая SoC. Ядра процессора ARM64. Обрабатывает сетевой траффик в датацентрах.
mrbakminster Автор
10.11.2021 10:58Да, для таких применений golang по-моему "сам Бог велел". Но проц, конечно желателен какой-то специфический, если не делать свой, а использовать существующий типа MediaTek, Realtek, Broadcom. Мой опыт показывает, что самому такое железо "с нуля" (со своей схемотехникой/трассировкой) можно сделать только при "адских количествах" устройств в сотни тысяч, или использовать готовые решения/SOM модули от дизайн хаусов.
Спасибо за информацию!
LARII
07.11.2021 09:24+1Как-то попробовал разобрать из Go Regexp часть кода, в котором компилируется регулярка-структура. Получилось 11.5 тысяч строк. Это без i/o ридера. На языке 1С получилось 2.5 тысячи. Как по мне высокоуровневость у Go своеобразная.
vtb_k
08.11.2021 14:41+3Верим больше в технологии развиваемые гигантом Google, что не «помрет», как другие, так как активно используется в массовых решениях (Google Chrome, Google Earth, YouTube, Kubernetes, Docker, GitHub)
Извините, но после смерти гугл ридера веры в гугл у меня нету, тут у раста как раз преимущество, потому что язык уже отделен от крупных корпораций и имеет уже Rust Foundation, в котором тот же гугл в спонсорах, но не только он.
mrbakminster Автор
09.11.2021 18:07-1мне кажется, что несопоставимое сравнение. RSS Google Reader это коммерческий проект/продукт, который стал убыточным, поэтому его закрыли.
На golang написан Docker и Kubernetis, я думаю не надо объяснять какое количество облачных сервисов будет готово финансово поддержать команду Google для поддержки языка. Ну и вообще количество широко использующих golang компаний немаленькое.
Кроме того, на golang инструмент, который Google широко использует и для внутреннего применения. Я расцениваю вероятность приблизительно такую же, как если бы Microsoft отказалась от сопровождения C#, то есть "крайне невелика".Но форс мажоры всё равно нельзя исключать, но и к безумству я уже давно не склонен, чтобы писать на ассемблере/машинных кодах, чтобы ни от чего не зависеть - жизнь слишком коротка :)
vtb_k
09.11.2021 18:15+2На golang написан Docker и Kubernetis, я думаю не надо объяснять какое количество облачных сервисов будет готово финансово поддержать команду Google для поддержки языка. Ну и вообще количество широко использующих golang компаний немаленькое.
На С/С++ написано побольше, тем не менее много кто переписывает из плюсов, на другие языки. Как пример — браузеры на раст переписывают потихоньку и не только Mozilla. Go прекрасный язык, я постоянно работаю с ним. Просто поддержка гугла тут явно не преимущество на стороне Go, если сравнивать с Rust.
Tuxman
09.11.2021 00:26+6Мой короткий пересказ статьи.
C/C++ - наши инженеры не перестают делать глупых ошибок, ведь компилятор пропускает, на выходе SIGSEGV, и всё вот это, мы устали.
Python - стильно/модно/молодежно, но явно не для embedded, хотя жаль конечно.
Rust - стильно/модно/молодежно, но готовых спецов на рынке почти нет, переучиваться долго, при этом какая-то Мозила спонсирует, а не Гугл, подождём как дальше будет рынок реагировать.
Go - стильно/модно/молодежно, а главное за спиной стоит Гугл, значит всё будет чётко, при этом синтаксис простой, плюшки удобные, расплачиваться приходится производительностью, но мы прикинули, не хуже Java, а значит Окей.
mrbakminster Автор
09.11.2021 18:11Спасибо :) помимо SIGSEGV есть еще много чудес типа memory leak, mempry corrupt и прочего:)
попробую в следующий раз делать короткий пересказ вначале или в выводах :)
edo1h
11.11.2021 01:45-1не особо слежу, но вроде бы современный c++ позволяет выбрать стиль с минимальным набором возможностей стрелять себе в ноги.
другое дело, что язык не запрещает писать иначе. golang в этом отношении сильнее ограничивает программиста.
PqDn
10.11.2021 18:48Давно уже для embedded решений пара переходить на облачные решения с тупыми клиентами. А там уже не важно какой быстрый язык, эффект узкого горлышка скорей всего на сети будет.
p.s. если вам нужно с энкодером каким-нибудь повзаимодействовать, то тут без вариантов только Си подходит
nagayev
@mrbakminster,с 1 статьей Вас!
По-моему вышло хорошо.
mrbakminster Автор
Благодарю!