>.NET компилируется в машинный код и исполняется непосредственно процессором.
Это только пока вашему коду ничего не нужно от системы. Когда что-то требуется .net код идет к системе через прослойки.
>Еще раз: это не мешает использовать nuget где угодно.
Вы правда в верите в то, что отсутствие интеграции не влияет на вероятность использования nuget?
(мы же говорили не о том, что его нельзя использовать, а о том насколько он репрезентативен как источник для количества С++ библиотек)
>Можешь показать ссылку где эту кучу можно увидеть?
Эта «куча» не собрана в одном месте. Правда. Есть много платных и бесплатных библиотек, но нету репозитория где бы они все были. Это конечно недостаток инфраструктуры, но не значит что библиотек нет.
Их просто сложнее искать т.к. они не собраны в одну кучу.
> Что такого в вебе, что C++ не справляется, и что не критично в других областях?
Мне кажется в первую очередь это нетерпимость к кривому коду. На C++ вполне можно завалить сервер кривым кодом, а это очень большой риск для веб сервера.
Managed-же языки, как правило, не в состоянии завалить сервер, вероятно это одна из основных причин, почему они предпочтительнее.
>Во вторых, там вообще не факт, что есть живая ISAPI, а не редирект.
Возможно ее там уже и нет, к сожалению узнать это точно можно лишь покопавшись на самом сервере.
Я не писал что на С++ в других областях писать «не дороже».
Но в других областях «доплата» за использование С++,- заметно меньше чем в вебе.
И кстати, С++ — используется для веба например на ebay.com, посмотрите код его страниц, они достаточно часто обращается к некой eBayISAPI.dll :) Но я не уверен что это хороший пример того как надо делать.
> Про кучу прослоек ты сам придумал.
Даже .net на Windows прослойка. И я с вами, на «ты» пока что не переходил, извольте это учитывать в ваших постах.
>пример кода на Qt, который без директив условной компиляции
Директивы условной компиляции в С++ используются даже в базовых заголовках. Примером кода можно привести массу, но примеров целостного приложения без директив условной компиляции вы не найдете.
>Вообще ссылаться на википедию в профессиональной дискуссии — все равно что считать надписи на заборе за доказательства теорем. Показывет ваш уровень.
Разве в википедии написана не правда?
Знаете, по степени агрессивности ваших высказываний мне кажется что вы тут на зарплате от Микрософта, и просто рекламируете его технологии, я прав?
Еще раз. Nuget не интегрирован ни с одной средой разработки С++ кроме тех, что распространяет микрософт. Это достаточно для того чтобы считать его не ориентированным на С#/
>очевидным является тот факт что сборщики мусора делают автоматическую оптимизацию (сборку копированием, уплотнение объектов в памяти), что повышает производительность,
Я чаще встречался с другим поведением сборщика мусора. Фундаментально сборщик мусора решает очень общую задачу, поэтому даже при идеальной реализации у него меньше шансов ее решить оптимально, чем у не-кривой ручной реализации, написанной под конкретную задачу. Менеджер памяти далеко не всегда может предсказать что захочет ваш код в следующий момент, а вы — можете.
>в большинстве своем у программистов нет ресурсов/квалификации повторить тоже самое вручную
Это печально, но думаю поправимо.
>сейчас производительность машинных кодов вообще дело десятое для 99% бизнес приложений: чтение с диска, чтение с сети, работа с БД, параллельное выполнение, dead lock'и, плохая архитектура — все куда более страшные причины
Многое из перечисленного следствие изначально непросчитанной архитектуры и выбора технологий, то есть эти проблемы не возникают внезапно… Сам по себе переход на unmanaged языки их конечно не решит, но и трудоемкость выправления таких приложений может быть соизмерима с их переписью.
>Вы правда верите что столько сил потрачено для разработку Java и С# когда был такой замечательный универсальный C++ просто так? Все не умели считать и думать?
Любые траты сил можно сравнить с инвестициями, а инвестиции, с рациональной точки зрения, привлекает ожидание роста. Пока на горизонте был рост производительности заниматься «ловлей блох» в с низкоуровневой оптимизацией не было смысла, это было бы просто убыточно потому что более производительное железо появлялось быстрее, чем писался оптимизированный код.
Для той рыночной ситуации такая стратегия была вполне разумна, по крайней мере для не очень больших проектов, но рыночная ситуация постоянно меняется.
Кстати, не знаете ли вы проектов с ожидаемым временем развития 10-20 лет и более, написанных на Java? (или C#, было бы интересно посмотреть на них..)
> Ага, только код не будет ничего рисовать, обрабатывать ввод, поучать по сети и читать\писать в постоянную память. То есть бесполезный код. А на C# можно можно полноценное приложение сделать.
Я не уверен, что приложение работающее с системой через кучу прослоек, и пытающееся использовать одинаковый UI на всех платформах можно назвать полноценным. Но, если угодно, тоже-самое можно сделать и на C++ используя Qt.
> почему бы не стал рекомендовать C++ для бекенда? Наверное потому что такой хороший язык, да?
Нет, не по этому :)
Очень мало веб фреймворков для С++, в результате многое придется писать самому, это все-таки дороговато.
> Что значит «ориентирован»? там есть пакеты и для C++, только их мало.
Вот смотрите:
en.wikipedia.org/wiki/NuGet
Разработчик: Microsoft — ок, это не всегда плохо.
Разработан на C# под .net framework, — казалось бы ладно, но это уже значит что как есть он мало где запустится.
Интегрирован с Visual Studio и SharpDevelop и все. Понимаете? Больше ни с чем.
С 2012 студией приходит preinstalled — а действительно что в этом такого? Explorer же идет preinstalled с Windows и ничего, Microsoft так часто делает со своими продуктами.
Думаете Visual Studio и SharpDevelop являются основными средствами для разработки на С++?
Уверяю вас — не являются, и хотя доля Visual Studio велика, нельзя серьезно говорить о том NuGet ориентирован на С++ если кроме Visual Studio под Windows он не поддерживает ни одну платформу.
> если HDD/SSD не занят другими процессами
Я именно об этом и говорю. Не надо занимать другими процессами — и у вас будет производительность, а если полезете в параллель — получите падение производительности везде, так как железо будет дольше переключаться, чем передавать вам данные. (кстати с SSD ситуация лучше в этом плане)
> Базы данных, интеграция, любые высоконагруженные приложения ВСЕГДА утыкаются в скорость чтения с диска
Я разбирал другой пример. Упакованный структурированный файл, который нужно разложить в объектную модель, а не storage базы данных формата оптимизированного до такой степени, что времени на его обработку практически не требуется. Конечно там будет все упираться в железо.
>Распаковка архива в памяти выполняется намного быстрее чтения с диска почти всегда (есть совсем уж медленные форматы, но их в интеграции не используют), основное замедление происходит когда пытаешься записать распакованный архив на диск.
Я согласен с тем что сравнение с копированием не совсем корректное, если объем распакованных данных много больше упакованных.
Но мы можем упаковать например какой-нибудь divx\xvid AVI — он практический не сожмется, поэтому разницы времени записи между копированием и распаковкой не будет. Однако почему-то он будет дольше распаковываться, чем просто копироваться…
На самом деле вопрос скорее в том почему ниша оказалась занята PHP?
Первые версии ASP появились примерно в тоже время что и первые версии PHP, да и к моменту выхода ASP.NET, нишу еще нельзя было назвать занятой.
Другой интересный вопрос это снижение доли ASP.NET
w3techs.com/technologies/history_overview/programming_language/ms/y
(пусть даже в этом сегменте)
У меня есть некоторый опыт разработки под ASP.NET, но с PHP я знаком только по книжкам и огромному количеству сайтов на нем написанных. Я вряд-ли смогу провести их детальное сравнение… Поэтому как пользователь могу лишь сказать что сайты на PHP по какой-то причине работали достаточно быстро, а на ASP.NET — медленно… Может это и явилось причиной предпочтения PHP?
>На основании чего вы делаете этот вывод? Вы лично делали такие миграции для обоих языков?
Я видел начальный, конечный результат и потраченное на это время в том и другом случае.
>Зато я пользуюсь ими на телефоне.
У вас наверное WinPhone)
> В разных компаниях или в одной?
Закрытие ASP.NET проектов в двух разных, миграция C# на С++ в другой.
>Мы можем только смотреть на то, что делает MS, а делает он многое
Да, это безусловно важно. Мне кажется они будут пытаться увеличить прибыль, которая падает уже несколько кварталов подряд
Вот смотрите, HDD умеет отдавать данные со скоростью примерно 80 Mb/s, SSD так вообще 300 Mb/s, эта скорость вполне реальна если просто брать данные с носителя в память как есть.
И вы хотите сказать что сжатый структурированный структурированный поток данных распаковывается и раскладывается в объектную модель параллельно процессу чтения, с той-же скоростью? Если так, хотелось бы узнать, в каких именно задачах скорость обработки входного потока в 80 Mb/s-300 Mb/s вызывала проблемы?
И да, простой пример: по такой логике копирование архива и распаковка архива должны занимать почти одинаковое время, но это не так.
mono — лучше чем ничего, но честно говоря немного страшновато использовать его в уомерческих проектах. Может это излишняя параноя.
А разработчику на C++ этот переход обойдется бесплатно?
нет, но заметно дешеале.
.net-приложения прекрасно масштабируются горизонтально
Тут вопрос куда упремся и того насколько верно мы предсказали изменение объемов данных у заказчика.
.net тут никак не мешает.
Вы возможно не часто пользовались .net приложениями на какихнибудь Atom-ах…
Я вот в .net что-то вроде 12-ти лет, и за все это время ни с одним проектом ничего подобного не произошло.
У вас очень удачная статистика, у меня есть другая. Например года 3 назад в моей статистике прошла волна закрытий ASP.NET проектов, предназначенных для «внутреннего пользования» и некоторые библиотеки были переписаны с C# на С++ в целях повышения производительности и совместимости с iOS\MACOS.
И я пока не уверен, что все худшее для .net, в моей статистике, уже позади.
Если мы говорим о применении php в интернете, то мне кажется статистика достаточно адекватна.
То что на одном движке собрана масса сайтов-клонов и то что есть сотни блогов, движки которых на php вряд-ли ее искажают.
Ведь никто не мешает писать сайты-клоны на ASP.NET, никто не мешает создавать хостинги блогов на ASP.NET, то что их мало — это врадли вина метода измерения.
Если говорить внутриенних сайтах, работающих в локальной сети организации, то да — эта статистика не адекватна для сайтов внутреннего пользования. Но где мы можем найти статистику по ним?
Я могу нарисовать массу апокалиптических сценариев, если угодно:
1. Сильная реорганизация, смена приоритетов в Микрософте и следующая за ней заморозка развития .net. (MFC они неоднократно замораживали, некоторые платформы хоронили заживо, нельзя исключать что .net-у тоже достанется)
2. Переход заказчика на что-то вроде Эльбруса (сценарий конечно фантастический, но может когото он и постигнет) Да и кто знает какие платформы появятся через 3-5 лет…
3. Возросшие, со времянем эксплуатации, объемы данных и вычислений при недостатчном росте производительности железа (наиболее вероятный сценарий в случае если за эти 3-5 лет количество данных сильно увеличивается)
4. Желание заказчика перейти на «зеленые технологии» с потреблением 20w на рабочее место (а вдруг?)
Можно придумать и еще чтонибудь. Я бы дал примерно 30% на то что один из пунктов может случиться в течении 3-5 лет и нанести серъезный урон проекту.
Смысл поста в том, чтобы избежать огульных суждений при выборе средств разработки.
Как вы определили это «большинство» проектов? Терминами «нету сотен новых проектов» и «дофига»?
Есть ли у вас статистика по их востребованности и окупаемости?
И да, возвращаясь к вашему предидущему посту.
На С++ можно писать код, который заработает на всех мобильных устройствах.
Для веб бэкэнда используется в основном php, но я кстати пробовал писать веб бэкэнд на С++, это вполне реально, но я бы наверное не стал рекомендовать его.
Насчет процента пакетов nuget для С++, может быть дело просто в том что nuget ориентирован на .net, а не на С++?
Необязательно постоянно «не прекращать тестировать, оптимизировать и вылавливать грубли одновременно на всех платформах»,
При необходимости поддержки MacOS, если 5 лет сидели на Windows и писали «кроссплатформенно» вам придется потратить условно 3-6 месяцев на вылавливание платформо зависимых граблей. (этих граблей не более 10% от общего количества граблей, т.е. большинство багов вылезают на всех платформах)
Если же вы 5 лет присали под Windows не «кроссплатформенно», то вам придется переписывать огромное количество кода и тратить уже годы на поддержку MacOS (тут конечно многое зависит от того, как много специфичной Windows функциональности было притянуто за эти 5 лет)
Это только пока вашему коду ничего не нужно от системы. Когда что-то требуется .net код идет к системе через прослойки.
>Еще раз: это не мешает использовать nuget где угодно.
Вы правда в верите в то, что отсутствие интеграции не влияет на вероятность использования nuget?
(мы же говорили не о том, что его нельзя использовать, а о том насколько он репрезентативен как источник для количества С++ библиотек)
>Можешь показать ссылку где эту кучу можно увидеть?
Эта «куча» не собрана в одном месте. Правда. Есть много платных и бесплатных библиотек, но нету репозитория где бы они все были. Это конечно недостаток инфраструктуры, но не значит что библиотек нет.
Их просто сложнее искать т.к. они не собраны в одну кучу.
Мне кажется в первую очередь это нетерпимость к кривому коду. На C++ вполне можно завалить сервер кривым кодом, а это очень большой риск для веб сервера.
Managed-же языки, как правило, не в состоянии завалить сервер, вероятно это одна из основных причин, почему они предпочтительнее.
>Во вторых, там вообще не факт, что есть живая ISAPI, а не редирект.
Возможно ее там уже и нет, к сожалению узнать это точно можно лишь покопавшись на самом сервере.
Но в других областях «доплата» за использование С++,- заметно меньше чем в вебе.
И кстати, С++ — используется для веба например на ebay.com, посмотрите код его страниц, они достаточно часто обращается к некой eBayISAPI.dll :) Но я не уверен что это хороший пример того как надо делать.
Даже .net на Windows прослойка. И я с вами, на «ты» пока что не переходил, извольте это учитывать в ваших постах.
>пример кода на Qt, который без директив условной компиляции
Директивы условной компиляции в С++ используются даже в базовых заголовках. Примером кода можно привести массу, но примеров целостного приложения без директив условной компиляции вы не найдете.
>Вообще ссылаться на википедию в профессиональной дискуссии — все равно что считать надписи на заборе за доказательства теорем. Показывет ваш уровень.
Разве в википедии написана не правда?
Знаете, по степени агрессивности ваших высказываний мне кажется что вы тут на зарплате от Микрософта, и просто рекламируете его технологии, я прав?
Еще раз. Nuget не интегрирован ни с одной средой разработки С++ кроме тех, что распространяет микрософт. Это достаточно для того чтобы считать его не ориентированным на С#/
Я чаще встречался с другим поведением сборщика мусора. Фундаментально сборщик мусора решает очень общую задачу, поэтому даже при идеальной реализации у него меньше шансов ее решить оптимально, чем у не-кривой ручной реализации, написанной под конкретную задачу. Менеджер памяти далеко не всегда может предсказать что захочет ваш код в следующий момент, а вы — можете.
>в большинстве своем у программистов нет ресурсов/квалификации повторить тоже самое вручную
Это печально, но думаю поправимо.
>сейчас производительность машинных кодов вообще дело десятое для 99% бизнес приложений: чтение с диска, чтение с сети, работа с БД, параллельное выполнение, dead lock'и, плохая архитектура — все куда более страшные причины
Многое из перечисленного следствие изначально непросчитанной архитектуры и выбора технологий, то есть эти проблемы не возникают внезапно… Сам по себе переход на unmanaged языки их конечно не решит, но и трудоемкость выправления таких приложений может быть соизмерима с их переписью.
>Вы правда верите что столько сил потрачено для разработку Java и С# когда был такой замечательный универсальный C++ просто так? Все не умели считать и думать?
Любые траты сил можно сравнить с инвестициями, а инвестиции, с рациональной точки зрения, привлекает ожидание роста. Пока на горизонте был рост производительности заниматься «ловлей блох» в с низкоуровневой оптимизацией не было смысла, это было бы просто убыточно потому что более производительное железо появлялось быстрее, чем писался оптимизированный код.
Для той рыночной ситуации такая стратегия была вполне разумна, по крайней мере для не очень больших проектов, но рыночная ситуация постоянно меняется.
Кстати, не знаете ли вы проектов с ожидаемым временем развития 10-20 лет и более, написанных на Java? (или C#, было бы интересно посмотреть на них..)
Я не уверен, что приложение работающее с системой через кучу прослоек, и пытающееся использовать одинаковый UI на всех платформах можно назвать полноценным. Но, если угодно, тоже-самое можно сделать и на C++ используя Qt.
> почему бы не стал рекомендовать C++ для бекенда? Наверное потому что такой хороший язык, да?
Нет, не по этому :)
Очень мало веб фреймворков для С++, в результате многое придется писать самому, это все-таки дороговато.
> Что значит «ориентирован»? там есть пакеты и для C++, только их мало.
Вот смотрите:
en.wikipedia.org/wiki/NuGet
Разработчик: Microsoft — ок, это не всегда плохо.
Разработан на C# под .net framework, — казалось бы ладно, но это уже значит что как есть он мало где запустится.
Интегрирован с Visual Studio и SharpDevelop и все. Понимаете? Больше ни с чем.
С 2012 студией приходит preinstalled — а действительно что в этом такого? Explorer же идет preinstalled с Windows и ничего, Microsoft так часто делает со своими продуктами.
Думаете Visual Studio и SharpDevelop являются основными средствами для разработки на С++?
Уверяю вас — не являются, и хотя доля Visual Studio велика, нельзя серьезно говорить о том NuGet ориентирован на С++ если кроме Visual Studio под Windows он не поддерживает ни одну платформу.
Я именно об этом и говорю. Не надо занимать другими процессами — и у вас будет производительность, а если полезете в параллель — получите падение производительности везде, так как железо будет дольше переключаться, чем передавать вам данные. (кстати с SSD ситуация лучше в этом плане)
> Базы данных, интеграция, любые высоконагруженные приложения ВСЕГДА утыкаются в скорость чтения с диска
Я разбирал другой пример. Упакованный структурированный файл, который нужно разложить в объектную модель, а не storage базы данных формата оптимизированного до такой степени, что времени на его обработку практически не требуется. Конечно там будет все упираться в железо.
>Распаковка архива в памяти выполняется намного быстрее чтения с диска почти всегда (есть совсем уж медленные форматы, но их в интеграции не используют), основное замедление происходит когда пытаешься записать распакованный архив на диск.
Я согласен с тем что сравнение с копированием не совсем корректное, если объем распакованных данных много больше упакованных.
Но мы можем упаковать например какой-нибудь divx\xvid AVI — он практический не сожмется, поэтому разницы времени записи между копированием и распаковкой не будет. Однако почему-то он будет дольше распаковываться, чем просто копироваться…
Первые версии ASP появились примерно в тоже время что и первые версии PHP, да и к моменту выхода ASP.NET, нишу еще нельзя было назвать занятой.
Другой интересный вопрос это снижение доли ASP.NET
w3techs.com/technologies/history_overview/programming_language/ms/y
(пусть даже в этом сегменте)
У меня есть некоторый опыт разработки под ASP.NET, но с PHP я знаком только по книжкам и огромному количеству сайтов на нем написанных. Я вряд-ли смогу провести их детальное сравнение… Поэтому как пользователь могу лишь сказать что сайты на PHP по какой-то причине работали достаточно быстро, а на ASP.NET — медленно… Может это и явилось причиной предпочтения PHP?
Я видел начальный, конечный результат и потраченное на это время в том и другом случае.
>Зато я пользуюсь ими на телефоне.
У вас наверное WinPhone)
> В разных компаниях или в одной?
Закрытие ASP.NET проектов в двух разных, миграция C# на С++ в другой.
>Мы можем только смотреть на то, что делает MS, а делает он многое
Да, это безусловно важно. Мне кажется они будут пытаться увеличить прибыль, которая падает уже несколько кварталов подряд
www.microsoft.com/investor/EarningsAndFinancials/Earnings/PressReleaseAndWebcast/FY15/Q3/default.aspx
Это показывает, что-то неправильно в их стратегии развития, и они безусловно как-то попытаются это исправить, вопрос в том как именно…
И вы хотите сказать что сжатый структурированный структурированный поток данных распаковывается и раскладывается в объектную модель параллельно процессу чтения, с той-же скоростью? Если так, хотелось бы узнать, в каких именно задачах скорость обработки входного потока в 80 Mb/s-300 Mb/s вызывала проблемы?
И да, простой пример: по такой логике копирование архива и распаковка архива должны занимать почти одинаковое время, но это не так.
А разработчику на C++ этот переход обойдется бесплатно?
нет, но заметно дешеале.
.net-приложения прекрасно масштабируются горизонтально
Тут вопрос куда упремся и того насколько верно мы предсказали изменение объемов данных у заказчика.
.net тут никак не мешает.
Вы возможно не часто пользовались .net приложениями на какихнибудь Atom-ах…
Я вот в .net что-то вроде 12-ти лет, и за все это время ни с одним проектом ничего подобного не произошло.
У вас очень удачная статистика, у меня есть другая. Например года 3 назад в моей статистике прошла волна закрытий ASP.NET проектов, предназначенных для «внутреннего пользования» и некоторые библиотеки были переписаны с C# на С++ в целях повышения производительности и совместимости с iOS\MACOS.
И я пока не уверен, что все худшее для .net, в моей статистике, уже позади.
То что на одном движке собрана масса сайтов-клонов и то что есть сотни блогов, движки которых на php вряд-ли ее искажают.
Ведь никто не мешает писать сайты-клоны на ASP.NET, никто не мешает создавать хостинги блогов на ASP.NET, то что их мало — это врадли вина метода измерения.
Если говорить внутриенних сайтах, работающих в локальной сети организации, то да — эта статистика не адекватна для сайтов внутреннего пользования. Но где мы можем найти статистику по ним?
Почему вы пропустили этап создания объектов из прочитанных данных?
w3techs.com/technologies/overview/programming_language/all
w3techs.com/technologies/comparison/pl-aspnet,pl-php
1. Сильная реорганизация, смена приоритетов в Микрософте и следующая за ней заморозка развития .net. (MFC они неоднократно замораживали, некоторые платформы хоронили заживо, нельзя исключать что .net-у тоже достанется)
2. Переход заказчика на что-то вроде Эльбруса (сценарий конечно фантастический, но может когото он и постигнет) Да и кто знает какие платформы появятся через 3-5 лет…
3. Возросшие, со времянем эксплуатации, объемы данных и вычислений при недостатчном росте производительности железа (наиболее вероятный сценарий в случае если за эти 3-5 лет количество данных сильно увеличивается)
4. Желание заказчика перейти на «зеленые технологии» с потреблением 20w на рабочее место (а вдруг?)
Можно придумать и еще чтонибудь. Я бы дал примерно 30% на то что один из пунктов может случиться в течении 3-5 лет и нанести серъезный урон проекту.
Как вы определили это «большинство» проектов? Терминами «нету сотен новых проектов» и «дофига»?
Есть ли у вас статистика по их востребованности и окупаемости?
И да, возвращаясь к вашему предидущему посту.
На С++ можно писать код, который заработает на всех мобильных устройствах.
Для веб бэкэнда используется в основном php, но я кстати пробовал писать веб бэкэнд на С++, это вполне реально, но я бы наверное не стал рекомендовать его.
Насчет процента пакетов nuget для С++, может быть дело просто в том что nuget ориентирован на .net, а не на С++?
При необходимости поддержки MacOS, если 5 лет сидели на Windows и писали «кроссплатформенно» вам придется потратить условно 3-6 месяцев на вылавливание платформо зависимых граблей. (этих граблей не более 10% от общего количества граблей, т.е. большинство багов вылезают на всех платформах)
Если же вы 5 лет присали под Windows не «кроссплатформенно», то вам придется переписывать огромное количество кода и тратить уже годы на поддержку MacOS (тут конечно многое зависит от того, как много специфичной Windows функциональности было притянуто за эти 5 лет)