Комментарии 50
@mrbakminster,с 1 статьей Вас!
По-моему вышло хорошо.
В статье не хватает сравнения зарплат.
Почему к C/C++ решили добавить язык высокого уровня?
Как минимум, потому что C++ тоже язык высокого уровня
Это язык высокого уровня с историческими особенностями поколения garbage in garbage out. Rust - это С++, от которого отрезали "С".
Это никто не оспаривает. Но постановка предложения очень сильно хромает. То что в C++ остались некоторые зависимости C - не делает его низкоуровневым языком. Что в чистом C++, по вашему мнению, мешает ему быть высокоуровневым?
Путаница с move-семантикой, наличие UB в казалось бы невинных местах (в районе type aliasing'а и параллельного доступа к переменной из разных тредов).
Многопоточность - 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 который всегда вкурсе что хранит.
Сегодня на C# прекрасно используем кроссплатформенный Rider.
Прямо сейчас пишу код в macOS, билд сервер собирает в докере Linux, а результат запускаю в Windows.
То что написано в статье про c#/.net с реальностью пересекается слабо
коллеги, очень интересна Ваша точка зрения про реальность C#. Чтобы понять насколько это подходит для embedded применений, если есть реальная статистика, подскажите пожалуйта (можно с погрешностью в 20%):
сколько занимает места на диске более-менее современный .net framework под linux?
сколько на диске жрёт минимальное приложение "Hello World!" (RAM+ROM), и вообще прекрасно, если есть статистика по какому-нибудь минимальному http или rpc серверу, чтобы сравнить это с golang
Спасибо!
Мой ответ был насчёт несостоятельности .NET для кроссплатформенной разработки.
Насчёт встроенных систем то тут .NET не конкурент.
Во первых размер больше, .NET 6 уже добавил улучшение в удалении неиспользуемого кода но не так как в Go.
Далее в .NET есть JIT, который также занимает место на диске и память, а также время для запуска.
Для этого есть Ready to Run (R2R) , который увеличивает размер файла за счёт предкомпиляции и ускорения запуска.
.NET 7 обещает нам компиляцию в нативный код и тогда это будет полноценным конкурентным сравнением с GoLang.
Полноценный фреймворк под linux весит 166 Мб ссылка
Но есть несколько вещей, которые были сделаны для оптимизации размера и удобства поставки:
упаковать приложение в один файл ссылка
можно весь фреймворк поставлять вместе с приложением ссылка
если что-то не используется в приложении, это можно не поставлять ссылка
Попробовать можно достаточно легко. Устанавливаем сдк, потом вызываем в терминале
dotnet new consoleДобавляем в csproj файл строку
<PublishSingleFile>true</PublishSingleFile>и вызываем подставив нужную OS
dotnet publish -r osx-x64 -p:PublishTrimmed=true --self-contained --configuration ReleaseУ меня получилось 13 мб исполняемый файл и hello world при запуске занял в памяти 9 Мб.
Если заменить dotnet new concole на dotnet new web, то получим простой веб сервер размером 38 Мб на диске и 32 Мб оперативной памяти при запуске.
Не совсем понятно, что писать собираетесь. Вызовы С<=>Go занимают около сотни наносекунд, что почти на два порядка больше, чем C<=>Rust.
Для некоторых применений это фатально, для других вполне норм.
Мало того, что они занимают приличное время, так ещё и проблемы могут быть при кросс-компиляции. А если собирать нормально, то там танцы с gonative, что тоже тот ещё секс. Хотя может что с 2015 года и изменилось.
Будут нарисованы (для примера) микросервисы мониторинга, управления настройками, обновления с резервированием, некоторые приложения верхнего уровня. Там где наносекунды имеют значение будет С. На примере светодиодов - "ШИМмить" golang'ом светодиод бессмысленно - надо писать компонент на C/C++, который будет принимать на вход паттерн мигания/плавного зажигания/затухания светодиодом, а golang как gRPC/или сервис REST API, реализует интерфейс общения с внешними клиентами/работу с конфигом(БД, если надо)/логику обновления приложения, взаимодействие с другими компонентами в системе и прочее.
P.S. очевидно, что мониторинг/настройки/обновления уже есть готовые, но некоторые в linux обладают непозволительным(моё оценочное суждение :) ) количеством зависимостей.
Я хотел бы ворваться в Линукс GUI. Из опыта Delphi / C#. Есть какие нибудь фреймворки под C(++) или Golang которые не тянут 100500 зависимостей и легко подключить в какую-нибудь IDE? Т.е. желательно комплект IDE+GUI framework и очень хочется чтобы это были сотни мегабайт а не гигабайты. Обращаюсь к автору статьи, но если кто знает - тоже набросайте вариантов. GUI нужен базовый, без наворотов.
Посмотрите:
https://github.com/gotk3/gotk3
Я на нем писал гуй для малинки. Мне не с чем его сравнивать, т.к. "попробовал и зашло".
А сам гуй я делал в Glade.
Если есть требование к кроссплатформенности, и есть много сил и воли, то можно еще обратить внимание на flutter (dart). Его, вроде как, выбрали дефолтной технологией для ubuntu приложений. Но он очень своеобразный :)
где наконец-то порешают долгожданный вопрос с обработкой ошибок
Кажется, функционала оборачивания и проверки ошибок из go 13 достаточно для большинства задач.
Свои языки программирования использую так:
Линукс: С, можно С++. Из коробки есть gcc make. Нужны библиотеки? Иди в /usr/lib, /usr/include. Тоже думал ой, то же си. Но как практика показала, ничего лучше нету. Но формошлёпы не поймут меня. Пусть познают дзен. Го и раст от лукавого.
Виндовс: С#. Потому что вижуал студия, потому что Майкрософт, потому что виндовс формы, с++ задолбаешся библиотеки подключать, и с PATH игратся.
Автоматизация, если не важна супер скорость то это питон. Там все просто и понятно. Хотя можно ограничиться и башом, если под Линукс.
Делать кроссплатформенные проги под десктоп это все же electron. Потому что виндовс хрен ложил на POSIX, а единственное до чего не добрались лапы индусов это до стандартов браузера. Полгига занимает, но все же бугурт облегчает. Тем более сейчас трендово.
Мой петроджект кроссплатформенный гуй к Apache Kafka на С++. Не играюсь с PATH, зависимости идут через пакетные менеджеры. Под Windows собираю через Visual Studio. Что я делаю не так?
STM32MP153/512MB DDR3/8GB. STM32MP153 это microprocessors а не microcontroller.
Это уже ни какой не embedded.))
С такими мощностями можно писать на любом языке, на котором дешевле с точки зрения трудозатрат. Если нет специфических требований.
Современные нейросети кладут все что угодно на лопатки. Причем задействованы могут быть и векторные расширения и GPU и все ядра.
Это так кажется. предыдущая попытка была с мелкой архитектурой на базе 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МБ ОЗУ и специфические требования к устройству, то всё равно надо быть аккуратным :)
В целом, Rust действительно требует некоторого душевного перерождения. Для С-background это в первую очередь наличие гигиены: нет, мы не едим руками и не моем посуду в унитазе, даже если это удобно прямо здесь и сейчас. Когда вот эта часть преодолена, любой человек, знающий С++ на умеренном уровне, с лёгкостью входит в Rust и ощущает блага цивилизации.
Перейти с Python в Rust куда сложнее, потому что одновременно сваливаются и статические типы, и generic'и, и трейты, и lifetimes, и (изящно замаскированные) указатели.
Samsung/Qualcomm/Broadcom - уже перешли(переходят) на go в своей разработке. Похоже это тенденция.
Но в java вы немного не туда смотрели... Уже есть GraalVM, который умеет компиляться в натив и напрямую вызывать сишные библиотеки. Сама JVM тянет 10мб и бинарник получается не сильно жирнее гоуланг. Правда все это для 64 бит онли.
Если с специалистами Явы проще чем с гоуланг, то посмотрите ещё раз.
Allwinner уже на 64 бита перешёл. Даже малинка ща 15$ уже там. Дальше и все остальные уйдут так же как и 15-20 лет назад с 8 бит на 32 ибо окажется более массово и дешевле
64-бита решает в векторных расширениях. Чуть ли не четырехкратный прирост относительно 32-битной ОСи на той же железке.
Тоже выбрал Go для embedded Linux проектов и автоматизации на них. И это прямо счастье какое-то. Основные плюшки которые мне зашли:
Кросплатформенность из коробки. Одной командой бинарник собирается для Arm и все что надо там внутри. Просто копируешь его на таргет и оно работает. Python тут и рядом не стоит.
Многопоточность. Наконец-то где-то осознали, что в процессорах давно уже не одно ядро и дали нормальный способ этим пользоваться.
Простой, С подобный синтаксис.
Через какое-то время у меня сложилось ощущение,что Go это такой более человеческий Python для тех кто привык к С. Сейчас если в проекте есть Linux то в сторону C/C++ смотрю только в случае крайней необходимости.
Спасибо за комментарий! если не секрет, а что за конфигурация железа? CPU/ROM/RAM и что в целом за задачки приходится решать ею?
Железо полностью кастомное включая SoC. Ядра процессора ARM64. Обрабатывает сетевой траффик в датацентрах.
Да, для таких применений golang по-моему "сам Бог велел". Но проц, конечно желателен какой-то специфический, если не делать свой, а использовать существующий типа MediaTek, Realtek, Broadcom. Мой опыт показывает, что самому такое железо "с нуля" (со своей схемотехникой/трассировкой) можно сделать только при "адских количествах" устройств в сотни тысяч, или использовать готовые решения/SOM модули от дизайн хаусов.
Спасибо за информацию!
Как-то попробовал разобрать из Go Regexp часть кода, в котором компилируется регулярка-структура. Получилось 11.5 тысяч строк. Это без i/o ридера. На языке 1С получилось 2.5 тысячи. Как по мне высокоуровневость у Go своеобразная.
Верим больше в технологии развиваемые гигантом Google, что не «помрет», как другие, так как активно используется в массовых решениях (Google Chrome, Google Earth, YouTube, Kubernetes, Docker, GitHub)
Извините, но после смерти гугл ридера веры в гугл у меня нету, тут у раста как раз преимущество, потому что язык уже отделен от крупных корпораций и имеет уже Rust Foundation, в котором тот же гугл в спонсорах, но не только он.
мне кажется, что несопоставимое сравнение. RSS Google Reader это коммерческий проект/продукт, который стал убыточным, поэтому его закрыли.
На golang написан Docker и Kubernetis, я думаю не надо объяснять какое количество облачных сервисов будет готово финансово поддержать команду Google для поддержки языка. Ну и вообще количество широко использующих golang компаний немаленькое.
Кроме того, на golang инструмент, который Google широко использует и для внутреннего применения. Я расцениваю вероятность приблизительно такую же, как если бы Microsoft отказалась от сопровождения C#, то есть "крайне невелика".
Но форс мажоры всё равно нельзя исключать, но и к безумству я уже давно не склонен, чтобы писать на ассемблере/машинных кодах, чтобы ни от чего не зависеть - жизнь слишком коротка :)
На golang написан Docker и Kubernetis, я думаю не надо объяснять какое количество облачных сервисов будет готово финансово поддержать команду Google для поддержки языка. Ну и вообще количество широко использующих golang компаний немаленькое.
На С/С++ написано побольше, тем не менее много кто переписывает из плюсов, на другие языки. Как пример — браузеры на раст переписывают потихоньку и не только Mozilla. Go прекрасный язык, я постоянно работаю с ним. Просто поддержка гугла тут явно не преимущество на стороне Go, если сравнивать с Rust.
Мой короткий пересказ статьи.
C/C++ - наши инженеры не перестают делать глупых ошибок, ведь компилятор пропускает, на выходе SIGSEGV, и всё вот это, мы устали.
Python - стильно/модно/молодежно, но явно не для embedded, хотя жаль конечно.
Rust - стильно/модно/молодежно, но готовых спецов на рынке почти нет, переучиваться долго, при этом какая-то Мозила спонсирует, а не Гугл, подождём как дальше будет рынок реагировать.
Go - стильно/модно/молодежно, а главное за спиной стоит Гугл, значит всё будет чётко, при этом синтаксис простой, плюшки удобные, расплачиваться приходится производительностью, но мы прикинули, не хуже Java, а значит Окей.
Давно уже для embedded решений пара переходить на облачные решения с тупыми клиентами. А там уже не важно какой быстрый язык, эффект узкого горлышка скорей всего на сети будет.
p.s. если вам нужно с энкодером каким-нибудь повзаимодействовать, то тут без вариантов только Си подходит
Golang для Embedded Linux