Здравствуйте, StanislavK, Вы писали:
SK>>>Беспокоит не столько язык/код, сколько вся экосистема. Если начинаешь не правильно пользоваться тулзами, что-то не так организовывать, использовать "не те" библиотеки, потом очень трудно выкарабкаться. EL>>что значит "не те"? SK>Точно не скажу, но могу дать такой пример, недавно по несчастному стечению обстоятельств надо было сделать гуй на javascript. Наша команда на этом не специализируется, так, что быстренько погуглили и наваяли на jQuery. В целом промахнулись, так как jQuery замечательно только для части того, что нам было надо и сейчас уже приходится переписывать с AngularJS, которую опять же без опыта правильно использовать не просто и там в процессе тоже пару раз промахнулись. Трудно когда нет "ощющения" того, что правильно.
Это называется "Отсутствие опыта" и язык\библиотеки тут как бы совершенно не при чём
Здравствуйте, StanislavK, Вы писали:
SK>Интригующий заголовок, но вопросто не в измерении длинны сами знаете чего Прошу на касаться вопросов производительности.
SK>Вопрос в следующем, если бы вам пришлось начать разрабатывать большую серверную, многопоточную, многокомпонентную, распределенную систему, то какой язык бы вы выбрали? SK>Я сам явист
Используйте то, что знаете.
SK>Подскажите как там у С++.
Чем то напоминает кунг-фу: порог вхождения высокий, всё долго и дорого, у каждого оно лучше чем у других, но результаты восхитительны.
p.s. И детских бед с обработкой беззнаковых типов, не наблюдается :P
80% людей оценивают свое мастерство выше среднего...
2. Как следствие из п.1., у C++ программистов очень часто встаёт вопрос — "как лучше сделать", потому что реально в языке много разных способов сделать одно и то же.
я бы сделал разделение:
1) некоторый низкоуровневый движок, критичный к производительности и памяти, на C++
2) высокий уровень на Java, или чем-то подобном
НО, если Вы сами на C++ не писали хотя бы лет 5, то вряд ли получится что-то серьезное, т.к. слишком много ньюансов.
A>Тривиальные задачи типа прочитать/записать XML или какой-то другой JSON превращаются в кучу работы, с тоннами рукописного кода и кучей возможностей понаделать ошибок
Что-то не верится, что с XML, JSON, и подобными действительно тривиальными задачами дело в C++ обстоит вот так вот уж прям в 9000 раз хуже, чем в Java.
"Больше 100кмч можно ехать на автобане в любом ряду кроме правого крайнего" (c) pik
"В германии земля в частной собственности" (c) pik
"Закрывать школы, при нулевой смертности среди детей и подростков, это верх глупости" (c) Abalak
Здравствуйте, CreatorCray, Вы писали:
PM>>Вот что, а сборка Boost ни разу не проблема, даже на Windows
CC>Надобно заметить что tяue cборка без проблем на Windows выглядит как набор .sln + .vcproj а не какие то странные скрипты.
Даже на Windows есть как минимум MinGW и, может быть, будет Clang, так что набором .sln + .vcproj не удастся ограничиться.
Конечно, bjam — то еще изобретение, но я не знаю других систем сборки с такой же возможностью быстро задать разные варианты сборки и собрать их все. По-моему, для универсальной кросс-платформенной библиотеки типа Boost это самое то. Проект по переводу сборки Boost на CMake забуксовал и новостей оттуда не слышно.
Разработчики Boost сделали всё возможное, чтобы минимизировать усилия сборке. Для тех, кто и это не смог осилить есть бинарные дистрибутивы и пакеты, в том числе и в NuGet.
Так что сборка Boost ни разу не проблема, даже на Windows
Н>Чем то напоминает кунг-фу: порог вхождения высокий, всё долго и дорого, у каждого оно лучше чем у других, но результаты восхитительны.
Ок, ну значит ежели Ц++ — это кунг-фу, получается, Ява — это ММА: порог вхождения низкий, все быстро и дешево, через год тренировок будешь на ура заваливать мастеров кунг-фу, которые от банального прохода в ноги защититься не умеют
"Больше 100кмч можно ехать на автобане в любом ряду кроме правого крайнего" (c) pik
"В германии земля в частной собственности" (c) pik
"Закрывать школы, при нулевой смертности среди детей и подростков, это верх глупости" (c) Abalak
Здравствуйте, StanislavK, Вы писали:
SK>Интригующий заголовок, но вопросто не в измерении длинны сами знаете чего Прошу на касаться вопросов производительности.
SK>Вопрос в следующем, если бы вам пришлось начать разрабатывать большую серверную, многопоточную, многокомпонентную, распределенную систему, то какой язык бы вы выбрали?
C++
SK>Я сам явист, в качестве бефитов явы в данном контексте, я вижу следуюшее: SK>1. Развитая система билда (maven, gradle) с поддержкой зависимостей, модулей и т.д.
Ты просто не знаешь современные билд-системы C++. К тому же, (maven, gradle) -- это уже не совсем билд-системы, а гораздо больше. далеко не факт, что это "больше"
для С++ нужно -- там это делается другими средствами, поскольку бинарный код не кроссплатформный.
SK>2. Реально много библиотек и фреймворков. Надо встроить вебсервер — не проблема, надо математическую билиотечку, тоже пожалуйста, надо какой-нить complex event processing — все есть и т.д.
На С++ сейчас тоже дофига хороших библиотек.
SK>3. Хорошая совместимость с БД, мессаджингом и т.д. Драйвера есть для всех известных мне продуктов.
У С++ всё равно лучше.
SK>4. Легко (это все кончено относительно) интегрирутеся со всем чем угодно, есть JNI, можно в пол-тычка сделать rest-сервис и т.д.
Ну, REST-сервис вообще на чём угодно сделать очень легко, потому что REST -- это идеология, а не технология.
SK>5. Есть очень хорошая среда разработки (IntelliJ), которая легко работает (рефакторинг, поиск и т.д.) с проектами в десятки тысяч файлов.
IntelliJ CLion.
SK>6. У меня лично есть опыт как это все делается на Java. Насколько реально человеку "со стороны" сделать такое на C++? SK>Подскажите как там у С++ в этом плане.
Да всё хорошо, проблема как всегда с "сделать".
А так -- Java настолько дебильный язык и технологии, что я бы не решился с ними связываться вообще.
Единственный бриллиант там у них -- Java-машина.
Но если и делать что-то на ней, то не на Java и не на традиционных стеках фреймворков.
Легче самому сделать всё это на С++, чем разбираться в том зоопарке нелепых технологий, которые нагородили вокруг Java.
KP>По моим ощущениям, JNI не самая интуитивно понятная штука. Поэтому, если с этой стороны подойдете, то либо заранее разберитесь с JNI, либо найдите человека которой в этой хреноте разбирается.
Есть еще вполне положительный опыт ухода от JNI в сторону нативного standalone сервиса-числодробилки. Общение — через сокеты + протобуф. Это оказалось более надежным(падение дробилки не валило процесс жабы) и простым в поддержке, заодно дало возможность выделить дробилки на отдельные сервера.
Новости очень смешные. Зря вы не смотрите. Как будто за наркоманами подсматриваешь. Только тетка с погодой в завязке.
There is no such thing as a winnable war.
Прошу на касаться вопросов производительности.
