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

V>Потому что если бы со своим наивным подходом посмотрел, какой путь у нас совершают данные в нашем асинхронном логгере, у тебя бы сломался моск. )) Безблокировочность она такая, угу. Но это минимально затратно по тактам в целевом потоке обработки данных, а нам требуется именно такая минимальность.

Ага, ну то есть — нам нужна супер кастомная либа логгирования, но раз её не добавят в стандарт (потому что остальным нафиг не нужна) — то я за то, чтобы все остальные 99,9% разработчиков продолжали писать свои велосипеды?

V>Они отличаются по архитектуре, потоковой модели и, соответственно, по политикам блокировок.

Да в них всё нужное настраивается, а некоторые вещи, как "политики блокировок" в 99% случаях нафиг не нужны.

P>>Или ты про тот 0.001% уникальных случаев?
V>Каждый случай, требующий эффективности — по-своему уникален.
V>Потому что не может абстрагироваться от конкретной потоковой модели происходящего.

Ахахаха)))) Ты хочешь сказать, что все вещи _надо_ велосипедить? Ведь каждый случай по своему уникален. И получается что писать библиотеки вообще нет смысла? Ведь идеальных библиотек не бывает в принципе. Так или иначе каждая либа покрыват лишь некоторый процент случаев применения.

V>>>Просто на плюсах не заворачивают в дебильный XML то, что туда явно не лезет...

Оххх, да-да, оно конечно, все "нубы". Но беда в том, что такое "нубское" решение рвёт на рынке любое кастомно-плюсовое как тузик грелку во всех отраслях, где может конкурировать.
Отвечу твоими же словами. С этой херней сразу в сад. Потому что и опыт есть и видел разного.
Реально влом пережевывать настолько очевидные вещи, ибо жевать придётся много.

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

Конечно, но инженер в 99,9% случаев никогда не будет заново рассчитывать, создавать и испытывать базовые конструкции — когда достаточно типовых. Более того, в современном мире, в подавляющем большинстве случаев результат собирают из стандартных конструкций из каталога.

V>Пипец...
V>За то время, которое тебе потребуется на дотнете только лишь для стадии кодогенерации, в нейтиве можно сделать проект целиком.

точно пипец, до чего можно договориться

V>С БД в дотнете-джаве хуже.
V>С сетью вообще хана.
V>Конфиги мы уже обсудили.
P>>и плагинами
V>COM, WinRT — вполне компонентные технологии.
V>RPC отродясь возникло как нейтивное.
V>Асинхронности в дотнете НЕТ. ))
V>Есть её муляж в таком зачаточном состоянии, что признать ЭТО за наличие асинхронности сложновато.


OKAY

P>>как раз из-за скорости разработки и отсутствия рисков по сравнению с плюсами.
V>Если надо нарисовать неспешный магазинчик, то C#, Java, PHP, RoR — очень даже неплохие решения.
V>А если биржу — то увы.

О как, ну то есть только в отрасли криточной к ресурсам.
Напомни мне какое соотношение проектов уровня "неспешный магазинчик" и "биржа"? Один к миллиону, или это я слишком уж оптимистично оценил?
Хм, интересно, и почему же такой замечательный язык, с такой замечательной инфраструктурой (по твоим словам), с невероятно быстрой скоростью написания проектов так позорно сливает остальным языкам?
Все остальные дураки и мазохисты?

V>...то в "чистой заказухе" останется денег и работы даже меньше, чем выделяется денег и работы на встраиваемое ПО производителями оборудования...

Частично верно, но ты забываешь один ньюанс — соотношение количества проектов на страиваемое ПО (и другое, критичное к ресурсам) и остальной заказухи, что на корню рушит твои выводы. Взять работу любой большой софтверной компании — на 2-3 проекта по встраиваемому ПО — десятки проектов по с/х, медицинскому, медиа, казуально-игровых, кастомных решений для бизнеса и другому ПО.