LINUX.ORG.RU

История изменений

Исправление eao197, (текущая версия) :

Тогда вообще мимо.

Если голову не включать, то да.

Твой пост

Это не мой пост.

не сравнивает .NET с C++,

Тем не менее, там есть сравнение решения на .NET и с Go, и с Java, и с C++.

он сравнивает ASP.NET (конкретный веб фреймворк)

Там в тексте прямо говорится о том, что самое высокопроизводительное решение на .NET к ASP.NET не имеет отношения.

О чём нам это вообще должно сказать?

О том, что если потребуется производительность, то на .NET-е заколебешься ее выжимать.

Ты никогда не будешь писать платформу на сраном drogon.

О, какая-то «платформа» появилась в разговоре. Что за «платформа»?

Чтобы получить «оттранслированный шаблон» в Go, нужно вручную запустить внешний инструмент.

Этот запуск, предположу, может запросто быть частью build-процесса. Тут скорее вопрос почему разрабы бенчмарка для .NET не смогли пойти по тому же пути. Но меня этот вопрос не интересует.

Какое это отношение имеет к производительности Go?

Я понятия не имею почему вы мне навязываете разговор про производительность Go.

Была дана ссылка, в которой человек разобрал в какие тяжкие пришлось удариться разработчикам на .NET, чтобы их бенчмарк не отсасывал у всех подряд. Но и при этом он далеко позади производительных решений на Java и (что важно в контексте моего разговора с lovesan) C++.

Производительность Go меня не волнует. Но когда мне кто-то говорит, что замените C++ на .NET (конкретно на C#) и у вас все будет зашибись, то я лично в этом очень и очень сомневаюсь. И упомянутая статья (не моя!) лишнее подтверждение моим сомнениям.

Исходная версия eao197, :

Тогда вообще мимо.

Если голову не включать, то да.

Твой пост

Это не мой пост.

не сравнивает .NET с C++,

Тем не менее, там есть сравнение решения на .NET и с Go, и с Java, и с C++.

он сравнивает ASP.NET (конкретный веб фреймворк)

Там в тексте прямо говорится о том, что самое высокопроизводительное решение на .NET к ASP.NET не имеет отношения.

О чём нам это вообще должно сказать?

О том, что если потребуется производительность, то на .NET-е заколебешься ее выжимать.

Ты никогда не будешь писать платформу на сраном drogon.

О, какая-то «платформа» появилась в разговоре. Что за «платформа»?

Чтобы получить «оттранслированный шаблон» в Go, нужно вручную запустить внешний инструмент.

Этот запуск, предположу, может запросто быть частью build-процесса. Тут скорее вопрос почему разрабы бенчмарка для .NET не смогли пойти по тому же пути. Но меня этот вопрос не интересует.

Какое это отношение имеет к производительности Go?

Я понятия не имею почему вы мне навязываете разговор про производительность Go.

Была дана ссылка, в которой человек разобрал в какие тяжкие пришлось удариться разработчикам на .NET, чтобы их бенчмарк не отсасывал у всех подряд. Но и при этом он далеко позади производительных решений на Java (и, что важно в контексте моего разговора с lovesan) и C++.

Производительность Go меня не волнует. Но когда мне кто-то говорит, что замените C++ на .NET (конкретно на C#) и у вас все будет зашибись, то я лично в этом очень и очень сомневаюсь. И упомянутая статья (не моя!) лишнее подтверждение моим сомнениям.