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

_>Так и было поэкспериментировал. Пришел к выводу что для некоторых задач идеальный инструмент.

У меня сейчас сервер на Qt. Многие говорят, что извращение, но со своими задачами справляется идеально. И пул потоков есть, и веб реквесты, и json/xml/sql из коробки.

_>...WinRT не целевая платформа так не является десктопной.
Что? Тут всё с вами понятно

_>Что вы имеете ввиде под новыми API — DirectX12. Если оно вам надо вы будете юзать готовый движок.
Тогда отпадает смысл в U++. Под новыми апи я имею в виду тот же метро.

_>Ultimate++ только на десктопах и серверах работает от i486 до Xeon, пускается даже под Win95 на самом убогом железе и не требует доп. библиотек.
_>Позволяет решать очень широкий круг задач, дешево и быстро.

Этот круг значительно меньше, чем у Qt. При том, что читаемость кода ниже.

_>К примеру java всё вроде отлично полный entrprise всё очень правильно и комьюнить, и поддержка, и фирма вроде серьёзная. Но системы работающие на java требют огромных ресурсов и частенько костылей в виде watchdog-ов т.к. начинаю по неизвестным причинам выедать всю имеющуюся память и люто тормозить. А рекомендации типа min 64Gb озу... Вобщем грусть и печаль.

Ну так на джаве значительно ниже порог вхождения. Каждым инструментом надо уметь пользоваться. К примеру, многие веб-сервисы твиттера написаны на джаве. Есть балансировщик (на плюсах), который мониторит сервера. Как только java приложение понимает, что слишком много мусора, GC есть много времени, высокая фрагментация кучи и вообще, скоро всё ляжет, то приложение уведомляет балансировщик об этом. Балансировщик перестаёт отправлять запросы этому серверу. Сервер заканчивает обрабатывать все уже поступившие запросы и перезагружается. Далее оповещает балансировщик, что он снова готов к работе.

Понятно, что надо выбирать баланс между стоимостью разработки, стоимостью железа и желаемой производительностью. Так вот, в случае U++ всё печально, потому что стоимость разработки очень высокая (а именно — стоимость ответа разработчиков на нетривиальные вопросы).

_>Так никто и не заставляет вас пересаживаться. Инструмент определяется задачами.

Это в идеале. На практике, как правило, инструмент выбирается исходя из квалификации команды и предсказуемости поддержки/документирации/стабильности этого инструмента.
Вот когда портнут KDE на U++ — тогда можно будет сравнивать его с Qt. Пока же это бессмысленно.

_>Главная задача программиста это не использование самой свежей студии, на самом топовом железе, и не создание приложений с самыи свежими api которые приводят к не совместимости с предыдущими системами на которых сидят основные массы. Главная задача выполнить поставленную задачу при фиксированном наборе ограничений.

Вот именно. И в данном случае U++ — это ограничение. Qt прекрасно работает на многих embeded девайсах. А если уж совсем задр*****ть заморачиваться насчёт производительности, то откройте для себя boot-to-qt. Который стал возможен именно благодаря хорошо продуманной архитектуре Qt. А именно — чётких абстракций над различными платформами и железом. U++ до этого — как до луны.

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

_>Так и было поэкспериментировал. Пришел к выводу что для некоторых задач идеальный инструмент.

У меня сейчас сервер на Qt. Многие говорят, что извращение, но со своими задачами справляется идеально. И пул потоков есть, и веб реквесты, и json/xml/sql из коробки.

_>...WinRT не целевая платформа так не является десктопной.
Что? Тут всё с вами понятно

_>Что вы имеете ввиде под новыми API — DirectX12. Если оно вам надо вы будете юзать готовый движок.
Тогда отпадает смысл в U++. Под новыми апи я имею в виду тот же метро.

_>Ultimate++ только на десктопах и серверах работает от i486 до Xeon, пускается даже под Win95 на самом убогом железе и не требует доп. библиотек.
_>Позволяет решать очень широкий круг задач, дешево и быстро.

Этот круг значительно меньше, чем у Qt. При том, что читаемость кода ниже.

_>К примеру java всё вроде отлично полный entrprise всё очень правильно и комьюнить, и поддержка, и фирма вроде серьёзная. Но системы работающие на java требют огромных ресурсов и частенько костылей в виде watchdog-ов т.к. начинаю по неизвестным причинам выедать всю имеющуюся память и люто тормозить. А рекомендации типа min 64Gb озу... Вобщем грусть и печаль.

Ну так на джаве значительно ниже порог вхождения. Каждым инструментом надо уметь пользоваться. К примеру, многие веб-сервисы твиттера написаны на джаве. Есть балансировщик (на плюсах), который мониторит сервера. Как только java приложение понимает, что слишком много мусора, GC ест много времени, высокая фрагментация кучи и вообще, скоро всё ляжет, то приложение уведомляет балансировщик об этом. Балансировщик перестаёт отправлять запросы этому серверу. Сервер заканчивает обрабатывать все уже поступившие запросы и перезагружается. Далее оповещает балансировщик, что он снова готов к работе.

Понятно, что надо выбирать баланс между стоимостью разработки, стоимостью железа и желаемой производительностью. Так вот, в случае U++ всё печально, потому что стоимость разработки очень высокая (а именно — стоимость ответа разработчиков на нетривиальные вопросы).

_>Так никто и не заставляет вас пересаживаться. Инструмент определяется задачами.

Это в идеале. На практике, как правило, инструмент выбирается исходя из квалификации команды и предсказуемости поддержки/документирации/стабильности этого инструмента.
Вот когда портнут KDE на U++ — тогда можно будет сравнивать его с Qt. Пока же это бессмысленно.

_>Главная задача программиста это не использование самой свежей студии, на самом топовом железе, и не создание приложений с самыи свежими api которые приводят к не совместимости с предыдущими системами на которых сидят основные массы. Главная задача выполнить поставленную задачу при фиксированном наборе ограничений.

Вот именно. И в данном случае U++ — это ограничение. Qt прекрасно работает на многих embeded девайсах. А если уж совсем задр*****ть заморачиваться насчёт производительности, то откройте для себя boot-to-qt. Который стал возможен именно благодаря хорошо продуманной архитектуре Qt. А именно — чётких абстракций над различными платформами и железом. U++ до этого — как до луны.