Здравствуйте, Serginio1, Вы писали:

S> C C++ Я уже писал про CoreRT. Это наследник .Net Core. Там используется компилятор С++

Действительно приятно, что они обращают внимание на производительность, но в моем случае Core скорее противопоказан, т.к. много унаследованного (да и не только) кода цепляется за window-овое окружение. Я и так использую сторонние лайбы (иногда платные), а в случае Core мне понадобиться тащить еще больше стороннего, т.к. по очевидным причинам в погоне за мультиплатформенностью там много чего полезного нет.

Использовать Core меня пожалуй обяжет вектор на импортозамещение в моей конторе, но у меня столько унаследованного кода, что проще поменять контору.
Могу кратко рассказать, как у нас 4 года назад позанимались импортозамещением ...

Есть ряд сильно устаревших систем на FoxPro/dBase (разработка их велась еще с 96-го года), есть ряд устаревших систем использующих не реляционные (очень модные в далекие времена) БД типа Pick https://en.wikipedia.org/wiki/MultiValue (у нас где-то с 94-го), причем эти системы почти не развиваются, но все еще активно используются.

Основной же "интерпрайз" (развивающийся и активно использующийся) я заморозил на .NET 3.5 SP1 (и студия кстати 2008 SP1), а в качестве БД сейчас используется Oracle 10/11 и MSSQL 2008R2/2012.
[Причем Oracle мне тоже навязали 10 лет назад, но это уже другая история.]
Так вот, этот интерпрайз также активно использует данные из БД FoxPro/dBase и Universe, к которым вероятно будет проблематично подобрать вменяемые драйвера при переходе на Core, также есть приличный объем унаследованного кода, который цепляется за WINAPI и прочее виндовое окружение.

Так вот, в конце 2016-го нужно было где-то использовать PostgreeSQL, т.к. он в рамках "импортозамещения" оказался обязателен к использованию в моем учреждении. Хочу обратить внимание, под замещением получается подразумевается — использовать, а не заместить .
Поскольку на горизонте давно маячила задача по сбору аналитики (отчеты/статистика и т.п.) из данных разбросанных по различным хранилищам (в данном случае это получается FoxPro/dBase, Universe/Pick, Oracle, MSSQL), то была создана БД PgSQL, в которую с определенным временным интервалом мигрируются необходимые данные из вышеперечисленных хранилищ. К счастью после миграции эта БД по сути ReadOnly, не считая различных логов.
Отдельно стоит упомянуть страдания по выжиманию производительности из PgSQL, т.к. сколько памяти и ядер я ему не выделял, и как не помогал планировщику запросов hint-ами, но на той же машине он прилично отставал от MSSQL или Oracle. Речь идет в окрестностях 30 млн записей на таблицу, не сказать, что прям много для современного железа. Может конечно беда в том, что наши доморощенные "импортозамещенцы" развернули PgSQL на винде, а в родном НЕ виндовом окружении было-бы лучше. Не могу сказать.

В рамках вышеобозначенного вектора на импортозамещение, теперь собираются с винды переползать на "отечественный" Astra Linux.
Клиенты у меня исторически под Web (ASP.NET). Почти и так все нормально работает под Chromium-браузерами, единственный нюанс, это в ряде мест используются ActiveX-ы для работы с ЭЦП и сканером (в т.ч. сканером штрих-кодов). Для ЭЦП и так есть официальный плагин под различные браузеры, но вот для доступа к сканеру вероятно плагин прийдется писать самому. Вообщем клиентов перевести с винды, пускай и не просто, но все-таки можно.

А серверная часть это беда, т.к. под Linux, очевидным выбором будет Core, но в нём как было выше озвучено много чего нет (ибо мультиплатформенность).