.net7 C# vs Golang. Сравнение производительности

[@shkippitor1895]

Все таки не зря подписался) а искал изначально вообще про кейклок)

[@Kulibins1]

Всегда нужно подписываться 😉

[@Lolohaev]

Спасибо за сравнение. Но так же хочется отметить некоторые моменты: Многопоточка в го по сравнению с шарпами (если в ней разобраться) намного удобнее (по крайней мере мне). Было бы интересно почитать обсуждение тезисов в комментариях под статьей на Хабре(если видео будет перенесено в статью), чтобы многие опытные программисты могли дать свои оценки данному тесту и привести свои примеры сравнения. Да и говоря "при использовании gRPC такой проблемы не будет" можно это и показать. Да, мы можем это сделать сами, но тогда зачем нам смотреть видео?) Еще, если говорить о переходе с шарпа на го, то стоит упомянуть отсутствие огромного Легаси в котором необходимо разбираться из за приличного возраста шарпов в продакшне. Со временем на го тоже будет много Легаси, но в данный момент его просто нет в силу возраста языка. Ещё из плюсов го: зарплаты в среднем выше(на 2023 год), разношерстное комьюнити (ведь в го обычно приходят из других языков) и бОльшие требования к знаниям смежных областей (в шарпе на уровне мидл и ниже многое уже решено и есть best practice, из за которых тебе и в голову не придет лезть под капот той или иной технологии). От себя хочу добавить что знакомство с другими языками, которые построены не на ООП очень полезный опыт. Когда смотришь на отличия невольно начинаешь задавать вопрос "а почему так?" и в итоге больше понимаешь не только новый язык, но и те вещи что казались магией в шарпе становятся понятнее. Ну и лайк за Артура из искусства программирования. P.s.: автору спасибо за видео, посмотреть на сравнение всегда интересно.

[@Kulibins1]

Самому было интересно

[@antosha2224]

Что в вашем понимании легаси? Код написанный вчера сегодня уже легаси. Если не нравится копаться с уже существующими проектами на шарпе, то просто ищите новые проекты. Их полно. Я шарпист и поменял уже 3 проекта за 2 года. И все они были гринфилд. Просто надо искать… и кстати ребята из команды сишарп уже работают над грин тредс. Это новая асинхронная модель по типу го

[@Lolohaev]

@@antosha2224 Легаси - достаточно большой и старый проект, часто без хорошей документации, часто на старых версиях языка, который не стремится развиваться и нуждается в постоянной поддержке. "Если у тебя нет дома то просто купи дом, лол, вот же глупые люди" - а зачем мне копаться в куче проектов и рассматривать где старые а где новые технологии, когда я могу перейти на го и лишить себя этой проблемы изначально? А если ещё не обсуждать частные случаи а перейти к общей ситуации? На каждого найдется ли новый интересный проект? Зелёный тред - это концепция которой очень много лет. Горутина - тот самый зелёный тред, который просто переименовали. Но обещать не значит жениться и пока в одном языке инструмент уже есть другой над ним только работает. Так зачем очень мое ждать пока работа закончится когда я просил сеанс могу использовать удобный мне инструмент?

[@antosha2224]

Вы(люди которые свичнулись на го) все звучите одинаково. Есть ощущение, что вы пытаетесь убедить себя и зачем-то других в интернете, что все сделали правильно. Причем вас никто не спрашивал...Удачи вам с новым языком

[@Lolohaev]

@@antosha2224 спасибо, от языка нового в самом деле кайфую. Далее в библии Иисус говорил что в момент любви можно не соблюдать пост, так что не судите нас пока мы не привыкли к языку)))

[@nv188-x5i]

Болел за C#, было увлекательно, спасибо. Ждем Rust.

[@Kulibins1]

Нужно время на изучение. Но скоро будет 😁

[@Sky-pg8ot]

А надо за Россию болеть, лол, эхх ты

[@Tosha.V]

ну что, теперь на горизонте rust)

[@Kulibins1]

Изучаю. Но хочу до этого сделать виде где покажу что работа с потоками на c# не затратнее (по сложности разработки) чем горутины на golang. Вижу что нет понимания, т.к. ничего сверхъестественного в горутинах не вижу.

[@СерёгаСокольский]

Actix WEB.

[@Tosha.V]

давно ждали, молодец!

[@Kulibins1]

🥳

[@MrCommanderKid]

Хе, думал после шарпа го изучать, а тут такое... 😂😮

[@Kulibins1]

главное что после шарпа начинает бесить простота golang. Хоть и видел, когда пытаются сказать что в golang есть ООП, лично моё мнение его нет! да и многое что уже на шарпе привык, просто отсутствует (перезагрузка операторов, свойства?!!, да даже интерыейсы каличные по сравнению с шарпами)

[@releyshic]

@@Kulibins1 Go это больше скриптовый язык, не нужно от него ожидать богатого инструментария. Выглядит как хорошая замена питону и js

[@Kulibins1]

@@releyshic Он точно не скриптовый, т.к. копилируется, по скорости он в разы быстрее питона, а js для меня это язык для фронтэнда, применение его для бэка от безысходности (кто знает js, может бэк делать на ноде, часто делают протатипы на js, но мне легче на C# написать бэк чем на js, хоть js знаю очень хорошо). Вот если станет выбор писать бэк на питоне/js/go, а на c# нельзя, то точно выберу go.

[@vitalyneumoin]

Хотелось бы тогда увидеть использование jsoniter вместо обычного json маршаллера на го. Раз на шарпе использовалось что-то не родное. По тестам он быстрее, но в чем именно была оптимизация не изучал.

[@Kulibins1]

Я еще не настолько специалист по go, не знал про него. Но посмотрю этот пакет, если что сделаю второе видео.

[@PersyJekson]

сравнивали с sonic ?

[@minimalstory]

Хорошее сравнение. Но каждому инструменту свою задачу) с радостью смотрю как мой коллега на го пытается сделать утилиту с формами и на десктоп которую я уже. Месяц назад как написал на шарпе)) но в вэб сервисах он пока впереди. Никаких тестов не делаем, просто скорость разработки у го выше в части случаев. Скорость! =качество)

[@Kulibins1]

На шарпе с minimal api сервисы делаются очень быстро. Мне кажется наоборот будет быстрее чем на go. Но может я и не прав 😉

[@minimalstory]

@@Kulibins1 я пока проигрываю коллеге в многопоточных задачах) но это скорее я ещё криворук, а не коллега такой классный))

[@andrewbondaryuk]

@@Kulibins1 У го пока очень херово с enterprise level библиотеками. Типа EF.

[@unknown6535]

@@Kulibins1 можно пример или ссылку на то, что понимается под minimal api сервисы

[@Kulibins1]

@@unknown6535 В описании ролика есть ссылки на github как на проект c#, так и на проект golang. если вопрос про minimal api, то вот мой ролик на эту тему kzbin.info/www/bejne/eXbTiYOXZp2XjtE

[@sezam-zz6lf]

глянул сортировку, пусть спецы по go поправят: 1) result += Compare(STR1+strconv.Itoa(i), STR2+strconv.Itoa(i)) делается через fmt.Sprintf 2) := это создание переменной, вероятно декларировать нужно через var до цикла 3) слайсы рун...

[@Kulibins1]

Можете проверить. На результат не повлияет

[@sezam-zz6lf]

@@Kulibins1 Есть ежегодный тест tech empower Web Framework Benchmarks, там ванильный go сильно уступает net core, но есть варианты

[@Kulibins1]

@@sezam-zz6lf я уже не верю этим тестом, решил сам перепроверять. Вон как сильно зависит серелизация, есть ли там много даблов или нет. Нужно на своих задачах перепроверять, а то в рекламных материалах всё супер. Хочу еще grpc прикрутить к тесту (хоть и для веба он кастрированный)

[@sezam-zz6lf]

@@Kulibins1 Как раз в тесте сериализации ванильный core проигрывает большинству. Вроде как сходится?

[@Kulibins1]

@@sezam-zz6lf да вероятно это оно

[@andrewbondaryuk]

1) По идее native AOT должен ещё немного улучшить показатели 7ки. 8я ещё больше продвинулась в этом направлении, но очень мешает reflection - мерзкий легаси :) 2) Где данные по использованию памяти? 3) Ещё большее внедрение source generators даст возможность отказываться от тормозного reflection

[@Kulibins1]

в моём примере нет уже рефлекшена. Тестирование проводится jmeter, для анализа пямяти нужно делать другие тесты. чисто визуально в диспетчере задач цифры были сопоставимы. т.к. я написал свою функцию сериализации, то генерация не улучшит. Сейчас сделаю ролик по Angular, потом покажу как работает многозадачность в .net и сраню с golang. Потом ролик по сравнению c# и rust (уже на rust код делаю, хотя не хотел 🤣)

[@farSleeper]

go на самом деле и привлекает иногда своим минимализмом (их отказ от абстракций в принципе понятен). Еще больше он привлекает отсутствием, если можно так сказать, "языкового легаси". Но там для каждого найдется своя бесячая штука:) Я от их обработок ошибок подгораю неимоверно. Вроде бы и понятно, что в такой реализации есть смысл, но блин как-то оно "леворезьбово".

[@Kulibins1]

Обработка ошибок уровня языка C, даже не C++. Если честно очень хардкорная и не удобная в go, но это моё мнение.

[@andrewbondaryuk]

@@Kulibins1 У го есть огромный плюс - довольно лёгкий вход. Хотя подводных камней у него УЖЕ дохера :) Для тулинга, для стаи микросервисов - идеально. Хотя Minimal API сильно повышают шансы для дотнета.

[@user-io9iq2di4w]

Всем привет, выбираю между двумя языками C# и Go, учить собираюсь для back-end. С шарпом уже знаком, учил на 2 курсе универа, знаю на уровне до ООП. Можно ли начинать свой путь в IT с Go или лучше продолжить учить C# и пытаться найти свою первую работу с ним?

[@Kulibins1]

go очень простой, не знаю языка проще, наверное даже basic и тот сложнее. Мне конечно больше c# нравится, одно время go очень фыорсили, сейчас сильно поутихло.

[@errmaker]

бери го )) я сам с шарпа ушел давно/ Параша от майкрософта

[@Kulibins1]

@@errmaker какие реальные аргументы?

[@user-io9iq2di4w]

@@errmaker поздно, выбор уже пал на шарп

[@Sky-pg8ot]

​@@user-io9iq2di4wамериканская мелкомягкая игла ближе для души? одумойся

[@unknown6535]

спасибо за контент, было интересно. Что вы думаете на счет DI Lazy (Lazier) для сервисов в wep api asp core проектах, есть мнение, что повсеместное использование ленивой загрузки может быть более накладно, чем без ленивой загрузки, могу предоставить ссылку на мнение. Хотелось бы увидеть от вас бенчмарк или мнение по этому поводу, спасибо.

[@Kulibins1]

Нужно сделать сранение. Запишу в список роликов. Ссылку на мнение можно скинуть.

[@unknown6535]

@@Kulibins1 комментарий ссылкой выпиливается

[@goldgold594]

​@@Kulibins1 Очень интересная тема :) Хотелось бы послушать ваше мнение

[@СерёгаСокольский]

Какой сериализатор в C# использовался? Newtonsoft или System.Text.Json?

[@Kulibins1]

system.text.json А потом написал свою серелизацию , когда разбирался что тормозит.

[@MaximT]

GO хранит строки в Utf8, а C# в Utf16

[@andrewbondaryuk]

В го yield конечно же нет, там каналы :) Основную проблему которую я испытываю при изучении гошки - шаблонность мышления после 5 лет работы на шарпах. Ищешь подобного, а его там нет :) Начинатя от каналов, заканчивая iota.

[@Kulibins1]

каналы так же есть и в шарпе. Я уже подготовил материал где покажу как работает многозадачность в c# сравню с go

[@andrewbondaryuk]

@@Kulibins1 Каналы в шарпах есть, да, но в го они на уровне языка и сделаны сильно удобнее. Ждём появления "лёгких потоков" в шарпах :)

[@stefano_schmidt]

А почему Го решили изучать?

[@MakarenkoSasha]

как с# приложение работает под линукс? core? насколько это все сложно поддерживать?

[@Kulibins1]

великолепно работает. у нас прод именно в линуксе. в кубере крутится.

[@MakarenkoSasha]

@@Kulibins1 блин... я сам на с++ пишу. но писать бакенд на с++ то еще веселье. попробовать, чтоли.. всегда пугал доп фреймворк. но опять-же таже нода...

[@MakarenkoSasha]

@@Kulibins1 Если бы я накидал маленькое т.з для задания. могли бы мы его реализовать на шарпе? Готов за это заплатить.

[@Kulibins1]

у меня сейчас работы много, пока не беру дополнительные проекты

[@MakarenkoSasha]

@@Kulibins1 Это конечно хорошо, когда работы много :) Если честно. сейчас ее у всех много, кто работает.

[@viktoralferov2874]

правильная Gang of Four (4G): Generators Generics Goroutines Garbage Collector )

[@Kulibins1]

Не выспался, поясни. Не понял коммента. Если об основных преимуществах, то все это есть в c#. Аналог горутинов в C# это Task, но task более функционален. Но что бы не было холивара go хорош своей простотой. Даже больше мы можем сделать функцию c#: async f() и при вызове f() будет аля go f() из golang, разница в том что в c# это при определении функции а в golang при вызове.

[@viktoralferov2874]

@@Kulibins1 это я так, вообще

[@redice8928]

Я бы еще добавил, то что сложность и глубина языка с# серьезный недостаток с точки зрения карьерного роста. Не советую новичкам его выбирать, так как с его наворотами вы рискуете завязнуть джуном на 3 года. Чего не сказать о минималистичном голэнге. За 3 года сеньором можно стать

[@Kulibins1]

Тут несколько факторов почему этот карьерный рост может случится: 1) гораздо меньшее количество разработчиков на go 2) самый простой язык (тут думаю, через время захочется чего-то более серьёзного) Ну и главное дело не в языке программирования, а в программисте, т.к вроде бы серьёзные разработчики со стажем пишут такуб дичь...

[@recycle-bin-camp]

конкурентный квиксорт интересно увидеть в сравнении

[@Kulibins1]

Тут проверяется не сама сортировка, а функция сравнения с учётом чисел в строке (в любом месте) эта функция потом используется в сортировке. А сама быстрая сортировка и так в каждом фреймворке и будет +/- одинаковая

[@recycle-bin-camp]

@@Kulibins1 понятно, было интересно потому, что есть пропаганда мол в go очень легко и просто писать конкурентный код и он мегабыстрый, конкурентный дженерик квиксорт я нашел и запускал у себя,а как он выглядин на C# без понятия

[@Kulibins1]

@@recycle-bin-camp скинь ссылку, посмотрю по возможности

[@recycle-bin-camp]

@@Kulibins1 в книге Generic Data Structures and Algorithms in Go An Applied Approach Using Concurrency, Genericity and Heuristics - Richard Wiener

[@recycle-bin-camp]

@@Kulibins1 я кстати когда конкурентный квиксорт на go исследовал то int быстро сортировало, а float просто бесконечность можно ждать. не знаешь почему?

[@Tosha.V]

кстати, актуальная тема для видео, C# в России, что будет дальше.. А то майки вроде как уходят и т.д., думаю многим будет интересно.

[@Kulibins1]

Так dotnet бесплатный с открытым исходным кодом. Работаешь будет как и любая другая платформа. Или вопрос про большую visual studio? Можно и vs code использовать. Пока с VS нет проблем.

[@СерёгаСокольский]

Не уходят. Продажи Windows вернули. .NET Core находится под лицензией MIT. То - есть, распространяется как свободное и открытое ПО. Но с сохранением авторских прав.

[@igorchvalun1838]

Надо было и для го Ryu применить, для чистоты эксперимента

[@Kulibins1]

а какой сейчас из коробки в go используется алгоритм? мой вывод такой - чистая математика чуть быстрее на шарпе. + весь код фреймворка написан с ичюспользованием интрисиков, что так же сильно ускоряет код. Чуть позже сделаю второе видео с применением быстрого алгоритма преобразования в float64 в строку (но есть подозрения что он и так уже там). Сейчас погрузился в Rust.

[@andrewbondaryuk]

@@Kulibins1 Да, раст сильно "ломает" голову, почти как функциональщина :)

[@Sky-pg8ot]

​@@andrewbondaryukпрям неимоверно

[@esp2644]

Нужно ждать bun на винду, и ттгда нахер этот го нужег, если нода точно такая же по скрости как и го будет

[@Kulibins1]

go быстрее и это реально самый простой язык, даже basic и тот сложнее. Есть же видосики от яндекса где они свои сервисы с ноды на go переводили и получали дикий профит. Я еще буду делать видео где постараюсь своё мнение о каждом языке рассказать, не чьё-то пересказать, а именно свои впечатления. Больше всего меня Rust конечно напряг.

[@phat80]

Не коверкайте, пожалуйста, название языка. Язык называется Go. Так и надо бы писать в тестах. Нет такого языка Golang. Это просто старый домен. Видимо поэтому от него и избавились. Удивительно, что у Rust сайт до сих пор - rust-lang, но его никто не называет rustlang’ом.

[@Kulibins1]

набери в поиске golang и получишь ответ.

[@sadvalblitz6258]

Google language, парень

[@phat80]

@@Kulibins1 чего трешь ответы? Лоханулся и все равно хочет, чтобы последнее слово было за ним… 🤦‍♂️

[@Kulibins1]

Я тру только оскорбления. Как например в вашем крайнем сообщении. На ваш вопрос я ответил. Если в сообщении будет оскорбление, тогда в бан отправлю, без вариатов.

[@alexandrsharp920]

осталось сравнить с RUST

[@Kulibins1]

Пока в плане только это сравнение осталось.

[@naugad2]

асинк-авэйт впервые появились в f#. а не c#

[@Kulibins1]

@@naugad2 Буду знать. Да в f# на 2 года раньше появились

[@MakarenkoSasha]

остался rast и с++

[@Kulibins1]

c++ не обещал 😉, да и мало сейчас именно бэка на плюсах делают. Драйвера, всякий embaded (да и то, потому что часто нет другого языка) всякий супер критичный код. Сейсас с плюсовиками не густо, сталкивался с такими откровенными нубами, которые простейшие действия не понимаю, хоть и не смешно но каждая функция у одного начиналась с while (true){......} каждая 😭 зато плюсовики

[@andrewbondaryuk]

@@Kulibins1 Плюсы это теперь легаси и геймдев. Драйвера, встройка явно проще на чистых сях, но и тут начинается ползучая замена на раст. Scylla на расте, полная замена Кассандре. Многие критические вещи переписываются с шарпов на раст (Seq, RavenDB).

[@metlic5209]

12:28 да блин, что за категоричные утверждения, особенно от человека со словом "Архитектор" в названии канала. Не всем нужны микросервисы, не нужно вестись на "истории успеха" крупных компаний.

[@Kulibins1]

Не понял вашего утверждения, хотя что до этой минуты досмотрели 👍

[@xotamxudoyberganov5847]

jsom rust

[@Kulibins1]

Посмотрю, но вероятно результат будет = c# первая часть до json уже быстрее + пусть будет одинаково на стерилизации = паритет или c# чуть быстрее. Но все исходники на гитхабе - помогайте улучшить пример go.

[@xotamxudoyberganov5847]

@@Kulibins1 rust будет быстрее для сериализации и десериализации

[@Kulibins1]

@@xotamxudoyberganov5847 тут нужно смотреть что он делает, конечно все понимают что rust низкоуровневый язык, но все зависит от алгоритмов, мой пример как раз это показывает. Сделаю видео тогда будем обсуждать rust 😉

[@СерёгаСокольский]

Rust более низкоуровневый. Сериализатор такой же. Будет быстрее.

[@vas_._sfer6157]

@@Kulibins1 Rust не низкоуровневый. Он даже более высокоуровневый, чем C#. Но вот runtime у Rust гораздо более минималистичный. И бекенд компилятора очень хороший. Подозреваю, что обыграть Rust можно только в очень спецефической задаче, но при написании +- хорошего кода Rust побеждает. Единственное, нужно обратить внимание на клонирование объектов, а также использовать итераторы - это залог высокой производительности. Unsafe же для тестов вам не пригодится, даже можете его не трогать. Он не даст больше производительности.