# Стоит ли связываться с C#



    На рынке есть десятки популярных ЯПов, и сеть набита статьями для новичков: какой язык выбрать? Мы решили сделать подборку статей с субъективным обзором языков для профессионалов, которые ищут, в какую сторону можно расширить свой кругозор.

    Первую статью цикла мы посвящаем языку C#.

    Шарпы — популярны


    Все плюсы и минусы технологии вытекают из этого факта. Огромное сообщество, тысячи библиотек на все случаи жизни, превосходный туллинг — всё есть. Когда приходишь в дотнет, у тебя нет никаких проблем. Есть Visual Studio и Rider — сверхсовременные IDE, которые сами умеют создавать все основные шаблоны проектов, скачивать все необходимое, чтобы они заработали, и собирать их по нажатию кнопочки.

    Туллинг по-настоящему взрослый. Линтеры делались долго и вдумчиво, компилятор набит фичами под завязку и покрывает даже самые неочевидные сценарии сборки.

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

    Процесс изучения отлажен годами, все знают что читать, как делать, у кого спрашивать. При этом сама платформа не суперсложная. Крепкий мидл на другом языке уже через пару дней сможет писать сносный код на C#, пока дело не коснется многопотчки, работы с памятью или оптимизаций.

    C# — мощный язык с кучей возможностей


    Корная либа достаточно богатая — из коробки ты в дотнете получаешь тысячи утилит, структур данных, и всяких таких вещей. Решать стандартные задачи здесь действительно легко — все есть, обо всем подумали за тебя. Хороший интероп с плюсами докидывает сверху кучу плюсовых либ, обернутых в дотнетные — на случай, если тебя заставят молотить байты в каком-нибудь софте, связанном с видео или звуком.

    Язык достаточно современный, все самые популярные фичи на рынке в нем или есть, или планируются. Синтаксис полегче чем в Java, потяжелей чем в совсем современных языках вроде Котлина. Шарповый код при компиляции превращается в промежуточный язык, который выполняется JIT-компилятором на клиентской машине — в этом есть свои преимущества, но такой принцип работы не оставляет шансов писать настолько же быстрый код, как на плюсах или голанге. Но C# все ещё достаточно быстрый в своей категории. Если просто сесть и писать незамудренный код, очень долго не будешь упираться в какие-то неожиданные проблемы в производительности самого языка.

    Язык не супер быстрый — но есть огромное пространство для оптимизаций. Структуры — чтобы хранить данные на стеке, АПИ сборщика мусора, чтобы оптимизировать его работу в конкретных кейсах, есть unsafe — чтобы поработать с указателями и оптимизировать какой-то ботлнек. Богатые инструменты для параллелизма. Есть интринсики, для оптимизаций под конкретные процессоры. Короче, если заморачиваться — скорость работы можно прокачать на раз.

    В C# мощная поддержка ООП — тут любой код лежит в классах, полный суппорт наследования, а теперь и множественного наследования через дефолтную реализацию интерфейсов. Куча различных модификаторов доступа, возможность разделять ответственность модулей на уровне сборок. Типизация строгая статическая — всё что можно тайпчекается на этапе компиляции, всё что нельзя — метаинфа о типах едет в рантайм, и может быть прочекана там. Сам дизайн языка как будто специально сделан так, чтобы фигачить архитектуру по Бобу и Фаулеру. В C# очень легко объяснить компилятору, какие части системы делают это, а какие то, и кто из них о ком знает.

    Гораздо меньше шарпы поддерживают функциональную парадигму. Но и здесь есть четкое движение вперед. Недавно завезли слегка кастрированный паттерн-матчинг, есть таплы и почти есть рекорды. Давно есть лямбда выражения. Самый распространненый в дотнете способ работы с коллекциями — LINQ выражения — выполнен полностью в функциональном стиле.

    Но основную проблему языка это только усугубляет. Для современного ЯПа C# слишком многословный. Они завозят новые функциональные фичи, но огромное количество необходимых синтаксических надстроек не позволит их использовать так же изящно, как в каком-нибудь OCaml. Тут чем дальше, тем хуже. Страшный груз обратной совместимости легко разруливается создателями языка на техническом уровне, но всегда выливается в ещё одно утяжеление синтаксиса. Мне немного стыдно, когда я вижу код минимально рабочей программы на C# — язык буквально отказывается освобождать меня от написания очевидного.

    Дотнет — для ентерпрайза


    Если ты решил прийти, чтобы изобретать новые подходы — тебе тоже не сюда. В дотнете на все есть практики, и все им следуют. Даже скобочки тут придётся форматировать именно так, как принято. Это даже не минус — так со всеми взрослыми языками, и от этого никуда не уйдешь. Самое дурацкое — очень легко стать шарповой боевой единицей, но момент, когда ты точно понимаешь, как работает твой код — наступит оооочень не скоро. В платформе, принципах её работы — масса нюансов, которые по щелчку не выучатся.

    Дотнет объективно хорош тем, что на нем можно делать почти все. Бекенды, десктопы, мобильные приложения, сервисы, машинное обучение, ботов. Но это дома можно. Работу ты все равно найдешь только бекендером — других вакансий тупо не бывает.

    Что касается рыночных мотивов — тут все просто. В СНГ неплохой рынок на дотнет, зп именно что средние, работенка непыльная. Если хорошо знаешь английский — тогда все круто меняется. В мире много мест, где за дотнетчиков платят полновесным золотом — в том числе и за удаленных. Беда тут одна — культура собесов в дотнете — настоящая жопа. Тут принято мучить кандидатов десятками вопросов на знание деталей платформы, которыми никто не пользуется -их придется именно что учить. Добавьте к этому стандартную дрочь на бекендерском собесе, и получите эталонное шарповое интервью. Тяжелое, и непроходимое без подготовки для спецов любого уровня.

    В целом мой вывод такой: если в плане карьеры, то дотнет — это для людей, которые хотят найти свой энтерпрайз, и долго, методично и планомерно развиваться в одном узком направлении, которое гарантирует стабильный рост уровня жизни. Если хочешь менять индустрию своими идеями и библиотеками, скакать с одной работы на другую, или просто поменьше учить и работать — тебе не сюда.

    А если в плане поэкспериментировать дома — самое то. Ничего не надо изучать и настраивать, скачал IDE, написал мобильное приложение, веб-приложение, ML модуль. Быстро и просто.



    На правах рекламы


    Подыскиваете сервер для разработки и размещения или VDS для отладки проектов? Вы наш клиент! Посуточная тарификация виртуальных серверов самых различных конфигураций, антиDDoS и лицензии Windows уже включены в стоимость. Поспешите попробовать!

    VDSina.ru хостинг серверов
    Серверы в Москве и Амстердаме

    Комментарии 172

      –31

      Плюсы шарпа вижу, а минусы?
      Почему нет ничего про его четкую заточенность на Виндовс? Десктоп приложения на нем писать можно только под мелкомягких, а все никсы и маки — это лабораторные наработки. Тот же моно красиво ушел в мобайл как ксамарин и остался в глючном юнити...

        +17
        > Почему нет ничего про его четкую заточенность на Виндовс?
        Microsoft уже сами депрецировали не cross platform версию .Net. Сейчас большинство .Net приложений или уже на linux, или переходят, так как это отличный способ экономии.
        Это, кстати, крайне удобно для разработчиков. В то время как джависты с трудом «продают» переход со старых версий Spring, .Net разработчикам достаточно показать как дорого стоит виндовый сервер и… рефакторинг продан:)
        > Десктоп приложения на нем писать можно только под мелкомягких
        А разве десктоп кому-то сейчас нужен? Сейчас разработка это или бек, или веб фронт, или мобилки, или игры.
        >… глючном юнити
        А можно рассказать про глючность юнити? А то у читателей может возникнуть ложное ощущение, что в Unreal Engine, как будто, глюков меньше.
          +18
          А разве десктоп кому-то сейчас нужен?

          Да.
            –17

            Сейчас все в в вебе. Сегодня популярные десктоп, приложения можно по пальцам пересчитать: web-браузеры, IDE, Office. Я больше не смог вспомнить ни одного desktop приложения не из этих категорий, которое бы использовал за последний год.

              +15

              "Не будет ни театров, ни кино, ни книг. Одно сплошное телевидение!" © к/ф "Москва слезам не верит".


              Вы не первый.

                –4
                Ну почти так и случилось ведь. Только не телевидение, а Ютуб и ТикТок. Разве что книги пока ещё слушают, а не смотрят, но уже скоро, скоро, я думаю.
                +5
                А в корп сегменте десктоп отлично себя чувствует.
                  +5
                  1. Всевозможные графические редакторы: растр, вектор, 3д.
                  2. Остальные редакторы, не попавшие в п. 1: текстовые, научные, музыкальные, туда же относятся, например, слайсеры для 3д принтеров.
                  3. Различные корпоративные приложения (erp, crm) — далеко не все в вебе.
                  4. Игоры.
                  5. Всевозможный геймдев-тулинг, включая мобильный геймдев, запускается на десктопе онли.
                  6. Специализированные приложения для конкретного железа — их целый пласт, от прошивальщиков ECU до контроллеров больших станков.
                  7. Клиенты видеонаблюдения. Браузеры пока не умеют в h265.

                  Это то, что навскидку вспомнил.
                    +1
                    Интересно, что Slic3r, один из самых мощных и гибких слайсеров, вообще на Perl написан. Кто бы мог подумать, что на Perl до сих пор пишут приложения. И не просто приложения, а с 3D-графикой и кучей мозголомной математики.
                      +4
                      Эм, нет. Пёрла там 22 процента, если верить статистике гитхаба. Это слишком мало, чтобы утверждать, что слайсер написан на пёрл. Основной язык там именно тот, который принято использовать для разработки такого рода приложений.
                    0
                    Я бы посмотрел, как вы файловый менеджер через веб юзаете)))
                    –6
                    Сейчас разработка это или бек, или веб фронт, или мобилки, или игры. А для всего остального есть Electron
                      +1

                      В Microsoft, видимо, рассуждали также, когда приняли решение переписать Skype.

                    0

                    Да

                    +9

                    .net уже давно как кроссплатформенный, а заморачиваться десктоп приложениями под никсы, зачем и для кого? Уже под вондовс десктоп давно как умер, а вы никсы хотите.

                      +6

                      Да, хочу десктоп под Вынь и Мак. И много у меня заказчиков, которые в корп среде хотят десктоп приложения. И что вас удивляет? Что мир разный? Я написал свое мнение о неполноценности статьи без недостатков. Все языки их имеют — это неплохо и нехорошо — это факт.

                        +3
                        Увы можно только предложить использовать какой нибудь WebView по типу CEF и логику писать на C#
                          0
                          Пока мучаюсь на Юнити. Десктоп писать сложно, но выходит красиво. :)
                            0
                            Скоро выходит MAUI мультиплаформенный GUI. Через год в .Net 6 запланирован релиз. Делают на основе Xamarin.
                              0
                              Xamarin.Forms, прошу заметить
                            +3
                            Для кроссплатформенной десктоп-разработки с шарпом есть как минимум два крупных фрэймворка:

                            github.com/AvaloniaUI/Avalonia

                            github.com/unoplatform/uno

                              0

                              За второй спасибо. С авалоном несрослось.

                                +1
                                Скажите, а что не так с AvaloniaUI?
                                  0
                                  Очень сырая, отсутствие документации(название метода + сигнатура — не дока) и куча багов(у меня очень часто отваливались стандартные компоненты ListBox, Image).
                                  P.S сейчас посмотрел доку, она стала намного лучше, появились туториалы. Вообще проект очень многообещающий, желаю ему удачи, но пока что это не совсем пригодно для продакшена.
                          +6
                          1) .NET Core
                          2) Avalonia UI
                          2) имхо основной упор таких технологий как Java и .NET сейчас именно в вебе. Xamarin нужен в основном если очень важно иметь кодовую базу на одном ЯП.
                            0

                            Причем тут авалония и прочие фреймворки и поделки? Я акцентировал внимание на то, что от мелкомягких нет движения языка в десктоп на неродной ОС и это его минус. Да есть сторонние решения, но вопрос об их готовности к продакшину вызывает длинные дискуссии.

                              +2
                              Десктопная разработка сейчас в целом не в тренде. Мелкомягкие развивают .NET в том векторе, на котором хорошо зарабатывают — веб, облака и даже кое какие подвиги в ML есть
                                +3
                                Это я понимаю, я написал, что это минус (или вы считаете это плюсом?).

                                Я акцентировал на то, что статья изначально хвалебная — а у языка шарп и решения.НЕТ в целом есть проблемы (как и у любого другого языка). Статья необъективная.
                                  +1
                                  1) это не хорошо и не плохо, это просто рыночек
                                  2) статья заказная, чисто чтобы хостера прорекламировать. Такие часто в последнее время выходят
                                    0
                                    Вот за что меня так жестко заминусовали — за нелестный отзыв заказной статье. Приму к сведению, что проплаченные посты комментировать опасно.:))))

                                    P.S. Вижу и тебе прилетело за правду… :)))
                                +3
                                Вообще то движение есть. Тот же .NET Multi-platform App UI (MAUI) например. Вопрос в том когда это будет настолько развито чтобы это было удобно использовать и как сложно будет туда портироваться с уже существующих проектов.
                                  +1
                                  Это ой как нескоро…
                                    0
                                    Через год обещали .Net 6 с релизом MAUI
                                      0
                                      Ну если смотреть на то какими темпами мелкомягкие продвигают такие фичи, то это скорее всего год-два. С тем же блэйзором примерно тоже самое было.
                                    +2
                                    Претензия непонятна. О каком десктопе идёт речь конкретно? На Qt? На GTK? Ещё на чём-то? У Линукса нет такого понятия как единый десктоп. Или речь идёт о чём-то вроде Swing у Явы? Вот этого точно не надо.
                                      0
                                      Речь идёт о более-менее удобном и работающем кроссплатформенном десктопе. И его у .Net действительно пока нет и местами его действительно не хватает.Например у нас на фирме джава нужна только чтобы писать десктоп под «не винду».
                                        +1
                                        И какие библиотеки вы используете в итоге для решения этой задачи?
                                          0
                                          Тот самый свинг и используем например. И на Qt тоже отдельные команды работают.
                                            +1
                                            > Свинг

                                            Интерфейс должен выглядеть нативно везде, свинг этому не соответствует. Qt соответствует, но он не про Яву совсем.

                                            Нативно выглядящие фрэймворки для шарпа я приложил в другом комментарии:

                                            github.com/AvaloniaUI/Avalonia

                                            github.com/unoplatform/uno

                                            Так что это проблема из прошлого.

                                              +1
                                              В случае с B2B решениями интерфейс часто просто должен стабильно работать. Как он при этом выглядит это уже даже не вторично. И что Авалония, что Уно на данный момент ещё достаточно сыроваты и часто создают проблемы.
                                                0
                                                B2B-решения постепенно, но массово переползают в облако, как тут было верно замечено до этого, поэтому этот вопрос бизнес-актуальности для MS не имеет.

                                                Про Авалонию и её определённую сырость я спорить не могу, пилят вовсю, а что не так с Уно?
                                                  +2
                                                  B2B-решения постепенно, но массово переползают в облако, как тут было верно замечено до этого, поэтому этот вопрос бизнес-актуальности для MS не имеет.

                                                  Не смешите меня. Мы например делаем автоматические и полуавтоматические производственные линии и для наших клиентов «облако» это ругательное слово. Сейчас никто в здравом уме не будет пихать управление подобными вещами в облако. Там даже обычно доступа к интернету нет :)

                                                  Про Авалонию и её определённую сырость я спорить не могу, пилят вовсю, а что не так с Уно?

                                                  Если честно то после того как тестовые приложения начали глючить на наших тестовых «экзотах», то мы даже и разбираться не стали. Может потом ещё раз попробуем.
                                                    0
                                                    Не смешите меня. Мы например делаем автоматические и полуавтоматические производственные линии и для наших клиентов «облако» это ругательное слово. Сейчас никто в здравом уме не будет пихать управление подобными вещами в облако. Там даже обычно доступа к интернету нет :)


                                                    Да я и не смешу. То, что десктопная разработка в B2B становится нишевой это неоспоримая реальность, чем дальше, тем меньше её будет, и ориентироваться на нишу при разработке массового инструмента нецелесообразно.

                                                    insights.dice.com/2020/03/04/desktop-development-dead-still-worth-it

                                                    Conclusion: Desktop (Barely) Hanging On

                                                    Если честно то после того как тестовые приложения начали глючить на наших тестовых «экзотах», то мы даже и разбираться не стали. Может потом ещё раз попробуем.


                                                    Когда это было и на какой версии?
                                                      0
                                                      . То, что десктопная разработка в B2B становится нишевой это неоспоримая реальность, чем дальше, тем меньше её будет, и ориентироваться на нишу при разработке массового инструмента нецелесообразно.

                                                      У нас клиенты местами до сих пор на XP сидят. Как вы думаете перейдут они на облако до того как я на пенсию уйду? Я что-то сомневаюсь.

                                                      И да, чистый десктоп всё больше становится нишей. Но скорости там совсем не космические…

                                                      Когда это было и на какой версии?

                                                      Было это года полтора-два назад. И поскольку занимался этим не я лично, то детали сейчас дать не могу. Но если действительно интересно, то могу поспрашивать.
                                                        +1
                                                        Клиенты на XP это такая же миниатюрная ниша и Ява бросила поддержку этой ОС ещё в 2014 году, поэтому аргумента в её пользу тут нет.

                                                        И да, чистый десктоп всё больше становится нишей. Но скорости там совсем не космические…


                                                        Какие бы скорости ни были, тренд очевиден, будущее не за десктопом, и прицельно под него разрабатывать на разные платформы это не очень умно с точки зрения бизнеса, особенно с учётом, того, что уже есть сторонние продукты, реализующие кроссплатформенный десктоп.

                                                        Было это года полтора-два назад. И поскольку занимался этим не я лично, то детали сейчас дать не могу. Но если действительно интересно, то могу поспрашивать.


                                                        Тогда у Уно ещё версии 2.0 не было, сейчас актуальна третья ветка, даже с поддержкой и обучением:

                                                        platform.uno/training
                                                          0

                                                          Ну так о том и речь что нужно что-то кроссплатформенное и даже если что-то где-то уже и есть, то многие ге готовы менять шило на мыло. И поэтому ждут "официального" решения от Микрософта.

                                                            0
                                                            Его не будет, и это очевидно. Microsoft сама рекомендует сторонние решения, в том числе и Uno:

                                                            blogs.windows.com/windowsdeveloper/2020/05/19/introducing-winui-3-preview-1
                                                              0

                                                              Ну, как уже писалось выше, очевидно что Майкрософт как минимум собирается толкать свой MAUI.

                                                                0
                                                                Ну так это тот же Xamarin после ребрендинга, и готов он будет только через год, а Uno уже сейчас. Хотя на гитхабе пишут, что для макоси MAUI конкретно поддерживать будет сама MS, но для Линукса нет, так же Community, так что непонятно, чего ждать.

                                                                github.com/dotnet/maui#xamarinforms-vs-net-maui
                                                                  0

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


                                                                  А год подождать это для большинства вообще не проблема.

                                                                    0
                                                                    Если год подождать не проблема, тогда соглашусь, потому что .NET 6 будет LTS как раз.
                                                                      –1

                                                                      Ну так об этом и речь. Плюс по идее всякие превью и пререлизы должны появиться и раньше. И там уже можно будет прикинуть стоит вообще ждать или нет.

                                                            –2
                                                            Какие бы скорости ни были, тренд очевиден, будущее не за десктопом, и прицельно под него разрабатывать на разные платформы это не очень умно с точки зрения бизнеса, особенно с учётом, того, что уже есть сторонние продукты, реализующие кроссплатформенный десктоп.

                                                            скоро в рф будет чебурнет и вы будете сидеть в каком-н российском облаке. Или БЕЗ облаков.

                                                  0
                                                  свинг этому не соответствует

                                                  Никто не запрещает задать одинаковый LookAndFeel для всех систем или создать свой.
                                      +8
                                      Могу от себя сказать про минусы:
                                      • Высокий порог входа, по сравнению с php или go
                                      • Зарплаты на 10% ниже чем у Java разработчиков сравнимой компетенции
                                      • До сих пор есть «особенные» разработчики, считающие что C# это только Windows или только формочки
                                      • Есть несколько языковых конструкции (например поддержка динамической типизации вместе со статической) которые не нужны (хотя тот же dynamic замечательно подходит для прототипирования)
                                      • Не возникают так часто проблемы с heap при работе с большим объемом данных (так как есть отдельный дефрагментируемый heap для больших объектов), но вот конфигурируемости GC, что есть в java, увы нет. Как и внятных альтернативам дефоллтному GC
                                      • AOP есть, но не популярен
                                      • Есть только один внятный фреймворк для мутационного тестирования
                                      • Интерация со Apache Spark тольк очерез API (как сделано в python), т.е. нет возможность вклинивать свой код в ноды, как можно в JVM ориентированных языках
                                      • ML в зачаточном состоянии. Но это если мы не говорим о SAAS. В плане интеграции с ML SAAS решений все ок (а это и нужно в 90% случаев :) )
                                      • Кросс платформ для мобилок очень мощный (так как есть прямой доступ к нативным API), то требует высокой квалификации (так как есть прямой доступ к нативным API)
                                      • Если говорить о Unity, то проблема не в «глюках», а в банальных вещах: GC (в Unity он «свой») и комплируемости языка (очень бесит что, по сравнению с Godot, необходимо перезапускать проект (и перепроходит уровень) ради написания одной строчки кода)
                                      • .wasm фреймворк blazor неплох, но пока недостаточно mature
                                      • Интеграция с anaconda есть… но этого недостаточно


                                      Т.е. если у вас есть задачи, которые я описал выше (ML, Data Science, Spark, Big Data), то C# тут действительно не очень хорошо подходит
                                        +13

                                        После шарпа, зайти в php с его синтаксисом ($, ->) и слабо развитым инструментарием, было больно. Так что тут еще неизвестно где порог входа (боли) выше :)


                                        В java зп выше, ну так это за вредность доплачивают.


                                        По поводу dynamic, так по мимо него есть еще и goto, но это не проблемы языка.

                                          0
                                          На java не только зп выше, но и специка работы совсем другая (в лучшую сторону).
                                            0
                                            А можно уточнить?
                                              +1

                                              На java написано много всякого распределенного и высоконагруженного. См spark, hadoop, kafka, lucene, elasticsearch. На C#/.NET ничего такого практически нет (RavenDB, что ещё?)


                                              Как результат, на C# много вакансий клепать круды и формочки, а на java больше интересных вариантов.

                                                0
                                                На java больше интересных вариантов.

                                                Если смотреть вакансии по России — кроме банков и страховщиков много контор, которым java кодеры нужны? Я вот только jetbrains могу вспомнить. Так что насчет интересности я бы поспорил.
                                                  0

                                                  Одноклассники и Яндекс.
                                                  У первых хватает всякого веселого самописного и работы в open source проектах, помимо всей соцсети.
                                                  Во втором есть Маркет, Облако и разные другие веселые ребята.
                                                  А еще есть ALM(с плагином для JIRA), биоинформатики, Wrike со своей альтернативой JIRA, Exactpro со своими инструментами автоматизации тестирования, куча финтех проектов, Почта России(сам в афиге), разные аутсорсеры и консультанты и далее, далее, далее…
                                                  Это те компании, в которые меня пытались схантить, либо в которых я работал. Ну и это Питер, в основном. На мой взгляд — работа есть.

                                                    0
                                                    Хм… удивительно, вокруг меня сложился какой-то такой пузырь из людей, которые на java пишут только для финансовых организаций, что у меня сложилось мнение что у нас java не особо популярна в других отраслях. Хотя про почту россии довелось слышать и даже была возможность почитать кое-какую техническую документацию оттуда. (спойлер: все очень плохо)
                                                      0
                                                      Там все бюрократизированно регламентированно, и многое под это регламентированное написано на джаве с лохматых годов. Многие банки меняют вывески, а лицензии были получены еще в девяностых, софт соответственно тоже древнючий.
                                                        0
                                                        > софт соответственно тоже древнючий

                                                        Тогда это не Java, а Clipper :)
                                                        0
                                                        Посмотрите видео от JUG.ru. Составите разнообразное мнение о Java проектах.

                                                        На Java когда то даже геномный ассемблер писали.
                                                    –2
                                                    На сисярп в основном asp.net, веб сервисы, всякие там сервисы доставки, всякие почты россии и прочий новодел.
                                                    Если начинать сейчас средний типовой проект на микросервисах с бэком, фронтом + мобайл ну кто на джаве его будет строить.
                                                      –1
                                                      Умеющие в Java люди, кто ж еще.
                                                      Не переучиваться же им на C# только ради возможности построить очередной типовой проект, которые они уже строили не раз на известном им стеке.
                                                      Да и Kotlin + JVM на мой взгляд удобнее для таких проектов, чем C# + .Net. Как минимум наличием нормальной IDE под Linux.
                                                        +3
                                                        Как минимум наличием нормальной IDE под Linux.

                                                        Внезапно
                                                          –1

                                                          Насколько я помню, Rider по возможностям не дотягивает ни до IntelliJ IDEA ни до Visual Studio.
                                                          Если я не прав — что ж, голову пеплом(в прямом смысл) я умудрился посыпать еще позавчера :)

                                                            0
                                                            В VS испокон веков прикручивали R#, который в райдере, по сути, идет «из коробки». Единственное ограничение, с которым я сталкивался на практике — нет поддержки шаблонов T4, которые любят в легаси проектах.
                                                            Про саму IDEA судить особо не могу, но она славится своими рефакторингами, которых у Rider тоже есть богато.
                                                              0
                                                              Единственное ограничение, с которым я сталкивался на практике — нет поддержки шаблонов T4, которые любят в легаси проектах.

                                                              А какая поддержка нужна? Код сгенерить можно, подсветка есть, хоть и частичная.

                                                              0

                                                              Насколько я помню, решарпер перестали прикручивать несколько лет назад. Толи конфликтовал он с новыми возможностями студии, толи перестал быть нужным из-за них.
                                                              Но это лишь выжимка из дошедших до меня слухов.

                                                                0
                                                                Не перестали) Это рассуждения уровня: «C# можно писать в VS Code, там классный IntelliSense». В студии таки начали появляться реафакторинги, но до R# она до сих пор не дотягивает.
                                                              +1

                                                              Для меня Rider по возможностям как минимум не хуже студии. Насчет IDEA не могу сказать точно, но на первый взгляд они примерно одинаково мощные, хотя сравнивать их не совсем корректно, так как все же на разные языки ориентированы.

                                                                –1

                                                                Ну, у меня просто опыт неосилятора: взял имеющийся проект на .net, открыл его в Rider на MacOS, собрать не смог. Предполагаю, что в Visual Studio на Windows проект был бы собираемым.
                                                                С Java проектами в IDEA на общеупотребимых системах сборки я такого не встречал.

                                                                +1
                                                                Я в райдер перешёл с Visual Studio (и куча коллег заодно). Навигация по коду несравнимо быстрее. Рефакторинг удобней. Отличная поддержка систем контроля версий, чтоб вообще не вылезать из него.
                                                                  +2

                                                                  Rider и IDEA — это одна и та же IDE, заточенная под разные языки (как и все прочие IDE от жетбрейнс). Пользуюсь и тем и другим ежедневно, под Linux. Возможности примерно одинаковые.

                                                                    0
                                                                    Rider и IDEA — это одна и та же IDE

                                                                    Не буду спорить, я где то читал несколько другую информацию.
                                                                –1
                                                                А что такое нормальная IDE? Если говорить о сборщике и анализаторе то roslyn ничуть не хуже maven и тоже может на линух. Если говорить о редакторе то кому-то vim за глаза.
                                                                  0

                                                                  Если maven с чем и сравнивать, то с msbuild + nuget, а не с компилятором!

                                                                    0
                                                                    Да, вы правы, maven это сборщик как и msbuild, если сравнивать roslyn то скорее с javac
                                                          0

                                                          Это может так где-то у вас оно так. У нас в регионе ситуация скорее обратная.

                                                            0

                                                            Какую роль в 2020 играет регион? Все на удаленке. Важна глобальная ситуация.

                                                              0
                                                              Я не знаю где «все на удалёнке». У нас подавляющее большинство до сих пор работает из офиса. Ну за исключением периода локдауна конечно.
                                                                0

                                                                +1, у нас тоже удалёнка не прижилась нигде в городе.

                                                          0
                                                          По поводу dynamic, так по мимо него есть еще и goto, но это не проблемы языка

                                                          .


                                                          Начинающие программисты говорят, что goto — зло.
                                                          Продвинутые — пытаются замаскировать goto под break, throw, return…
                                                          Просветленные — молчат и улыбаются когда пишут goto.

                                                          тот же выход из вложенных циклов куда проще через goto, чем флаги. И хреновый код это не проблема языка. Скорее, использование множества флагов вместо goto это хреновый код.

                                                            –2
                                                            Поддерживаю. Всегда удивляюсь ущербности мышления избегающих применения goto. Проблема не в Goto, а в его неумелом повсеместном использовании. Выход из вложенных циклов это как раз и есть сфера Goto, где его ГЛУПО заменять захламляющими код флагами. Частично проблема решена в Python с его for… else, но лишь в некоторых случаях код получается чище.
                                                              +1
                                                              тот же выход из вложенных циклов куда проще через goto, чем флаги

                                                              А точно не через break по метке?

                                                                0

                                                                не знал. Когда-то пробовал, но то ли не было в языке, то ли не работало… С тех пор писал goto.

                                                                  0
                                                                  Это как? Погугли, но не нашел. Можете пример привести?
                                                                    0

                                                                    Нет в C# break по метке. И, судя по реакции дизайнеров, не будет.

                                                              +9
                                                              Есть несколько языковых конструкции (например поддержка динамической типизации вместе со статической) которые не нужны (хотя тот же dynamic замечательно подходит для прототипирования)

                                                              Как-то странно записывать в минусы языка его фичи, которые не обязательно использовать.

                                                                0
                                                                Подход «не обязательно использовать» работает только если нет унаследованного кода, в котором эту необязательную фичу активно использовали.
                                                                0
                                                                Есть несколько языковых конструкции (например поддержка динамической типизации вместе со статической) которые не нужны
                                                                Есть некоторые вещи, которые без динамической типизации не реализуются
                                                                github.com/NightmareZ/PropertyProxy
                                                                  +1

                                                                  Для таких случаев придумали интерфейсы.

                                                                    –4
                                                                    Это натуральный гемморой, создавать по интерфейсу на каждый класс, когда у тебя их могут быть десятки, а потом ещё и поддерживать всю эту лабуду в консистентном состоянии. Вместо того, чтобы на месте задать атрибутами то, что надо.
                                                                      +4

                                                                      А ловить ошибки доступа в рантайме — что, не гемморой?


                                                                      Плюс такой подход нарушает DIP. Плюс такой подход ломается когда у вас есть два потребителя, которым требуются разные API.

                                                                        0
                                                                        Конкретно этот код был мной написан для использования стороннего закрытого компонента. Какой к чёрту DIP? Давайте спустимся с небес и поговорим в терминах реального программирования.

                                                                        Я делал простой 2D редактор, где по холсту можно было таскать компоненты. Каждый компонент задаётся классом, количество компонентов и их типов заранее неизвестно. У каждого компонента (класса) есть набор свойств, увсех разное. Мне нужно было отображать эти свойства в некотором гриде.

                                                                        Как должен работать грид. Ты задаёшь свойствам своего класса специальный аттрибут. Затем можешь объект этого класса передать в этот грид и он отобразит все те свойства, которые ты аттрибутом пометил, а другие — не отобразит.

                                                                        Всё бы было хорошо, но грид не работал, как надо, и отображал все свойства объекта, даже те, которые не нужно. Можно было, конечно, использовать другой грид или ещё как-то поступить по-умному, но я вышел из ситуации таким вот образом: создал генератор прокси-классов, которые пробрасывали нужные свойства, помеченые атрибутами.
                                                                          +2

                                                                          Вот, теперь задача начинает вырисовываться, и она отличается от того, что было написано изначально.


                                                                          Во-первых, вам тут нужен класс для передачи в чужой код, который будет обращаться к нему через отражение (рефлексию). Вам для этой задачи нет необходимости обращаться к этому классу самостоятельно через dynamic, задача решается без него!


                                                                          Во-вторых, вполне возможно, что вам на самом деле был нужен метод TypeDescriptor.AddProvider. Или можно вовсе сделать особый класс, основанный на массиве настроек...

                                                                            +1

                                                                            Да, вот вам для примера код с которого можно начать:


                                                                            Код
                                                                                [TypeDescriptionProvider(typeof(PropertyProxyTypeDescriptionProvider))]
                                                                                public sealed class PropertyProxy
                                                                                {
                                                                                    public PropertyProxy(object obj, IReadOnlyCollection<string> properties)
                                                                                    {
                                                                                        Object = obj;
                                                                                        Properties = properties;
                                                                                    }
                                                                            
                                                                                    public object Object { get; }
                                                                                    public IReadOnlyCollection<string> Properties { get; }
                                                                                }
                                                                            
                                                                                public sealed class PropertyProxyTypeDescriptionProvider : TypeDescriptionProvider
                                                                                {
                                                                                    public override ICustomTypeDescriptor GetTypeDescriptor(Type objectType, object instance)
                                                                                    {
                                                                                        if (instance is PropertyProxy pp)
                                                                                            return new TD(pp);
                                                                            
                                                                                        return base.GetTypeDescriptor(objectType, instance);
                                                                                    }
                                                                            
                                                                                    private sealed class TD : CustomTypeDescriptor
                                                                                    {
                                                                                        private readonly PropertyProxy pp;
                                                                            
                                                                                        public TD(PropertyProxy pp)
                                                                                        {
                                                                                            this.pp = pp;
                                                                                        }
                                                                            
                                                                                        public override PropertyDescriptorCollection GetProperties() => GetProperties(null);
                                                                                        public override PropertyDescriptorCollection GetProperties(Attribute[] attributes)
                                                                                        {
                                                                                            var result = TypeDescriptor.GetProperties(pp.Object, attributes)
                                                                                                .Cast<PropertyDescriptor>()
                                                                                                .Where(prop => pp.Properties.Contains(prop.Name))
                                                                                                .Select(prop => new PD(prop))
                                                                                                .ToArray<PropertyDescriptor>();
                                                                            
                                                                                            return new PropertyDescriptorCollection(result);
                                                                                        }
                                                                                    }
                                                                            
                                                                                    private sealed class PD : PropertyDescriptor
                                                                                    {
                                                                                        private readonly PropertyDescriptor inner;
                                                                            
                                                                                        private EventHandler onValueChanged = null, innerValueChanged = null;
                                                                            
                                                                                        public PD(PropertyDescriptor inner) : base(inner)
                                                                                        {
                                                                                            this.inner = inner;
                                                                                        }
                                                                            
                                                                                        public override Type ComponentType => typeof(PropertyProxy);
                                                                                        public override bool IsReadOnly => inner.IsReadOnly;
                                                                                        public override Type PropertyType => inner.PropertyType;
                                                                                        public override TypeConverter Converter => inner.Converter;
                                                                            
                                                                                        private object GetObject(object component) => ((PropertyProxy)component)?.Object;
                                                                            
                                                                                        public override bool CanResetValue(object component) => inner.CanResetValue(GetObject(component));
                                                                                        public override object GetValue(object component) => inner.GetValue(GetObject(component));
                                                                                        public override void ResetValue(object component) => inner.ResetValue(GetObject(component));
                                                                                        public override void SetValue(object component, object value) => inner.SetValue(GetObject(component), value);
                                                                                        public override bool ShouldSerializeValue(object component) => inner.ShouldSerializeValue(GetObject(component));
                                                                            
                                                                                        private EventHandler MakeInnerValueChanged(object component)
                                                                                        {
                                                                                            if (innerValueChanged == null)
                                                                                                innerValueChanged = (_, args) => onValueChanged?.Invoke(component, args);
                                                                                            return innerValueChanged;
                                                                                        }
                                                                            
                                                                                        public override void AddValueChanged(object component, EventHandler handler)
                                                                                        {
                                                                                            if (onValueChanged == null)
                                                                                                inner.AddValueChanged(GetObject(component), MakeInnerValueChanged(component));
                                                                            
                                                                                            onValueChanged += handler;
                                                                                        }
                                                                            
                                                                                        public override void RemoveValueChanged(object component, EventHandler handler)
                                                                                        {
                                                                                            onValueChanged -= handler;
                                                                            
                                                                                            if (onValueChanged == null)
                                                                                                inner.RemoveValueChanged(GetObject(component), MakeInnerValueChanged(component));
                                                                                        }
                                                                                    }
                                                                                }

                                                                            Работоспособность не проверял, но после исправления каких-нибудь глупых NRE должно заработать. Просто передаём вашему гриду new PropertyProxy(realObject, new HashSet<string>(список свойств)), и он должен отобразить для редактирования указанные свойства (если это адекватный грид, уважающий ComponentModel).


                                                                            Как видно, ни dynamic, ни кодогенерации, ни даже открытой рефлексии для решения задачи не понадобилось.

                                                                    0

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

                                                                      +2
                                                                      (хотя тот же dynamic замечательно подходит для прототипирования)

                                                                      Никогда не мог понять подобных заявлений. Каким образом это может облегчать прототипирование хоть как-то? Или это я не умею на питоне динамиках писать?

                                                                        0
                                                                        Могу назвать пример, когда dynamic явился почти необходимостью и архи-полезной фичей — я писал парсер игровых скриптов Factorio и модов к нему. Собственно, interop между Lua и .NET в силу динамичности первого можно осуществить либо очень больно и нудно, либо через dynamic. Так что dynamic хорош не только для прототипирования, но как минимум ещё и для взаимодействия с другими языками/средами. Да и я думаю ещё много примеров наберётся. Так что зря вы так про динамическую типизацию в шарпе.
                                                                        0
                                                                        Вот реально, чего глючного в Unity? UE опробуйте, движок прям впечатляет, чуть ли не любая ошибка в C++ приводит к крэшу редактора UE, да, очень удобно, очень безглючно. А учитывая «качество» документации UE, эти ошибки будут прям на регулярной основе. А если взять blueprint, да, тут с ошибками лучше, но когда оно не умеет работать по ссылкам, нет, увольтес, что-то адекватное сделать уже куда сложнее чем на том же Unity. А если брать бесплатные, опенсорсные, то ситуация с глючностью ещё лучше, они такие безглючные, что некоторые тупо падают вообще без внешних разражителей.
                                                                          0

                                                                          Отвечу самый простой пример — переход с версии на версию ломают проекты. Странно получать несовместимость в textmesh при переходе с 2019 на 2020 и из-за этого получать море нерабочих асертов купленных ранее. Парадигма поиска объектов по их текстовому имени — это вообще отдельная статья. Проваливание гейм объектов через стандартные коллайдеры обсуждаются уже несколько лет...

                                                                            +1
                                                                            > переход с версии на версию ломают проекты
                                                                            Мне кажется, в плане Unity не стоит вообще обновляться на на LTS релизы. Разработчики пилят сейчас очень много новых (и реально крутых) фич, что с учетом размеры команды, не позволяет им с первого раза выкатывать нормальную версию. В принипе, похожая ситуация была в свое время с докером, когда x.0 версией нельзя было пользоваться.

                                                                            > Парадигма поиска объектов по их текстовому имени
                                                                            А кто требует этим пользоваться, можно же искать по тегу? В unity есть еще масса проблемных вещей, которые не стоит юзать.

                                                                            > Проваливание гейм объектов через стандартные коллайдеры
                                                                            А можно линку? У меня были похожие проблемы, но только если я двигал что-то в Update, а не в FixedUpdate. Но похоже тут другая проблема…
                                                                              0
                                                                              Вот с 2012 года
                                                                              unity3d.ru/distribution/viewtopic.php?f=89&t=7896
                                                                              Мы в нашей игре поймали это на версии Unity 2019.4 LTS и переписывали логику меш колайдеров костылями.
                                                                                0
                                                                                О, интересно. Т.е. проблема возникает именно на очень больших скоростях и маленьких коллайдерах?
                                                                                  0
                                                                                  Мы поймали на каплях воды при падении на поверхность (колайдер). Скорость была невысокая, а колайдер меняли размер — все равно проблема оставалась на большом количестве частиц.
                                                                              +7
                                                                              Потому что это оптимизация физического движка. Первая ссылка в гугле по запросу «unity fast collider»:
                                                                              stackoverflow.com/questions/44266691/collision-detection-for-fast-moving-game-object-in-unity
                                                                              Поменяйте тип collision detection на continuous для вашего коллайдера, и будет вам счастье. Это не специфично для Юнити, все физические движки так работают, я не понимаю, что там было обсуждать несколько лет.
                                                                            0
                                                                            Почему нет ничего про его четкую заточенность на Виндовс?

                                                                            у нас в банке некоторые проекты уже крутятся на кор и под линукс
                                                                            и…
                                                                            Десктоп приложения на нем писать можно только под мелкомягких,

                                                                            У нас же в банке до сих пор есть команды которые пишут под WPF
                                                                            Так что вы расскажите, вы видимо на пенсию вышли лет пять назад, если нет то я не уверен что вы правильно выбрали профессию, отставать на пять лет в программировании не простительно.
                                                                            А стоп, вы просто тролль?
                                                                              0
                                                                              ну так Visual Studio for Mac есть, плюс к этому есть Mono который пашет под линуксом. Правда работает под GTK.
                                                                              +7

                                                                              Статья ради статьи?


                                                                              Шапрпповый код при компиляции превращается в промежуточный язык, который выполняется JIT-компилятором на клиентской машине — в этом есть свои преимущества, но такой принцип работы не оставляет шансов писать настолько же быстрый код, как на плюсах или голанге. Но C# все ещё достаточно быстрый в своей категории

                                                                              Просто оставлю это здесь: https://benchmarksgame-team.pages.debian.net/benchmarksgame/fastest/go-csharpcore.html


                                                                              C# почти на всех бенчмарках бьёт Go по скорости. Могли бы потрудиться посмотреть их.

                                                                                +1
                                                                                Действительно странная логика автора: c чего это JIT может быть медленее AOT? Есть же, в таком случае, возможность оптимизации под конкретное железо, но котором выполняется код.

                                                                                А вот где действительно есть просадка, так это во времени запуска. Но тут лучше не go выбирать, а node.js, так как холодный старт объективно выше в интерпретируемых языках.

                                                                                С другой стороны… а в каких случаях вам нужен именно быстрых холодный старт?
                                                                                  0
                                                                                  С другой стороны… а в каких случаях вам нужен именно быстрых холодный старт?

                                                                                  Serverless. Там это бывает важно. Хотя облака с этим борятся. Амазон, например, в прошлом году запилил Provisioned Concurrency, который правда денег стоит.
                                                                                    0
                                                                                    Проверяли как то холодный старт в AWS… нода всех уделал в плане холодного старта, а .Net после прогрева. Но это было год назад, сейчас может поменялось.

                                                                                    Так же была одна задача, когда генерили тонну инстансов на пару секунд. И там JIT был оченьвреден и пришлось использоват другой подход.
                                                                                      0
                                                                                      Да, нода обычно всех уделывает по холодному стрту. Го правда потом меньше памяти обычно жрёт, но в лямбдах IMO холодный старт выжнее.
                                                                                    0
                                                                                    Действительно странная логика автора: c чего это JIT может быть медленее AOT?

                                                                                    С того, что у JIT, в отличие от AOT, весьма небольшое время для применений оптимизаций, и потому некоторые оптимизации он просто не в состоянии провести в принципе?

                                                                                +20

                                                                                C# кажется лучшим языком общего назначения на данный момент:


                                                                                • Лучший тулинг
                                                                                • Лучшая стандартная библиотека
                                                                                • Лучшая документация
                                                                                • Перформанс близок к нативному коду
                                                                                • Высокая скорость разработки
                                                                                • Нормальный асинк
                                                                                • LINQ
                                                                                • Низкоуровневые возможности, лёгкий интероп с нативным кодом

                                                                                Kotlin наступает на пятки, но пока ещё недостаточно популярен.


                                                                                В дотнете на все есть практики, и все им следуют

                                                                                Да, и это прекрасно. Взять ту же асинхронщину. Да, тема сложная, но всё стандартизировано, расписано в доках, изучи и будет хорошо. В Java, к примеру, полный бардак и зоопарк, в каждой либе свои Future, культура асинхронного кода отсутствует, далеко не все даже "синьёры" знают, как правильно с этим всем работать.

                                                                                  +8
                                                                                  И вот тут возникает интересная ситуация: в соседнем топике про «Scala крута, но большой бинарь. Вот приходится писать на go» мой вопрос «а почему бы не посмотреть на C#» заминусовали.
                                                                                  habr.com/en/post/520114/#comment_22130682

                                                                                  Возникает ощущение, что большинство не .net разработчиков предпочитает не задумываться о существовании C#/.Net. И как результат, страдают. Невежество оно такое… поражает в первую очередь невежду.
                                                                                    +5

                                                                                    Потому что у C# тоже большой бинарь.

                                                                                      0
                                                                                      Уже есть апп тримминг в .NET 5, который хорошо уменьшает размер апп'а.
                                                                                    0

                                                                                    А как же CompletableFuture в Java?

                                                                                      +4

                                                                                      Проблема в том, что CompletableFuture — это аналог TaskCompletionSource, возвращать его из public API не айс, это нарушает инкапсуляцию — кто угодно снаружи может вызвать complete(). Казалось бы, можно возвращать CompletionStage, но оно не реализует Future. Более того, у CompletionStage есть toCompletableFuture(), что возвращает нас к изначальной проблеме. Всё это выглядит как ошибка проектирования.


                                                                                      Вышесказанное, а так же исторические причины, приводит к тому, что многие популярные либы возвращают свои собственные фьючи (см Netty, Lettuce). Можно представить, как здорово смотрятся 3 разных фьючи в рамках одного проекта.

                                                                                      +1
                                                                                      Я бы еще в плюсы добавил что за .net стоит MS, с кучей денег, амбициями и классными результатами на мировом рынке. Синергия технологий, подкрепленная рекой денег.

                                                                                      Мне интересно почему новые проекты не стартуют массово именно на C#, почему люди, которые принимают решения (технологии + бюджет) все еще не смотрят на .net по дефолту
                                                                                        0
                                                                                        Мне интересно почему новые проекты не стартуют массово именно на C#, почему люди, которые принимают решения (технологии + бюджет) все еще не смотрят на .net по дефолту

                                                                                        Ну например потому что разработчиков на С# не бесконечное количество и тех же разработчиков на джаве тоже надо куда-то девать :)
                                                                                          0

                                                                                          Можно переучиться — не так сложно на самом деле, инфраструктура проще на мой взгляд.

                                                                                            0
                                                                                            Можно. Но это время и кроме того «переученный джавист» всё равно долгое время на С# будет писать хуже чем до этого писал на джаве. Плюс далеко не все вообще согласятся переучиваться.

                                                                                            Но да, в принципе я бы сказал что как минимум у нас гораздо больше фирм переходят с джавы на шарп чем обратно.
                                                                                        0
                                                                                        • Перформанс близок к нативному коду
                                                                                        • LINQ

                                                                                        Вот эти вещи довольно плохо сочетаются.

                                                                                          +2

                                                                                          А что не так с LINQ?

                                                                                            –2

                                                                                            То, что он плохо оптимизируется, причём чисто в силу дизайна, основанном на стирании типов.

                                                                                              +3
                                                                                              О каком стирании типов речь? Сам интерфейс LINQ статически типизирован, а .NET поддерживает дженерики в рантайме (в отличие от JVM, где параметры-типы затираются).
                                                                                                –1
                                                                                                Сам интерфейс LINQ статически типизирован

                                                                                                Да в том-то и дело, что не очень. Что возвращает Where? Where возвращает IEnumerable<TSource>. Что возвращает Skip? Снова IEnumerable<TSource>. А что возвращает Select? IEnumerable<TResult>. Каждый из этих методов возвращает вполне конкретный тип, но в силу того, что тип объявлен как IEnumerable<T>, эта информация теряется, тип деградирует до интерфейса, и компилятору приходится выяснять, какой именно это тип на самом деле, чтобы модно было заинлайнить методы.


                                                                                                Также все методы IEnumerable также принимают экземпляр интерфейса. Казалось бы, что мешает написать сигнатуру навроде


                                                                                                public static IEnumerable<TSource> Where<TSourceEnumerable, TSource> (this TSourceEnumerable source, Func<TSource,bool> predicate) where TSourceEnumerable: IEnumerable<TSource>;

                                                                                                Но нет, мы будем принимать именно интерфейс и забывать исходный тип. И плевать, что мог быть структурой — мы всё равно сделаем сигнатуру, которая всегда будет требовать боксинга.


                                                                                                И в итоге мы имеем, что при написании проекта на C# всегда нужно выбирать между удобством LINQ и производительностью циклов.

                                                                                                  +1
                                                                                                  что мешает написать сигнатуру навроде

                                                                                                  Передача структуры в метод по значению (копирование).

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

                                                                                                  Все стандартные коллекции (включая массивы) .NET — референсные типы. Кейс с коллекциями-значениями имеет право на существование, но преувеличивать их значение в типичных сценариях использования C#, имхо, не стоит.
                                                                                                0
                                                                                                Там и так всё почти прекрасно с оптимизацией, и ежели, например, результаты LINQ запроса тебе нужны неоднократно, то тебе статический анализатор пальчиком пожюрит и предложить преобразовать в Array.
                                                                                          –8
                                                                                          C# отличная замена Oracle и 1C в рамках средних размеров организации.
                                                                                            0
                                                                                            По каким KPI столь категоричный отзыв? Просто сферическая организация в вакууме нанимает 1с-ника (их много по разным ценам) на поддержку стандартной конфигурации (их тоже много на выбор).
                                                                                            P.S. Я сам за шарп, но таков опыт работы с разными организациями (особенно подальше от мск).
                                                                                            +3
                                                                                            Работу ты все равно найдешь только бекендером — других вакансий тупо не бывает.

                                                                                            Слишком громкая фраза. Может быть большинство вакансий для бекендеров, но существуют и другие сферы.

                                                                                              0
                                                                                              На hh появилось несколько вакансий на blazor.
                                                                                              +18
                                                                                              Корная либа

                                                                                              Май айз а блидин…
                                                                                                0

                                                                                                Мне больше понравилось "полный суппорт наследования".

                                                                                                +6
                                                                                                промежуточный язык, который выполняется JIT-компилятором на клиентской машине

                                                                                                У вас почему-то слова «выполняется» и «компилятором» находятся в одной строке.
                                                                                                  0

                                                                                                  Это у вас языка без phase distinction не было.

                                                                                                    –1
                                                                                                    А причём тут phase distinction? Java в этом плане не сильно от шарпа отличается, но она может интерпретатором запускаться, пока не скомпилилась. Соль в том, что JVM не называют компилятором. Компилятор умеет только компилировать, интерпретируют интерпретаторы. Может быть где-то существует интерпретатор шарпа, но выполнение байт-кода — это не про jit-компилятор.
                                                                                                      0

                                                                                                      Соль в том, что jit-компиляция — это устоявшийся термин. Вам следовало спорить чем оно является и чем не является 17 лет назад.


                                                                                                      И да, JIT-компилятор именно что компилирует. Только не всю программу целиком, а отдельные методы.

                                                                                                        –1
                                                                                                        Вы таки хотите сказать, что jit-компилятор сишарпа умеет интерпретировать? В противном случае я не понимаю, к чему претензия.
                                                                                                        0

                                                                                                        Ну кстати интерпретатор С# существует и их даже несколько. И даже вполне себе рабочие. Правда производительность относительно сильно уступает компилированному коду.

                                                                                                          0
                                                                                                          Я не отрицаю возможность наличия интерпретаторов сишарпа, я даже прямо об этом сказал. Я отрицаю их целесообразность.
                                                                                                            0

                                                                                                            Ну это вы зря. Чем то массовым это естественно не станет, но скрипты выполнять иногда надо. И часто проще использовать такое чем пытаться интегрировать в С# проекты какой-то другой скриптовый ЯП.

                                                                                                          0

                                                                                                          Я бы не стал делить вещи на классические «компилятор», «интерпретатор», «линкер» и так далее. В 2020-м году это всё очень сложно, смешанно и неконструктивно.

                                                                                                      +4

                                                                                                      Какая-то совершенно сумбурная статья. Как из неё можно понять, где используется платформа .Net, какие у неё в этих нишах конкуренты? Особенности самого языка из статьи может понять только ветеран боёв в комментариях, а не свежеиспечённый программист.


                                                                                                      Даже какой-нибудь IEEE Spectrum, несмотря на спорные результаты, полезнее такой статьи. Там хоть какие-то критерии есть.

                                                                                                        0
                                                                                                        Платформу можно использовать почти везде, кроме, разве что, микроконтроллеров, да и там поползновения были (.NET Micro), и фронта (но, опять же, Silverlight, земля ему пухом). На .NET даже операционку писали.
                                                                                                        А так, это среда общего назначения, очень общего. Игры, игровые движки, десктоп, бэкэнд, в принципе даже высоконагруженные приложения и в какой-то мере ML.
                                                                                                        Ни в чём из этого, кроме десктопа, язык не обладает киллер-фичами, но он просто неплох во всём.
                                                                                                          +1
                                                                                                          > фронта

                                                                                                          Блазор же.
                                                                                                            0
                                                                                                            А, ну тем более. Я далековат от веба, не в курсе был.
                                                                                                        +3
                                                                                                        Мне немного стыдно, когда я вижу код минимально рабочей программы на C#
                                                                                                        Скоро в C# 9:
                                                                                                        using System;
                                                                                                        
                                                                                                        Console.WriteLine("Hello World!");
                                                                                                          +8

                                                                                                          Или даже еще чуть проще:


                                                                                                          System.Console.WriteLine("Hello World!");
                                                                                                            +2
                                                                                                            using static System.Console;
                                                                                                            
                                                                                                            WriteLine("Hello World!");
                                                                                                          +1
                                                                                                          Фронт тоже на блазоре пилят.
                                                                                                            +1
                                                                                                            один вопрос, я люблю Сишарп, но почему многие крутые data engineering фреймворки написаны на Java/JVM языках, а не на шарпе?
                                                                                                            типа хадуп, спарк например и его части.
                                                                                                            Есть ли аналоги-конкуренты чего-то из экосистемы Хадуп написанные на шарпе?
                                                                                                              +1

                                                                                                              Причины исторические — шарп был долгое время с закрытым кодом и только под винду — никак не годился под такие задачи, и момент был упущен.

                                                                                                                0
                                                                                                                Для бигдаты у MS есть Data Lake в облаке. А онпремис они вряд ли будут сами что-то разрабатывать, другая бизнес-модель сегодня у компании.
                                                                                                                  +2
                                                                                                                  очень просто — апач фондейшен
                                                                                                                  0
                                                                                                                  так и не понял, стоит ли связываться с С# в 2020-2021?
                                                                                                                  если, например, хочу в перспективе удаленно работать на буржуев?
                                                                                                                  и с какой его частью стоит связываться на перспективу — десктоп или web, бэк или фронт, Blazor или ASP, ковырять ли интеграцию приложений с Azure?
                                                                                                                    +4
                                                                                                                    хочу в перспективе удаленно работать на буржуев

                                                                                                                    Если это — единственная цель, то ответ — нет. Лучше учить Javascript, вакансий намного больше.


                                                                                                                    Но если есть цель стать хорошим разрабом, то C# — один из лучших вариантов для обучения, потому что даёт возможность попробовать себя во всех областях (бэк, фронт, игры, мобилки), и даёт понимание разнообразных концепций и подходов (асинхронщина, функциональщина, итд). После опыта с шарпом несложно переходить на другие языки. А вот с жаваскрипта перейти на что-то другое будет посложнее.

                                                                                                                    +1
                                                                                                                    Самое дурацкое — очень легко стать шарповой боевой единицей, но момент, как работает твой код — наступит оооочень не скоро. В платформе, принципах её работы — масса нюансов, которые по щелчку не выучатся.
                                                                                                                    Прям интересно стало(без сарказма). Можете привести пример? И, если можно, то посоветуйте литературу какую-нибудь.
                                                                                                                      0
                                                                                                                      И, если можно, то посоветуйте литературу какую-нибудь.

                                                                                                                      clr via c#, исходники платформы в репозиториях github.com/dotnet
                                                                                                                        0
                                                                                                                        Алексей, спасибо. Читаю на данный момент, правда очень медленно. Тяжелый язык изложения у автора. В оригинале, конечно, попроще читается, но не намного. Да и совет по литературе я просил, исходя из контекста:
                                                                                                                        масса нюансов, которые по щелчку не выучатся
                                                                                                                          +1
                                                                                                                          Я думаю что большая часть неназванных нюансов о которых говорит автор как раз в clr via c# описываются. Из того что можно назвать нюансами и о чем идет речь в книге сходу в глову приходят внутренности GC, что делает box/unbox и почему с ним надо быть очень аккуратным, не все lock'и одинаково полезны и тд. На собеседованиях правда иногда любят спросить про внутренности каких-либо стандартных классов, тут уже надо обращаться к исходникам платформы так как не припомню чтобы про это кто-то особо много писал.
                                                                                                                            0
                                                                                                                            Alexsey, спасибо большое за ответ. Да, про это у Рихтера написано, но блин… опять же, очень тяжело.
                                                                                                                      –3
                                                                                                                      Шарпы — популярны

                                                                                                                      Исходя из этого пункта не понятно зачем нужно, т.к. есть много более популярных языков.


                                                                                                                      C# — мощный язык с кучей возможностей

                                                                                                                      Если вам скучно можете найти в языке ещё одно специальное решение для особого случая, что бы ваши коллеги/наследники, подольше разбиралить. А что вы хотели программирование — это не просто, знали куда шли.)


                                                                                                                      Дотнет — для ентерпрайза

                                                                                                                      Описали почти любой ЯП общего назначения.

                                                                                                                      Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                                                                                                                      Самое читаемое