Какого рода тех поддержка была?

Prosto Vasya,

Отлично берите c++.

По поводу хипстоты и ентерпрайза. Когда у вас будет диалог с рекрутером (pre screen) не говорите сразу перечень ваших нежеланий.

Рекрутеры немного психологи и очень внимательно читают у вас мотивацию. И громкие заявления от вас они помечают у себя в базе по своему. Категоризируют.

Поэтому воздержитесь.

А когда у вас уже будет на руках offer - вот тогда можно поиграть личное мнение.

Сам по себе java - не сложный язык.

Но вся инфраструктура фреймворков и сред требует длительного времени на изучение.

В с++ по другому немного. Но и порог вхождения в язык высокий. До седины в висках будете входить.

Я позволю себе процитировать в формате списка.
Prosto Vasya- Поддержка разного самописного ПО в брокере. Там вся логика на SQL Server.
- Запускаю готовые скрипты программистов:),
- делаю какие-то исправления в коде по задачам в jira,
- пишу скрипты на выгрузку данных для отчетов, и прочая админская муть.
Вот от этого надо понять что умеет делать автор. И какое отсюда расстояние до С++.
Тут всё важно. Опыт. Возраст. Склад ума. И умение быстро синтезировать новые
решения и понимать (угадывать) что хочет заказчик.

Чтобы делать исправления в SQL-скриптах - много ума не надо. Обычно исправление
очевидно когда очевидна ошибка. Но совсем другая задача - прочитать business requirements
и создать новую рабочую модель ПО. Синтез ПО - сложная вещь. И он далёк от вопросов
сопровождения.

Программирование на С++ это вообще не только С++. Это знание всего стека начиная от
операционки и заканчивая например UI. Здесь и С++ неодинаков. Для Win32 он один. Для MacOS
будет другой и для мобильных устройств вообще третий. Дорожки расходятся.

полудухAnatoly Moskovskyпропущено...

В C++ уже давно достаточно кроссплатформенности, чтобы не надо было адаптировать под платформы.
т.е. можно код из линухового g++ пихать и в андроид, и в айфон?
Будет вам. Это толсто. Даже html5+javascript требует адаптации под разные браузеры и размер диагоналей экранов.

Кроссплатформенность это метафора. Она существует только в системе координат где все "договорились" ее поддержать.

Писать надо на том что вы знаете и сможете поддерживать в будущем.
Ruby. PHP. Node.js. ещё лучше брать похожую по функционалу CMS и подпиливать её потихоньку.
Но я не спец по веб-фреймворкам.поэтому спорить особо не буду в названиях.

Я - больше по серверных бизнес процессам.

Anatoly MoskovskyА то так я могу вам дать исходник на джаве и вы с таким же успехом его в аднроиде не сможете использовать без допила. Потому что там не джава, а просто похожее на нее ))
Сама необходимость кросс-платформенности немного преувеличена. Лично для меня было большая
практическая польза от способности java-байткода реверс-инжинерится и рефлексироваться. Я могу
брать любой бинарь и любую библиотеку и 99% я ее могу использовать. Это - наивысший
уровень интегрируемости. А если очень надо - можно и посмотреть реализацию
без "белых пятен".

В современном Jdk (OpenJdk) идут дискусии и переосмысление самого байткода. Excelsior Jet, AOT и прочие
технологии поставили под сомнение пользу от байткода. Правильнее сказать что количество платформ
по сравнению с 2000 годами сократилось. Энтерпрайзу фактически нужна поддержка в RHEL, а на остальное
плевать.

Кроме того для современного Java EE программирования о котором я знаю достаточно много, доля Java-кода
в исходниках невелика. Это Junior-s считают что надо зубрить Java. На самом деле современный JavaEE код
состоит из:

- Spring Configurations (XML/JavaDSL)
- Прочие конфигурации для фреймворков
- ORM (Hibernate/MyBatis) конфигурации.
- Build subsystems (maven/gradle)
- Business rules (Droolz, e.t.c.) и прочие языки описатели бизнес рулов
- Route rules (Camel) описатели роутов бизнес сообщений в вашей системе. (Xml или JavaDSL опционально)
- Scripts (MVEL, JavaScript)
- Мапперы бинов (Dozer)
- Кастомные серализаторы-парсеры Apache bean-io
- @Generated код. Это продукт (JavaCC, Antlr, Axis, CXF, Thrift, Protobuf e,t,c) технологий. Сорцы выглядят как java но генерируются из ДСЛ вышеуказанных систем.
- Библиотечный Java-код (здесь я вангую более 50%) Сюда всякие гуавы и прочее.
- Собственно Java код (это и есть сухой остаток)

И если вы посчитаете долю Java кода то ее окажется не очень много. А все остальные технологии - это необходимые
левлы синьорити. Или признаки зрелости самого проекта. Чем больше этих технологий - тем ближе проект к Domain Driven.