Traces of the cat's shadow

Хорошо тебе - посмотрел и тем ограничился.

А у меня тут проблема - надо включать в состав продукта софт, написанный на этом языке.

Нормально запакетировать все требуемые библиотеки - нельзя. Приходится по ходу сборки из интернета тащить.

Использовать компилятор который в составе дистрибутива - нельзя, эта версия языка уже не поддерживается сообществом (знаем мы что там за сообщество на букву G). Ну и на "Эльбрус" не портировано.

С "Эльбрусом" - как раз понятна ситуация.

А вот на чём написать софт, который будет уметь:
общаться по сети (клиент-сервер, TCP/UDP),
общаться по последовательным портам (RS разнообразные),
общаться с БД (sqlite, mysql, MS SQL DE, PostgreSQL)
записывать/воспроизводить звук через звуковухи компа,
компилировался в исполняемый бинарник без зависимостей...
в идеале - кроссплатформенный...

Можешь посоветовать?
Это я всё про умный дом думаю. :)

Не понимаю, зачем для "умного дома" условие "один бинарник без зависимостей".

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

Вообще, программу, которая общается по сети и работает со звуковыми и последовательными устройствами, можно писать на чем угодно, так как все необходиммые для этого средства встроены в ядро операционной системы, и в языке нужен только доступ к системным вызовам read и write. (ну там еще по мелочи open, ioctl, socket,bind).

Но наличие условия "компилируемость" свидетелствует о том, что имеется некорректно поставленная задача. Возможно, на самом деле нужно "чтобы оно раотало на слабеньких микроконтроллерах" А значит мы упираемся в переносимость и новомодные языки пролетают со свистом.

А вообще я б эту задачу на питоне решал. Потому что компилируемость - это недостаток. Иногда простительный (если процессорной мощности не хватает). Но на таких языкак как perl и python всегда можно спрятать критичные по производительности куски в компилируемые модули. а основную логику. где торопиться некуда писать на удобном языке.

То же самое с внешними зависимостями - нахрена бояться внешних зависимотей, если тебе программу надо использовать, а не продавать?

Если продавть, и надо ее выпускать под 30 операционных систем. у каждой из которых своя политика по части зависимостей, тогда понятно почему хочется единого бинарника. И то наша практика показывает, что делать переносимые распространяемые приложения на питоне можно. И зачастую это менее трудоемко, чем то же самое в виде компилируемых бинарников.

Но если это грубо говоря мозги твоего дома, то гибкость, которую обеспечит конструктор лего из готовых компонент, связанных скриптовым клеем дает больше преимуществ.


Но если уж очень хочется быть на острие прогресса, то не Go, а Rust.

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

А кроссплатформенность - потому что мне под виндой комфортнее работать, а жить оно будет под линуксом. :)

>Но если уж очень хочется быть на острие прогресса, то не Go, а Rust.

Не то, чтоб хочется на острие быть... Но на дельфях кроссплатформенный сервис не сделать. :) Так что придётся что-либо новое осваивать. Потому и думаю, что оптимальнее под такую задачу.

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

Это я в Debian за четверть века привык доверять и пакетному менеджеру и мейнтейнерам пакетов дистрибутива.
И то если вижу софт, который тянет сотню-другую пакетов по зависимостям, стараюсь поискать альтернативу.

А что касается того, можно ли писать кроссплатформные проекты на Паскале - да, можно. Существует Free Pascal, который, конечно не совсем дельфи, но большую часть дельфячего синтаксиса поддерживает. VCL там по-моему сильно неполноценная, но для умного дома ее и не надо.

Опять же, не обязательно учить что-нибудь новое, можно учить нифига не забытое старое. Например С без крестов.

Вообще на мой взгляд, в хорошем сложном проекте надо задействовать не меньше десятка языков разного уровня абстракции. Что-то на C, что-то может даже на ассемблере, что-то на более высокоуровневых компилируемых языках, что-то на скриптовых - perl,python, tcl, ruby, а то и php, если аллергии на него нет. Ну и shell с make, куда же без них.

У меня, как правило еще awk и sed попадаются в качестве экстендеров шелла.

Но вот чего не стоит делать, так это тащить в умный дом что-то на базе интелоподобных процессоров. aarch64 - наше всё. Машинки класса PI с названиями разных ягод сейчас бывают от 5 до ста долларов в зависимости от потребной мощности уровень лоу-энд писюков перекрывают с запасом.

>А что касается того, можно ли писать кроссплатформные проекты на Паскале - да, можно. Существует Free Pascal, который, конечно не совсем дельфи, но большую часть дельфячего синтаксиса поддерживает. VCL там по-моему сильно неполноценная, но для умного дома ее и не надо.

Угу, знаю про него, и даже что-то пробовал. Но вот чего нового иногда есть смысл осваивать, а то мозг костенеет.

>Опять же, не обязательно учить что-нибудь новое, можно учить нифига не забытое старое. Например С без крестов.

Про "чистый" C думал как раз. Так-то C-подобное и ассемблер я только на микроконтроллерах использую пока. Но вот вопрос, насколько удобно на чистом C работать с БД?

>Вообще на мой взгляд, в хорошем сложном проекте надо задействовать не меньше десятка языков разного уровня абстракции. Что-то на C, что-то может даже на ассемблере, что-то на более высокоуровневых компилируемых языках, что-то на скриптовых - perl,python, tcl, ruby, а то и php, если аллергии на него нет. Ну и shell с make, куда же без них

Вот сейчас стало страшновато. Я ж не настоящий программист. :)

>Машинки класса PI с названиями разных ягод сейчас бывают

Всё так. У них только один минус -- грузятся с MicroSD, в массе своей. Ну а дальше - уже вопрос архитектуры всей системы. Зачастую и они не нужны, всякие STM32 и ESP32 справляются с запасом, а иногда вообще безмозглые девайсы по жёстко прошитому алгоритму задачу решают (к примеру, включить свет по звуку, если темно, и погасить если тишина достаточно длится или светло стало).

У меня сейчас домашний сервер заодно заведует "умным домом" на базе Home Assistant, в дополнение к остальному. Пристроил, чтоб понять глобальное ТЗ для своего.