Хабр Курсы для бэкендеров
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Поток Бэкенд доступен 24/7 благодаря поддержке друзей Хабра
Комментарии 49
Nullable types, вроде "int?", params[], async/await, не?
Тут по каждому пункту просто дикая дичь написана. Какой ещё ContinueWith, вы чего...
Я просто вижу, что автор вообще не понимает шарп. Ну совсем. Ни капельки. Ну не понимает и не понимает, ладно. Но статью зачем писать?
Тут по каждому пункту просто дикая дичь написана.
Тогда разберите по пунктам. Только предметно, а не так, чтобы приходилось гадать, чем вам не нравится ContinueWith и пр.
А можно всё же ваши тезисы озвучить, чтобы было понятно, что обсуждаем?
Что язык раздутый и более сложный? Или что?
У вас все плохо в общем и целом. Вы на серьезных щах сравниваете то, что сравнивать не нужно. Вот представьте, что приходите в строительный магазин, и начинаете сравнивать деревянную киянку, резиновый плиточный молоток, сапожный молоток, инерционный молоток, промышленный молот для забивания свай и детскую погремушку.. на предмет что из этого лучше. Технически все из перечисленного - это молоток, которым можно забить гвоздь, но каждый придуман для своей сферы применения. Аналогично каждый язык хорош в какой-то своей области, не выделяется в остальных.. и имеет свою экосистему, философию и тд. Сравнивать их в лоб может только дилетант.
У вас все плохо в общем и целом.
Я не умею спорить в общем и целом, только по конкретным пунктам. У меня в статье этих конкретных пунктов полно — берите любой и приводите контраргументы.
Вы на серьезных щах
Ну это перебор. Что не так с этими комментаторами?
сравниваете то, что сравнивать не нужно.
Возражение было бы релевантным, если бы я сравнивал C++ и Excel. То, что их не нужно сравнивать — это клише. У них сильно пересекаются возможности и области применения. И их регулярно сравнивают. Выйдет какая-нибудь сложная статья по плюсам, обязательно в комментариях появится какой-нибудь г-н "Я 10 лет назад перешёл с C++ на C#, и до сих пор радуюсь своему решению и охреневаю от того, как у вас всё сложно и неудобно". А я вот, представьте, охреневаю от того как в сишарп всё сложно и неудобно.
Аналогично каждый язык хорош в какой-то своей области
Я сравниваю не области применения, а заложенные в них архитектурные решения, концепции и идиомы, а также удобство экосистемы и инструментов. Удобно ли пользоваться системами сборки и пакетными менеджерами, насколько удачным решением был Nullable контекст, в каком языке обобщённое программирование даёт больше возможностей, и т. д.
Сначала сложилось впечатление, что автор стебётся. Но нет.
В C#, чтобы подключить библиотеку, вам достаточно выполнить команду
А потом оказывается, что эта библиотека не совместима с текущим рантаймом. Удачи подключать библиотеки .net framework в .net core > 3. Примерно тоже самое касается .netcore - .net standard.
Это стирает границы между платформами и позволяет переносить компоненты приложений с одной ОС на другую
но опять же, очень сильно зависит от рантайма и того, как было собрано приложение. В большинстве случаев вы всё равно наступите на грабли.
Но даже с учетом того ставить балл здесь за С++ - это конечно интересный вывод. Сову порвало :)
Из-за этого в C++ слишком легко допустить маленькую ошибку, которая приведёт к большим последствиям
Ну да, поддерживаю, к черту продавать Феррари - малейшая ошибка и ты улетел в столб (сарказм, понятное дело)
Интерфейс Disposable
А еще там есть такое замечательное исключение, как HttpClient.
то в C# операторы сравнения должны возвращать именно
boolи ничто иное
Очень спорно, как минимум есть implicit/explicit (или я не понял идею тут). Вообще вся эта секция немного притянута за уши, КМК. Тут как раз-таки C# намного более удобен и по синтаксису, и по ограничениям - при вызове функции сразу видно что в неё передавать и что ожидается, не нужно лезть в код или читать комментарии.
чтобы всё было чисто и аккуратно,
Долго смеялся )))) мы точно про C++ , где есть define? ))) А еще громче смеялся после
Нельзя объявлять классы внутри функций
:)
voidfor_each_arg(F&& f, Ts&&... xs){ (f(std::forward<Ts>(xs)), ...);}
и чем это отличается от:
static void for_each_arg(Action<object> action, params object[] args) {
foreach (var arg in args) {
action(arg);
}
}
for_each_arg((o) => Console.WriteLine(o), 42, 3.14, "hello");
?
Формально рефлексия в C++ есть, и через несколько лет, когда её доделают, она будет лучше, чем в C#, так что это 8:0 в пользу C++
Ну и как через рефлексию достать значение приватного свойства в С++, объявленного в другой подключаемой библиотеке? А статья так хорошо начиналась.....
А потом оказывается, что эта библиотека не совместима с текущим рантаймом. Удачи подключать библиотеки .net framework в .net core > 3. Примерно тоже самое касается .netcore - .net standard.
А потом оказывается, что эта библиотека тянет за собой unmanaged .dll (или .so, или .dylib), которая может иметь не ту разрядность, не ту архитектуру, использовать API операционной системы, которого может не быть в старых системах, где предполагается работа продукта, или вообще скомпилирована с использованием дополнительного набора инструкций, который не поддерживаются процессором большинства пользователей.
В статье я 2 раза упоминал нативные зависимости как ограничение переносимости C# библиотек. Просто в C# проблемы бинарной совместимости возникают гораздо реже, чем в C++.
Просто в C# проблемы бинарной совместимости возникают гораздо реже,
Потому что исторически сложилось, что его только с винды на винду в основном и переносят. Мне кажется даже найти людей, которые бы занимались кроссплатформенными переносом найти проблематично, не говоря уже чтобы они рассказывали бы об этом. Тут явный перекос получается.
А потом оказывается, что эта библиотека не совместима с текущим рантаймом.
Во-первых, в тексте на это есть дисклеймер: кроме случаев с разными версиями рантайма, нативными библиотеками и другими ограничениями, на которых я не буду сейчас останавливаться.
Во-вторых, цитируемый Вами фрагмент — это уже не про бинарную совместимость, а про экосистему пакетных менеджеров, которая у C# более развита. Вы это хотите оспорить?
но опять же, очень сильно зависит от рантайма и того, как было собрано приложение.
Отсылаю вас к тому же самому дисклеймеру, который находится буквально в том же предложении, которое вы цитируете. И я не говорю, что проблема бинарной совместимости вообще отсутствует — я говорю, что таких проблем гораздо меньше, чем в C++.
Цитата:
ABI-совместимость в C# доставляет гораздо меньше проблем — по крайней мере, для тех библиотек, которые не имеют нативных зависимостей.
Но даже с учетом того ставить балл здесь за С++ - это конечно интересный вывод.
А в чём проблема? Я с самого начала сказал, что собираюсь объективно и беспристрастно сравнить эти два языка, и первый же пункт статьи прекрасно демонстрирует серьёзность этого намерения.
Ну да, поддерживаю, к черту продавать Феррари
А это вообще о чём? Против какого положения статьи это должно послужить опровержением?
А еще там есть такое замечательное исключение, как HttpClient.
Да, есть и такое. Хотя это и не настолько важно, чтобы упоминать это в статье.
Очень спорно, как минимум есть implicit/explicit (или я не понял идею тут).
Это легко проверить: попробуйте написать код на C#, в котором используется функция max из статьи, и операторы сравнения возвращают тип, наявно конвертируемый в bool. И посмотрите, скомпилируется или нет (спойлер — нет).
Вообще вся эта секция немного притянута за уши, КМК. Тут как раз-таки C# намного более удобен и по синтаксису, и по ограничениям
Я привёл конкретные примеры и объяснил, чем именно в этих примерах C# неудобен. Вы считаете, что конкретно в этих примерах есть какие-то удобства, которых я не замечаю? Так расскажите о них.
А еще громче смеялся после "Нельзя объявлять классы внутри функций"
Ну приведите код, в котором внутри функции объявляется именованный класс, и который при этом компилируется.
и чем это отличается от:
Если ничем не отличается, то почему в C# сделали 17 делегатов Func вместо того чтобы использовать один, с контейнером параметров?
Ваша функция принимает контейнер, для которого выделяется память из кучи, требует делать рантайм каст к нужному типу в каком-нибудь switch, а для значимых типов используется boxing. Это всё снижает производительность, да и в коде это выглядит некрасиво.
Ну и как через рефлексию достать значение приватного свойства в С++, объявленного в другой подключаемой библиотеке?
А вы опасный человек. И часто вам приходится так делать?
Насколько я знаю, в C++ это возможно с помощью std::meta::access_context::unchecked, если объявление члена доступно компилятору.
А в чём проблема?
Проблемы всего две: абсолютно не объективно и уж тем более не беспристрастно. Вы описали кучу минусов линковки в С++, и поставили ему это в заслугу. Серьезно?
тип, наявно конвертируемый в bool
Так и основной вопрос - зачем? С учетом implicit\explicit можно возвращать bool, а операторы сделают своё дело. Вы решаете проблему, которой нет.
именно в этих примерах C# неудобен
неудобен кому? Лично вам? Некоторым, знаете ли, спать на кровати неудобно.
внутри функции объявляется именованный класс
Опять - зачем? Плодить простыни кода? Сейчас все стремятся наоборот выносить максимум классов в отдельные файлы. Такой PR точно не пройдёт никогда.
Если ничем не отличается, то почему в C# сделали 17 делегатов Func
Ну точно не для того примера, который вы привели.
да и в коде это выглядит некрасиво
А то есть в плюсах это выглядит красиво? Абсолютно не читаемо, и если нет комментариях и описания что же она там делает - придётся смотреть код. ИМХО конечно, но мне кажется 9 из 10 PR-ов с таким кодом не пройдёт в крупном проекте.
И часто вам приходится так делать?
Да, специфика разработки плагинов под существующие системы (что в плюсах лютый геморрой, к слову).
Вы проигнорировали примерно половину моих вопросов. Спрошу ещё раз:
к чему была аналогия с Феррари, и какой тезис статьи она должна была опровергнуть?
зачем вы принялись рассказывать про бинарную несовместимость в C# и про непереносимость между ОС, притом что я сам рассказываю про эти проблемы буквально в том же предложении, которое вы цитируете?
Ответьте на них, пожалуйста, а то после таких возражений остаётся впечатление, что вы не читали статью, а просто скормили её LLM, и попросили написать комментарий.
абсолютно не объективно и уж тем более не беспристрастно
То есть вы на полном серьёзе обвиняете эту статью в отсутствии объективности? Чем больше я вас читаю, тем больше убеждаюсь, что разговариваю с роботом, который не видит общую картину текста и не понимает его общий настрой. Я даже не буду вас разубеждать или что-то подсказывать — просто дам совет сначала читать статью, а потом писать комментарии.
Так и основной вопрос - зачем? С учетом implicit\explicit можно возвращать bool
Если операторы сравнения для класса возвращают другой тип, конвертируемый в bool, то вы не сможете использовать его с функцией max — это просто не скомпилируется. std::convertible_to — это пример гибкости концептов. С их помощью можно задать любые требования к параметрам шаблона. Возможности шаблонов в C++ на порядки шире, чем возможности C# дженериков. Вы всерьёз собираетесь это оспаривать?
Покажите, как в C# можно использовать функцию max для типа, у которого определён только оператор <. Либо есть все 6 операторов, но не реализован интерфейс IComparisonOperators. Писать класс-обёртку, и в нём определять 6 операторов сравнения, 5 из которых вы никогда не будете использовать? Положа руку на сердце, вы считаете, что это пример хорошей архитектуры языка?
В C++ вы выражаете требования в концепте, который сам достаёт всю информацию о классах, без помощи интерфейсов. Если для класса определён оператор <, то концепт просто это видит. Зачем классам через интерфейсы сообщать о себе информацию, которая и так известна на этапе компиляции? Это просто нелогично, и это ограничивает ваши возможности.
Из всех преимуществ шаблонов, о которых я рассказал, вы выдернули один std::convertible_to<bool>, без которого операторы сравнения могут обойтись (ибо что ещё им возвращать кроме bool), и на основе этой мелкой детали сделали обобщённую оценку на весь раздел: "Вообще вся эта секция притянута за уши". Это приём из области демагогии.
Ну точно не для того примера, который вы привели.
А что меняется для этого примера? Массив params[] перестаёт выделять память в куче? Для значимых типов перестаёт использоваться boxing? Или куда-то пропадает рантайм каст к нужному типу? Я вижу, вы решили проигнорировать технические возражения, надеясь, что никто не заметит, и сосредоточиться на вкусовщине: "то есть в плюсах это выглядит красиво? Абсолютно не читаемо". Это опять демагогия. Да и что значит нечитаемо? Во-первых, вполне читаемо, во-вторых используется обычно для классов с простым и понятным назначением, вроде function или tuple, код которых никому и не надо читать. В C# для Func написано 17 реализаций с разным числом параметров, а для ValueTuple — 8 реализаций — вот это реально нечитаемо, и к тому же ограничено по числу параметров.
Опять - зачем?
А зачем запрещать? Программист сам может решить, что для его кода хорошо, а что плохо.
Плодить простыни кода?
Наоборот, чтобы сделать код более читаемым и не засорять внешнее пространство имён каким-то мелким служебным классом, который имеет смысл только внутри этой функции.
притом что я сам рассказываю про эти проблемы буквально в том же предложении
Потому что вы не рассказываете, а упомянули их как "не значащие", хотя на самом деле это единственный большой минус C# (точнее фреймворка), а остальным параметрам он просто наголову удобнее линковки в плюсах. То, что не понимаете как работает линковка в шарпе и какие минусы несёт в себе cmake (про dll hell вы предпочли не заметить) - ну это ваши проблемы.
Для значимых типов перестаёт использоваться boxing? Или куда-то пропадает рантайм каст к нужному типу?
Где это всё в моем и вашем примере?
Абсолютно не читаемо". Это опять демагогия.
Угу, так и есть, потому взял ваш стиль, у вас вся статья такая - "мне так удобнее" :) И миллионы строк кода написанного на шарпе (и яве, там примерно тоже самое) - ну это просто все ошиблись. Можно угадаю - вы не пишите в команде?
Если операторы сравнения для класса возвращают другой тип, конвертируемый в bool, то вы не сможете использовать его с функцией max — это просто не скомпилируется.
А зачем он мне?
public class MyInt
{
private int _value;
public MyInt(int x)
{
_value = x;
}
public static MyInt operator +(MyInt a, MyInt b) => new MyInt((a?._value ?? 0) + b._value);
public static MyInt operator -(MyInt a, MyInt b) => new MyInt((a?._value ?? 0) - b._value);
public static explicit operator bool(MyInt x)
{
return x._value > 0;
}
public override string ToString()
{
return _value.ToString();
}
}
public static T Max<T>(IEnumerable<T> values)
{
using var it = values.GetEnumerator();
if (!it.MoveNext())
throw new ArgumentException(values);
dynamic max = it.Current;
while (it.MoveNext())
{
if ((bool)(it.Current - max))
max = it.Current;
}
return (T)max;
}
Такой же изврат (хотя если посидеть, можно и красивее, это просто в лоб), как и у вас в коде, и так же как ваш никогда не пройдет PR в нормальной команде. Потому что оно нафиг никому не надо ни в плюсах, ни в шарпе.
Как в С++ делается следующее:
Защита от подмены библиотеки?
Защита от dll hell, когда у вас 5 разных версий одной и тоже библиотеки лежит в разных местах?
Выбор версии библиотеки (можно использовать любую от 2.0.0.0 до 2.9.0.0, или только определенную)
Можно проверить хэш-сумму библиотеки. 2+3. В Windows можно использовать LoadLibraryW (LoadLibraryExW) + GetProcAddress. Перед загрузкой библиотеки этом способом можно проверить версию библиотеки через GetFileVersionInfoSizeW + GetFileVersionInfoW + VerQueryValueW.
А вы с какой целью интересуетесь? Если хотите получить короткий технический ликбез, то спросите у LLM. Если ваша проблема слишком сложная, и LLM не помог, то опишите её подробнее.
статическая линковка, всякие ухищрения с запретом на LD_PRELOAD где-нибудь в _start секции. Ну и прочие способы защиты от TOCTOU атак.
настройки линковки, конфигурация версий и путей поиска в сборочной системе
На этапе сборки - опять же конфигурация в сборочной системе. На этапе запуска - резолвится силами системы. На линуксе в случае чего ругнётся, что версия библиотеки не подошла, на винде скорее всего скажет, что blabla.x.y.z.dll не найден.
Ну, всё, уговорили. Теперь приведите пример минимального "Hello, world" на C++ и объясните мне, словно впервые увидевшего код, что значит каждое слово. Но так, чтобы мне захотелось продолжить изучать программирование.
А потом повторите то же на C#.
А в чём проблема?
#include <print>
int main(){ std::println("Hello, world!"); }+4 строчки на CMake.
библиотеку, собранную MinGW, нельзя подключить к проекту на MSVC — если её интерфейс не объявлен через extern "C"
А библиотеку gcc одной версии нельзя подключить к gcc другой версии, а почему? Да потому что strtol поменялся -
undefined reference to `__isoc23_strtol' from upgrade of 3.1.3 to 3.5.4 (from vcpkg)
https://github.com/openssl/openssl/issues/29121
Скрытый текст
Сидит как-то Линус Торвальдс с утреца за компом, скукотища дикая, нумерация ядер как раз на ноль поменялась, на дворе 7.0, до номера 7.21 еще огого как долго ждать. Заняться нечем от слова совсем. И захотелось ему движухи. И взял он и прибавил __isoc23 к названию strtol, чтоб никому жизнь мёдом не казалась. А глаза у него такие добрые-добрые.
Вспоминается
В чём же ошибка?
Хорошо что не просто послали подальше :)
и кстати,
auto err = mHal.setLayerCursorPosition(mDisplay, mLayer, readSigned(), readSigned());
в упоминаемом вами статическом анализаторе это не ошибка, а предупреждение. Все таки UB может быть хоть чем.
Это как сравнивать автомат (c++) с атомной бомбой (c#). Оба хороши, но только для своих задач, я так считаю
Считайте как Вам угодно, но объективный и беспристрастный анализ показывает, что C++ выигрывает со счётом 8:1.
Я не собираюсь ничего набрасывать на вентилятор или разводить холивар, а просто хочу объективно и беспристрастно ответить
Вы и не обьективны и не беспристрастны, и разводите холивар. Потому что C# можно обьективно сравнивать только с Java, это бойцы в одной весовой категории и сферы применения. Я бы понял если бы это была первоапрельская шутка, потому что сравнивать С# и С++, может только человек с умыслом.. или человек который в принципе не выкупает разницу, но решил срубить рейтинга.
Свои пара центов:
Я познакомился с C# на версии 1.0, еще без дженериков. Но отметил, что пишу не менее продуктивно, за счет лучшей поддержки в Студии.
Самым большим сюрпризом оказалось - как это здорово, что не надо писать отдельно файлы .h и .сpp!
Я за вас искренне радуюсь! Вы гораздо лучше меня умеете получать удовольствие от программирования на C#.
как это здорово, что не надо писать отдельно файлы .h и .сpp!
Странный комментарий. В современном мире уже .ixx и .сxx, в C++ уже несколько лет как завезли модули. Да и Separation of Concerns это не такая и плохая штука, отделение интерфейса от реализации. То, что в "современных" ЯП все валится в кучу - это не так уж и хорошо. Вместо того, чтоб пробежаться по заголовочному файлу - теперь нужно отдельно генерировать рядом документацию, просто чтоб пользователь библиотеки не потерялся в спецификациях и знал, что можно трогать, а что нельзя. И в IDE делать отдельные символьные browserы по иерархиям классов, т.е. .h файлы просто переехали в другое место, а суть же отделения интерфейса от реализации никуда и не делась.
А продуктивность это такое - любой бухгалтер с Excel может быть в сотни раз продуктивнее целого отдела программистов, это смотря как оценивать продуктивность.
А где сравнение скорости компиляции? Скорости разработки? Удобства встроенной библиотеки? Получите дату и время из строки на с++ .
Судью на мыло.
И читаемость кода. Почему я спокойно в C# могу использовать все типы данных, а C++ string это отдельная фича для которой надо добавлять отдельную библиотеку.
Для С-style строк даже никаких библиотек не нужно, все работает и так.
std::string это лишь одна из библиотечных реализаций строк, ничто не мешает сделать и собственную, заменив "стандартную" (чего нельзя в C#, там только то что изначально завезли, только то и пользуйте)
А так - вон в Erlang вообще изначально нет строк (некие списки символов вместо них), и ничего, отличный язык по отзывам некоторых.
Собственно почему строка, список или хештаблица должны быть частью языка, а не свободно реализуемыми и заменяемыми библиотечными функциями?
А если мне не подходит стандартная реализация строк, почему меня кто-то должен ограничивать? К примеру я пишу код для микроконтроллеров, и никакой HEAP с RAII и jemalloc мне не нужен, у меня MISRA, которая явно запрещает динамическую аллокацию памяти.
А где сравнение скорости компиляции?
Просто купите более мощный комп, и проект, который собирался 4 часа, будет собираться всего за час. (если что, это сарказм, смешанный с самоиронией. Время компиляции в C++ действительно не радует)
Удобства встроенной библиотеки
В 7-м разделе статьи я подробно рассказал об "удобстве" контейнеров C# в сравнении с C++ и его итераторами.
Время компиляции в C++ действительно не радует)
Справедливости ради это только если Release/rebuild all the world делать.
А если в режиме правка-отладка, то скорость сборки и запуска даже очень больших проектов может занимать секунды. Нужно просто уметь в PCH, и разного рода модули - от .so/.dll до .ixx/.cxx, тысячи мануалов разложены в интернетах на этот счет.
Д. Лакос же уже две книжки написал про это (заново открыв для себя и мира известные еще со времен Delphi Packages, но тем не менее).
Пункт 5. Зарплата
медианная зарплата для разработчиков C++ составляет 240 000, а для C# — 250 000. Как видите, по этому показателю C++ снова оказывается впереди
Это как?
Что лучше, стол или стул? И 9 пунктов сравнения... Ну такое.
C++ даже в 2026-м году может работать без runtime, т.е. без stdlib++/STL и прочих Boost.
Даже exceptions можно из него выбросить прям на старте.
Можно полностью заменить new/delete, переделав их на старте на GC, ARC, или Arena Allocator и т.п. И это все равно будет C++. А STL это просто библиотека, не часть языка, хоть ее и пытаются позиционировать как неотделимую от языка, но это слава богу не так, пока ее еще можно полностью выбросить из зависимостей.
Подобная гибкость сразу дает недостижимые никому иному 100500 очков и ложит абсолютно всех на лопатки на старте, включая Swift, Kotlin и даже Rust.
C# - это просто yet another Java style Enterprise bloatware, в котором декларируется наличие библиотек для всего что угодно. А по сути эдакий 1C на супер-пупер стероидах. Но по факту там неизлечимая родовая травма - жестко вкодированный на системном уровне UTF-16. Ну и GC окончательно выводит его из технологического трека долгосрочной перспективы, т.к. GC в принципе не способен эффективно работать с кучами на десятки гигабайт, базы данных и ОС на нем точно никогда не написать. GC offheap - это костыль, а не решение. Веб странички, CRUD и простенькие UI - это да, но не более того. Даже Office на С# так и не смогли переписать, да и в самой Windows перешли на Webkit/Electron для UI, что уже говорит о многом. Плюс C# проприетарный и не true open source. И даже неповоротливую Java в которой до сих пор нет тех же properties - так и не смог победить, практически нигде.
Swift и тот смог уйти от UTF-16 и переехать на UTF-8, но не C#. C++ даже с STL в этом плане может в любые кодировки. Swift кстати, в сравнении со всеми остальными именно как язык на самом деле прям сильно хорош, и мог бы быть перспективным в целом, но в нем намертво прикручен ARC, что, увы, делает его тупиковым решением на длинной дистанции.
Так что альтернатив С++ нет (да и не было никогда).
Rust с его прям очень странными девиациями вроде "на объект может быть только одна мутабельная ссылка" выглядит скорее как агрессивно-религиозная секта пуританцев. А по факту уже 15 лет прошло, а даже coreutils толком не смогли на нем переписать, процесс все еще идет. Зато поломали вообще всем рендеринг True Type шрифтов (включая всех, которые на WebKit/Electron), других достижений и не вспомнить. Да и очень далеко не все готовы разделять подобную rust-аскезу, автор zig не даст соврать. Хайп вокруг Rust понятен, особенно подогретый уже недоступными ссылками "рекомендаций" АНБ, NASA и прочих White House, но на Silver buller он не тянет. Попытка заменить С++ по сути прогорела, если сразу не взлетело, сколько не рассказывай, что на C++ уже нельзя новые проекты открывать, но по факту на выходе получилась просто еще одна экосистема, в ряду Java, C#.NET, D, Go и прочих сообществ "С++ заменителей" появилось еще одно бесценное пополнение: Rust сообщество просто добавят своей энтропии с еще одной парой десятков невиданных реализаций веб серверов и JSON и YAML парсеров, которых к слову и под C++, и под C в избытке, а у HR-ов и PR-ов добавится головной боли на собеседованиях, так дальше все и поплывем в неведомые дали этого вашего энтерпрайз кодирования очередных CRUD UI.
Статья, очевидно, шуточная.
Хотя поток возмущенных серьезных комментариев заставляет меня усомниться...
хочу объективно и беспристрастно ответить
8:1 в пользу C++
Не, ну тут конечно же все объективно и беспристрастно, он же смог найти минус в С++
Забавно как концу статьи кода на плюсах становится всё меньше и меньше, а очки в его пользу растут всё также.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Что лучше — C++ или C#?