Как-то раз наши разработчики тёрли за что-то важное у кофемашины и между делом стебались, что им скоро придётся уйти из .NET, потому что он вымирает. Шутки шутками, но мысль застряла в голове и не отпускала.
Чтобы прояснить ситуацию, мы заглянули в DotNet-сообщество, сходили к ребятам из Microsoft, Райффайзенбанка, Контура, CUSTIS и задали несколько вопросов. Вы тоже возьмите чашечку кофе, устройтесь поудобнее, поразмышляйте о будущем .NET и поделитесь своими мыслями в комментариях.
Какие позиции занимает .NET сегодня
4 февраля 2014 года Сатья Наделла был назначен главой корпорации Microsoft, заменив Стива Балмера. Это означает, что с Microsoft снято проклятие привязки к Windows. Наделла начал движение в сторону open source и кросс-платформенности, поэтому сейчас .NET Framework не имеет недостатков по отношению к Java, и как никогда до этого перспективен.
.NET сейчас — крепкий середнячок по всему. Не самый сложный или простой, не самые высокие или низкие зарплаты, не самый популярный, но C# всё ещё в топ-5.
Это хороший фреймворк общего назначения, с прилично развивающимся языком и достойной производительностью. Microsoft в последние годы развивает платформу в очень правильном направлении — open source, полноценная кросс-платформенность и множество технических улучшений. Прямо сейчас ту же нишу занимает только Java, но в этой борьбе всё без изменений уже много лет.
Это одна из самых популярных платформ, где разработчики высоко востребованы. Множество компаний ищут опытных специалистов и новичков. Здесь я говорю как о крупных банках, так и о стартапах.
Плюс у .NET довольно сильное сообщество в России. Многие компании и независимые сообщества проводят митапы на площадках крупных российских городов. Ребята-профессионалы из российских сообществ активно помогают новичкам осваивать новые рубежи.
Хорош ли .NET для старта в IT
Сейчас популярны курсы, обещающие трудоустройство программистом на %язык_нейм% за N месяцев. Я больше склоняюсь к классическому подходу и считаю, что для начинающих куда важнее знания, не зависящие от конкретного стека технологий. Об архитектуре компьютера, операционных системах, сетях, алгоритмах, интеграции с внешними сервисами, подходах к разработке ПО, организации кода, тестировании, отладке. Всё это нужно изучать сразу на различных современных платформах и языках, будь то .NET(C#)/JVM(Java, Kotlin), Python, С++, JS, Go. И лишь после этого выбирать, в какой теме развиваться дальше. Это уже зависит от личных предпочтений и рынка в регионе. Научиться базовым концепциям и встроить их в своё мышление гораздо сложнее, чем освоить ещё одну платформу, фреймворк или язык программирования. Нужно уметь смотреть на код сквозь слои абстракции языка и платформы, тогда не придётся учиться новой технологии с нуля.
В целом .NET и JVM, на мой взгляд, оптимальны для новичка-бэкендера как платформы со статически типизированными языками, готовыми библиотеками и фреймворками, большим сообществом, богатым тулингом и имеющие концептуальное сходство, позволяющее достаточно легко перескочить с одного стека на другой на начальных этапах. Начинающему совершенно точно не следует выбирать плохой курс по Java, если есть хороший по C#, руководствуясь тем, что на Java вакансий на K% больше. Как и плохой курс по C#, если есть хороший по Java, Python или другой технологии.
Для изучения С# не очень сложен. Посложнее, чем Python, но попроще Go, как по мне. Для новичка многое может простить. И есть возможность подучиться в крупной компании, где берут джунов и нет супер критического продакшена. Такой работы много. Платформа развивается, сейчас перешла на кросс-платформенные рельсы полностью.
Марк Быстров
Тимлид команды Монетизация в Циан, 9 лет в .NET
Наверное, моё мнение в этом вопросе слишком предвзято, ведь я «запрыгнул» именно через .NET. Потом был коммерческий опыт и в Python, и в NodeJS на разных проектах, но .NET мне всегда казался удобным для старта: устоявшаяся платформа с подробной документацией и решениями, работающими «из коробки», что в том же Python тогда решалось разными сторонними библиотеками и костылями.
Если говорить о разработке игр, то C#/.NET — один из двух возможных вариантов (имею в виду UE Blueprints). В других областях я бы судил исключительно по количеству вакансий entry-уровня. Конечно, сложно тягаться с той же фронтенд-разработкой на JavaScript или TypeScript.
Именно для входа он хорош. Есть ASP.NET Core для веба, Unity для игр, WinForms, WPF, MAUI, Avalonia для десктопа (и спорный, но достойный упоминания Blazor в Electron).
Visual Studio — крайне мощная, но довольно простая в освоении IDE, где Integrated — не пустой звук, к тому же ещё и с Community-лицензией, которая позволяет не только обучаться, но и вести коммерческую разработку в маленькой команде. Отдельно стоит выделить MSBuild — пожалуй, лучшая система сборки, которая просто работает и в подавляющем большинстве случаев не доставляет головной боли.
Но как по мне, молодые специалисты идут в .NET неохотно. Сказывается репутация Microsoft. В головах многих людей это по-прежнему кровавый энтерпрайз, который гвоздями прибит к Windows. Будем честны, много где ещё осталось легаси, из-за которого это утверждение какое-то время будет не пустым звуком (даже у нас оно есть). Есть тренд на улучшение, но пройдёт, наверное, десяток лет, прежде чем эти стереотипы вымрут как явление в сообществе разработчиков.
У .NET есть и другая проблема. Python подмял под себя машинное обучение, на Go написан Kubernetes, а JavaScript слишком долго был единственным языком для фронтенд-разработки. Каждая из этих областей буквально на хайпе. А что .NET? С какой областью он ассоциируется у большинства разработчиков в первую очередь? Десктопные приложения под Windows. Не самая хайповая сфера, мягко говоря.
Вячеслав Залыгин
Стажёр в Dodo Engineering и наш самый молодой .NET-разработчик— ему только 17
Программированием именно на С# я занимаюсь уже 4 года. Последний год изучал сетевое взаимодействие, саму сеть, ASP.NET Core, немного HTML, CSS, JavaScript. В будущем планирую пройти курс по React, чтобы немного прокачать знания про фронтенду, но вообще погружаюсь в тот стек и те инструменты, что используются в Dodo.
Мне кажется, что Python более привлекателен для старта за счёт простоты синтаксиса. Но объективно я не могу судить, т.к. не знаю, что нужно изучить в нём, чтобы начать работать. .NET мне нравится, он мне роднее.
Есть ли кризис и нехватка .NET-разработчиков
Кризис есть. Но связан он не с тем, что поток джунов стал меньше, а скорее наоборот, — с тем, что он стал больше. Сейчас многие компании выбирают C#, потому что, на первый взгляд, это простой язык, на котором легко писать, и набирают соответствующих «специалистов». А потом эти люди, выходя на рынок, портят репутацию языка и ухудшают мнение о C#-разработчиках в целом. Причина понятна: фреймворк, IDE, сторонние инструменты (такие как R#) много думают вместо разработчика, и не все люди, которые их используют, задумываются «что же там внутри». Такое поверхностное знание получается.
Сегодня я вижу одинаковый поступательный рост спроса на специалистов во всех технологиях. В особенности это касается разработчиков уровня мидл. Они сейчас наиболее востребованы, причем независимо от стека. Джунов и сеньоров ищут реже, но и для них работы хватает.
Что касается отношения к технологии самих джунов, то оно остаётся также стабильным. Никто резко не бросается переучиваться на другие технологии.
Мне кажется, что количество разработчиков вполне соответствует количеству рабочих мест. По всем показателям популярность .NET не особо падает, новички всё также приходят, в основном из университетов (там .NET как-то исторически популярен). Нехватка кадров ощущается постоянно, но такая же нехватка кадров ощущается и в Java, например.
Марк Быстров
Тимлид команды Монетизация в Циан, 9 лет в .NET
Уже больше года нахожусь в активном поиске дотнетчиков в свою команду и, на мой взгляд, точно есть кризис уверенных мидлов и сеньоров. Специалистов на рынке мало, а те, кто есть, часто не стараются развиваться в ногу с платформой и застряли ещё в .NET Framework 3.5, или избалованы ленивой атмосферой и не требовательностью к качеству кода в банках или крупных аутсорс-компаниях.
Что ждёт .NET в будущем
Будущее определённо есть. Microsoft наняли Гвидо и теперь он пишет на F# За .NET стоит Azure, а за Azure — очень много денег. В перспективе 5-10 лет вряд ли что-то будет на замену. .NET — это технология Microsoft, в которую она очень много и долго инвестирует. Планируется постепенно закопать .NET Framework (последняя версия — 4.8 и новых не будет) и развивать .NET (ранее имевший приставку Core).
Серьёзную ставку делают на Blazor. Сыграет она или нет — покажет время. Я же достаю попкорн и наблюдаю за происходящим :)
Считаю, что .NET будет развиваться и захватывать всё больше областей деятельности. Ещё вчера он ассоциировался с Windows Forms. Сегодня это веб, игры, облачная разработка, кросс-платформенность, IoT, ML и многое другое. Безусловно, это не может не сказаться на конкурирующих платформах JVM-стека и Python. Думаю, все эти технологии будут развиваться, перенимать опыт друг у друга (как это видно сейчас в тех же C#, Java, Kotlin), завоёвывать всё больше умов и сфер деятельности. Процентное соотношение захваченного той или иной технологией рынка будет меняться, но резких изменений, как мне видится, не будет. Здесь важное влияние также оказывает опыт нынешнего поколения IT. Нередко бывает так, что при создании нового проекта в том же энтерпрайзе технология выбирается исходя из опыта организатора команды (архитектора, лида, менеджера). Это способствует пропорциональному образованию рабочих мест и сохранению спроса на специалистов.
Эти ответы мы бы не услышали, если бы всё, что происходит у кофемашины, оставалось у кофемашины. Да не переведутся молодые специалисты в .NET, ведь он живее всех живых. Согласны?
Что ещё посмотреть по теме:
Будущее .NET — обсуждение на 50-й встрече сообщества MskDotNet
Наши вакансии для .NET-разработчиков.
Комментарии (206)
gdt
19.08.2021 17:58+2MSBuild — ... не доставляет головной боли.
Я бы сказал что это так только на простых решениях, есть свои подводные камни и ограничения.
VanKrock
21.08.2021 01:31A я бы сказал, что это на решениях, где техлид не извращенец. Превратить простой проект в сложный - это не так уж и сложно. И в большинстве случаев, там, где я видел сложности с msbuild, то сложности скорее были с архитектурой решения в целом
gdt
21.08.2021 07:24То, о чем вы говорите, относится практически к любой технологии — я бы сказал что угодно можно испортить, если наворачивать, не думая. Имею ввиду какие-то неочевидные ограничения этой системы. Например, через пропсы нельзя за один проход сгенерировать и подключить глобальный ассембли инфо так, чтобы при открытии студии он сгенерировался и подтянулся везде — т к импорт происходит до генерации, и хоть ты лопни, хоть ты тресни.
mayorovp
21.08.2021 12:23+1Э-э-э, импорт чего? И зачем вообще нужно генерировать его при открытии студии?
gdt
21.08.2021 12:36Не думал, что это так сложно.
Вот у вас есть солюшен проектов на сто, из которого собирается продукт с большим количеством сборок. Вам бы хотелось, чтобы в каждой из них ассембли инфо было одинаковым, в частности версия. Есть несколько подходов для решения этой проблемы, один из них — создать для этого отдельный props-файл, который будет подключать какой-то файл типа GlobalAssemblyInfo.cs (или модные определения в sdk-style, не суть), и импортировать этот props-файл в Directory.build.props — так, чтобы каждый проект его получил. Пока все просто и понятно.
Теперь заметим, что держать версию прям в cs-файле неудобно, т к она бывает нужна и в других местах (CI например), поэтому версия сама по себе лежит где-то отдельно, откуда ее просто достать — в json, xml или даже plain-text — тоже не суть. По итогу ассембли инфо генерируется из шаблона подстановкой этой версии. Соответственно в системе контроля версий не участвует.
Теперь вы клонируете чистый репо, в котором еще ничего не сгенерировано. Сначала импортируются пропсы, потом выполняются таски при сборке. И на тот момент, когда нужна ассембли инфо — она еще не сгенерирована.mayorovp
21.08.2021 13:44А зачем она вам нужна так рано? Раньше стадии компиляции этот файл не понадобится, соответственно в большинстве случаев достаточно засунуть его генерацию в
BeforeTargets="Compile".Перфекционисты же могут использовать в качестве точки расширения GenerateAdditionalSources, которая как раз занимается генерацией исходников.
gdt
21.08.2021 13:46Вот не работает с BeforeTargets, перепробовали все. С GenerateAdditionalSources надо попробовать.
P.S. Точных деталей уже не помню, но кажется для Compile Include нужно чтобы файл уже существовал, и вот генерируется он после включения пропсов — т е билдить надо два раза, не комильфо.mayorovp
21.08.2021 14:07Всегда работало.
кажется для Compile Include нужно чтобы файл уже существовал
Никогда подобное не требовалось. Возможно, это требуется какому-нибудь решарперу — но точно не msbuild и не студии.
gdt
21.08.2021 14:09-1Ну если вы хотите, чтобы файл подключился — на этот момент он должен существовать. И хоть куда эту таску зашедулить, пропсы импортируются раньше.
mayorovp
21.08.2021 14:11Ну если вы хотите, чтобы файл подключился — на этот момент он должен существовать.
Зачем?
gdt
21.08.2021 14:13Очень грубо говоря — система собирает все compile include и затем их компилирует. Если файл не существует — он пропускается. Или вы хотите сказать, что существует какая-то магия, позволяющая вмешаться в уже созданный список файлов для компилятора?
mayorovp
21.08.2021 14:18Смотрите, с точки зрения msbuild этот Compile — это просто очередной Item, который ничем не отличается от, к примеру, PackageReference.
Откройте любой проект и поищите в файловой системе файлы, которые соответствуют подключенным PackageReference. Спойлер — их нет. Мешает ли это пакетам "подключаться"?
Или вы хотите сказать, что существует какая-то магия, позволяющая вмешаться в уже созданный список файлов для компилятора?
Да, разумеется.
Список файлов для компилятора фиксируется на этапе CoreCompile. Любой target, который был выполнен до этого момента, может создать новый Item и именем Compile, и этот Item попадёт в список.
Но мы сейчас обсуждаем другую ситуацию, при которой элемент Compile задан статически. Какие в принципе могут быть причины непопадания этого элемента в список?
gdt
21.08.2021 14:21-1Я вам говорю не про таргеты а про пропсы, они импортируются в самом начале и compile include определен там. Выполнить таргет с таской ранее этого момента невозможно.
mayorovp
21.08.2021 14:24Вот именно, невозможно. А значит, и "сформировать список" раньше этого момента невозможно. Следовательно, статический элемент Compile из файла с пропсами будет успешно создан до момента формирования списка.
gdt
21.08.2021 14:26-1Я вам про практику а вы мне про теорию, сами для начала попробуйте из directory.build.props подключить файл, формируемый таргетом позже — вот тогда и поговорим :)
mayorovp
21.08.2021 14:36Моя "теория" основана на часах практики, которые я проводил изучая msbuild и настраивая сборку.
Но, раз этого вам мало, я только что проверил. Вот проект из одного файла:
using System; namespace TestMsBuild.App { class Program { static void Main(string[] args) { Foo.Bar(); Console.WriteLine("Hello World!"); } } }И вот Directory.build.props директорией выше:
<?xml version="1.0" encoding="utf-8"?> <Project> <ItemGroup> <Compile Include="$(MSBuildThisFileDirectory)foo.cs" /> </ItemGroup> <Target Name="GenerateFoo" BeforeTargets="GenerateAdditionalSources"> <WriteLinesToFile File="$(MSBuildThisFileDirectory)foo.cs" Lines="static class Foo { public static void Bar() { } }" /> </Target> </Project>Оно работает! Оно успешно компилируется. Оно даже генерирует файл при открытии проекта в студии.
mayorovp
21.08.2021 15:00Уж не вот это ли вы упустили?
Никогда подобное не требовалось. Возможно, это требуется какому-нибудь решарперу — но точно не msbuild и не студии.
gdt
21.08.2021 15:01Обижаете :) Нет, видимо был еще какой-то момент, который уже стерся из памяти за давностью. Будет время воспроизведу
CodeShaman
19.08.2021 18:06С .NET не работал и не знаком, но с большим интересом иногда факультативно интересуюсь F#. Интересно, каково его будущее в .NET, вакансий для него практически нет, но вроде Microsoft продолжают его развивать и какие-то фичи из него перекочевывают в C#.
harvester
19.08.2021 18:23+1Имхо, в .net его будущее стабильно, он продолжит развиваться. Посмотрите на whats new и roadmaps для f#.
AquariusStar
19.08.2021 18:57+1Появятся. Надо учесть, что .NET ещё молодой, если отбросить в сторону старый Framework .NET. Он ещё поборется за место под солнцем. Я в этом уверен. Уже писал одну программу для конкретной задачи, которая может одинаково работать в любой операционной системе и процессоре. Например, отлаживал на Windows 10 x86-64, а запускал на Linux ARM (Raspberry Pi). Этой осенью выйдет финальный релиз .NET 6, уже в разработке следующая версия. Судя по всему, она очень старается не привязываться к Windows.
KvanTTT
19.08.2021 20:20+2Я как-то пробовал даже на проект затащить, но не зашло — все-таки его сложнее освоить, библиотеки не так хорошо совместимы, под капотом компилируется много неоптимального кода. В то же время C# продолжает перенимать в себя фишки F#.
balberbro
19.08.2021 19:03+7Но в .net нет ответа на один простой ответ — если сложность .net сопоставима с java, а на java платят на 10-20% больше, и выбор компаний шире, то зачем изучать .net?
bazzilic
19.08.2021 19:21+48На дотнете писать заметно менее тошно :) И язык, и тулы, и экосистема заметно моложе и делались с учетом ошибок джавы. Так что на джаве доплачивают за вредность.
siziyman
20.08.2021 02:16+2Вкусовщина же. Последние годы джава как язык развивается вполне бодро, экосистема в целом куда меньше замкнута на решения от MS (и это я ещё искренне хорошо к компании отношусь, а есть те, кто их просто ненавидят), кроме того, никто не мешает писать на том же Котлине.
По моему опыту, доплачивать за вредность надо, например, за использование Visual Studio. :)
Iados
20.08.2021 11:44+3Про VS полностью поддерживаю, сам год назад пересел на райдер, это небо и земля.
Viacheslav01
21.08.2021 00:53+1Ну тут как пойдет последние годы основная IDE Android Studio по сравнению с VS 5-и летней давности убогое говно.
bazzilic
23.08.2021 07:16+3Ну а я не соглашусь — лучше VS, на мой взгляд, пока ничего не сделали. Райдеру еще расти и расти до VS.
marshinov
27.08.2021 22:25Ну хз. Когда в 2015 с рослином она начала кушать всю память в своём 32-разрядном процессе…
bazzilic
28.08.2021 09:21Ну во-первых, на райдере тоже будет рослин, вижла тут ни при чем. Да и на других языках тоже будет комплиятор и language сервер, так что деться тут некуда.
Во-вторых, я вот щас посмотрел, у меня среднего размера солюшен открыт — проект на 20 сорс файлов и проект с тестами такого же размера примерно. Студия последняя с десятком экстеншенов и решарпером: всё вместе это занимает около 2-2.5 ГБ в памяти. Как по мне, очень скромно, меньше браузера :) Да и вообще — пусть жрет память сколько влезет, лишь бы работало быстрее! Нафига мне пустой РАМ?
marshinov
28.08.2021 12:45Речь о 32x-процессе и имутабельных коллекциях в рослине. Фактически решарпер просто уже не помещался, да и рослин на больших проектах - тоже. Сейчас на win вроде бы все стало лучше в новых версиях vs. Но у меня сейчас, например, Mac
bazzilic
29.08.2021 09:03А, я пропустил про 32 бита. Ну вот новая студия вроде будет 64-битная, ЕМНИП. Кроме вижлы на дотнете особо податься некуда в любом случае. Райдер это пока потемкинская деревня, но они вроде быстро развиваются, так что посмотрим. Плюс, наконец у вижлы есть конкурент, они тоже мб начнут быстрее там лапками шевелить.
marshinov
29.08.2021 16:05Ну не знаю, я на этой "потемкинской деревне" несколько лет сижу. Полет нормальный.
Kiel
19.08.2021 19:23+20Java обладает ужасными IDE, после VS это невыносимо.
.net по философии хочет чтобы мы заранее обо всём позаботились, Java же заставит описать всё. Понятия middleware в Java боятся. Отсюда же и нежелание использовать var.
В .net гораздо понятнее устроен DI. @beam - просто не хочется с этим разбираться
Java при установке заставит тебя пройти все ступени ада с непониманием почему не работает даже hello world. И после приложение будет довольно часто терять какую версию вы используете для сборки.
В Java очень неудобный Maven. Появился Gradle, но на него с большим трудом переходят. И даже он далек до идеала. Опять же в .net ты даже не задумываешься что управление зависимостями может быть проблемой.
Сервисы Java занимают в 2+ раз больше памяти чем аналогичные на .net.
И в общем Java это больше о долгой кропотливой разработке. .net и удобнее и веселее
Так же Java просто любят на российском рынке. В мире с .net всё лучше
По итогу выходит так, что да, ты получишь +10% к зп и чуть большую востребованность на рынке. Но сильно потеряешь в удовольствии от работы
balberbro
19.08.2021 19:42-14Когда между двумя платформами, начинаются аргументы «а там язык чуть красивее», сразу появляется улыбка.
Какая разница, что на Java чуть дольше настраивать конфиги, если тебе за это время все равно платят? Ну оценишь ты свою задачу в 12 часов, а не в 10 (на.нет), но все равно большая часть времени уйдет на согласование и орг-вопросы, а не на написание кода.
Крутой язык, большие перспективы, бороздящие корабли — это либо для молодняка, либо для сайд проектов в свободное время по кафу.Опытным программистам нужна адекватная зп, востребованность на рынке и возможность работать в комфортных условиях (не код комфортно писать, а чтобы менеджмент и окружение были адекватными). И тут Java просто круче.
Единственное, где .net давит — это универы и геймдев, но опять же для начинающих ребят.Kiel
19.08.2021 19:49+8Разница в том, что в .net ты просто работаешь, а в Java "превозмогаешь" и всё намекает на то, что инфраструктуру Java нужно переписывать
То, что за Java больше платят не делает его "круче". Скорее говорит плохо о Вас.
iiopy4uk_mck
19.08.2021 20:47+7Да и если честно уже не такая большая разница в зп, как 10 лет назад. Я бы сказал несущественная. Сейчас эту вотчину го занял с большой зп в бэке, вот уж и правда забавный момент.
KvanTTT
19.08.2021 20:28+12Какая разница, что на Java чуть дольше настраивать конфиги, если тебе за это время все равно платят?
Эту же мысль можно переформулировать так: какая разница, что платят на 10% больше, если нужно настраивать конфиги и заниматься еще какой-то фигней, а не чем-то приятным.
Опытным программистам нужна адекватная зп, востребованность на рынке и возможность работать в комфортных условиях (не код комфортно писать, а чтобы менеджмент и окружение были адекватными). И тут Java просто круче.
Как связан коллектив и язык программирования?
0xd34df00d
20.08.2021 10:05+10Как связан коллектив и язык программирования?
Программисты на хаскеле ленивые, на окамле — энергичные.
glestwid
19.08.2021 22:10+3Так же Java просто любят на российском рынке. В мире с .net всё лучше
Но только не в Германии., особенно с релокацией. На глаз , позиций на Java раза в 1.5-2 больше, чем для стека .NET
siziyman
20.08.2021 02:20+9Java обладает ужасными IDE, после VS это невыносимо.
После IDEA от VS тошнит, без решарпера это вообще преступление против человечества.
В .net гораздо понятнее устроен DI.
...чем в каком из 5-10 вариантов его реализации разными инструментами в джавовой экосистеме?
И после приложение будет довольно часто терять какую версию вы используете для сборки.
Нет, если вы один раз прописали это в любом используемом билд-туле, это никогда не происходит - это прямая ложь или непонимание того, о чём вы говорите.
В Java очень неудобный Maven. Появился Gradle, но на него с большим трудом переходят. И даже он далек до идеала.
Вкусовщина.
И в общем Java это больше о долгой кропотливой разработке. .net и удобнее и веселее
Да нет же, всё строго наоборот, никак иначе!
(это я показываю, как такие рукомашеские заявления работают в любую сторону).
kasthack_phoenix
20.08.2021 11:26+6>.чем в каком из 5-10 вариантов его реализации разными инструментами в джавовой экосистеме?
Как раз наличием DI-контейнера из коробки / возможностью подсунуть свою реализацию через стандартный интерфейс. Наличие 5-10 несовместимых API — это не плюс.
> без решарпера это вообще преступление против человечества.
В каком году? С R# студия тормозила всегда, а вот стандартный Roslyn с навешенным Roslynator делает чудеса, не потребляя ресурсы.
siziyman
20.08.2021 12:12+2Как раз наличием DI-контейнера из коробки
Ну есть относительно стандартное javax-API, которое поддерживается сторонними фреймворками, например.
Наличие 5-10 несовместимых API — это не плюс.
Наличие выбора в зависимости от того, какие у вас предпочтения по организации кода и сложности/эксплицитности используемых решений - это плюс. :)
В каком году? С R# студия тормозила всегда, а вот стандартный Roslyn с навешенным Roslynator делает чудеса, не потребляя ресурсы.
Она просто жутко неудобная, на мой вкус: после JB'шных инструментов возникало ощущение, как будто меня заставляют, не знаю, ногами работать.
Но последнее не стоит воспринимать очень всерьёз, я скорее показываю, как плохо работают аргументы вида "это плохо, потому что я так сказал, а это хорошо, потому что мне нравится". :)
darkagent
20.08.2021 12:54а студию под какой OS вы пробовали? там все что не win — и не студия вовсе
siziyman
20.08.2021 12:56Не, это была именно полноценная VS (не VS Code - это всё-таки не IDE, а продукт несколько другой категории, кмк) под виндой. :)
darkagent
20.08.2021 13:31+3видимо, на вкус и цвет. с переходом на vs2019 даже в resharper отпала необходимость, не говоря уже об остальных продуктах JB (но это сугубо личное)
KislyFan
20.08.2021 18:38+3В силу обстоятельств перепробовал VS, VS Code, Mono Developer и Rider, но так и не смог понять восхищения продуктами JB. Для меня единственным фактором использования Rider оказалось то что для Linux Desktop просто нет достойной альтернативы, и по этой же причине он (Rider) совершенно не конкурент для VS2019/2022 в окнах.. ну разве что только по цене лицензии. Ах да! Лицензия! Модель распространения Rider без community лицензии.. это сильно. Можно конечно пользоваться EAP, но это совершенно не тоже самое.
Zashikivarashi
20.08.2021 16:24+2под .net полно сторонних DI, как пример
siziyman
20.08.2021 17:03-5Оттого мой вопрос - а что такое вообще "понятнее DI в языке, где есть много его реализаций" становится только уместнее же. :)
VanKrock
21.08.2021 01:44+1Думаю тут скорее дело в
IServiceProviderиIServiceCollection, c которыми все эти контейнеры совместимы.
rrrad
20.08.2021 08:45-5В Java очень неудобный Maven. Появился Gradle, но на него с большим трудом переходят.
maven превосходен
vabka
20.08.2021 16:17Не согласен, в нём есть очень много чего, что можно улучшить.
1. Например веб-интерфейс браузера пакетов сильно хуже (менее удобен, сложно искать), чем npm или nuget
2. Сам он очень долго инициализируется
3. Не присутствует из коробки
4. Очень сложный (просто сравни размер документации)
vedenin1980
20.08.2021 16:28-2Не присутствует из коробки
Это скорее плюс, чем минус. Если засунуть систему сборки в спецификацию языка, то потом фиг избавишься. Так бы и был у нас сейчас ant, а не maven. Сила Java как раз в том, что в базовой библиотеке лишь необходимое, а куча фреймворков, систем сборки, библиотек конкурируют между собой и ни одни из них не установлен по умолчанию. Завтра появится новая система сборки и ее придется тащить во все реализации jdk — ну нафиг.
Плюс Net в том что тебе дают все и сразу по-умолчанию, минус в том что если есть реализации всего по-умолчанию, то очень сложно пробиться чему-то нестандартному (просто потом что, нестандартное нужно изучать, а на новой работе она скорее всего не потребуется).Например веб-интерфейс браузера пакетов сильно хуже
А он есть? Я знаю несколько сайтов которые показывают браузер пакетов, но все они неофициальные (и это тоже плюс), сам мавен централ (который тоже лишь одна из репозиторий) просто показывает список директорий с файлами.
KvanTTT
19.08.2021 20:24+5Соглашусь с авторами комментариев выше. У меня есть опыт использования и .NET и JVM платформ — первое приятней, быстрей и удобней. Это касается даже IDE от JetBrains, хотя, казалось бы, один и тот же разработчик.
Refridgerator
20.08.2021 08:44+5Если абстрагироваться от зарплаты, то есть такое понятие как «интуитивное принятие». Это когда смотришь язык — а там всё логично, правильно и красиво. И программировать тогда легко, приятно и сложности преодолевать легко и приятно. А когда смотришь в язык и недоумеваешь, по какой такой логике там точка используется для конкатенации строк — то и программировать на таком языке будет сложновато, вне зависимости от сложности самой программы.
И если лично Вам джава кажется логичнее и интереснее — так выбирайте её! Это же дело сугубо добровольное. Хотя опять же, никто не запрещает изучать и то и другое одновременно, если не можете выбрать что-то одно.
Kanut
20.08.2021 10:27+10Мы используем и джаву и дотнет. Дотнет заметно удобнее и приятнее в использовании. Но до недавнего времени он в принципе не был кроссплатформенным и даже до сих пор на нём не особо удобно делать кроссплатформенный десктоп. Поэтому там где не получалось использовать дотнет мы использовали джаву. Сейчас всё больше и больше от неё уходим.
Разницы в зарплатах у тех кто пишет только на шарпе или только на джаве внутри самой фирмы в общем-то нет.
Разница на рынке в целом есть. Но при этом если посмотреть на конкрентые позиции на которых джавистам предлагают больше, то часто сразу видно почему им больше предлагают. Например потому что надо работать с "легаси джавой". То есть например куча фирм "застряли" на восьмой версии и по той или иной причине не могут или не хотят мигрировать. В куче фирм просто не используются ни Marvel, ни Gradle. И так далее и тому подобное.
Iceg
20.08.2021 16:04+4Одни только async/await и extension methods делают C# на порядок лучше Java.
> если сложность .net сопоставима с java
В итоге по синктаксису — да, сопоставимы (мб, джава попроще будет, никакого вам синтаксического сахара), а реальный код на джаве с фьючами, стримами и отсутсвием лаконичных инициализаторов массивов — обнять и плакать.
anon12332
19.08.2021 19:37лично моё мнение: в C# не хватает move-семантики для value-типов(struct, enum);
если бы в C# добавили move-семантику с помощью какого-нибудь спец. атрибута или ключевого слова, тогда в тех структурах, которые реализуют move-семантику, можно объявить деструктор, в котором можно освобождать ресурсы(закрывать файлы, сокеты, и т.д.)
в C# у value-типов по умолчанию copy-семантика(семантика копирования), но в C# нет move-семантики(семантики перемещения) для value-типов.
Kiel
19.08.2021 20:03+1out/ref
unsafe + fixed в крайнем случае
Но это я Вам рассказал "по секрету", увижу такую в коде - буду много верещать ))
gdt
20.08.2021 07:40+2Тут наверное имеется ввиду аналог std::move и всего, что с ним связано (move-конструктор, move-assignment оператор и т. д.) в C++, в C# действительно этого нет. Ref это вообще-то передача по ссылке и к move-семантике действительно не имеет никакого отношения.
VanKrock
21.08.2021 01:51-2Мне кажется, если шарписты этого не знают, то им это и не нужно, если бы это вызывало какую-то боль, то наверняка бы знали о проблеме
gdt
21.08.2021 07:26Ну, во-первых, не надо говорить за всех. Во-вторых, отличная мантра — «если я чего-то не знаю — значит, оно мне и не нужно». Должно быть, хорошо помогает в саморазвитии.
Cryvage
21.08.2021 09:38+2Тут, всё же, надо учитывать, насколько концепция полезна, да и вообще применима ли она, в заданных условиях.
В C++, все классы, являются value-типами. И move-семантика нужна тем из них, кто в своих полях хранит указатели на кучу, а при необходимости копировать объект, подразумевает глубокое копирование данных на куче, а не просто копирование указателя. Такое копирование создаёт проблемы, не только потому, что объём копируемых данных может быть большим, но и просто уже потому, что эти данные лежат в куче, и при копировании требуют аллокаций в куче. При этом, существуют сценарии, когда копирование является лишним, например, при возврате из метода, когда нам достаточно было бы просто переместить данные вниз по стеку вызовов, и move-семантика, позволяет избежать таких копирований.
В C#, только структуры являются value-типами, а все остальные типы — ссылочные (reference-типы). Структуры используются только в тех случаях, когда это необходимо, так что value-типами является достаточно небольшой процент сущностей в программе. Это уже делает проблему менее актуальной. При этом, общепринятой практикой для структур является их полная иммутабельность. Можно сказать, что без этого условия, структуры просто работают не корректно. При чём, альтернативы иммутабельности, по сути, нет, о чём ещё скажу ниже. Иммутабельность подразумевает, что у нас не только отсутствуют методы, меняющие состояние структуры, но и все поля структуры, принадлежащие к ссылочным типам, защищены от изменения. Это касается даже геттеров. К примеру, наружу могут торчать только геттеры иммутабельных ссылочных типов (таких как string). Иными словами, если структура сделана с учётом всех best-practice, то при копировании ей не требуется глубокое копирование объектов в куче, на которые она ссылается, т.к. они тоже иммутабельные, и скопировать ссылку вполне достаточно — побочных эффетков не будет. Классам, следующим подобному дизайну, и в C++ move-семантика не нужна. Хотя, нужен подсчёт ссылок, но если в полях лежат умные указатели, то подсчёт уже есть из коробки, и даже конструктор копирования становится не нужен. За свою пятилетнюю практику программирования на плюсах, убедился, что такой подход почти всегда удобнее, чем move-семантика. Исключения, конечно есть, и наиболее каноничные их представители — коллекции, такие как std::vector. Но даже тут есть альтернатива move-семантике, например QList использует «Copy on Write», как и почти все Qt-шные типы. Вот только, как часто мы пишем свои коллекции? Большей части моего пользовательского кода, что move-семантика, что CoW были нужны как телеге пятое колесо.
Но что если кто-то всё же захочет другой дизайн для структур в C#, не связанный с иммутабельностью? И тут мы возвращаемся к утверждению о том, что альтернативы иммутабельности, для структур, в C# — не существует. В C#, в отличие от C++, конструктор копирования не вызывается автоматически. При копировании структуры, просто копируются все её поля, при этом ссылки копируются поверхностно. Переопределить это поведение нельзя. Вы можете написать конструктор копирования, но не можете заинфорсить его использование средой. Иными словами, сделать структуру иммутабельной — это единственный способ, сделать её корректной. С одной стороны, это снижает область применимости структур. С другой — исключает целый пласт проблем с их копированием, ведь копирование остаётся легковесным всегда, а не только когда копирование возможно заменить перемещением (только при возврате из метода?). В принципе, структуры в C# имеет смысл использовать, если вы реализуете тип, с которым будет делаться что-то типа арифметических операций. Vector3D или ComplexNumber — каноничные примеры использования структур в C#. А вот какую-нибудь коллекцию делать структурой, никто, в здравом уме, не станет. То же касается и любых больших объектов. Не даром string является классом. Строки на стеке — это просто не вариант, из-за их размера.
Получается, что move-семантика в шарповую парадигму никак не вписывается. Она просто не имеет здесь смысла. Поэтому странно критиковать шарписта за то, что он не понимает эту концепцию. Она шарписту не нужна. Лично я об этой концепции узнал, когда начал изучать C++. И это правильно, и логично. Понадобилось — изучил. До того момента, я бы, возможно, не смог даже понять проблему, которую она решает. На самом деле, неоднократно сталкивался с тем, что многие вещи не понимаешь до конца, не прохавав их на практике. Вроде, кажется что понял, а потом начинаешь использовать, и понимаешь, что нет, не понял. Поэтому изучать концепции, которые тебе негде применить — такое себе. Даже опасно, в чём-то. Иллюзия знания — хуже незнания.
P.S. я тут написал много, довольно очевидных вещей, и расписал их, возможно, через чур подробно, так что даже меня самого, после повторного прочтения, этот текст раздражает. Но учитывая, что здесь идёт сравнение подходов C++ и C#, и половина из читающих будет незнакома с первым, а другая половина — со вторым, я просто не смог написать более лаконично, и без игры в «капитана очевидность». Надеюсь на понимание.gdt
21.08.2021 09:43+1Ух как у вас бомбануло :) Ничего не имею против иммутабельности, но все же это концепция как бы ортогональная move-семантике. И сами же говорите, что и в плюсах для иммутабельных сущностей она не нужна. И раз в шарпах бывают не-иммутабельные структуры, значит, и место для move-семантики я думаю нашлось бы.
А насчет того, чтобы коллекции не делать структурами — расскажите это разработчикам System.Collections.Immutable. А то пацаны-то не в теме наверное, упускают что-то важное :)Cryvage
21.08.2021 11:17И раз в шарпах бывают не-иммутабельные структуры, значит, и место для move-семантики я думаю нашлось бы
Неиммутабельные структуры в шарпах являются ошибкой проектирования. В частности, в стандартных библиотеках вы такого не найдёте. Это, конечно, не значит, что их нельзя встретить в чьём-либо коде. Можно, к сожалению, так же, как можно встретить и любые другие ошибки. Но людей, использующих такие структуры, никакая move-семантика не спасёт.А насчет того, чтобы коллекции не делать структурами — расскажите это разработчикам System.Collections.Immutable
Это иммутабельные коллекции, а не структуры-коллекции. Единственная коллекция, из их числа, которая является структурой — это ImmutableArray<T>. Все остальные коллекции: ImmutableDictionary<TKey,TValue>, ImmutableHashSet<T>, ImmutableList<T>, ImmutableQueue<T>, ImmutableSortedDictionary<TKey,TValue>, ImmutableSortedSet<T>, ImmutableStack<T> — являются иммутабельными классами, а не структурами. И это не случайно. Хранение коллекции на стеке — это очень специализированный случай, применимость такой структуры очень ограничена, из-за того что такая коллекция должна быть маленькой. На ум приходят массивы байт, которые могут быть полезны для внутренней реализации многих value-типов. Если же это будет массив не байт, а чего-то большего, такая структура довольно быстро превысит разумные размеры. Скажем, если размер структуры будет больше, условно, 64 байт на стеке, у меня такой код вызовет подозрения.Ух как у вас бомбануло :)
Не сказал бы, что от того вашего комментария меня бомбануло. Скорее уж меня бомбануло вот от этого:И раз в шарпах бывают не-иммутабельные структуры
Обычно, когда я вижу мутабельную структуру в C# коде, у меня запускается цепочка: отрицание -> гнев -> торг -> депрессия -> рефакторинг.gdt
21.08.2021 13:20+2Я заметьте ничего не имею против иммутабельных структур, но говорить, что это ошибка — заблуждение. Например, интероп с winapi ну иммутабельных структурах не построишь. Также я слышал, что в высоконагруженных участках кода разумная замена классов на структуры может снизить нагрузку на GC. Если задуматься — уверен, что найдутся и еще примеры.
Cryvage
22.08.2021 06:16Я заметьте ничего не имею против иммутабельных структур
Это хорошо, что вы не против. Потому что делать их таковыми — это официальный гайдлайн от Microsoft. Основная их рекомендация:In general, structs can be very useful but should only be used for small, single, immutable values that will not be boxed frequently.
но говорить, что это ошибка — заблуждение
Если не жалко, покажите мне правильный пример использования мутабельной структуры, чтобы в будущем я мог писать что это почти всегда ошибка, и приводить этот пример как исключение. До сих пор, все мутабельные структуры, которые я видел, были ошибкой, и не давали никаких преимуществ. А добавлять слово «почти», просто из полит корректности, не имея в голове хотя бы одного исключения, я не могу. А то ещё попросят привести такой пример, а у меня его нет.Например, интероп с winapi ну иммутабельных структурах не построишь.
Не моя область специализации, но заявление звучит странно для меня. Вы хотите сказать, что при взаимодействии с winapi нельзя использовать byte, int, double и т.п. типы? А то они тоже являются структурами. И тоже иммутабельные.Также я слышал, что в высоконагруженных участках кода разумная замена классов на структуры может снизить нагрузку на GC.
Это так. В том числе, это так и для иммутабельных структур. Хоть они и порождают копии при изменении, они порождают их на стеке. Поэтому, с этим никаких проблем нет.
На самом деле, довольно странно предполагать, что мутабельная структура может дать какой-то существенный выигрыш, по сравнению с иммутабельной. Это так для классов, но не для структур. Весь выигрыш от использования структур, по сравнению с классами, идёт именно от возможности оставаться на стеке, не трогая кучу, с её медленными аллокациями, и не нагружая сборщик мусора.
В то же время, привязка к стеку, накладывает и определённые ограничения на структуры — их размер должен быть относительно небольшим. Так, для 64-битных приложений, стек имеет размер 4 МБ. Для 32-битных — 1 МБ. Из этого сразу становится понятно, что о больших объёмах данных на стеке речь не идёт. Ну нечего там оптимизировать, делая структуры мутабельными.
В то же время, мутабельные структуры имеют целый ряд проблем. Они криво работают, при доступе к ним через свойства. Они криво работают, при доступе к ним через индексаторы коллекций, таких как List (это следует из предыдущего пункта, но заслуживает отдельного упоминания). Они криво работают с модификатором readonly. Компилятор эти проблемы не ловит. Работая с такими структурами, программисту всегда нужно держать ухо востро, и закладывать обходные пути в дизайн своей программы. Не даром, в стандартных библиотеках от Microsoft, вы никогда не найдёте мутабельную структуру. Язык под них просто не заточен.gdt
22.08.2021 06:28К сожалению, методы winapi работают не только лишь с примитивными типами данных, такими, как byte, int, double. На самом деле очень часто они принимают на вход и возвращают как раз структуры, различной степени сложности (бывает такое что волосы дыбом встают, например, уведомления wlan api). Иногда нужно передать структуру по ссылке, чтобы метод что-то в ней изменил, или заполнил недостающие поля. В общем, с иммутабельностью это никак не вяжется, как бы вам этого ни хотелось. Не ваша область специализации, вот вы и делаете такие безапелляционные заявления, а сколько еще таких областей :)
axmct
20.08.2021 20:52-5При тех же затратах на обучение и сил на работу - самое меньшее value. Это на "почему молодые не идут в .NET".
По сравнению с любыми другими технологиями. Самое неблагодарное.
Как-то живете. C любовью в сердце к безликому божеству.
axmct
21.08.2021 17:08-4На дотнете писать заметно менее тошно :) И язык, и тулы, и экосистема заметно моложе и делались с учетом ошибок джавы. Так что на джаве доплачивают за вредность.
Вот это вот сообщение имеет здесь 43 лайка. Собственно этим же выражением я и воспользовался. Поэтому посылка к врачу несколько неадекватна.
Обсуждение мне интересно чтобы понять что в головах. Потому как те кто так фокусируется на синтаксисе и удобстве редактора кода для меня инопланетяне.
Или просто кодеры :)
axmct
21.08.2021 20:55-4На UX, сценариях и производительности. На создании как можно более тупого, понятного и надежного кода.
При тех же парадигмах и подходах программирования, собственно семантика и синтаксис любого кода не так важны как важно понимание фреймворка и процессов. И здесь что VB что Шарп что Java что Python просто не важно.
Это как на блюде еду раскладывать. В левом углу морковка или в правом. А картошку вот надо обязательно вот так и не иначе.
Все переварится в машинные инструкции в любом случае и важнее что эта еда в себе несет. И где лежит нужная тебе еще одна тарелка.
В этом смысле, уровень и фокус мышления красоты раскладки пищи на тарелке - выносит мой мозг. От зависти.
mayorovp
21.08.2021 21:10+3Вот только вы почему-то забываете, что плохой ЯП, вроде Java без Lombok, активно отвлекает вас от этих самых UX, сценариев и производительности.
А уж задачи создания "как можно более тупого, понятного и надежного кода" в недостаточно выразительном языке превращаются в лебедя, рака и щуку, при этом все вместе конфликтуя с производительностью.
axmct
21.08.2021 21:30-2В сложных фреймворках и приложениях где черт ногу сломит
ГДЕ писать код и ЧТО должен делать этот код? Вот это вопросы. Знание фреймворка и процессов.
КАК именно его написать - вот вообще не отвлекает. Хоть из нескольких блокнотов копировать куски заготовок. Какая там выразительность. Цикла или условия? Обьявления, присвоения, вложенности? Красота и изящество оно в дизайне решения, а не в том как именно мы наш псевдо-код из головы запишем на уровне метода/класса. И здесь опыт во многих языках и дает понимание что важно, а что нет.
mayorovp
21.08.2021 21:45+2КАК именно его написать — вот вообще не отвлекает.
Как оно может не отвлекать, когда отнимает время?
0xd34df00d
21.08.2021 19:49+2Потому как те кто так фокусируется на синтаксисе
В некоторых задачах это довольно важно. Например, возможность создавать свои миксфиксные операторы — это бывает полезно.
и удобстве редактора кода для меня инопланетяне.
О, а я как раз на своей клавиатуре (которая поддерживает QMK и, в частности, макросы) не так давно потратил полчаса на настройку макросов для того, чтобы некоторые часто употребимые закорючки вводить не за четыре нажатия, а за одно-два.
Формально это, конечно, не удобство редактора, но ИМХО близко.
axmct
21.08.2021 21:11-1А в чем польза миксфиксных операторов? Для расширения кода, удобства дебага, производительности?
Если это просто про лаконичность и красоту - мне не понять.
Сложные приложения могут выжить только с максимально простым кодом. То же удобство дебага - важнее на порядок чем одна строчка вместо трех.
Там где в принципе просто (изолированно) и кодерам хочется чувства прекрасного - да, наверное. Чтобы не депрессовали.
mayorovp
21.08.2021 21:49+1Лаконичность, будучи применённой правильно, как раз и даёт ту самую простоту понимания.
axmct
21.08.2021 22:23-2Редко такое в моей практике. Писать осмысленные комментарии к коду, не избегать лишних переменных в целях удобства дебага, возможность расширять код без рисков - все это про не про лаконичность.
Простота это когда взгляд струится по коду, а не пытается с третьего раза осмыслить что делает тернарный оператор в тернарном операторе.
mayorovp
21.08.2021 22:37+1А что, тут кто-то предлагает писать вложенные тернарные операторы в одной строке?
axmct
22.08.2021 14:49-4Простите. Путь будет
return Человек().ЧастьТела().Потрогал();
Вроде бы и не придраться. И даже понятно. А убить хочется.
Потому что ахтунг, требование - при определенных условиях мужчине нельзя чесать яйца. Надо увидеть входящие условия и таки запретить такой сценарий. При этом добавить параметр на пользовательский интерфейс разрешающий ряду пользователей их таки чесать.
И что мне с той лаконичной понятности?
А вот за код вида ниже буду ставить пиво понимающему ремесло. Все части двигателя должны быть легко видны и легко заменяемы. Делать двигатель красивым кубом - это к инопланетянам.
bool ret; if (Человек) { частьТела = Человек.ЧастьТела(); if (частьТела) { ret = частьТела.Потрогал(); } } return ret;
mayorovp
22.08.2021 16:44+2У-у-у, как всё запущено...
Ну вот, допустим, я виду код в "краткой" форме:
return Человек().ЧастьТела().Потрогал();И мне потребовалось добавить в него новое требование. Забудем на секунду о том, что требование, скорее всего, я буду добавлять в другое место, и предположим что выбранная архитектура говорит добавить его сюда.
Что же мне делать? Неужели я… просто возьму и перепишу код в более полной форме? Почему же вы не можете поступить так же?
А, наверное, переписывание кода в полной форме — это сложный процесс, на который вам нужно потратить время, чего вы делать не желаете, а потому вы… предлагаете тратить время заранее и всегда, независимо от того понадобилась полная форма или нет? Вижу дыру в логике.
axmct
22.08.2021 19:10Согласен. В правильной архитектуре метод полностью подменяется. Но где правильная архитектура и где корпоративный Microsoft.
Common sense. Какое-то чувство баланса. Собственно пойнт в том, что красота кода в его надежности на которую время не жалко, и лаконичность тут сама по себе - не ценность.
И да, пишу полную форму практически всегда так как это очень экономит время в той же отладке и делает код более безопасным. Но повторюсь что задачи и условия работы у всех разные.
mayorovp
22.08.2021 19:22А какое отношение корпоративный Microsoft имеет к языку программирования общего назначения? И почему вообще Microsoft, пусть даже корпоративный, определяет архитектуру вашего приложения?
И да, пишу полную форму практически всегда так как это очень экономит время в той же отладке и делает код более безопасным.
Нет, не делает.
Refridgerator
22.08.2021 20:30В вашем примере получается, что у человека может не быть части тела. Ну так её можно передавать как параметр, а не метод. Или «потрогать» — как событие с параметром, что именно. Не понимаю, при чём тут язык вообще.
0xd34df00d
21.08.2021 22:33+1А в чем польза миксфиксных операторов? Для расширения кода, удобства дебага, производительности?
Для большей читаемости и понимаемости кода. Конечно, если читатель знаком с предметной областью (правда, если он с ней не знаком, то ему и так тяжко будет).
Сложные приложения могут выжить только с максимально простым кодом. То же удобство дебага — важнее на порядок чем одна строчка вместо трех.
Сложные приложения куда лучше выживают, когда язык позволяет гарантировать больше всякого разного. Тогда, кстати, возможно, и дебага нужно будет сильно меньше.
axmct
22.08.2021 14:22-1mixfix подход в виде
if_then_else_ x y zвместо классического
IF ()
{
}
ELSE
{
}
не дает приложению никаких преимуществ. Когда мы потом десять раз меняем этот код под новые условия, комментируем код для Source control, то читабельная лаконичность она не является ценностью.
Конечно, где-то это находит применение, но точно не на передовой в окопах.
0xd34df00d
22.08.2021 20:39+1Так смысл как раз в том, что вы можете написать свой собственный оператор
if_then_else_:if_then_else_ : Bool -> a -> a -> a if_then_else_ True a _ = a if_then_else_ False _ b = bкоторый затем вполне используется как классический (с точностью до вида скобочек): с определением выше потом вполне можно писать
if foo then bar else baz.Желание наваять миксфиксных операторов во вполне себе продакшен-коде у меня было.
axmct
23.08.2021 14:09-5Спасибо за ответы! У меня нет вопросов. В принципе все понял.
Есть кодеры, есть архитекторы, есть поставщики решений. Есть
написание изолированных компонент, есть расширение спагетти приложений. Все в контексте, есть разные миры.
Любопытство было вызвано давно непонятным мне феноменом
любви (большей) части программистов к закорючкам конкретного языка как бы как любовь к чистописанию готическим шрифтом с красивыми закорючками. Когда сама красота письма для писца важнее смысла самого текста.
Хорошее Computer Science образование оно дает дополнительный слой восприятия над кодом и над конкретным языком.
Исторически сложилось что искусство построения приложений и решений, оно сложилось вне мира Microsoft. Microsoft это продвижение продуктов Microsoft и техническое их использование. Конкретная привязка к продуктам и навязанной архитектуре.
Выпускник с хорошим Computer Science не выберет .NET при наличии выбора. Потому что .NET это уровень техника по обслуживанию. Не инженера.
Восприятие техника оно как раз именно такое. Не парьте меня лишним выбором, дайте мне кнопку. Восприятие кодера где все что от него нужно это код - это закорючки чтобы хоть какое-то удовольствие.
При этом .NET будет жить, никуда особенно не денется. Но идти в .NET при возможности идти в Java или Python - точно не стоит.
0xd34df00d
23.08.2021 20:20+3Вы зачем-то излишне всё загрубляете. Красота закорючек вполне может быть определяющим фактором при прочих равных (вроде интересности проекта, интересности предметной области, и так далее). Учитывая спрос на услуги, эти прочие действительно нередко равны, и вполне можно найти работу себе по душе, плюс чтобы с красивыми закорючками.
не пофлексить радиЛично я просто люблю решать интересные задачи. А решать задачи приятно, когда инструмент приятный. Да, честно признаюсь, на решения бизнес-проблем мне плевать, это совсем не мой приоритет. Но, например, в загашнике у меня и самописные компиляторы (которые, при всей интересности задачи, на дотнете, джаве или питоне я писать не буду), и всякие ML-системы (про которые тоже можно много чего интересного сказать), и пайплайны для трейдинга. А, ну и образование прикладного математика. Так что, наверное, по вашим критериям я не совсем кодер-техник.
Потому что .NET это уровень техника по обслуживанию. Не инженера.
Я практически не писал на дотнете, но я так и не могу понять, почему вы делаете такой вывод, даже после этого треда.
Но идти в .NET при возможности идти в Java или Python — точно не стоит.
Сорта известной субстанции, ИМХО.
axmct
24.08.2021 13:19-3Красота закорючек вполне может быть определяющим фактором при прочих равных (вроде интересности проекта, интересности предметной области, и так далее).
Согласен полностью. Спасибо.
Сорта известной субстанции, ИМХО.
Есть некое отношение к языку. К каллиграфии. "Язык" это лишь вывеска на конкретном мире проектов, атмосферы, образа жизни. Как именно написана вывеска, неоном или карандашом на салфетке - не так важно. Именно эту мысль по теме "молодые не идут в .NET" я и хотел и донести.
Те же Java, Python, PHP и прочие, это не языки, это миры.
.NET как мир, это мир военного госпиталя. Как язык - красив, белоснежный и чистый моток марли. До очередных изменений.
почему вы делаете такой вывод
Почти 20 лет работы руками с .NET, MCSD по .NET 2003 года.
Вывод основан на том что Microsoft это не про инструменты для программиста, а про программиста под инструменты/продукты. Абсолютно все определяет односторонне Microsoft, исходя только из своих интересов.
А то что вы называете .NET как язык общего назначения, используя как Java, вне стека Microsoft и его продуктов - это не .NET. Не может быть язык вне мира.
Этот .NET живет не в мире .NET, а в мире созданным по правилам и духом Java, Go, Python и прочих. Как бы уже не свой мир, а высадка на Марсе для жизни под куполом.
Нет желания флеймить, просто IMHO.
mayorovp
24.08.2021 13:50+1Отвечу вашими словами — это кодеры живут в чьём-то мире. Программисты создают свой мир.
axmct
24.08.2021 14:24-3В том то и дело. Почти 50 тысяч программистов Microsoft создают свой мир. Бесконечно далекий от мира бизнеса.
P.S. Мир сам в себе. Беда в том, что создание мира - для них бесконечный процесс ради процесса. Это не про дом, а про построили - разрушили, построили - разрушили. При этот не их дом. Они для других их строят.
At Microsoft, 47,000 developers generate nearly 30 thousand bugs a month.
darkagent
19.08.2021 20:45+1в c# всего хватает, разве что enum с полями жаль до сих пор не завезут в чистом виде; решения через ienumerable+yield выглядят немного монстроуозно, в сравнении с реализацией в java.
ChessMax
19.08.2021 22:04А можно пример?
darkagent
20.08.2021 08:34и того и другого? в тг с тем же @. здесь слишком громоздко выйдет )
ChessMax
25.08.2021 11:13Я про `решения через ienumerable+yield `. Мне кажется лучше ответить здесь, т.к. это будет полезно не только мне).
Cryvage
26.08.2021 06:41Полагаю, что речь про это.
TL;DR; основная идея в том, что возможность хранить в enum какие-то поля или методы для каждого значения, устранит нужду в большинстве switch-case по этому enum в коде.
Существует альтернативное решение, с использованием extension методов.
Из плюсов:
1. используются нативные enum'ы;
2. можно добавить даже к существующим enum'ам;
3. субъективно, оно проще и понятней.
Из минусов:
1. менее ООП-шное решение, возможно, в чём-то менее гибкое;
2. лишние скобочки в синтаксисе, т.к. вместо свойств вызываются методы.
Второй минус в будущем может быть решён, т.к. обещали завезти в язык extension property.Пример решения на extension методахEmployeeType.csusing System.Collections.Generic; namespace ExtendedEnumApproach { enum EmployeeType { Manager, Servant, AssistantToTheRegionalManager } static class EmployeeTypeExtensions { record EmployeeTypeData(string DisplayName, decimal BonusSize); static readonly Dictionary<EmployeeType, EmployeeTypeData> employeeTypeFields = new Dictionary<EmployeeType, EmployeeTypeData>(); static EmployeeTypeExtensions() { //TODO заполнять DisplayName в зависимости от выбранного языка employeeTypeFields[EmployeeType.Manager] = new EmployeeTypeData("Менеджер", 1000m); employeeTypeFields[EmployeeType.Servant] = new EmployeeTypeData("Служащий", 400m); employeeTypeFields[EmployeeType.AssistantToTheRegionalManager] = new EmployeeTypeData("Ассистент регионального менеджера", 800m); } //обращение к "полям" через extension methods //в будущем обещают завезти в язык extension properties, которые позволят избавиться от скобочек //https://stackoverflow.com/questions/619033/does-c-sharp-have-extension-properties public static string DisplayName(this EmployeeType employeeType) { return employeeTypeFields[employeeType].DisplayName; } public static decimal BonusSize(this EmployeeType employeeType) { return employeeTypeFields[employeeType].BonusSize; } } }
Employee.csnamespace ExtendedEnumApproach { class Employee { public string Name { get; set; } public EmployeeType Type { get; set; } public Employee(string name, EmployeeType type) { Name = name; Type = type; } } }
Program.csusing System; namespace ExtendedEnumApproach { class Program { const decimal Tax = 0.13m; static decimal CalculateTotalSalary(decimal salary, EmployeeType employeType) { return (salary + employeType.BonusSize()) * (1 - Tax); } static void Main(string[] args) { var vasiliyPetrovich = new Employee("Иванов Василий Петрович", EmployeeType.Manager); Console.OutputEncoding = System.Text.Encoding.UTF8; Console.WriteLine($"Имя: {vasiliyPetrovich.Name} | Должность: {vasiliyPetrovich.Type.DisplayName()} | Зарплата: {CalculateTotalSalary(5000,vasiliyPetrovich.Type)}"); } } }
mayorovp
19.08.2021 20:45+2Проблема move-семантики — в том, что её нельзя делать абсолютной, она должна быть опциональной. Ресурсы должны не только открываться, перемещаться и закрываться — их ещё, как правило, кто-то использовать должен.
А если у нас то структура доступна по ссылке, то делается move — надо как-то следить за временем жизни, тут и до борроу-чекера недалеко.
iiopy4uk_mck
19.08.2021 20:57+8Каких целей вы добиваетесь мув семантикой в менейджед среде?
Cryvage
20.08.2021 00:56+1Посмотрите в сторону record. Они предоставляют value-семантику при сравнении, но в то же время, являются ссылочными типами, т.е. в них нет copy-семантики.
Честно говоря, единственное чего мне не хватает в C#, из того, что есть в C++, так это const correctness для value-типов.
iiopy4uk_mck
19.08.2021 20:40+4Ну молодые идут туда, где перспективы более туманные, либо платят больше, либо и то и другое. Всякий мл, датасаенс, го, фронтэнд на новых фреймворках, старый добрый геймдев - мечта молодых.
Это не делает дотнет менее перспективной менейджед средой.
derikn_mike
19.08.2021 21:08-6почти все в додо работают , реклама?
кстати Роман Букин невероятно таксичный человек в Телеги у нас в группе.
vabka
20.08.2021 03:33+4Ни разу не заметил токсичности за ним.
Обычно токсичность вижу только в ответ на какие-то очень резкие заявления.
В посте всего 3 человека из 10 работают в додо.
Когда 33% стало "Почти все"?
axmct
19.08.2021 22:19-11Вот вы будете советовать изучать своим детям .NET?
Я - нет.
"У .NET блестящее будущее" - уже 20 лет.
Java мир устоял. Мир PHP/Python не особо заметил.
Место .NET только в корпоративных продуктах Microsoft.
Идти ему вовне некуда.
Да, есть часть программистов которые испытывают Стокгольмский синдром застряв в продуктах Microsoft без возможности перейти на другие платформы.
Какие технологии стоят за пиццериями— (Фил) В 2011 году .NET не был очевидным выбором. Почему выбрали его?— Просто наши ребята знали .NETumbarov
19.08.2021 23:50+14Идти ему вовне некуда.
А почему некуда? Вы можете писать на дотнете любые программы на любых платформах и без Микрософта.
Место .NET только в корпоративных продуктах Microsoft.
Это только архаическое мнение. Много стартапов, которые используют новые версии дотнета.
ASP.NET Core на первом месте среди Loved frameworks https://insights.stackoverflow.com/survey/2021#technology-most-loved-dreaded-and-wanted
siziyman
20.08.2021 02:22-1ASP.NET Core на первом месте среди Loved frameworks
Мне кажется, это не очень показательно в экосистеме, где других фреймворков-то и нет.
vabka
20.08.2021 03:37+7Это первое место среди всех языков.
Тоесть он более loved, чем какой-нибудь Spring/Flask/Django итд
vedenin1980
20.08.2021 09:31+2Проблема в том, что если это единственный фреймворк в языке, ты либо его любишь, либо пишешь на другом языке. Плюс тем кто пишет только на этом языке просто не с чем сравнивать (условно JavaEE часто недолюбливают, потому что есть Spring и другие фреймворки, а если это был единственный фреймворк в экосистеме его популярность была бы сильно выше).
Поэтому к такой статистике стоит стоит относится осторожнее, думаю если спросить о 1С как фреймворке у 1C программистов у нее тоже может быть высокий рейтинг любви (ибо куда им деться с подводной лодки).
P.S. Это не камень в огород .Net, писал на Spring и .Net и на мой взгляд они примерно одинаковые по удобству и возможностям. Просто не стоить забыть, что есть «ложь, наглая ложь и статистика».siziyman
20.08.2021 10:12-2Да, именно это я имел в виду, спасибо. Если сравнивать не с чем, то сильно проще не замечать недостатки.
Cryvage
20.08.2021 10:41+3Во первых, помимо ASP.NET Core, есть ещё просто ASP.NET. Он кстати, тоже есть в рейтинге, и расположился существенно ниже.
Во вторых, есть Blazor — тоже web фреймвёрк.
В третьих, раньше ещё существовал ASP.NET Web Forms. И его ненавидели многие. Впрочем, трудно сказать, как много людей из участвовавших в опросе его в живую видело.
В четвёртых, раз уж JavaEE со Spring сравниваем, то можно и ASP.NET с WCF сравнить, пожалуй.
В пятых, посмотрите на результаты Ruby on Rails и Django — их положение в родных языках похоже на положение ASP.NET Core в C#, но они гораздо ниже в рейтинге.siziyman
20.08.2021 11:11-3Я так понимаю, традиционный дотнет (не .кор) во-первых сильно постарше, во-вторых, не подходит для тех, кто не привязывается к Винде, чем сильно ограничивает выбор многих.
Блэйзор, кажется, в принципе не шибко распространён (и тоже является решением от майкрософт), ещё и строится поверх дотнеткора. Кстати, я подглядел в википедию - они что, правда думают, что шаблонизаторы с встраиванием кода прямо в HTML-шаблоны в %current_year% - это что-то хорошее? В джаве это лет 6 назад уже считалось плохим тоном и ошибкой прошлого десятилетия.
Вот только в джаве помимо Спринга и ЕЕ фреймворков прямо-таки полно - Quarkus, Micronaut, Play (его, конечно, чаще скалисты используют, но и в джаве бывает), прости господи, GWT, и это только то, что за первую минуту в голову пришло.
Джанго - нет, далеко не такое же положение, вон, там кто-то Фласк вспомнил, и на них вроде тоже не всё заканчивается.
Cryvage
20.08.2021 12:55+5они что, правда думают, что шаблонизаторы с встраиванием кода прямо в HTML-шаблоны в %current_year% — это что-то хорошее? В джаве это лет 6 назад уже считалось плохим тоном и ошибкой прошлого десятилетия.
Тогда вам лучше не смотреть на React, и вообще на современный фронтенд, т.к. в %current_year% это считается стандартом. Blazor просто заменяет JS на C#, по большому счёту.Вот только в джаве помимо Спринга и ЕЕ фреймворков прямо-таки полно
Вообще, главной моей мыслью было не сравнение ситуации с Java, а то, что шарпистам таки есть с чем сравнивать ASP.NET Core. К текущим решениям Microsoft далеко не сразу пришёл. И альтернативные решения тоже есть. Причина любви к фреймвёрку, точно не в отсутствии у людей другого опыта. На самом деле, всё просто. Это хороший фреймвёрк, с ним приятно работать. И по сравнению с предыдущей реализацией, он стал лучше. Люди видят прогресс. Потому и довольны. Может .NET уступает Java в распространённости, но никак не в удобстве и инновациях.
vedenin1980
20.08.2021 16:05-2ASP.NET Core, есть ещё просто ASP.NET, ещё существовал ASP.NET Web Forms
По-моему, вы сейчас перечисляете разные версии одного фреймворка (официально, ASP.NET Core сначала хотели называть ASP.NET 5), это как говорить есть Spring 1, Spring 2,…, Spring 5 или Angular 1, Angular 2 и т.п.Blazor — тоже web фреймвёр
Вообще-то это часть ASP.NET Core, тогда в JavaEE есть Servlet, JSP, JavaServiceFace и еще куча разных «web» фреймворков. Тоже не похоже на отдельный фреймворк, который можно было бы использовать без ASP.mayorovp
20.08.2021 18:11+2это как говорить есть […] Angular 1, Angular 2
Но ведь так и есть, Angular 1 (который angular.js) и Angular 2 (который просто Angular) — это два разных фреймворка.
axmct
20.08.2021 19:12-4Azure открыт для Java и Python и прочих так же как и для .NET.
Low-code, No-code. Работа для программистов MS стека уходит в сам Microsoft и там только и остается.
.NET уже побочная история для Microsoft. Нет никакого профита для Microsoft в успехе .NET.
MS SQL Server уверенно теряет популярность. Azure SQL это совсем другое.
Web - поле не MS. Clouds - поле не особо .NET.
Не вижу драйверов успеха.
axmct
20.08.2021 21:32-5Не только. Еще и вкладчик, требующий свою долю:)
За 15 лет работы в качестве программиста на стеке Microsoft просто тошнит от него. В Java и PHP - меня не тошнит что интересно.
Хороших выходных!
marshinov
27.08.2021 22:45+1Ну не, Nancy ещё был (или есть?). Просто asp.net core реально классный:) я даже не знаю чего там захотеть, кроме дефолт модел байндеров с поддержкой параметрических конструкторов:)
axmct
20.08.2021 17:43-4
Не только, еще и кардиган красный. И репутация вендора который тебя неизбежно подставит.
KislyFan
20.08.2021 19:42+2где других фреймворков-то и нет
Я может быть буду не объективен, потому что .net мой любимый язык, но все же думаю, что вы не правы. Да, многие проводят знак равенства C# = Net Framework, но это не так как минимум потому что пока еще есть свободный Mono, есть коммерческий Mono/Xamarin.. он конечно со временем исчезнет, как самостоятельное явление (а судя по roadmap это произойдет примерно с выходом NET7.0), но существовать не перестанет. Есть .NET Micro Framework.
Если смотреть шире, то фреймворк не имеет альтернатив не потому что майкрософт ось зла, а потому что это жирная стандартная библиотека языка, и прикладные фреймворки выиграли гонку с другими решениями.. aspnet выиграл не потому что это кровавый энерпрайз, а потому что его альтернативы не выросли. Тот же Spring-Net не смог, хотя и был чрезвычайно популярен до появления собственных DI в dotnet core. Или например winforms, silverlight устарели и умерли, а wpf еще не умер, но вот уже почти.. его место стремится занять MAIU (бывший Xamarin Forms).
В любом языке есть фреймворки занимающее доминирующее положение, это не их вина, что ничего лучше не было написано. Откройте библиотеку Nuget, там сотни и тысячи пакетов сторонних фреймворков.. для всего.
axmct
20.08.2021 15:07-2А почему некуда? Вы можете писать на дотнете любые программы на любых платформах и без Микрософта.
Некуда потому, что нет места. Все естественным образом на своих местах.
.NET это в любом случае Микрософт. Не WIndows, так СLR etc.
Гениальная статья Joel 2004 года отражающая суть и сейчас. И которая будет отражать положение дел и через 10 лет.
Если мы сравним изначально равных программистов с 20 летним опытом (2000- 2020) в мире .NET и в мире Java, то мы увидим совершенно разную изношенность нервной системы.
https://www.joelonsoftware.com/2004/06/13/how-microsoft-lost-the-api-war/
One runtime to rule them all. It was beautiful. And they pulled it off, technically. .NET is a great programming environment that manages your memory and has a rich, complete, and consistent interface to the operating system and a rich, super complete, and elegant object library for basic operations.
And yet, people aren’t really using .NET much.
Oh sure, some of them are.
...
No developer with a day job has time to keep up with all the new development tools coming out of Redmond, if only because there are too many dang employees at Microsoft making development tools!
Kanut
20.08.2021 15:15+6Если мы сравним изначально равных программистов с 20 летним опытом (2000- 2020) в мире .NET и в мире Java, то мы увидим совершенно разную изношенность нервной системы.
Может и увидим. Но с моей точки зрения сравнение будет не в пользу Java. Ну если брать именно изношенность нервной системы :)
Гениальная статья Joel 2004 года отражающая суть и сейчас. И которая будет отражать положение дел и через 10 лет.
Вот только на данный приличная часть написанного в этой статье к Java применима не меньше чем к .NET. :)
axmct
20.08.2021 16:09-8Microsoft. Это достаточная причина сама по себе.
KislyFan
20.08.2021 19:47+2Ну это же дичь, и ненависть ради ненависти. Тут еще не хватает лозунга "windows must die!" для полноты картины. В общем обычный пример фанатичного красноглазия.
axmct
20.08.2021 20:16-4"Microsoft. Это достаточная причина сама по себе."
Ну это же дичь, и ненависть ради ненависти.
Непредсказуемый бизнес-партнер, себе на уме. Вообще не заинтересован в твоей доле и даже не замечает что ты его партнер. При этом полностью контролирует твои средства производства.
Используя .NET вы так или иначе берете Microsoft в свое дело.
Это не хейт, а боль.
0xd34df00d
21.08.2021 08:21+3Например, в The Pragmatic Programmer. Под рукой pdf'ки нету, чтобы дать более конкретную ссылку.
0xd34df00d
20.08.2021 23:48+1В том чтобы кое-как знать 100500 языков и платформ?
«Кое-как» не надо, а вообще рекомендация более-менее изучать один новый язык в год вполне себе существует. Конечно, это не значит, что надо кричать «вот это точно рулез» про каждую из них.
buldo
20.08.2021 02:50+9Уже несколько лет разрабатываю сервисы на .net, которые крутятся в докере, ходят в постгрес и никогда не видели винды. Последнее время сижу в райдере и подумываю о том, чтобы рабочий комп перевести на Ubuntu.
axmct
20.08.2021 15:47-7Не вижу предмета для гордости. Прилипли к .NET как инструменту и не можете оторваться от него.
Профессиональному программисту все равно на чем писать.
И выбор .NET чтобы в контейнере на Linux обращаться скажем к PostgreSQL - это какая-то роспись в отсутствии развития как программиста. Понятно что проект исторически и поддержка, но явно не предмет для гордости.
Kanut
20.08.2021 15:52+7Профессиональному программисту все равно на чем писать.
Тогда почему вы не пиште под .NET? Ну если всё равно?
И выбор .NET чтобы в контейнере на Linux обращаться скажем к PostgreSQL — это какая-то роспись в отсутствии развития как программиста.
Почему? Если всё равно на чём писать, то чем в данной ситуации вас не устраивает .NET? Или Linux? Или PostgreSQL? Или что вас конкретно не устраивает и почему?
axmct
20.08.2021 16:26-5Что в этой связке делает .NET кроме как использования того это сладко для конкретного программиста/команды?
с точки зрения самого языка — C# прекрасный, замечательный и офигенный. Там огромное количество синтаксического сахара и понятных конструкций, которые можно нормальным логическим образом объяснить.
https://habr.com/en/company/habr_career/blog/433168/
Сладкое - вредно.
О чем думают те кто в .NET по самые уши?
— (Фил) Если Microsoft исчезнет и перестанет поддерживать свои технологии, насколько дорого это вам обойдётся? Все — нет .NET, нет Azure.
— Насчёт Azure. У нас глобальное направление — это контейнеризация в Кубер, и по факту неважно, где он запускается. Экстренное восстановление и переход на другую платформу у нас занимает где-то пять часов. С точки зрения операционки мы потеряем четыре-пять часов работы.
А если вдруг исчезнет .NET, разработчики никуда не денутся. Переход на другой стек, конечно, нас затормозит, но я не думаю, что окажет значительное влияние. Мы понимаем, что новые сервисы нужно сделать на каком-то другом стеке — Java, Go, Python, неважно — мы просто начнем постепенно переделать и поддерживать операционную работу того, что есть сейчас.
А почему вообще такие вопросы возникают? Светлое же будущее последние 20 лет.
.NET, "по честному", это не сахар с пудрой для кодера, а Windows server, IIS.
Я понимаю, что обнулили, и .NET Core это уже настоящая Java присыпанная пудрой. Но если есть соленый ветрами оригинал, то не смысла идти на поводу у программистов для которых синтаксис это программирование.
Kanut
20.08.2021 16:41+4Что в этой связке делает .NET кроме как использования того это сладко для конкретного программиста/команды?
Так а что принципиально изменится если там вместо него будет Java?
Я понимаю, что обнулили, и .NET Core это уже настоящая Java присыпанная пудрой
Что .NET Core, что Java это одна и та же "пудра". Давно уже. Разве что в .Net денег больше вливают.
Но если есть соленый ветрами оригинал
Привет вам там в ваши 90-е. Нет уже давно никакого "оригинала". И Java уже точно так же дерёт концепты отовсюду. В том числе и с шарпа. А часть вещей в Java ещё даже и дёрнуть не успели.
axmct
20.08.2021 18:45-4Эти концепты по сути сахар синтаксический. Которые только программисты и могут на языке ощущать.
Зачем нужен опять инновационный .NET там где уже есть Java, PHP, Python, Go etc фреймворки со всей инфраструктурой и годы кода на все случаи жизни.
Какое-то место у .NET есть. Эти продадут и дохлого осла. Но советовать молодежи изучать и идти в .NET - безответственно. Кнопко-нажимательство и деградация.
Kanut
20.08.2021 18:49+4Зачем нужен опять инновационный .NET там где уже есть Java, PHP, Python, Go
Зачем нужны всякие Java, PHP, Python, Go и прочие ЯП с "концептами" если есть ассемблер?
axmct
20.08.2021 20:22-2Если есть популярные ассемблер фреймворки с библиотеками под web, e-commerce, Warehouse, CRM etc etc то да, не нужны.
Готов рвать 21 прерывание зубами если это позволяет выполнить проект в срок и бюджет.
Kanut
20.08.2021 20:25+3Так фреймворки и библиотеки это же сахарная пудра. И настоящему программисту всё равно на чём писать. Так что зачем вам всё это? Или вы не настоящий программист?
axmct
20.08.2021 21:13-1Фреймворки и библиотеки это соль. То есть именно они собственно инструмент, а не язык. Все равно на чем это когда common sense - программист берет наиболее подходящий инструмент под задачу.
Расширять Microsoft продукты - .NET, под e-commerce PHP wordpress-woocommerce/magento, под свои бизнес сложные - Python Odoo, для работы с PostgreSQL - Java, Python, C, Go.
Не потому что лямбды там или нет на уровне синтаксиса, а потому что value проекта. Идти на поводу комфортной зоны кодеров - платить трижды.
Kanut
20.08.2021 21:23+2Идти на поводу комфортной зоны кодеров — платить трижды.
Ну так выйдите наконец-то из своей комфортной зоны и пишите на ассемблере.
read_maniak
20.08.2021 17:05+5Да хороший язык же. Можно и бэкэнд пилить, и GUI-приложения под винду, и консольные приложения подо что угодно, и игры на движке Unity. Не замечал, чтобы в какой-то из этих областей он был прям сильно хуже других альтернатив. Смысл учить 100500 языков, если мне для всего этого хватает одного C#?
0xd34df00d
20.08.2021 23:53+3Профессиональному программисту все равно на чем писать.
Никогда не понимал это. Вот мне вроде деньги за программирование платят, код я более-менее пишу неплохо, но мне совершенно не всё равно, на чём писать. На некоторых из популярных языков я не буду писать даже под страхом увольнения (ну там, питон, go), на каких-нибудь плюсах — за очень большие деньги либо по фану и без ответственности, на хаскеле — в почти любой ситуации.
anonymous
00.00.0000 00:00balberbro
20.08.2021 09:17-6Особенность .net в том, что он не может подвинуть ни java, ни python, ни php, ни js.
1) Сложность .net выше, чем у python/php, поэтому всякие стартапы и небольшие проекты делаются на них, а не на .net. Плюс раньше, так вообще .net имел бан у стартапов, ибо пока купишь все лицензии — без штанов останешься. Сейчас это вроде как поправили — но осадочек остался.
2) В корпоративном мире айтишных компаний правит Java, которая имеет решение на любой вопрос (ибо столько топовых компаний на ней пишет софт), что полюбому уже все есть. И это все более менее задокументировано.
И естественно, никто не будет переписать софт с Java на .net, ибо зачем — это слишком дорого в плане переученивая кадров и поддержки двух систем.
В итоге, получается вроде бы отличный язык программирования и отличная платформа, но у неё большая сложность и ниже зарплата, чем на сопоставимых стеках. Плюс экосистема имеет определенные вендор-локи, когда есть всего одно подходящее решение для какой-то проблемы, а не 21 (как у Java).
__
Поэтому нет ничего удивительно, что Майкрософт продвигает свои решение (облачные и прочее) не через .net, а через TypeScript (он у них получился удачным и востребованным) и через геймдев.
P.s. естественно .net никуда не уйдет, уже написано слишком много систем на нем, и они будут поддерживаться, развиваться. Какие-то студенты после универа будут писать свои решения на нем и прочее.
Уже откровенно стало понятно, что их идея с .Net Core провалилась в плане продвижения среди разработчиков, ибо при выходе платформы на неё было много взглядов и ожиданий от неё (но платформа оказалос сырой без обратной совместимости и прочее). А сейчас, когда её доделали — уже поезд ушел.
В общем, всем Java пацаны!
umbarov
20.08.2021 00:58+5Используйте, пожалуйста, свежую статистику от Stack Overflow https://insights.stackoverflow.com/survey/2021, а не прошлогоднюю. Недавний опрос от Stack Overflow показывает, что .NET Core/ .NET 5 и ASP.NET Core стоит на первом месте среди Loved frameworks. За год подняться на первое это уже класс :)
gayka_m8 Автор
20.08.2021 13:18Спасибо за ссылку.
Только в статье приводится статистика наиболее популярных фреймворков, а loved — это другое.
Если смотреть текущую статистику, то там ситуаци поменялась по сравнению с прошлым годом: ASP.NET Core на пятом месте (поднялся с шестого), а ASP.NET – на седьмом (был на четвёртом).
mr_bag
20.08.2021 01:04+6"придётся уйти из .NET, потому что он вымирает"... смеялся до слёз ))
особенно после подкастов описывающих изменения в .Net 6...
static abstracts in interfaces например.
p.s. хотя для нового проекта с бэкендом я бы подумал - kotlin vs. c#
marshinov
27.08.2021 23:02Вот Котлин - да. C# классный, но Котлин делали позже и исправили мелкие всякие шероховатости C#. Хотя все ещё не вполне уверен, что корутины лучше специализированного синтаксиса под каждую задачу.
saboteur_kiev
20.08.2021 02:33Java и Nodejs очень много в контейнерах.
Как C# живет в нативных контейнерах?
Я слышал, что он стал кроссплатформенным, но насколько тяжелее будет запустить микросервис в кубере .NET по сравнению с java или nodeJS?
buldo
20.08.2021 02:55+1Если просто небольшой сервис, то далее-далее-далее в мастере создания проекта в ide(поддержка докера включается галочкой) и вот уже всё запускается в контейнере и к этому автоматом цепляется отладчик. Ещё несколько кликов мыши и готова поддержка compose или k8s.
Как в java или js - сказать не могу, но на минималках в .net от открытия в студии до запуска в контейнере несколько минут.
vabka
20.08.2021 03:39+1А если вместо студии взять райдер, то может даже меньше минуты, ибо поддержка докера включается одной галкой при создании проекта :)
Ну это если взять как цель "заспидранить контейнеры на дотнете"
saboteur_kiev
21.08.2021 10:12Эм, я спрашивал не про сложность создания сервиса, а про тяжелость самого процесса с точки зрения потребления ресурсов.
Все-таки кроссплатформенность java существует многие годы, и рантайм прилично оптимизирован, а .NET в этом недавно
buldo
22.08.2021 00:15Сравнить не могу - у меня нет опыта с другими языками. Могу только сказать, что на проде оно работает без проблем.
Плюс на habr проскакивала статья в которой показывалось, что даже в Azure у сервисов на .net, запущенных под *nix производительность выше, чем на windows.
saboteur_kiev
27.08.2021 00:52-4Плюс на habr проскакивала статья в которой показывалось, что даже в Azure у сервисов на .net, запущенных под *nix производительность выше, чем на windows.
Вот в этом и дело. Что возможно что сервисы написанные на java/kotlin запущенных под *nix будет производительность еще выше.
Но наверное тут нет смысла вести дискуссию. На простых задачах нечего мерять, а сложные сервисы писать и на java и на C# чтобы просто померять, задача слишком большая для любопытства.
gameplayer55055
20.08.2021 08:28+3Фронтендеры be like:
1)создаём динамически типизированный ЯП
2)делаем свистели перделки в браузере
3)слышим про бекенд, делаем ноду
4)создаём тайпскрипт
5)а теперь кажем .NET не нужно
6)PROFIT. Компилируемый подвид джаваскрипт же гораздо лучше дотнета
orthoxerox
20.08.2021 10:42+4И в .Net, и в Java можно нарваться на кровавый легаси:
В Java это будет JavaEE ранней версии с бесконечными простынями конфигурационного XML, собираемая ant'ом.
В .Net это будет ASP.Net Web Forms 2.0 с ViewState на 10 мегабайт, покрытый толстым слоем самописных фреймворков
Другое дело, что у Java лучше PR. Много директоров знают слова "микросервисы на Spring Boot", а вот на фразу "микросервисы на ASP .Net Core Web API" у них срабатывает триггер на "ASP", и они вспоминают тот самый кровавый легаси.
А так-то стек из ASP .Net Core + EF Core + MSSQL/Postgres даст фору любому спрингу по скорости и качеству разработки. (Если только вам не нужно работать с очередями...)
snuk182
20.08.2021 15:05+1Самое обидное, что Spring самый разрекламированный и востребованный рынком, но далеко не самый удобный для разработки фреймворк, даже в версии Boot. После связки Vert.x+Dagger от него часто хочется чесать затылок.
questor
20.08.2021 11:39Статья страдает некоторой однобокостью: высказаться дали только тем, кто уже занимается цать лет си шарпом. Это конечно хорошо, потому что люди в теме -- но если вспомнить про то, что опросы в интернете показывают, что 100% участников опроса пользуются интернетом. Вероятно, если высказывались только представители компаний, где оба стека используют - было бы более объективно.
Много ли компаний уровня FAANG (списка Top fortune 500) использует C#? Кто ещё помимо самого вендора готов по-крупному вкладываться в развитие экосистемы?
С аргументацией у некоторых выступавших тоже не всё хорошо. Пример. Когда в си шарп тянутся новички за простотой (которая небесспорна) то это создаёт плохую репутацию языку. Отчего ж когда другие новички прутся в другие языки попроще (не будем показывать пальцами) это им не создаёт такую плохую репутацию? Или тоже создаёт? Тогда видимо не в новичках проблема и не в простоте языка.
Flaksirus
20.08.2021 13:12+2Беда с ФААНГ в том что они не молоды и легаси кода у них вагон и маленькая тележка. Само собой код этот на джаве, питоне, плюсах и самописных языках. Большую часть этого кода составляют лютые костыли и велосипеды, от которых только и приходится, что плеваться. C# же молодой язык, поэтому на нем ничего и не написано толком. Хотя есть и в ФААНГ проекты на нем. В гугле например штадия на шарпе, у теслы чего то есть на шарпе, у нетфликса тоже. Теперь и гитхаб пишут на шарпе (хотя это мс теперь, который тоже ФААНГ). В этом плане завидую фронтендерам - вообще ребята не парятся с языками, ведь есть дефакто только один и слава богу. Плюс ко всему им не надо мучиться с легаси, ведь фронт каждый год надо переписывать на новый модный фреймворк и горя не знать.
Kanut
20.08.2021 13:47+2C# же молодой язык, поэтому на нем ничего и не написано толком
C# вышел в 2001-м. Java старше его всего на пять лет. Проблема скорее в том что долгое время C# был исключительно "языком программирования для разработки под винду".
Bellerogrim
20.08.2021 14:32+1C# же молодой язык
Ну конечно не плюсы, да, но 20 лет уже прошло.
Flaksirus
20.08.2021 14:35С тех пор как его стало нормальным использовать в проде всего лет 5 :) а так если задача писать строго под Винду, думаю проектов и 20ти летних найдется пачка.
Bellerogrim
20.08.2021 15:15+4Плюс ко всему им не надо мучиться с легаси, ведь фронт каждый год надо переписывать на новый модный фреймворк и горя не знать.
Наоборот, у них абсолютно весь код — легаси. Как только вышел в продакшен — всё, фреймворк уже устарел, а может даже сам подход устарел, и надо срочно писать всё совсем по-новому.
Red_Lord
20.08.2021 16:25-5На Java есть Zookeeper, Kafka, Hadoop, Elastic Search. Ни одного аналога на .NET не существует. Правда в том, что рынок энтерпрайза .NET проиграл. И все остальные направления тоже сдуваются — на desktop правит бал Qt, для микросервисов есть Go, для простых сайтов — PHP. Единственное, что ее живо — игрушки на Unity.
KislyFan
20.08.2021 21:25+5Это совершенно некорректное сравнение. Вы приводите в пример какие-то специфические узкие задачи, и на основе этого хороните язык и фреймворк, а если разобрать коммент на тезисы, то к каждому будет много вопросов. Например
На Java есть Zookeeper, Kafka, Hadoop, Elastic Search
Это не преимущества языка, а технологии с реализацией на Java, и dotnet имеет официальные клиенты почти к каждой из них. Понятное дело что интеграция с родным Java будет лучше, но это не является киллер-фичей. Более того, сейчас идет тенденция на гетерогенные решения.
для микросервисов есть Go, для простых сайтов — PHP
А тут вы вообще приводите примеры, где за пределами которых эти языки фактически не существуют. Ситуация с PHP вообще интересна тем, что он лидер в отрасли потому "тут так принято", что выражается в огромном количестве дешевых или вовсе бесплатных хостингов php+mysql, и огромной кодовой базе готовых проектов которые надо поддерживать.
на desktop правит бал Qt
Начнем с того что это опять фреймворк, который к тому же ну ни разу не стандарт, а просто единственно что вменяемо выглядит на С++. А во вторых, смерть standalone приложений - это вопрос времени, их нишу займут гибридные веб сервисы, и тут dotnet уже впереди всех со своим Blazor.
что ее живо — игрушки на Unity
Юнити популярен потому что ему нет альтернатив с тем же порогом вхождения. Это не заслуга языка или фреймворка, а разработчиков и маркетологов из UniTech.. и скорее его (языка) бич. На собеседованиях в компании не связанных с геймдевом крайне не рекомендуется упоминать о том, что ты делал игрушки на юнити. Надеюсь не надо объяснять почему.
Смысл мессаджа в том, что быть популярным в какой-то узкой области, не значит являться лидером или быть лучше. В MS вовремя поняли что условия меняются и поезд энтерпрайза уходит, и предприняли верные шаги. Кроссплатформенность, оптимизации производительности, развитие языка и фреймворка.. все это (если они не поменяют темп и курс) поможет им "пройти как моча сквозь снег" и забрать себе жирный кусок пирога.. благо все предпосылки для этого есть.
axmct
20.08.2021 21:46-4Логично все. Ждем результатов? Я их 20 лет жду.
Правда в том, что рынок энтерпрайза .NET проиграл. И все остальные направления тоже сдуваются
Согласен с автором данного заявления так как наблюдаю именно это. При этом страшен Microsoft не тем что проигрывает, а тем что стреляет себе в ноги сам. Каждый раз.
Вот ни разу Microsoft не отождествляется с разумом и верными шагами. То есть он шагает но на рынке акций, а развитие языка и оптимизация производительности они успеху акций параллельны. Заплатят паре агенств и PR компаниям и те прогудят что все тип-топ. Вот это важно, да.
AnthonyMikh
23.08.2021 18:09+7На собеседованиях в компании не связанных с геймдевом крайне не рекомендуется упоминать о том, что ты делал игрушки на юнити. Надеюсь не надо объяснять почему.
Эм, надо. Мне не очевидно.
KislyFan
02.10.2021 21:31Пропустил ответ в треде, почему-то ушло в спам.
Если мы все еще говорим о начинающих разработчиках, то нужно понимать что Unity подложил нам огромную свинью. В один миг появилось огромное количество "начинающих разработчиков", которых прельстил низкий порог вхождения, который обеспечивает Unity. Они умеют писать простые скрипты с MonoBehaviour Start\Update и делать несложные вещи с GameObject, но на этом их знания как правило заканчиваются.. Для собеседующего это скорее "маркер" о том, что собеседуемый скорее всего имеет поверхностные, кусочные или отрывочные знания.
Это не только мое мнение, я постоянно читаю о подобном мнении на профильных ресурсах.. и это косвенно подтверждается по результатам тех собеседований в которых я участвовал на стороне работодателя. Если я вижу в резюме, что человек претендует на низшую должность в табеле (у нас это "инженер") и делал игру на юнити, то скорее всего он объективно не пройдет собеседование.. потому что его знания не дотянут до проходного минимума. И тут нет хейта или предвзятого мнения, я сам увлекаюсь созданием игрушек на Unity3D и может быть когда-нибудь допишу статью "почему я не закончил порт Lineage2". Вот как-то так.
NikolayPyanikov
20.08.2021 19:15+1Большую часть времени пишу на C#, на Java и на Kotlin. На последнем процентов 60 - 70. По моим субъективным оценкам C# эффективнее. Что касается дизайна, C# имеет большой плюс – это нормальные обобщенные типы. По оптимизации C# так же хорош, так как есть типы значений и возможность использовать стек вместо кучи в «горячих» местах. Есть, конечно, надежда на проект Valhalla.
В плане платформы .NET, Microsoft дали слишком большую фору конкурентам, пока сделали ее открытой и кроссплатформенной, лучше поздно чем никогда. В любом случае, все эти языки и технологии вокруг слишком схожи, чтобы беспокоится что какой-то из них будет более или менее популярен.
AlexeyALV
А когда html стал языком программирования? Раньше был языком разметки...
gayka_m8 Автор
Если речь об этом
то тут просто перечисление, что Слава изучал, но нигде не написано, что это язык программирования.
AlexeyALV
Речь про иллюстрацию опроса об основных используемых ЯП
gayka_m8 Автор
Не могу знать, чем руководствовались в JetBrains, когда проводили опрос.
avengerweb
Нынче это самый популярный вопрос, все эти опросы не о том что есть язык программирования, а о том что разработчики используют для выпуска продуктов. Ни один продукт нынче не может не использовать HTML, это значит что большая часть разработчиков вынуждена изучать эту технологию, значит что она востребована. Если проще то, конечно да, на html не программируют, но часто чтобы получить html программируют.
anwender95
Как часто эмбедеры, например, юзают хтмл?
avengerweb
Почти все что имеет экран и доступ в интернет умеет рендерить html, так что скорее всего одну страничку оно имеет. Если устройство современное, да ещё и с тач скрином, то с довольно большой долей вероятности они вполне может быть выполнено на основе какого нибудь облегчённого браузерного движка. На самом деле есть несколько компаний которые делают аля облегчённый «электрон» для разработки embedded приложений, и на рынке они сильно дольше чем к примеру электрон, так что по видимому спрос есть.
nightwolf_du
И куча того, что его не имеет, достаточно сетевого интерфейса.
Когда 10 лет назад перекантовывался работой на спиртазаводе, здоровенные электронные весы для зерна торчали по сети страничкой с конфигурацией, прям как роутер. Это же очень удобно - не надо искать документацию на устройство, разбираться где у него конфиги и как их править. А ресурсов под простенький веб-сервер на 10-20 статических страниц хватит, наверное, у всех устройств, что по размеру больше кредитки.
0xd34df00d
Раз тут пошли такие тонкости, то в том софте, за разработку которого мне платили деньги, с хтмл мне работать не было нужно ни разу.
major-general_Kusanagi
Вроде, обещали что пятый html станет тьюринг-полным языком программирования.
0xd34df00d
Это вместе с css3.