Комментарии 205
А когда html стал языком программирования? Раньше был языком разметки...
Если речь об этом
Последний год изучал сетевое взаимодействие, саму сеть, ASP.NET Core, немного HTML, CSS, JavaScript.
то тут просто перечисление, что Слава изучал, но нигде не написано, что это язык программирования.
Нынче это самый популярный вопрос, все эти опросы не о том что есть язык программирования, а о том что разработчики используют для выпуска продуктов. Ни один продукт нынче не может не использовать HTML, это значит что большая часть разработчиков вынуждена изучать эту технологию, значит что она востребована. Если проще то, конечно да, на html не программируют, но часто чтобы получить html программируют.
Почти все что имеет экран и доступ в интернет умеет рендерить html, так что скорее всего одну страничку оно имеет. Если устройство современное, да ещё и с тач скрином, то с довольно большой долей вероятности они вполне может быть выполнено на основе какого нибудь облегчённого браузерного движка. На самом деле есть несколько компаний которые делают аля облегчённый «электрон» для разработки embedded приложений, и на рынке они сильно дольше чем к примеру электрон, так что по видимому спрос есть.
все что имеет экран
И куча того, что его не имеет, достаточно сетевого интерфейса.
Когда 10 лет назад перекантовывался работой на спиртазаводе, здоровенные электронные весы для зерна торчали по сети страничкой с конфигурацией, прям как роутер. Это же очень удобно - не надо искать документацию на устройство, разбираться где у него конфиги и как их править. А ресурсов под простенький веб-сервер на 10-20 статических страниц хватит, наверное, у всех устройств, что по размеру больше кредитки.
когда html стал языком программирования? Раньше был языком разметки
Вроде, обещали что пятый html станет тьюринг-полным языком программирования.
MSBuild — ... не доставляет головной боли.
Я бы сказал что это так только на простых решениях, есть свои подводные камни и ограничения.
A я бы сказал, что это на решениях, где техлид не извращенец. Превратить простой проект в сложный - это не так уж и сложно. И в большинстве случаев, там, где я видел сложности с msbuild, то сложности скорее были с архитектурой решения в целом
Э-э-э, импорт чего? И зачем вообще нужно генерировать его при открытии студии?
Вот у вас есть солюшен проектов на сто, из которого собирается продукт с большим количеством сборок. Вам бы хотелось, чтобы в каждой из них ассембли инфо было одинаковым, в частности версия. Есть несколько подходов для решения этой проблемы, один из них — создать для этого отдельный props-файл, который будет подключать какой-то файл типа GlobalAssemblyInfo.cs (или модные определения в sdk-style, не суть), и импортировать этот props-файл в Directory.build.props — так, чтобы каждый проект его получил. Пока все просто и понятно.
Теперь заметим, что держать версию прям в cs-файле неудобно, т к она бывает нужна и в других местах (CI например), поэтому версия сама по себе лежит где-то отдельно, откуда ее просто достать — в json, xml или даже plain-text — тоже не суть. По итогу ассембли инфо генерируется из шаблона подстановкой этой версии. Соответственно в системе контроля версий не участвует.
Теперь вы клонируете чистый репо, в котором еще ничего не сгенерировано. Сначала импортируются пропсы, потом выполняются таски при сборке. И на тот момент, когда нужна ассембли инфо — она еще не сгенерирована.
А зачем она вам нужна так рано? Раньше стадии компиляции этот файл не понадобится, соответственно в большинстве случаев достаточно засунуть его генерацию в BeforeTargets="Compile".
Перфекционисты же могут использовать в качестве точки расширения GenerateAdditionalSources, которая как раз занимается генерацией исходников.
P.S. Точных деталей уже не помню, но кажется для Compile Include нужно чтобы файл уже существовал, и вот генерируется он после включения пропсов — т е билдить надо два раза, не комильфо.
Всегда работало.
кажется для Compile Include нужно чтобы файл уже существовал
Никогда подобное не требовалось. Возможно, это требуется какому-нибудь решарперу — но точно не msbuild и не студии.
Ну если вы хотите, чтобы файл подключился — на этот момент он должен существовать.
Зачем?
Смотрите, с точки зрения msbuild этот Compile — это просто очередной Item, который ничем не отличается от, к примеру, PackageReference.
Откройте любой проект и поищите в файловой системе файлы, которые соответствуют подключенным PackageReference. Спойлер — их нет. Мешает ли это пакетам "подключаться"?
Или вы хотите сказать, что существует какая-то магия, позволяющая вмешаться в уже созданный список файлов для компилятора?
Да, разумеется.
Список файлов для компилятора фиксируется на этапе CoreCompile. Любой target, который был выполнен до этого момента, может создать новый Item и именем Compile, и этот Item попадёт в список.
Но мы сейчас обсуждаем другую ситуацию, при которой элемент Compile задан статически. Какие в принципе могут быть причины непопадания этого элемента в список?
Вот именно, невозможно. А значит, и "сформировать список" раньше этого момента невозможно. Следовательно, статический элемент Compile из файла с пропсами будет успешно создан до момента формирования списка.
Моя "теория" основана на часах практики, которые я проводил изучая 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>Оно работает! Оно успешно компилируется. Оно даже генерирует файл при открытии проекта в студии.
С .NET не работал и не знаком, но с большим интересом иногда факультативно интересуюсь F#. Интересно, каково его будущее в .NET, вакансий для него практически нет, но вроде Microsoft продолжают его развивать и какие-то фичи из него перекочевывают в C#.
Имхо, в .net его будущее стабильно, он продолжит развиваться. Посмотрите на whats new и roadmaps для f#.
Появятся. Надо учесть, что .NET ещё молодой, если отбросить в сторону старый Framework .NET. Он ещё поборется за место под солнцем. Я в этом уверен. Уже писал одну программу для конкретной задачи, которая может одинаково работать в любой операционной системе и процессоре. Например, отлаживал на Windows 10 x86-64, а запускал на Linux ARM (Raspberry Pi). Этой осенью выйдет финальный релиз .NET 6, уже в разработке следующая версия. Судя по всему, она очень старается не привязываться к Windows.
Я как-то пробовал даже на проект затащить, но не зашло — все-таки его сложнее освоить, библиотеки не так хорошо совместимы, под капотом компилируется много неоптимального кода. В то же время C# продолжает перенимать в себя фишки F#.
На дотнете писать заметно менее тошно :) И язык, и тулы, и экосистема заметно моложе и делались с учетом ошибок джавы. Так что на джаве доплачивают за вредность.
Вкусовщина же. Последние годы джава как язык развивается вполне бодро, экосистема в целом куда меньше замкнута на решения от MS (и это я ещё искренне хорошо к компании отношусь, а есть те, кто их просто ненавидят), кроме того, никто не мешает писать на том же Котлине.
По моему опыту, доплачивать за вредность надо, например, за использование Visual Studio. :)
Про VS полностью поддерживаю, сам год назад пересел на райдер, это небо и земля.
Ну а я не соглашусь — лучше VS, на мой взгляд, пока ничего не сделали. Райдеру еще расти и расти до VS.
Ну хз. Когда в 2015 с рослином она начала кушать всю память в своём 32-разрядном процессе…
Ну во-первых, на райдере тоже будет рослин, вижла тут ни при чем. Да и на других языках тоже будет комплиятор и language сервер, так что деться тут некуда.
Во-вторых, я вот щас посмотрел, у меня среднего размера солюшен открыт — проект на 20 сорс файлов и проект с тестами такого же размера примерно. Студия последняя с десятком экстеншенов и решарпером: всё вместе это занимает около 2-2.5 ГБ в памяти. Как по мне, очень скромно, меньше браузера :) Да и вообще — пусть жрет память сколько влезет, лишь бы работало быстрее! Нафига мне пустой РАМ?
Речь о 32x-процессе и имутабельных коллекциях в рослине. Фактически решарпер просто уже не помещался, да и рослин на больших проектах - тоже. Сейчас на win вроде бы все стало лучше в новых версиях vs. Но у меня сейчас, например, Mac
А, я пропустил про 32 бита. Ну вот новая студия вроде будет 64-битная, ЕМНИП. Кроме вижлы на дотнете особо податься некуда в любом случае. Райдер это пока потемкинская деревня, но они вроде быстро развиваются, так что посмотрим. Плюс, наконец у вижлы есть конкурент, они тоже мб начнут быстрее там лапками шевелить.
Java обладает ужасными 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% к зп и чуть большую востребованность на рынке. Но сильно потеряешь в удовольствии от работы
Какая разница, что на Java чуть дольше настраивать конфиги, если тебе за это время все равно платят? Ну оценишь ты свою задачу в 12 часов, а не в 10 (на.нет), но все равно большая часть времени уйдет на согласование и орг-вопросы, а не на написание кода.
Крутой язык, большие перспективы, бороздящие корабли — это либо для молодняка, либо для сайд проектов в свободное время по кафу.Опытным программистам нужна адекватная зп, востребованность на рынке и возможность работать в комфортных условиях (не код комфортно писать, а чтобы менеджмент и окружение были адекватными). И тут Java просто круче.
Единственное, где .net давит — это универы и геймдев, но опять же для начинающих ребят.
Разница в том, что в .net ты просто работаешь, а в Java "превозмогаешь" и всё намекает на то, что инфраструктуру Java нужно переписывать
То, что за Java больше платят не делает его "круче". Скорее говорит плохо о Вас.
Какая разница, что на Java чуть дольше настраивать конфиги, если тебе за это время все равно платят?
Эту же мысль можно переформулировать так: какая разница, что платят на 10% больше, если нужно настраивать конфиги и заниматься еще какой-то фигней, а не чем-то приятным.
Опытным программистам нужна адекватная зп, востребованность на рынке и возможность работать в комфортных условиях (не код комфортно писать, а чтобы менеджмент и окружение были адекватными). И тут Java просто круче.
Как связан коллектив и язык программирования?
Так же Java просто любят на российском рынке. В мире с .net всё лучше
Но только не в Германии., особенно с релокацией. На глаз , позиций на Java раза в 1.5-2 больше, чем для стека .NET
Java обладает ужасными IDE, после VS это невыносимо.
После IDEA от VS тошнит, без решарпера это вообще преступление против человечества.
В .net гораздо понятнее устроен DI.
...чем в каком из 5-10 вариантов его реализации разными инструментами в джавовой экосистеме?
И после приложение будет довольно часто терять какую версию вы используете для сборки.
Нет, если вы один раз прописали это в любом используемом билд-туле, это никогда не происходит - это прямая ложь или непонимание того, о чём вы говорите.
В Java очень неудобный Maven. Появился Gradle, но на него с большим трудом переходят. И даже он далек до идеала.
Вкусовщина.
И в общем Java это больше о долгой кропотливой разработке. .net и удобнее и веселее
Да нет же, всё строго наоборот, никак иначе!
(это я показываю, как такие рукомашеские заявления работают в любую сторону).
del
>.чем в каком из 5-10 вариантов его реализации разными инструментами в джавовой экосистеме?
Как раз наличием DI-контейнера из коробки / возможностью подсунуть свою реализацию через стандартный интерфейс. Наличие 5-10 несовместимых API — это не плюс.
> без решарпера это вообще преступление против человечества.
В каком году? С R# студия тормозила всегда, а вот стандартный Roslyn с навешенным Roslynator делает чудеса, не потребляя ресурсы.
Как раз наличием DI-контейнера из коробки
Ну есть относительно стандартное javax-API, которое поддерживается сторонними фреймворками, например.
Наличие 5-10 несовместимых API — это не плюс.
Наличие выбора в зависимости от того, какие у вас предпочтения по организации кода и сложности/эксплицитности используемых решений - это плюс. :)
В каком году? С R# студия тормозила всегда, а вот стандартный Roslyn с навешенным Roslynator делает чудеса, не потребляя ресурсы.
Она просто жутко неудобная, на мой вкус: после JB'шных инструментов возникало ощущение, как будто меня заставляют, не знаю, ногами работать.
Но последнее не стоит воспринимать очень всерьёз, я скорее показываю, как плохо работают аргументы вида "это плохо, потому что я так сказал, а это хорошо, потому что мне нравится". :)
В силу обстоятельств перепробовал VS, VS Code, Mono Developer и Rider, но так и не смог понять восхищения продуктами JB. Для меня единственным фактором использования Rider оказалось то что для Linux Desktop просто нет достойной альтернативы, и по этой же причине он (Rider) совершенно не конкурент для VS2019/2022 в окнах.. ну разве что только по цене лицензии. Ах да! Лицензия! Модель распространения Rider без community лицензии.. это сильно. Можно конечно пользоваться EAP, но это совершенно не тоже самое.
под .net полно сторонних DI, как пример
В Java очень неудобный Maven. Появился Gradle, но на него с большим трудом переходят.
maven превосходен
Не согласен, в нём есть очень много чего, что можно улучшить.
1. Например веб-интерфейс браузера пакетов сильно хуже (менее удобен, сложно искать), чем npm или nuget
2. Сам он очень долго инициализируется
3. Не присутствует из коробки
4. Очень сложный (просто сравни размер документации)
Не присутствует из коробки
Это скорее плюс, чем минус. Если засунуть систему сборки в спецификацию языка, то потом фиг избавишься. Так бы и был у нас сейчас ant, а не maven. Сила Java как раз в том, что в базовой библиотеке лишь необходимое, а куча фреймворков, систем сборки, библиотек конкурируют между собой и ни одни из них не установлен по умолчанию. Завтра появится новая система сборки и ее придется тащить во все реализации jdk — ну нафиг.
Плюс Net в том что тебе дают все и сразу по-умолчанию, минус в том что если есть реализации всего по-умолчанию, то очень сложно пробиться чему-то нестандартному (просто потом что, нестандартное нужно изучать, а на новой работе она скорее всего не потребуется).
Например веб-интерфейс браузера пакетов сильно хуже
А он есть? Я знаю несколько сайтов которые показывают браузер пакетов, но все они неофициальные (и это тоже плюс), сам мавен централ (который тоже лишь одна из репозиторий) просто показывает список директорий с файлами.
Соглашусь с авторами комментариев выше. У меня есть опыт использования и .NET и JVM платформ — первое приятней, быстрей и удобней. Это касается даже IDE от JetBrains, хотя, казалось бы, один и тот же разработчик.
И если лично Вам джава кажется логичнее и интереснее — так выбирайте её! Это же дело сугубо добровольное. Хотя опять же, никто не запрещает изучать и то и другое одновременно, если не можете выбрать что-то одно.
Мы используем и джаву и дотнет. Дотнет заметно удобнее и приятнее в использовании. Но до недавнего времени он в принципе не был кроссплатформенным и даже до сих пор на нём не особо удобно делать кроссплатформенный десктоп. Поэтому там где не получалось использовать дотнет мы использовали джаву. Сейчас всё больше и больше от неё уходим.
Разницы в зарплатах у тех кто пишет только на шарпе или только на джаве внутри самой фирмы в общем-то нет.
Разница на рынке в целом есть. Но при этом если посмотреть на конкрентые позиции на которых джавистам предлагают больше, то часто сразу видно почему им больше предлагают. Например потому что надо работать с "легаси джавой". То есть например куча фирм "застряли" на восьмой версии и по той или иной причине не могут или не хотят мигрировать. В куче фирм просто не используются ни Marvel, ни Gradle. И так далее и тому подобное.
> если сложность .net сопоставима с java
В итоге по синктаксису — да, сопоставимы (мб, джава попроще будет, никакого вам синтаксического сахара), а реальный код на джаве с фьючами, стримами и отсутсвием лаконичных инициализаторов массивов — обнять и плакать.
лично моё мнение: в C# не хватает move-семантики для value-типов(struct, enum);
если бы в C# добавили move-семантику с помощью какого-нибудь спец. атрибута или ключевого слова, тогда в тех структурах, которые реализуют move-семантику, можно объявить деструктор, в котором можно освобождать ресурсы(закрывать файлы, сокеты, и т.д.)
в C# у value-типов по умолчанию copy-семантика(семантика копирования), но в C# нет move-семантики(семантики перемещения) для value-типов.
out/ref
unsafe + fixed в крайнем случае
Но это я Вам рассказал "по секрету", увижу такую в коде - буду много верещать ))
Перечисленное вами не имеет ничего общего с move-семантикой.
Тут наверное имеется ввиду аналог std::move и всего, что с ним связано (move-конструктор, move-assignment оператор и т. д.) в C++, в C# действительно этого нет. Ref это вообще-то передача по ссылке и к move-семантике действительно не имеет никакого отношения.
Мне кажется, если шарписты этого не знают, то им это и не нужно, если бы это вызывало какую-то боль, то наверняка бы знали о проблеме
В 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#, и половина из читающих будет незнакома с первым, а другая половина — со вторым, я просто не смог написать более лаконично, и без игры в «капитана очевидность». Надеюсь на понимание.
А насчет того, чтобы коллекции не делать структурами — расскажите это разработчикам System.Collections.Immutable. А то пацаны-то не в теме наверное, упускают что-то важное :)
И раз в шарпах бывают не-иммутабельные структуры, значит, и место для 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# коде, у меня запускается цепочка: отрицание -> гнев -> торг -> депрессия -> рефакторинг.
Я заметьте ничего не имею против иммутабельных структур
Это хорошо, что вы не против. Потому что делать их таковыми — это официальный гайдлайн от 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, вы никогда не найдёте мутабельную структуру. Язык под них просто не заточен.
А можно пример?
Я про `решения через ienumerable+yield `. Мне кажется лучше ответить здесь, т.к. это будет полезно не только мне).
TL;DR; основная идея в том, что возможность хранить в enum какие-то поля или методы для каждого значения, устранит нужду в большинстве switch-case по этому enum в коде.
Существует альтернативное решение, с использованием extension методов.
Из плюсов:
1. используются нативные enum'ы;
2. можно добавить даже к существующим enum'ам;
3. субъективно, оно проще и понятней.
Из минусов:
1. менее ООП-шное решение, возможно, в чём-то менее гибкое;
2. лишние скобочки в синтаксисе, т.к. вместо свойств вызываются методы.
Второй минус в будущем может быть решён, т.к. обещали завезти в язык extension property.
using 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.cs
namespace ExtendedEnumApproach
{
class Employee
{
public string Name { get; set; }
public EmployeeType Type { get; set; }
public Employee(string name, EmployeeType type)
{
Name = name;
Type = type;
}
}
}
Program.cs
using 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)}");
}
}
}
Что за решения через ienumerable+yield?
Енамы с полями?
Проблема move-семантики — в том, что её нельзя делать абсолютной, она должна быть опциональной. Ресурсы должны не только открываться, перемещаться и закрываться — их ещё, как правило, кто-то использовать должен.
А если у нас то структура доступна по ссылке, то делается move — надо как-то следить за временем жизни, тут и до борроу-чекера недалеко.
Каких целей вы добиваетесь мув семантикой в менейджед среде?
Честно говоря, единственное чего мне не хватает в C#, из того, что есть в C++, так это const correctness для value-типов.
Ну молодые идут туда, где перспективы более туманные, либо платят больше, либо и то и другое. Всякий мл, датасаенс, го, фронтэнд на новых фреймворках, старый добрый геймдев - мечта молодых.
Это не делает дотнет менее перспективной менейджед средой.
почти все в додо работают , реклама?
кстати Роман Букин невероятно таксичный человек в Телеги у нас в группе.
Вот вы будете советовать изучать своим детям .NET?
Я - нет.
"У .NET блестящее будущее" - уже 20 лет.
Java мир устоял. Мир PHP/Python не особо заметил.
Место .NET только в корпоративных продуктах Microsoft.
Идти ему вовне некуда.
Да, есть часть программистов которые испытывают Стокгольмский синдром застряв в продуктах Microsoft без возможности перейти на другие платформы.
Какие технологии стоят за пиццериями
— (Фил) В 2011 году .NET не был очевидным выбором. Почему выбрали его?
— Просто наши ребята знали .NET
Идти ему вовне некуда.
А почему некуда? Вы можете писать на дотнете любые программы на любых платформах и без Микрософта.
Место .NET только в корпоративных продуктах Microsoft.
Это только архаическое мнение. Много стартапов, которые используют новые версии дотнета.
ASP.NET Core на первом месте среди Loved frameworks https://insights.stackoverflow.com/survey/2021#technology-most-loved-dreaded-and-wanted
ASP.NET Core на первом месте среди Loved frameworks
Мне кажется, это не очень показательно в экосистеме, где других фреймворков-то и нет.
Это первое место среди всех языков.
Тоесть он более loved, чем какой-нибудь Spring/Flask/Django итд
Поэтому к такой статистике стоит стоит относится осторожнее, думаю если спросить о 1С как фреймворке у 1C программистов у нее тоже может быть высокий рейтинг любви (ибо куда им деться с подводной лодки).
P.S. Это не камень в огород .Net, писал на Spring и .Net и на мой взгляд они примерно одинаковые по удобству и возможностям. Просто не стоить забыть, что есть «ложь, наглая ложь и статистика».
Да, именно это я имел в виду, спасибо. Если сравнивать не с чем, то сильно проще не замечать недостатки.
Во вторых, есть Blazor — тоже web фреймвёрк.
В третьих, раньше ещё существовал ASP.NET Web Forms. И его ненавидели многие. Впрочем, трудно сказать, как много людей из участвовавших в опросе его в живую видело.
В четвёртых, раз уж JavaEE со Spring сравниваем, то можно и ASP.NET с WCF сравнить, пожалуй.
В пятых, посмотрите на результаты Ruby on Rails и Django — их положение в родных языках похоже на положение ASP.NET Core в C#, но они гораздо ниже в рейтинге.
Я так понимаю, традиционный дотнет (не .кор) во-первых сильно постарше, во-вторых, не подходит для тех, кто не привязывается к Винде, чем сильно ограничивает выбор многих.
Блэйзор, кажется, в принципе не шибко распространён (и тоже является решением от майкрософт), ещё и строится поверх дотнеткора. Кстати, я подглядел в википедию - они что, правда думают, что шаблонизаторы с встраиванием кода прямо в HTML-шаблоны в %current_year% - это что-то хорошее? В джаве это лет 6 назад уже считалось плохим тоном и ошибкой прошлого десятилетия.
Вот только в джаве помимо Спринга и ЕЕ фреймворков прямо-таки полно - Quarkus, Micronaut, Play (его, конечно, чаще скалисты используют, но и в джаве бывает), прости господи, GWT, и это только то, что за первую минуту в голову пришло.
Джанго - нет, далеко не такое же положение, вон, там кто-то Фласк вспомнил, и на них вроде тоже не всё заканчивается.
они что, правда думают, что шаблонизаторы с встраиванием кода прямо в HTML-шаблоны в %current_year% — это что-то хорошее? В джаве это лет 6 назад уже считалось плохим тоном и ошибкой прошлого десятилетия.
Тогда вам лучше не смотреть на React, и вообще на современный фронтенд, т.к. в %current_year% это считается стандартом. Blazor просто заменяет JS на C#, по большому счёту.
Вот только в джаве помимо Спринга и ЕЕ фреймворков прямо-таки полно
Вообще, главной моей мыслью было не сравнение ситуации с Java, а то, что шарпистам таки есть с чем сравнивать ASP.NET Core. К текущим решениям Microsoft далеко не сразу пришёл. И альтернативные решения тоже есть. Причина любви к фреймвёрку, точно не в отсутствии у людей другого опыта. На самом деле, всё просто. Это хороший фреймвёрк, с ним приятно работать. И по сравнению с предыдущей реализацией, он стал лучше. Люди видят прогресс. Потому и довольны. Может .NET уступает Java в распространённости, но никак не в удобстве и инновациях.
Еще был фреймворк Nancy.
ASP.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.
Ну не, Nancy ещё был (или есть?). Просто asp.net core реально классный:) я даже не знаю чего там захотеть, кроме дефолт модел байндеров с поддержкой параметрических конструкторов:)
где других фреймворков-то и нет
Я может быть буду не объективен, потому что .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, там сотни и тысячи пакетов сторонних фреймворков.. для всего.
А почему некуда? Вы можете писать на дотнете любые программы на любых платформах и без Микрософта.
Некуда потому, что нет места. Все естественным образом на своих местах.
.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!
Если мы сравним изначально равных программистов с 20 летним опытом (2000- 2020) в мире .NET и в мире Java, то мы увидим совершенно разную изношенность нервной системы.
Может и увидим. Но с моей точки зрения сравнение будет не в пользу Java. Ну если брать именно изношенность нервной системы :)
Гениальная статья Joel 2004 года отражающая суть и сейчас. И которая будет отражать положение дел и через 10 лет.
Вот только на данный приличная часть написанного в этой статье к Java применима не меньше чем к .NET. :)
Уже несколько лет разрабатываю сервисы на .net, которые крутятся в докере, ходят в постгрес и никогда не видели винды. Последнее время сижу в райдере и подумываю о том, чтобы рабочий комп перевести на Ubuntu.
Не вижу предмета для гордости. Прилипли к .NET как инструменту и не можете оторваться от него.
Профессиональному программисту все равно на чем писать.
И выбор .NET чтобы в контейнере на Linux обращаться скажем к PostgreSQL - это какая-то роспись в отсутствии развития как программиста. Понятно что проект исторически и поддержка, но явно не предмет для гордости.
Microsoft. Это достаточная причина сама по себе.
Не только, еще и кардиган красный. И репутация вендора который тебя неизбежно подставит.
Azure открыт для Java и Python и прочих так же как и для .NET.
Low-code, No-code. Работа для программистов MS стека уходит в сам Microsoft и там только и остается.
.NET уже побочная история для Microsoft. Нет никакого профита для Microsoft в успехе .NET.
MS SQL Server уверенно теряет популярность. Azure SQL это совсем другое.
Web - поле не MS. Clouds - поле не особо .NET.
Не вижу драйверов успеха.
Ну это же дичь, и ненависть ради ненависти. Тут еще не хватает лозунга "windows must die!" для полноты картины. В общем обычный пример фанатичного красноглазия.
"Microsoft. Это достаточная причина сама по себе."
Ну это же дичь, и ненависть ради ненависти.
Непредсказуемый бизнес-партнер, себе на уме. Вообще не заинтересован в твоей доле и даже не замечает что ты его партнер. При этом полностью контролирует твои средства производства.
Используя .NET вы так или иначе берете Microsoft в свое дело.
Это не хейт, а боль.
Не только. Еще и вкладчик, требующий свою долю:)
За 15 лет работы в качестве программиста на стеке Microsoft просто тошнит от него. В Java и PHP - меня не тошнит что интересно.
Хороших выходных!
На дотнете писать заметно менее тошно :) И язык, и тулы, и экосистема заметно моложе и делались с учетом ошибок джавы. Так что на джаве доплачивают за вредность.
Вот это вот сообщение имеет здесь 43 лайка. Собственно этим же выражением я и воспользовался. Поэтому посылка к врачу несколько неадекватна.
Обсуждение мне интересно чтобы понять что в головах. Потому как те кто так фокусируется на синтаксисе и удобстве редактора кода для меня инопланетяне.
Или просто кодеры :)
На UX, сценариях и производительности. На создании как можно более тупого, понятного и надежного кода.
При тех же парадигмах и подходах программирования, собственно семантика и синтаксис любого кода не так важны как важно понимание фреймворка и процессов. И здесь что VB что Шарп что Java что Python просто не важно.
Это как на блюде еду раскладывать. В левом углу морковка или в правом. А картошку вот надо обязательно вот так и не иначе.
Все переварится в машинные инструкции в любом случае и важнее что эта еда в себе несет. И где лежит нужная тебе еще одна тарелка.
В этом смысле, уровень и фокус мышления красоты раскладки пищи на тарелке - выносит мой мозг. От зависти.
Вот только вы почему-то забываете, что плохой ЯП, вроде Java без Lombok, активно отвлекает вас от этих самых UX, сценариев и производительности.
А уж задачи создания "как можно более тупого, понятного и надежного кода" в недостаточно выразительном языке превращаются в лебедя, рака и щуку, при этом все вместе конфликтуя с производительностью.
В сложных фреймворках и приложениях где черт ногу сломит
ГДЕ писать код и ЧТО должен делать этот код? Вот это вопросы. Знание фреймворка и процессов.
КАК именно его написать - вот вообще не отвлекает. Хоть из нескольких блокнотов копировать куски заготовок. Какая там выразительность. Цикла или условия? Обьявления, присвоения, вложенности? Красота и изящество оно в дизайне решения, а не в том как именно мы наш псевдо-код из головы запишем на уровне метода/класса. И здесь опыт во многих языках и дает понимание что важно, а что нет.
А в чем польза миксфиксных операторов? Для расширения кода, удобства дебага, производительности?
Если это просто про лаконичность и красоту - мне не понять.
Сложные приложения могут выжить только с максимально простым кодом. То же удобство дебага - важнее на порядок чем одна строчка вместо трех.
Там где в принципе просто (изолированно) и кодерам хочется чувства прекрасного - да, наверное. Чтобы не депрессовали.
Лаконичность, будучи применённой правильно, как раз и даёт ту самую простоту понимания.
Редко такое в моей практике. Писать осмысленные комментарии к коду, не избегать лишних переменных в целях удобства дебага, возможность расширять код без рисков - все это про не про лаконичность.
Простота это когда взгляд струится по коду, а не пытается с третьего раза осмыслить что делает тернарный оператор в тернарном операторе.
А что, тут кто-то предлагает писать вложенные тернарные операторы в одной строке?
Простите. Путь будет
return Человек().ЧастьТела().Потрогал();
Вроде бы и не придраться. И даже понятно. А убить хочется.
Потому что ахтунг, требование - при определенных условиях мужчине нельзя чесать яйца. Надо увидеть входящие условия и таки запретить такой сценарий. При этом добавить параметр на пользовательский интерфейс разрешающий ряду пользователей их таки чесать.
И что мне с той лаконичной понятности?
А вот за код вида ниже буду ставить пиво понимающему ремесло. Все части двигателя должны быть легко видны и легко заменяемы. Делать двигатель красивым кубом - это к инопланетянам.
bool ret;
if (Человек)
{
частьТела = Человек.ЧастьТела();
if (частьТела)
{
ret = частьТела.Потрогал();
}
}
return ret;У-у-у, как всё запущено...
Ну вот, допустим, я виду код в "краткой" форме:
return Человек().ЧастьТела().Потрогал();И мне потребовалось добавить в него новое требование. Забудем на секунду о том, что требование, скорее всего, я буду добавлять в другое место, и предположим что выбранная архитектура говорит добавить его сюда.
Что же мне делать? Неужели я… просто возьму и перепишу код в более полной форме? Почему же вы не можете поступить так же?
А, наверное, переписывание кода в полной форме — это сложный процесс, на который вам нужно потратить время, чего вы делать не желаете, а потому вы… предлагаете тратить время заранее и всегда, независимо от того понадобилась полная форма или нет? Вижу дыру в логике.
Согласен. В правильной архитектуре метод полностью подменяется. Но где правильная архитектура и где корпоративный Microsoft.
Common sense. Какое-то чувство баланса. Собственно пойнт в том, что красота кода в его надежности на которую время не жалко, и лаконичность тут сама по себе - не ценность.
И да, пишу полную форму практически всегда так как это очень экономит время в той же отладке и делает код более безопасным. Но повторюсь что задачи и условия работы у всех разные.
А какое отношение корпоративный Microsoft имеет к языку программирования общего назначения? И почему вообще Microsoft, пусть даже корпоративный, определяет архитектуру вашего приложения?
И да, пишу полную форму практически всегда так как это очень экономит время в той же отладке и делает код более безопасным.
Нет, не делает.
mixfix подход в виде if_then_else_ x y z
вместо классического
IF ()
{
}
ELSE
{
}
не дает приложению никаких преимуществ. Когда мы потом десять раз меняем этот код под новые условия, комментируем код для Source control, то читабельная лаконичность она не является ценностью.
Конечно, где-то это находит применение, но точно не на передовой в окопах.
Спасибо за ответы! У меня нет вопросов. В принципе все понял.
Есть кодеры, есть архитекторы, есть поставщики решений. Есть
написание изолированных компонент, есть расширение спагетти приложений. Все в контексте, есть разные миры.
Любопытство было вызвано давно непонятным мне феноменом
любви (большей) части программистов к закорючкам конкретного языка как бы как любовь к чистописанию готическим шрифтом с красивыми закорючками. Когда сама красота письма для писца важнее смысла самого текста.
Хорошее Computer Science образование оно дает дополнительный слой восприятия над кодом и над конкретным языком.
Исторически сложилось что искусство построения приложений и решений, оно сложилось вне мира Microsoft. Microsoft это продвижение продуктов Microsoft и техническое их использование. Конкретная привязка к продуктам и навязанной архитектуре.
Выпускник с хорошим Computer Science не выберет .NET при наличии выбора. Потому что .NET это уровень техника по обслуживанию. Не инженера.
Восприятие техника оно как раз именно такое. Не парьте меня лишним выбором, дайте мне кнопку. Восприятие кодера где все что от него нужно это код - это закорючки чтобы хоть какое-то удовольствие.
При этом .NET будет жить, никуда особенно не денется. Но идти в .NET при возможности идти в Java или Python - точно не стоит.
Красота закорючек вполне может быть определяющим фактором при прочих равных (вроде интересности проекта, интересности предметной области, и так далее).
Согласен полностью. Спасибо.
Сорта известной субстанции, ИМХО.
Есть некое отношение к языку. К каллиграфии. "Язык" это лишь вывеска на конкретном мире проектов, атмосферы, образа жизни. Как именно написана вывеска, неоном или карандашом на салфетке - не так важно. Именно эту мысль по теме "молодые не идут в .NET" я и хотел и донести.
Те же Java, Python, PHP и прочие, это не языки, это миры.
.NET как мир, это мир военного госпиталя. Как язык - красив, белоснежный и чистый моток марли. До очередных изменений.
почему вы делаете такой вывод
Почти 20 лет работы руками с .NET, MCSD по .NET 2003 года.
Вывод основан на том что Microsoft это не про инструменты для программиста, а про программиста под инструменты/продукты. Абсолютно все определяет односторонне Microsoft, исходя только из своих интересов.
А то что вы называете .NET как язык общего назначения, используя как Java, вне стека Microsoft и его продуктов - это не .NET. Не может быть язык вне мира.
Этот .NET живет не в мире .NET, а в мире созданным по правилам и духом Java, Go, Python и прочих. Как бы уже не свой мир, а высадка на Марсе для жизни под куполом.
Нет желания флеймить, просто IMHO.
Отвечу вашими словами — это кодеры живут в чьём-то мире. Программисты создают свой мир.
В том то и дело. Почти 50 тысяч программистов Microsoft создают свой мир. Бесконечно далекий от мира бизнеса.
P.S. Мир сам в себе. Беда в том, что создание мира - для них бесконечный процесс ради процесса. Это не про дом, а про построили - разрушили, построили - разрушили. При этот не их дом. Они для других их строят.
At Microsoft, 47,000 developers generate nearly 30 thousand bugs a month.
Профессиональному программисту все равно на чем писать.
Тогда почему вы не пиште под .NET? Ну если всё равно?
И выбор .NET чтобы в контейнере на Linux обращаться скажем к PostgreSQL — это какая-то роспись в отсутствии развития как программиста.
Почему? Если всё равно на чём писать, то чем в данной ситуации вас не устраивает .NET? Или Linux? Или PostgreSQL? Или что вас конкретно не устраивает и почему?
Что в этой связке делает .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 присыпанная пудрой. Но если есть соленый ветрами оригинал, то не смысла идти на поводу у программистов для которых синтаксис это программирование.
Что в этой связке делает .NET кроме как использования того это сладко для конкретного программиста/команды?
Так а что принципиально изменится если там вместо него будет Java?
Я понимаю, что обнулили, и .NET Core это уже настоящая Java присыпанная пудрой
Что .NET Core, что Java это одна и та же "пудра". Давно уже. Разве что в .Net денег больше вливают.
Но если есть соленый ветрами оригинал
Привет вам там в ваши 90-е. Нет уже давно никакого "оригинала". И Java уже точно так же дерёт концепты отовсюду. В том числе и с шарпа. А часть вещей в Java ещё даже и дёрнуть не успели.
Эти концепты по сути сахар синтаксический. Которые только программисты и могут на языке ощущать.
Зачем нужен опять инновационный .NET там где уже есть Java, PHP, Python, Go etc фреймворки со всей инфраструктурой и годы кода на все случаи жизни.
Какое-то место у .NET есть. Эти продадут и дохлого осла. Но советовать молодежи изучать и идти в .NET - безответственно. Кнопко-нажимательство и деградация.
Зачем нужен опять инновационный .NET там где уже есть Java, PHP, Python, Go
Зачем нужны всякие Java, PHP, Python, Go и прочие ЯП с "концептами" если есть ассемблер?
Если есть популярные ассемблер фреймворки с библиотеками под web, e-commerce, Warehouse, CRM etc etc то да, не нужны.
Готов рвать 21 прерывание зубами если это позволяет выполнить проект в срок и бюджет.
Так фреймворки и библиотеки это же сахарная пудра. И настоящему программисту всё равно на чём писать. Так что зачем вам всё это? Или вы не настоящий программист?
Фреймворки и библиотеки это соль. То есть именно они собственно инструмент, а не язык. Все равно на чем это когда common sense - программист берет наиболее подходящий инструмент под задачу.
Расширять Microsoft продукты - .NET, под e-commerce PHP wordpress-woocommerce/magento, под свои бизнес сложные - Python Odoo, для работы с PostgreSQL - Java, Python, C, Go.
Не потому что лямбды там или нет на уровне синтаксиса, а потому что value проекта. Идти на поводу комфортной зоны кодеров - платить трижды.
1) Сложность .net выше, чем у python/php, поэтому всякие стартапы и небольшие проекты делаются на них, а не на .net. Плюс раньше, так вообще .net имел бан у стартапов, ибо пока купишь все лицензии — без штанов останешься. Сейчас это вроде как поправили — но осадочек остался.
2) В корпоративном мире айтишных компаний правит Java, которая имеет решение на любой вопрос (ибо столько топовых компаний на ней пишет софт), что полюбому уже все есть. И это все более менее задокументировано.
И естественно, никто не будет переписать софт с Java на .net, ибо зачем — это слишком дорого в плане переученивая кадров и поддержки двух систем.
В итоге, получается вроде бы отличный язык программирования и отличная платформа, но у неё большая сложность и ниже зарплата, чем на сопоставимых стеках. Плюс экосистема имеет определенные вендор-локи, когда есть всего одно подходящее решение для какой-то проблемы, а не 21 (как у Java).
__
Поэтому нет ничего удивительно, что Майкрософт продвигает свои решение (облачные и прочее) не через .net, а через TypeScript (он у них получился удачным и востребованным) и через геймдев.
P.s. естественно .net никуда не уйдет, уже написано слишком много систем на нем, и они будут поддерживаться, развиваться. Какие-то студенты после универа будут писать свои решения на нем и прочее.
Уже откровенно стало понятно, что их идея с .Net Core провалилась в плане продвижения среди разработчиков, ибо при выходе платформы на неё было много взглядов и ожиданий от неё (но платформа оказалос сырой без обратной совместимости и прочее). А сейчас, когда её доделали — уже поезд ушел.
В общем, всем Java пацаны!
Используйте, пожалуйста, свежую статистику от Stack Overflow https://insights.stackoverflow.com/survey/2021, а не прошлогоднюю. Недавний опрос от Stack Overflow показывает, что .NET Core/ .NET 5 и ASP.NET Core стоит на первом месте среди Loved frameworks. За год подняться на первое это уже класс :)
Спасибо за ссылку.
Только в статье приводится статистика наиболее популярных фреймворков, а loved — это другое.
Если смотреть текущую статистику, то там ситуаци поменялась по сравнению с прошлым годом: ASP.NET Core на пятом месте (поднялся с шестого), а ASP.NET – на седьмом (был на четвёртом).
Особенно доставляет то что сам stackoverflow написан на шарпе
"придётся уйти из .NET, потому что он вымирает"... смеялся до слёз ))
особенно после подкастов описывающих изменения в .Net 6...
static abstracts in interfaces например.
p.s. хотя для нового проекта с бэкендом я бы подумал - kotlin vs. c#
Java и Nodejs очень много в контейнерах.
Как C# живет в нативных контейнерах?
Я слышал, что он стал кроссплатформенным, но насколько тяжелее будет запустить микросервис в кубере .NET по сравнению с java или nodeJS?
Если просто небольшой сервис, то далее-далее-далее в мастере создания проекта в ide(поддержка докера включается галочкой) и вот уже всё запускается в контейнере и к этому автоматом цепляется отладчик. Ещё несколько кликов мыши и готова поддержка compose или k8s.
Как в java или js - сказать не могу, но на минималках в .net от открытия в студии до запуска в контейнере несколько минут.
А если вместо студии взять райдер, то может даже меньше минуты, ибо поддержка докера включается одной галкой при создании проекта :)
Ну это если взять как цель "заспидранить контейнеры на дотнете"
Эм, я спрашивал не про сложность создания сервиса, а про тяжелость самого процесса с точки зрения потребления ресурсов.
Все-таки кроссплатформенность java существует многие годы, и рантайм прилично оптимизирован, а .NET в этом недавно
Сравнить не могу - у меня нет опыта с другими языками. Могу только сказать, что на проде оно работает без проблем.
Плюс на habr проскакивала статья в которой показывалось, что даже в Azure у сервисов на .net, запущенных под *nix производительность выше, чем на windows.
Плюс на habr проскакивала статья в которой показывалось, что даже в Azure у сервисов на .net, запущенных под *nix производительность выше, чем на windows.
Вот в этом и дело. Что возможно что сервисы написанные на java/kotlin запущенных под *nix будет производительность еще выше.
Но наверное тут нет смысла вести дискуссию. На простых задачах нечего мерять, а сложные сервисы писать и на java и на C# чтобы просто померять, задача слишком большая для любопытства.
У нас смешанный продукт (часть микросервисов на Java, часть на net).
И сервисы Java доставляют нам в контейнерах сильно больше проблем.
Там из коробки есть поддержка сборки containerd / docker.
Фронтендеры be like:
1)создаём динамически типизированный ЯП
2)делаем свистели перделки в браузере
3)слышим про бекенд, делаем ноду
4)создаём тайпскрипт
5)а теперь кажем .NET не нужно
6)PROFIT. Компилируемый подвид джаваскрипт же гораздо лучше дотнета
И в .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 даст фору любому спрингу по скорости и качеству разработки. (Если только вам не нужно работать с очередями...)
Статья страдает некоторой однобокостью: высказаться дали только тем, кто уже занимается цать лет си шарпом. Это конечно хорошо, потому что люди в теме -- но если вспомнить про то, что опросы в интернете показывают, что 100% участников опроса пользуются интернетом. Вероятно, если высказывались только представители компаний, где оба стека используют - было бы более объективно.
Много ли компаний уровня FAANG (списка Top fortune 500) использует C#? Кто ещё помимо самого вендора готов по-крупному вкладываться в развитие экосистемы?
С аргументацией у некоторых выступавших тоже не всё хорошо. Пример. Когда в си шарп тянутся новички за простотой (которая небесспорна) то это создаёт плохую репутацию языку. Отчего ж когда другие новички прутся в другие языки попроще (не будем показывать пальцами) это им не создаёт такую плохую репутацию? Или тоже создаёт? Тогда видимо не в новичках проблема и не в простоте языка.
Беда с ФААНГ в том что они не молоды и легаси кода у них вагон и маленькая тележка. Само собой код этот на джаве, питоне, плюсах и самописных языках. Большую часть этого кода составляют лютые костыли и велосипеды, от которых только и приходится, что плеваться. C# же молодой язык, поэтому на нем ничего и не написано толком. Хотя есть и в ФААНГ проекты на нем. В гугле например штадия на шарпе, у теслы чего то есть на шарпе, у нетфликса тоже. Теперь и гитхаб пишут на шарпе (хотя это мс теперь, который тоже ФААНГ). В этом плане завидую фронтендерам - вообще ребята не парятся с языками, ведь есть дефакто только один и слава богу. Плюс ко всему им не надо мучиться с легаси, ведь фронт каждый год надо переписывать на новый модный фреймворк и горя не знать.
C# же молодой язык, поэтому на нем ничего и не написано толком
C# вышел в 2001-м. Java старше его всего на пять лет. Проблема скорее в том что долгое время C# был исключительно "языком программирования для разработки под винду".
C# же молодой язык
Ну конечно не плюсы, да, но 20 лет уже прошло.
Плюс ко всему им не надо мучиться с легаси, ведь фронт каждый год надо переписывать на новый модный фреймворк и горя не знать.
Наоборот, у них абсолютно весь код — легаси. Как только вышел в продакшен — всё, фреймворк уже устарел, а может даже сам подход устарел, и надо срочно писать всё совсем по-новому.
А что, кто-то запрещает подключаться к кафке из дотнета?
Это совершенно некорректное сравнение. Вы приводите в пример какие-то специфические узкие задачи, и на основе этого хороните язык и фреймворк, а если разобрать коммент на тезисы, то к каждому будет много вопросов. Например
На Java есть Zookeeper, Kafka, Hadoop, Elastic Search
Это не преимущества языка, а технологии с реализацией на Java, и dotnet имеет официальные клиенты почти к каждой из них. Понятное дело что интеграция с родным Java будет лучше, но это не является киллер-фичей. Более того, сейчас идет тенденция на гетерогенные решения.
для микросервисов есть Go, для простых сайтов — PHP
А тут вы вообще приводите примеры, где за пределами которых эти языки фактически не существуют. Ситуация с PHP вообще интересна тем, что он лидер в отрасли потому "тут так принято", что выражается в огромном количестве дешевых или вовсе бесплатных хостингов php+mysql, и огромной кодовой базе готовых проектов которые надо поддерживать.
на desktop правит бал Qt
Начнем с того что это опять фреймворк, который к тому же ну ни разу не стандарт, а просто единственно что вменяемо выглядит на С++. А во вторых, смерть standalone приложений - это вопрос времени, их нишу займут гибридные веб сервисы, и тут dotnet уже впереди всех со своим Blazor.
что ее живо — игрушки на Unity
Юнити популярен потому что ему нет альтернатив с тем же порогом вхождения. Это не заслуга языка или фреймворка, а разработчиков и маркетологов из UniTech.. и скорее его (языка) бич. На собеседованиях в компании не связанных с геймдевом крайне не рекомендуется упоминать о том, что ты делал игрушки на юнити. Надеюсь не надо объяснять почему.
Смысл мессаджа в том, что быть популярным в какой-то узкой области, не значит являться лидером или быть лучше. В MS вовремя поняли что условия меняются и поезд энтерпрайза уходит, и предприняли верные шаги. Кроссплатформенность, оптимизации производительности, развитие языка и фреймворка.. все это (если они не поменяют темп и курс) поможет им "пройти как моча сквозь снег" и забрать себе жирный кусок пирога.. благо все предпосылки для этого есть.
Логично все. Ждем результатов? Я их 20 лет жду.
Правда в том, что рынок энтерпрайза .NET проиграл. И все остальные направления тоже сдуваются
Согласен с автором данного заявления так как наблюдаю именно это. При этом страшен Microsoft не тем что проигрывает, а тем что стреляет себе в ноги сам. Каждый раз.
Вот ни разу Microsoft не отождествляется с разумом и верными шагами. То есть он шагает но на рынке акций, а развитие языка и оптимизация производительности они успеху акций параллельны. Заплатят паре агенств и PR компаниям и те прогудят что все тип-топ. Вот это важно, да.
На собеседованиях в компании не связанных с геймдевом крайне не рекомендуется упоминать о том, что ты делал игрушки на юнити. Надеюсь не надо объяснять почему.
Эм, надо. Мне не очевидно.
Пропустил ответ в треде, почему-то ушло в спам.
Если мы все еще говорим о начинающих разработчиках, то нужно понимать что Unity подложил нам огромную свинью. В один миг появилось огромное количество "начинающих разработчиков", которых прельстил низкий порог вхождения, который обеспечивает Unity. Они умеют писать простые скрипты с MonoBehaviour Start\Update и делать несложные вещи с GameObject, но на этом их знания как правило заканчиваются.. Для собеседующего это скорее "маркер" о том, что собеседуемый скорее всего имеет поверхностные, кусочные или отрывочные знания.
Это не только мое мнение, я постоянно читаю о подобном мнении на профильных ресурсах.. и это косвенно подтверждается по результатам тех собеседований в которых я участвовал на стороне работодателя. Если я вижу в резюме, что человек претендует на низшую должность в табеле (у нас это "инженер") и делал игру на юнити, то скорее всего он объективно не пройдет собеседование.. потому что его знания не дотянут до проходного минимума. И тут нет хейта или предвзятого мнения, я сам увлекаюсь созданием игрушек на Unity3D и может быть когда-нибудь допишу статью "почему я не закончил порт Lineage2". Вот как-то так.
Большую часть времени пишу на C#, на Java и на Kotlin. На последнем процентов 60 - 70. По моим субъективным оценкам C# эффективнее. Что касается дизайна, C# имеет большой плюс – это нормальные обобщенные типы. По оптимизации C# так же хорош, так как есть типы значений и возможность использовать стек вместо кучи в «горячих» местах. Есть, конечно, надежда на проект Valhalla.
В плане платформы .NET, Microsoft дали слишком большую фору конкурентам, пока сделали ее открытой и кроссплатформенной, лучше поздно чем никогда. В любом случае, все эти языки и технологии вокруг слишком схожи, чтобы беспокоится что какой-то из них будет более или менее популярен.
Молодые не идут в .NET. Правда или нет?