Как стать автором
Обновить

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

и не могу это сделать на .Net (привет web.config, который “по сути” тот же web.xml, только еще и перемешанный с конфигом).

Я вот пишу облачные микросервисы в Azure (serverless и webapp) и чот мне ни разу не потребовалось включать web.config в проект. Всё можно из кода настроить. Пишу под netcoreapp2.0
Максимум для удобства быстрой настройки логирования или параметров приложения вообще (connection strings) подключается app.config (который JSON)

Спасибо за комментарий. Сфокусированность микрософта на своем личном облаке это одна из вещей, которая меня очень настораживает в. net core и почему я не очень верю в его будущее (по крайней мере в российских реалиях). Весь кровавый интерпрайз попытались оставить в старом заброшенном .net 4.6+ и всё переписать заново в core где сегодня csproj (xml), завтра json (который project) а потом опять xml (решили все-таки не выкидывать msbuild), зато в entity framework core банально уже n лет нет lazy loading (т. е. оно не Enterprise ready). Для облаков и микросервисов в них .net core возможно действительно вполне себе ок.

В версии 2.1 уже есть.
Выше уже ответили что еще не зарелизилось.
А как насчет many-to-many отношений?
А как насчет many-to-many отношений?

Так ли велика эта проблема?
Заставляет плодить новые сущности там где они не нужны.
Почему же не нужны? Связная сущность отражает структуру базы данных. К костылям или какому-то неочевидному ужасу в коде не приводит. А уж что лучше: явность или неявность — это дискуссионный вопрос.
Естественно, они этим зарабатывают. Но .Net Core и Azure никак не связаны. Core реально кроссплатформенно (не зря они сделали Linux Subsystem в Win10). А еще поддержка Docker из коробки. Да с EF Core есть проблемы, но учитывая, что он написан с нуля, он взрослеет с каждым релизом. Ну и с выпуском .Net Core платформа переродилась. О ней говорят и пишут больше.
Core реально кроссплатформенно (не зря они сделали Linux Subsystem в Win10).

Как связаны .NET Core и WSL?
Возможность тестировать и писать .net core приложения сразу в Linux. Сразу после анонса WSL появилось много статей как настроить .net core и VS Code в WSL
Возможность тестировать и писать .net core приложения сразу в Linux.
Вы же про нативный докер и прочие специфичные инструменты, которые нормально работают только в Linux-окружении? Иначе разрабатывать кроссплатформенное приложение, используя WSL в качестве референса целевой платформы — это выглядит немного странно, как по мне.
Целевая платформа всё-таки это Linux. Я считаю возможность разработки в WSL одной из причин появления последней.
Да и выбор типа проекта был на стадии RC, с релиза 1.0 тип проекта не менялся.
LazyLoading скорее вреден чем бесполезен и очень хорошо там, где его нет.
НЛО прилетело и опубликовало эту надпись здесь
Сразу скажу, что отношусь к java и java-сообществу, как собратам .net.
И был IIS един и монолитен… да я знаю про Kestrel для .Net Core

Над Kestrel можно и Nginx или IIS в качестве прокси.

Я могу написать web-приложение на Java без единой строчки xml и не могу это сделать на .Net

netcore?
Вот весь xml, который был автосгенерён. Больше трогать его не надо.
<?xml version="1.0" encoding="utf-8"?>
<configuration>
  <system.webServer>
    <handlers>
      <add name="aspNetCore" path="*" verb="*" modules="AspNetCoreModule" resourceType="Unspecified" />
    </handlers>
    <aspNetCore processPath="%LAUNCHER_PATH%" arguments="%LAUNCHER_ARGS%" stdoutLogEnabled="false" stdoutLogFile=".\logs\stdout" forwardWindowsAuthToken="false" />
  </system.webServer>
</configuration>


Есть два основных монстра: EJB и Spring с огромнейшей экосистемой и практиками “вокруг”. В .Net ничего этого нет. Вплоть до выбора нужного DI/IoC-контейнера на вкус разработчика

Очень сомнительный минус, и очень сомнительный плюс.
Вся ирония в том, что некоторое время назад все.нетчики подкалывали джавистов про «программирование на xml». А сейчас этот самый xml остался, как необходимость, как раз в .Net.
Я программирую в .net и не имею необходимости использовать xml.
Что я делаю не так?
НЛО прилетело и опубликовало эту надпись здесь
Кстати, в Visual Studio файлы проектов уже можно писать с нуля руками, как это делается с Maven/Gradle, или там всё ещё чёртов ад, править который без гуя рука не поднимется?
Кстати, в Visual Studio файлы проектов уже можно писать с нуля руками

Уж пару лет как. Не уверен за самую раннюю версию msbuild, которая может понимать сокращённый *.csproj, но чтобы написать webapp какой-нибудь достаточно пару строчек.

И новые PackageReference руками добавляете?
И новые PackageReference руками добавляете?

Ну я вас умоляю, мы ж не в каменном веке. Package Manager'ы же есть.

Причем здесь каменный век, в Java тоже есть пакетные менеджеры и появились они гораздо раньше чем возник тот же nuget. Но вот принято референсы прям в pom.xml руками прописывать. Вопрос привычки и удобства. Поначалу выглядит странновато, но по факту на самом деле оказывается удобней чем отдельный CLI.

В .Net есть варианты (перечислю самые, на мой взгляд, популярные):


  • Отличный GUI в Rider/Visual Studio (и частично через Command Palette в VS Code)
  • dotnet CLI (dotnet add package Newtonsoft.Json)
  • Ручками в csproj (нет подсказок по именам/версиям)
  • Nuget Package Manager (CLI / package.config, который ужасен)
  • Paket (CLI / paket.dependencies, который прекрасен + есть lock файл с транзитивными зависимостями)
НЛО прилетело и опубликовало эту надпись здесь
НЛО прилетело и опубликовало эту надпись здесь
Еще ни разу «матерый дотнетчик с десятилетним стажем» не был так близок к провалу.
Вы слишком токсичны. Но я плюсанул, радуйтесь.
Не поверите, но через CLI, ведь nuget-manager включен в cli tools у dotnetcore:
dotnet add package Newtonsoft.Json

Так же есть выбор добавить через GUI от разных IDE: VSC, Rider, VS.
Есть два основных монстра: EJB и Spring с огромнейшей экосистемой и практиками “вокруг”.


EJB — это не фреймворк. Может быть автор хотел сказать Java EE (Jakarta EE). EJB — это всего лишь одна из спек Java EE

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

EJB это грубо говоря контейнер (я верю что вы это знаете, просто пишу для синхронизации терминологического контекста) и именно альтернативой ему стал в свое время спринг. Это собирательное название для «того что не спринг» и именно эту аббревиатуру обычно не пишут в спринговых вакансиях.

Но концептуально вы правы, наиболее корректно использовать JEE Server (именно эту бирку «лепят» (или лепили?) себе всякие jboss-ы). Или уже правильно Jakarta Server? :)
JEE Server означает, что у данного продукта есть сертификация реализации Java EE. Например, тот же Wildfly имеет сертификацию по Java EE 7, но не имеет по Java EE 8.
С Jakarta пока не понятно, в каком виде будет сертификация и будет ли вообще.
Эталонная реализация Java EE 8 — GlassFish 5.0.
Всем, кто переходит с VisualStudio, советую только IDEA. Когда переходил (очень давно), думал что умнее студии ничего нет, но IDEA приятно удивила и продолжает удивлять до сих пор. И ReSharper от тех же JetBrains, которые делает студию умнее и удобнее, тому подтверждение.
В .NET выбор очевиден — Visual Studio.
Как же Rider?
Отсутствует бесплатная версия, аналогичная VS Community
Это имеет мало значения, если большинство компаний и так покупает платную студию, да еще и решарпер. Idea с поддержкой всякого EE тоже стоит денег, если сравнивать. Тем более, что это единственное адекватное решение для .NET-разработки из *nix.
Для Rider есть достаточно милая инди-лицензия, позволяющая разрабатывать на ней хоть лично для себя, хоть чужой лютый интерпрайз (проблемы совместимости я обнаружил только для некоторых T4-шаблонов, но это специфика).

Это только до тех пор, пока не покупается решарпер.

Скорее всего схвачу минусов (на хабре культ Jetbrains), но это хайп. Да еще и платный.
Я года 3-4 работал с VS Community и ни одной мысли о Pro не возникало — хватало всего что есть. А в Idea Community со спрингом нормально работать невозможно — сделано всё чтобы люди платили деньги.
Я года 3-4 работал с VS Community и ни одной мысли о Pro не возникало — хватало всего что есть.
Вы/организация точно не нарушали Community-лицензию при этом? Ведь при желании можно и райдер «покрякать» и считать бесплатным.
А решарпер (который всего на $10 дешевле райдера) вы тоже принципиально не используете?

сделано всё чтобы люди платили деньги.
Вы так говорите, будто это что-то плохое. Коммерческая фирма делает качественные инструменты и просит за это деньги! То ли дело MS, которая выпускает эсклюзивную Visual Studio для своей платной операционной системы!
Не нарушал я ничего, речь идет о домашнем компьютере и pet-проектах. Visual Studio Community хватает «на всё что угодно» (в отличие от ужасающей Express которая была ранее давно). А вот в IDEA Community жадинки отрезали использование спринга с бутом, что отвратительно и неприятно.
Не нарушал я ничего, речь идет о домашнем компьютере и pet-проектах.
Там может каждый делать то, что ему вздумается. Я все же про прямое назнчение инструментов — интерпрайз. MS молодцы, конечно, но у них такие меры — не от лучшей жизни.
Вопрос про решарпер все так же актуален.

А вот в IDEA Community жадинки отрезали использование спринга с бутом
Вам maven там тоже отрезали?)
Что же это за контейнер такой, которым без специальной поддержки от IDE пользоваться отвратительно и неприятно?
Почему-то все забыли про NetBeans IDE. А в ней достаточно инструментария для создания Java9 и Java EE 7- приложений, которые можно тут же в среде тестировать в GlassFish 5.x и WildFly 12, собирать метрики и протоколы обмена (http-monitor), а maven является родным форматом организации проектов на Java. Интегрированы Git и Mercurial-плагины (используют внешние git и hg) для прозрачного сохранения изменений в коде — можно буквально щелчком мыши откатиться на определённый коммит в истории изменений.
Что именно там отрезали от сприг бута?
Почему тогда у меня проекты на спринг буте прекрасно работают в IDEA Community?
Почитал лицензию. А что трактуется под «одновременным использованием»?
НЛО прилетело и опубликовало эту надпись здесь
Это утверждение ложно
Внезапно. Под Linux тоже версия данной IDE есть?

JetBrains Rider для индивидуалов без решарпера стоит 139$ в год пруфлинк + Linux = 7 942 рубля, Windows 10 Home стоит 5 500 руб пруфлинк + Visual Studio Community = 5 500 руб
… и еще решарпер сверху за $129 (=
НЛО прилетело и опубликовало эту надпись здесь
МС с удовольствием сделали бы версию под Линукс, но пока не могут — слишком долго портировать такого монстра.

Очевидно, что если бы MS не сделало бесплатной студию, то с таким подходом рынок они бы потеряли уже в обозримом будущем.

он может стать основным продуктом из семейства Visual Studio

Но он не станет Visual Studio (= Начало конца уже положено в его технологических основах.
VS Code к VS имеет такое же отношение, как слово «котлета» к «коту». Не позволяйте бренду смысл затмевать, а то так еще можно случайно сказануть, что есть студия на мак.
Цифры действительно не лгут. А вот люди их применяющие их, вполне могут…
Да, я знаю про jOOQ, но ни разу не видел его использование хоть в чем-то, напоминающем продакшен. Возможно потому что это полу-платный новодел без JSR, возможно по другой причине.


В защиту jOOQ'а скажу, что во всю используем в продакшене энтерпрайза: гораздо очевиднее, чем JPQL/Criteria Builder, а в сочетании с правильной готовкой миграций даёт управляемую работу с БД. Почему-то JPQL/Criteria Builder считают, что разработчики не могут в SQL, поэтому предлагают навернуть абстракций там, где можно обойтись понятным и проверяем (во время компиляции) кодом.
Есть вариант с iBatis/MyBatis для любителей SQL. И Spring Data для сильно нелюбящих. Довольно много в последнем запросов можно просто сделать названием методов.
И Spring Data для сильно нелюбящих. Довольно много в последнем запросов можно просто сделать названием методов.

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


Контейнеры головного мозга
По моему опыту отсутствие контейнеров в .net — это говнокод в 90% случаев. Статистика. :)
Говнокод — это не отсутствие контейнеров, а неосиливание DI.
Карго-культ контейнера от этого не спасает.
НЛО прилетело и опубликовало эту надпись здесь
Да и тенденции в мире также смотрят в сторону .Net ...

Это какие например?
C# куда как продуктивнее Java.

А что под этим подразумевается, можно поподробнее?

Нормальные генерики (существующие и в рантайме), непримитивные типы-значения, много меньший объем синтаксического словоблудия, LINQ.
Ни одно из слов к продуктивности не имеет отношения.

… к продуктивности программиста? Я не соглашусь, дженерики сильно на это влияют, expression trees — тоже.

Можете мне привести пример частого использования expression trees в кровавом энтерпрайзе? Мне действительно интересно.
Последний раз я их ковырял когда правил форк от ORM и больше «с ходу» не припомню необходимости.

Про дженерики тоже холиварный вопрос, в джаве они есть, причем с неплохой ковариантностью-контрвариантностью из коробки, ala
List<? extends A> myList1
List<? super B> myList2
Ну да, type erasure. Сейчас минусаторы набегут, но в большинстве повседневных задачах он не мешает.

Мы же про продуктивность? Почему не вспоминаем про тот же Lombok
@NonNull
@AllArgsConstructor
@ToString
@EqualsAndHashCode
Getter/@Setter

Вот это про продуктивность. И никакого бойлерплейта.
В дотнете такое возможно огромными костылями ala Postsharp (который почти загнулся из-за платности / заметно возрастающего времени компиляции), ну или Fody (который тоже не оч.популярен). Появилось ли что-то похожее в .Core?
Не, это не про продуктивность. Про продуктивность в Java — Kotlin :) И его я тоже больше 2х лет использую в продакшне в энтерпрайзе. Там все эти костыли не нужны.
Можете мне привести пример частого использования expression trees в кровавом энтерпрайзе?
Составление фильтров.
Можете мне привести пример частого использования expression trees в кровавом энтерпрайзе?

LINQ, AutoMapper, FluentAssertions. Мы вот у себя только что маленький внутренний движок критериев на expression tree сделали.


Почему не вспоминаем про тот же Lombok

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

Разве что LINQ принимается :)
Да и-то в качестве «запросов к БД» или куда-либо ещё.
Что автомаппер что FluentAssertions, что Linq2Objects на простых лямдах достаточно нормально отжимаются.
Разве что LINQ принимается

Вы просили пример использования — вы их получили. То, что это можно сделать иначе — понятное дело; но это не значит, что иначе сделать удобнее.


Что автомаппер что FluentAssertions, что Linq2Objects на простых лямдах достаточно нормально отжимаются.

И как вы из простой лямбды получите описание провалившегося assertion?

Почему не вспоминаем про тот же Lombok
Getter/@Setter

… так в C# это не нужно уже черт знает сколько, auto properties же.


@NonNull

С nullability планируют расправляться намного более системно.

Ну не черт сколько, возможность на авто-пропертях делать readonly setter появилась достаточно недавненько.

Плюс если вспомнить любимого Рихтера, то он ненавидит проперти со времен первого издания своей книги про CLR и говорит что стоит явно писать методы, которые не несут «многозначности то-ли переменная то ли метод» :D
Но это я уже подтроливаю немножко, да. Еще Рихтер везде sealed рекомендовал, помнится.
Ну не черт сколько, возможность на авто-пропертях делать readonly setter появилась достаточно недавненько.

Ну так никто все сразу и не обещал.


Плюс если вспомнить любимого Рихтера, то он ненавидит проперти со времен первого издания своей книги про CLR

Это вопрос вкуса.

НЛО прилетело и опубликовало эту надпись здесь
Хоспадя, причем здесь F#
НЛО прилетело и опубликовало эту надпись здесь

Что характерно, вопросов, причем тут котлин, не возникало.

Хоспадя, причем здесь F#

Я сам из тех, которые на F# лепят.
Он очень даже при том.


Получаете кучу бонусов в языке, синтаксисе, системе типов, но теряете немного в IDE (Visual Studio днищенски поддерживает F#, VS Code — норм, Rider EAP 2018.1 уже тоже норм), в тулах (нет ничего подобного R#, но учитывая что язык гораздо менее бойлерплейтный и защищает от ошибок намного сильнее, надобность уже не та. Так же нет нормальных декомпиляторов, если dotPeek'ом тыкаться, получаем бесплатную обфускацию)


А главное dll те же, dotnet xxx.dll всё так же работает, поэтому хоть в Azure, хоть в AWS Lambda заливается абсолютно одинаково.
Ну и если чо, компилятор и темплейты проектов F# в .NetCore SDK уже встроены.


Поэтому встречный вопрос:
А почему не F#?

Можете почитать мою статью про кодогенерацию. Там не то, что AllAgrsConstructor можно определить, но и вообще все что угодно, включая создание и использование новых токенов.
Почему не вспоминаем про тот же Lombok

Потому что инструменты с вплетением байт-кода есть и для дотнета: от Fody до PostSharp.
Для NotNull в дотнете хватает системы типов (благодаря тем самым, не имеющим отношения к вашей личной продуктивности, генерикам и структурам): я, например, просто могу писать NotNull<T> и это будет та же самая ссылка на класс без оверхеда, но с гарантией, что null там нет.


с неплохой ковариантностью-контрвариантностью из коробки

Согласно Джону Скиту, это единственное преимущество языка Java над C#.


в большинстве повседневных задачах он не мешает

Ну да, конечно. Если я в параметре конструктора укажу IEnumerable<TypeName>, то дотнетные контейнеры автоматически подставят мне все зарегистрированные реализации для TypeName.
В яве это не сработает по построению. Именно поэтому явовские контейнеры на фоне дотнетных смотрятся убого.
Если потребуется оптимизация по аллокации памяти в куче, в яве придется делать специальные алгоритмы с использованием только примитивных типов.


Getter/@Setter

В дотнете для этого костыли не нужны — все уже есть прямо в языке.

Вообще-то сработает, как минимум в Spring с этим проблем нет и это используется.
А работает это потому, что несмотря на type erasure, информация о типах вполне себе доступна в runtime, через reflection.
.Net Core это попытка выкинуть платформу, разрабатываемую 15 последних лет и переписать/переосмыслить всё заново. Насколько эта идея может быть успешна в нынешних реалиях, покажет только время.
Но то что большинство текущих проектов на .NET (не Core) внезапно стало Legacy — это факт.
НЛО прилетело и опубликовало эту надпись здесь
Ох, какая холиварная пятничная статья :)
В .Net ничего этого нет. Зато есть изобретение велосипедов “в каждом проекте по-своему”. Вплоть до выбора нужного DI/IoC-контейнера на вкус разработчика (если разработчик вообще в курсе про существование контейнеров) и решение как управлять транзакциями (если разработчик опять же знает, что такое транзакции и кто-то догадался отключить автокоммит на Sql Server-е). Разве что ASP.NET MVC немного похож на Spring MVC (который лишь малая часть Spring Framework).

.Net Core принес встроенный DI, который покрывает 95% нужд. И что вообще плохого в выборе DI/IoC-контейнера самостоятельно из существующих? Лучше иметь одну прибитую гвоздями реализацию?

Про транзакции немного не понял, их управление строится через конфигурацию ORM, как и в мире Java. Или речь о распределенных?

Опять-таки .Net Core предлагает многое, из того, что есть в Spring Framework (если, конечно, описание его состава на википедии не врет). Не все, но многое. Остальные вещи можно найти, установить и «подружить».

И был IIS един и монолитен. И поняли Микрософт, что System.Web это плохо. И придумали OWIN.

OWIN дал возможность более гибко и прозрачно конфигурировать пайплайн http-запроса через middleware.

В общем, на вкус и цвет — фломастеры разные.
Наконец-то принес, спустя 15 лет. Минусов «выбора» масса — в одном проекте Unity, в другом — Autofac, в третьем StructureMap, а в четвертом NInject — и все они различаются в API и при этом одинаковые на 95%. Здесь огромный плюс джавовских JSR виден, надеюсь, всем.

Транзакции — скорее про аннотацию @Transactional.

OWIN еще и Embended Server дает. Еще немного, и Микрософт придумают свой H2 (или уже придумали?).
в одном проекте Unity, в другом — Autofac, в третьем StructureMap, а в четвертом NInject — и все они различаются в API и при этом одинаковые на 95%. Здесь огромный плюс джавовских JSR виден, надеюсь, всем.

В том же ASP.NET MVC адаптируются в IDependencyResolver.
В том же ASP.NET MVC адаптируются в IDependencyResolver.

Опускаясь на уровень этого интерфейса все эти контейнеры полностью теряют уникальные фичи (Ninject — auto discovery, SimpleNinject — проверку на собираемость и т.д.) что делает наличие такого большого кол-ва реализации контейнеров бессмысленным.

А джавовые стандарты этой проблемы лишены?

Не теряют. Этот интерфейс — он для потребителя, вам ничто не мешает использовать уникальные фичи в composition root. Более того, скажем, у Autofac есть всякие милые штуки типа Func<T> и Lazy<T>, которые и на стороне потребителя видны.

Контейнер — это всего лишь инструмент для декларативного описания точки сборки, его замена в нормальном проекте — чисто техническая, причем несложная задача.
Если для в вашем проекте контейнер лезет куда-то еще, значит ваша команда не осилила DI.
Аннотации — магия из каменного века и антипаттерн.
Явовские контейнеры после дотнетных ужасны.
Composition Root оно называется и подобным образом на русский язык не переводится.
Точка сборки — это к Кастанеде Карлосу ;)

Явовские контейнеры можно конфигурировать кучей способов (сходу назову штук 5), при этом бут добавляет удобную авто-конфигурацию «из коробки». Не будьте столь категоричны, это неконструктивно и неприятно читать.
Для сборок еще кое где встречается старый добрый ant.
К счастью не застал :)
Вставлю и я свои 5 копеек. Всю жизнь был .NET developer, иногда хотелось поработать с Java, узнать как там и у них и перейдя в новую фирму стал больше Java Developer чем .NET. Что сразу бросилось в глаза:
1) IntelliJ лучше чем Visual Studio. Хотя VS+ReSharper стирает все преимущества IntelliJ, но всё же ReSharper добавляет свои проблемы (не знаю исправили баг или нет, но RS очень не любит WPF и в нашем проекте, плагин для VS, у нас почти все xaml.cs файлы были красные из-за того, что он не видел зависимости или что-то в этом роде), IntelliJ свои баги, тоже есть, но всё же для меня IntelliJ было приятным открытием
2) Очень неудобная настройка билдов (maven). Кроме того, что это огромные файлы xml, так в той же intellij нет(либо я не нашёл) GUI для управлением этим файлом и чтения зависимостей. Gradle почти тоже самое, правда все же файлы не такие огромные
3) Как же плохо без дефолтных фреймворков. Что я имею ввиду — огромное количество разных orm, библиотек логирования и т.д. Кому-то это плюс но в корпо это ужас ибо работаешь с разными программистами, с разных стран, у всех свои стандарты и пожелания. В итоге в проекте у нас 3 библиотеки для логов, ибо каждый вбил что хотел в свое время, используется MyBatis который конечно быстрый, но неудобный и вообще Spring Boot сейчас уничтожает все апгрейды у нас в проекте, потому что у нас Spring 3, сделали апдейт до 4, а дальше уже тяжело, ибо нужны новые версии зависимых других библиотек, а они все почти уже имеют настройки под Spring Boot. Ясно, что можно и под обычный настроить Spring, но если нет документации, то на это уходит много времени. Как пример — сейчас нам надо сделать Gateway и мы такие обрадовались, ведь в Spring Cloud появился как раз Gateway. Только фигушки нам ибо зависимости идут на Spring Boot и нет ещё статей на тему как поставить это на обычный Spring. К тому же очень мало статей на тему hello world в spring security на обычный spring. Найти конечно можно, но всё равно большинство под Spring Boot. В итоге сейчас думаем, что надо переноситься на Spring Boot 2, но у нас там столько зависимостей и не факт что все они имеют апдейт до SB2 и Spring 5. Вообщем ад и в .net даже близко такого не было никогда. В .net уже очень давно есть WCF и IIS, которые бы решили нашу проблему
4) Закончу на положительной ноте для Java — open source. В той же IntelliJ можно найти имплементацию любого метода и даже в дебаг кинуть. В .net core была подобная возможность, дебажить исходники, но потом почему то убрали и сделали фигню, которая работает только в call stack, а вот если просто нажму open implementation на системном методе, то мне покажет только методанные. Вообщем огромный плюс Java

Если я в чем-то не прав то пожалуйста напишите об этом, буду рад любой информации

rider нынче позволяте дебажить чужие исходники

В своё время со spring security здорово помог разобраться цикл статей отсюда. Они актуальны и для 4-го спринга: http://krams915.blogspot.com/search/label/Security?m=1

Очень неудобная настройка билдов (maven)

В idea есть maven plugin, который позволяет удобно выполнять частые операции с maven, поддерживает профили и т.д. Файлы xml maven хоть и часто большие, но однообразные и простые по структуре. Это отличается от xml в мире .net, где из-за сложности пришлось сделать графическую утилиту. Как правило в pom копируется зависимость и забывается, idea же при редактировании подсказывает синтаксис и проверяет ошибки.
Как же плохо без дефолтных фреймворков

Вам в помощь Spring Initializr (https://start.spring.io/). Выбрали нужный функционал, который нужен в проекте, нажали Generate и уаля у вас на выходе проект, который сразу запускается и содержит все что нужно.
Это отличается от xml в мире .net, где из-за сложности пришлось сделать графическую утилиту.

У вас устаревшие сведения. cproj нового образца и маленькие, и простые.

Да, устаревшие и я рад что сейчас на .net тоже это поменялось. Но я отвечал на комментарий, в котором упоминалась GUI для конфигов, видимо автор комментария переезжал с устаревшей версии
GUI при этом никуда не делся и прекрасно работает.
Я пользуюсь и тем и другим — смотря что удобнее по ситуации.
Так что у дотнета преимущество в обоих случаях.
Так что у дотнета преимущество в обоих случаях.

Не у дотнета, а у одной конкретной IDE (VS) над другой конкретной IDE (Idea) в конкретном вопросе (GUI для редактирования конфигов). Да и то преимущество спорное, на любителя.

Именно что у дотнета.


  1. Новый формат cproj — это все тот же msbuild (а не ide), замены которому де-факто нет.
  2. "Конкретная IDE" является лучшей и господствуещей на рынке разработки для платформы.
  3. Инструменты для явы почему-то никто от самой явы не отделяет — логично и с дотнетовскими поступать так же.
НЛО прилетело и опубликовало эту надпись здесь
Да, я знаю про jOOQ, но ни разу не видел его использование хоть в чем-то, напоминающем продакшен.

Есть Querydsl, использовал в продакшене и не могу нарадоваться. Ещё есть Jinq, но с ним я только игрался и идея использовать его в продакшене мне кажется сомнительной. Причина — использует сериализуемые лябмды, что накладывает множество ограничений (лучше анализировал байт-код лябмд с помощью какого-нибудь инструментатора/класслоадера).


Возможно потому что это полу-платный новодел без JSR, возможно по другой причине.

JSR не панацея. На спринг есть JSR? А, скажем, для логгирования используют log4j/logback/slf4j вместо стандартного (JSR) java.util.logging.

Работал с asp еще до того как был .net, потом с monorail, потом с asp.net mvc и asp.net core, тоже недавно перешел проект, где один из сервисов на Java и spring boot, остальные C# asp.net core.


Впечатления в радикально отличаются от впечатлений автора:


VisualStudio vs Idea


  • VS (даже с R#) гораздо стабильнее и быстрее чем idea, по крайней мере на моих маленьких проектах
  • в VS не нужна кнопка invalidate caches and restart, за много лет использовал сброс кеша R# один или два раза, в idea при переключении веток и редактировании зависимостей gradle регулярно ее использую

при переходе С# => Java очень напрягает:


  • отсутствие var, async/await, linq, extension methods и class properties
  • местами очень недружелюбный api библиотек
  • type erasure, не предполагал что так быстро с ним столкнусь
  • checked exceptions, не ощутил пока особой пользы

при переходе asp.net => spring boot:


  • аннотации везде и для всего, причем не везде даже с compile time checking
  • неявный DI, аннотации для регистрации
  • отсутствие nuget install-package и UI к нему

не могу согласиться с:


Впрочем, адекватные альтернативы IIS под Windows от этого не появились (да я знаю про Kestrel для .Net Core).

selfhosted asp.net webapi можно было писать и до .net core, хочешь запускай как консольное приложение, хочешь как win service с TopShelf например, отличный вариант для новых приложений который не зависят от возможностей IIS


Только спустя 15 лет в Микрософт поняли, что это хорошо и пора перестать диктовать миру “как правильно жить”

у меня сложилось впечатление что это в spring boot мне диктуют как правильно жить, как иcпользовать DI, как называть разные lifescope и тд


Я могу написать web-приложение на Java без единой строчки xml (привет Spring Boot), и не могу это сделать на .Net (привет web.config, который “по сути” тот же web.xml, только еще и перемешанный с конфигом).

пара очень простых и легко читаемых файлов в проекте напрягают гораздо меньше чем gradle config, хотя он и не xml

у меня сложилось впечатление что это в spring boot мне диктуют как правильно жить, как иcпользовать DI, как называть разные lifescope и тд

Так никто же не заставляет использовать Spring Boot, тем более на него нет JSR. Можете использовать любой другой фреймворк, коих довольно много. И это отличается от ситуации с .net, который до недавнего времени был закрытым и фактически был прибит гвоздями к Windows (энтузиасты из Mono не в счет). И хорошо, что сейчас все по другому, но почему бы не сделать этого раньше?
На самом деле весь спор решается наличием вакансий на ту или иную платформу в вашем регионе. Вокруг меня количество работы на Java стремится к нулю, зато .Net цветет и пахнет.
Сложно не согласиться, но вокруг меня ситуация прямо противоположная. И у автора статьи, похоже, такая же.
Рынок диктует условия. Я в универе яву учил… А потом пошел вакансии смотреть и резко пришлось платформу сменить. Так что мы все тут в одной корзине.
В статье нет самого главного, чем JVM сильно проигрывает .Net — это Type Erasure.

Подобное в JVM без костылей не сделать:
class Foo: IProcessor<A>, IProcessor<B> {
   void Exec(A arg){
   ...
   }

   void Exec(B arg){
   ...
   }
}
т.к. во время компиляции void Exec(A arg) и void Exec(B arg) превратятся в void Exec(Object arg) и мы получаем конфликт между двумя методами с одинаковой сигнатурой. Можно создать явно интерфейсы IProcessorA и IProcessorB в которых будет указана сигнатура, не имеющая generic type аргументов, но этот workaround мешает компоновке библиотек, т.к. появляется зависимость на конкретный интерфейс для конкретного аргумента generic типа (IProcessorA — A). А это значит, что все, кто захотят поддерживать интерфейс IProcessor, должны заранее договориться использовать общую сборку в которой лежит IProcessorA. А теперь представим, что есть N независимых разработчиков, не знающих друг о друге, объявивших в своих библиотеках свой IProcessorA…
Есть решение через полиморфизм, но это в свою очередь осложняет жизнь тем, что в каком-то месте вам нужно указать все поддерживаемые типы-наследники. Что также является антипатерном. В общем, из одной ловушки в другую.
Подробнее тут.

Можно привыкнуть к новой IDE, освоить новый язык, потратить многие месяцы на изучение нового технологического стека, но один лишь факт того, что в языке нет полноценной реализации такой базовой штуки как Generic Types, означает, что постоянно будет ощущение неполноценности разрабатываемого кода, по сравнению с аналогичной реализацией на .Net.

Пробовал программировать на Kotlin (на мой взгляд, у языка прекрасный синтаксис), но описанная выше проблема сводит его преимущества перед C# на нет.
постоянно будет ощущение неполноценности разрабатываемого кода

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

Да уж дженерики в яве сделаны отвратительно, я не могу понять почему выбрано такое странное решение.
Обратная совместимость на уровне байт-кода — иначе старые JVM не смогут в новые дженерики, а они дорожат запуском нового кода в рарихетных рантаймах.
а может добавить ключ компиляции и дать возможность мне самому решать нужна ли мне эта обратная совместимость или нет?
Тогда все сразу забьют на поддержку старых версий)
Когда это решение принималось, то это было самым простым решением. Сейчас же менять это уже поздно, и ОЧЕНЬ дорого.
В .NET выбор очевиден — Visual Studio.

Как же VS Code для .net core? Rider?
В высоко нагруженных проектах с mssql и радостным linq, когда начинаешь разбираться в миллионе планов, безумном их трафике и удивительной их параметризации, понимаешь, что это далеко не преимущество и так делать не нужно. Что значит отключать автокоммит инструкции и главное зачем?
Прочитал про LINQ. Интересно, хоть и дико для джависта видеть SQL в переменных.
Там есть другой вариант — использование лямбд, с которыми (если привыкнуть) код запросов становится совсем коротким, хоть и теряет в читабельности.
Почему теряет в читабельности?
Кому-то SQL-подобный синтаксис проще читать, он более «самодокументируемый».
Любой код самодокументируемый, потому что иначе оно бы не работало.

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

Очевидно, нет.


потому что иначе оно бы не работало.

Для того, чтобы код работал, читаемость не обязательна.

Ок, не так выразился. LINQ-код не более и не менее понятен, чем аналогичный SQL почти всегда.
Может я, конечно, ошибаюсь. Но мне кажется, мы недопоняли друг друга и говорим о разных вещах. Я говорил о том, что есть 2 формата записи LINQ (примеры чисто академические):
1) SQL-образный
var selectedUsers = from user in users
                    from lang in user.Languages
                    where user.Age < 28
                    where lang == "английский"
                    select user;

2) С использованием лямбд
var selectedUsers = users.SelectMany(u => u.Languages,
                            (u, l) => new { User = u, Lang = l })
                          .Where(u => u.Lang == "английский" && u.User.Age < 28)
                          .Select(u=>u.User);


Причём запросы могут формироваться, как LINQ for Objects, так и LINQ for Entities. Первое — для коллекций, второе — для ORM, что в итоге преобразуется в банальный SQL запрос для СУБД.

И то и то LINQ, просто у него 2 формы записи: query linq и method chain linq. Первый вариант иногда читаемее, а иногда нет. Например типичный запрос выглядит так:


var foo = mytable.Where(x => x.Foo == 1).Select(x =>x.Bar).FirstOrDefault()

В виде query получается немного нелепо.


А я изначально подумал что вы в прямом смысле про SQL в шарпе:


var foo = mytable.Query<Thing>("select * from Thing where Name = @Name", new {Name = "abcde" });

Насколько это читаемее — вопрос

Джава очень уж многословна по сравнению с шарпом. В нее автопроперти-то завезли наконец?

Недавно завезли var, что должно уменьшить многословность. Автопроперти делаются с помощью аннотации над классом (с Lombok). Но многих это несильно волнует, т.к геттеры и сеттеры генерятся легко в любой IDE.
геттеры и сеттеры генерятся легко в любой IDE

Претензия не в том, что геттеры/сеттеры сложно генерировать, а в том, что по сравнению с .Net наблюдается увеличение объёма кода. Вместо одной сущности — автосвойства, три — переменная + геттер + сеттер.
Как я и писал выше, для уменьшения кода применяется Lombok. К классу добавляется аннотация и после этого у всех полей появляются сеттеры и геттеры (при этом в коде класса их явно нет). Если и это напрягает, никто не мешает использовать Котлин )
Вплетение байт-кода вместо нормальных языковых средств — магия и костыль.
Гоферы с тем же успехом ссылаются на прости господи кодогенерацию.
В мире джавы мало кого смущает и генерация сеттеров IDE и Lombok, в котором магии не больше чем в Spring. Но, как уже писал выше, никто не мешает использовать Котлин, которые в обе стороны совместим с Джавой, и в котором есть все что нужно. Но, возможно, сейчас и тут напишут про проблему с дженериками.

В дотнете Fody тоже никого не смущает.
Но никто не делает вид, что вплетение кода заменяет имеющиеся языковые средства задаром.
А котлин мне очень нравится.


Но, возможно, сейчас и тут напишут про проблему с дженериками.

Такова жизнь. В JVM JIT и сборщик мусора лучше дотнетных. Но нет генериков и непримитивных типов-значений.

Больше 2х лет использую JOOQ в банковском (и похожем) энтерпрайзе.
НЛО прилетело и опубликовало эту надпись здесь
Причем здесь VSCode? VSCode это переосмысление Atom-а и Sublime, которое действительно выстрелило. VS код действительно очень крут и опенсорсен.

PnP в конечном итоге извергло из себя Unity (не движок для игр, а контейнер), которое преподносилось в ~2010 как супер ноу-хау в т.ч. в живых семинарах в Мск. Это было как минимум забавно — ничего нового, но пафоса горы.
НЛО прилетело и опубликовало эту надпись здесь
В каком месте-то?)
1. В .NET нет нормальной платформы для разработки ентерпрайз приложений.
2. 15 лет микрософт «в одно рыло» делал изменения в языке и .NET Framework.

И-то и то верно, вы с этим спорите что ли?
В .NET нет нормальной платформы для разработки ентерпрайз приложений.

Define "нормальная платформа".

a la Spring.
Ну то есть оригинальное высказывание было «В .NET нет Spring». Ну, возможно. Только не все вообще в курсе, что это.
Ну его действительно нет. Были давным-давно попытки a la Spring.NET, но оно разбилось об отсутствие Community.
Конструктивней в данном треде, увы, вряд ли получится, здесь какая-то атмосфера нездоровая — сплошные переходы на личности с двоемыслиями, define и т.д. Неинтересно.
Может просто стоит обосновывать такие громкие утверждения? В стиле «В дотнете нет Spring поэтому ынтырпрайз на нем не написать».
Если вам действительно интересно, зайдите на сайт спринга там есть features projects.spring.io/spring-framework оно всё вместе работает «из коробки». В .NET я не знаю фреймворка такого уровня зрелости (только десяток более мелких ежей-ужей которые постоянно приходится скрещивать).

А если посмотреть на спринг.клауд, projects.spring.io/spring-cloud то его фичи это вообще космос, вообще не знаю ничего похожего для .NET.

Один фреймворк для всего?
Спасибо, не надо.
Вдобавок у комментатора с опытом здесь же https://habrahabr.ru/post/352404/#comment_10732666
мнение про Spring слегка отличается от вашего.

Справедливости ради, Spring это не «Один фреймворк для всего».
Это множество библиотек и фреймворков, решающих различные проблемы построения приложения и разрабатываемых в схожем стиле для облегчения интеграции между собой. От базовых типа DI, до продвинутых типа Cloud.
НЛО прилетело и опубликовало эту надпись здесь
В .NET есть аналоги, но не прижились они.

Как не прижились?
Fody жив-здоров, чего и вам желает.
PostSharp на этом вообще деньги зарабатывает.
Ну и масса библиотек над Castle.DynamicProxy

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

А к примеру в том же спринге в разделе про Data — с этого всё начинается docs.spring.io/spring/docs/current/spring-framework-reference/data-access.html

Я сам прошёл путь от оголтелого отрицания «платформ» до понятия их необходимости в корпоративной среде. Позволяет не ходить по одним и тем же граблям разными путями в разных проектах.
НЛО прилетело и опубликовало эту надпись здесь
АОП не обязан (и по умолчанию не является) частью процесса сборки. JCA — Java Crypto API. Наверняка в дотнете есть аналогичный механизм— общее API для всего шифрования. JMX даёт не только телеметрию, но и возможность отправлять/получать данные как RPC примерно. JMS тянет за собой ещё и поддержку XA-транзакций на все JTA-compatible источники данных (ну то есть как минимум JDBC и сам JMS).
НЛО прилетело и опубликовало эту надпись здесь

Вы на редкость самокритичны.

Это не определение. Если вы хотите сказать, что ничто кроме Spring — не нормальная "платформа для ентерпрайз приложений", то… ну ок, чо. Пойду писать свои ентерпрайз приложения без платформы.

Servicestack.net еще адекватная платформа для NET которую я знаю. Там можно на странице Features нажать на коробочку и получить их список. Но к сожалению платная, поэтому жутко непопулярная как у разработчиков так и работодателей. Странно что ее так никто и не упомянул, я всё ждал, ждал.
Странно что ее так никто и не упомянул, я всё ждал, ждал.

Может быть, потому, что критерии адекватности и ентерпрайзности у всех разные?

1. Ни мне, ни моим работодателям, использующим дотнет для разработки самого что ни на есть кровавого энтерпрайза, эта мысль почему-то в голову не приходила. Что мы делали не так?
2. Как будто что-то плохое: в яве очень много сделано в стиле «лебедь щуку раком», когда на каждый чих есть 100500 разных несовместимым между собой библиотек со своими уникальными недостатками.
НЛО прилетело и опубликовало эту надпись здесь
Я много о чем и когда задумывался :))
И на OData доводилось писать когда не было никаких GraphQL. И только версия OData 4.0 уже хоть как-то подходила для продакшн, хотя и приходилось всё равно вставлять кучу костылей.

Вы как-то в одни ворота играете… :)
Давайте вспомним, например, (N)Hibernate. В каком году микрософт задумалась об ОРМ? А DI/IOC-контейнер в каком году появился? А библиотеки модульного тестирования ala N(J)Unit откуда портировались?

Я согласен, что синтаксис и возможности языка C# приятней (микрософт переосмыслил ошибки Java, это известный факт). Но что касается экосистемы вокруг — здесь Java действительно впереди, как бы я не любил C#.
И .NET Core это попытка MS запрыгнуть в уходящий поезд (возможно что-то и получится).
Кстати, Java тоже решила ускориться и перешла на полугодичный цикл релизов.
Так что дальше будет еще интересней. А то что языки черпают друг у друга новые возможности — это же хорошо.
Никто уже не помнит WCF Dataservices? Это и была одна из причин провала OData-ы — прибитая гвоздями кривейшая концепция и инфраструктура.
К версии 4 оно всё-такие мигрировало на более адекватный и гибкий Web Api.
Потом, впрочем, и Web Api канул в лету (оно и к лучшему).
Никто уже не помнит WCF Dataservices? Это и была одна из причин провала OData-ы — прибитая гвоздями кривейшая концепция и инфраструктура.

Вы под провалом OData понимаете то, что у нас до сих пор ощутимый поток интеграций через этот интерфейс?


Потом, впрочем, и Web Api канул в лету (оно и к лучшему).

Ыыы, а на чем я пишу сейчас?

Под провалом odata я понимаю что практически никто за пределом .net песочницы о ней не слышал, хотя технологии ~10 лет (да и в песочнице она нечасто всплывает)


Пишете на WebApi? А как же .Core которому здесь сотню комментариев подряд все оды поют?

Пишете на WebApi? А как же .Core которому здесь сотню комментариев подряд все оды поют?

Так это оно и есть.

Оно ж с MVC слилось в экстазе когда ms осознал что две параллельные реализации контроллеров и инфраструктуры вокруг них не есть хорошо. М?

Оно ж с MVC слилось в экстазе когда ms осознал что две параллельные реализации контроллеров и инфраструктуры вокруг них не есть хорошо. М?

ну да слилось, это плохо? Старые MVC неймспейсы убрали (System.Web.Mvc стал Microsoft.AspNetCore.Mvc), унифицировали работу с контроллерами, но в целом это тот же самый старый добрый WebApi.


Живее всех живых короче.

НЛО прилетело и опубликовало эту надпись здесь
Я думаю что МС не думает о ПЖЦ своих технологий, поэтому они часто «почкуются» и умирают.

Всё что можно было делать в Web Api, можно было делать и в MVC через JsonResult метода контроллера. Разве что без OWIN и Embeded Server и чуть более «многословно».

Так что Web Api попросту умер, когда в новом «более лучшем» MVC пришлось/удалось отказаться от System.Web за счет кросс-платформенности. Мавр сделал свое дело, мавр может уходить.
Всё что можно было делать в Web Api, можно было делать и в MVC через JsonResult метода контроллера.

Серьезно? Content negotiation — тоже? Из коробки?

Вам шашечки или ехать? Вот во всех комментариях найдут какую-то «мелочь» и цепляются к ней… Content negotiation только во 2м вебапи появилось, если мне склероз не изменяет и уж точно не было киллер-фичей.

Мне как раз ехать: я долго работал с MVC, потом долго работал (и работаю) с WebAPI, и хорошо помню это ощущение простоты при переходе — для всех типовых API-специфичных операций было готовое решение. Сейчас, конечно, задачи посложнее, и все не так мило.

НЛО прилетело и опубликовало эту надпись здесь
Да уж :) Помню как евангелисты микрософта на конференции TechEd 2011 преподносили OData как революцию. Но «что-то пошло не так» ©

Вот даже видюшку нашёл, харизматичный мужичок был www.techdays.ru/videos/3883.html
Под провалом odata я понимаю что практически никто за пределом .net песочницы о ней не слышал, хотя технологии ~10 лет (да и в песочнице она нечасто всплывает)

Берем, значит, любимый аналитический инструмент офисного работника — я про Excel — и видим там Get Data for OData feed.


Пишете на WebApi? А как же .Core которому здесь сотню комментариев подряд все оды поют?

У нас проект на .net framework. Когда поедем на Core — там все равно схожий движок, так что конкретно в этом месте я ожидаю тривиальную миграцию. Это вам не с WCF переписывать.

  1. Солюшен всегда был солюшен. Проекты пытались переделать на project.json, но не заехало + я работал с кором начиная с beta4 (в продакшне) — так вот изначальной кор это ад. У JSON нет никакой схемы, ничего не понятно, документации кот наплакал, периодически все перестает работать, где искать ответы — хз. По сравнению с этим расширение существующего XML выглядит как верх читаемости и удобства. JSON ради JSON'а это очень круто, но я на практике видел оба варианта. Не считая того, что я буквально вчера писал свой кастомный таргет для csproj, который через 30 минут после моей идеи о нем был реализован. Потому что не стали городить свой велосипед и просто убрали бойлерплейт, привнеся пользу причем и обычным проектам, ибо новый формат обратно совместим с полным фреймворком.
  2. Первый раз слышу, чтобы пытались собрать чем-то другим. Первый вопрос — зачем? Ведь в итоге все равно все выльется в msbuild, никто в здравом уме не будет писать свою обертку над csc. Сюда можно как раз вспомнить то, что я написал в предыдущем пункте, я когда писал свой таргет смотрел на стандартные, там СТОЛЬКО логики, что дублировать её можно, конечно, но смысл? Это очень дорогой эффорт, профит от которого неясен — msbuild вполне хорош, если не считать транзитивных зависимостей.
    Насчет разных версий msbuild'а было бы интересно послушать, потому что у меня например никогда проблем не было, включая сборку какого-нибудь солюшена под 2010 студию последним компилятором.
    Ну а что касается cake — я очень подозрительно отношусь к словосочетаниям "скрипты", "make" и "сборочная система". Ибо навевает печальные воспоминания как я пробовал opencv собрать правильно. Хотя кроссплатформа выглядит заманчиво, не спорю, но разрабатывать на шарпе я бы все равно иначе как на винде не стал бы — все-таки студия пока вне конкуренции. Через пару-тройку лет мб можно будет посмотреть на райдер, но пока в нем много чего не хватает.
  3. Не вижу, чем свобода выбора плоха. Если у вас разработчики не умеют договариваться, то тогда наверное да, диктатура со стороны языка вам на пользу. В моей практике наоборот, возможность выбрать тонко инструмент под задачу позволяет писать намного более приятный код. Нужен простенький DI? Не вопрос, берем Microsoft.Extensions. Нужно что-то посложнее? Окей, берем Autofac. Нужно, чтобы ASP.Net использовал Autofac вместо встроенного DI? Для этого тоже есть пакет. Ну и про "велосипеды на каждом углу" хотелось бы подробнее. Что именно люди переизобретают? В вашем десятилетнем стаже наверняка найдется пара-тройка примеров.
  4. Как я выше сказал, множество вариантов это всегда хорошо. С другой стороны, у вас ведь разработчики, которые не могут договориться, как же вы можете ставить это как плюс? А вдруг один возьмет servlet api, а другой — tomcat?
  5. Тут все верно, коммьюнити недавно появилось в процессах. Правда, как мне кажется язык и без того развивался быстрее и эффективнее, а с появлением коммьюнити это впечатление только усиливается.
  6. Тоже нечего добавить
  7. А вот тут поподробнее. Я, конечно, извиняюсь, но XML конфиги я уже года 2 точно не видел. Для настроек есть appsettings.json, который удобно подсасывается. Покажите, где тут хоть строчка с XML

Хотел вкратце ответить — но как-то не срослось, решил подробнее остановиться на каждом из пунктов, очнулся уже в конце простыни.


Мое мнение, что на новых языках писать всегда удобнее, чем на старых. Поэтому джава удобнее плюсов, шарп — джавы, а раст — шарпа. С другой стороны, количество библиотек — обратная зависимость. В итоге для меня лично сейчас компромиссная точка — шарп, у которого библиотек меньше чем у любого из этих языков, за исключением конечно раста, но появившийся позже плюсов и джавы и сумевший проделать работу над ошибками. По сути шарп можно считать Java++ с потерей обратной совместимости. Но с ростом количества библиотек у этого самого раста я планирую перейти на него как на основной язык в течение нескольких лет. И не потому, что я люблю системное программирование или производительность, а потому что я на него смотрю высокоуровнево, и для меня отсутствие null в языке это одна-единственная возможность, ради которой можно многое простить. Не считая того, что раст развивается даже быстрее шарпа, причем скорость развития даже сравнивать страшно, 6-недельные циклы против годового, и через эти самые пару-тройку лет там появятся и более крутые вещи — я например очень хотел бы увидеть HKT. В шарпе есть пропозал, но когда его примут — неизвестно. Ну а в джаве я не ожидаю их вообще никогда.


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

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

Тут мне кое-кто шепнул, что на дотнете есть F#.

У джавы наверняка есть свои плюсы

Java сильна точно не языком. В первую очередь обратной совместимостью и аккуратным подходом к нововведениям. И это очень ценят в бизнесе, но как следствие — медленное развитие и постоянное отставание по фичам. Кроме этого, у джавы мощная инфраструктура и наличие открытых библиотек на все случаи жизни.
Если не нравится Java именно как язык, то можно посмотреть в сторону Котлина. Получите современный язык, который стремительно развивается + из коробки все наследие Java.
Выше уже писали, те же дженерики — это критический недостаток не то что джавы, а рантайма. Как следствие хотя Котлин и выглядит клевым, под капотом происходит все то же самое, и нет-нет, да вылезает за пределы аккуратных абстракций. Хотя он шажище вперед, никто не спорит.
Опять слышу про дженерики… Чем оно лично вам «критическое»-то? Может всё-таки не в дженериках дело? :) Object он и есть Object никаких супер-оптимизаций «серебряная пуля» — не бывает.

Кстати, подумалось, что свеженький Kotlin-то бегает на JRE, а не на CLR…
Кстати, подумалось, что свеженький Kotlin-то бегает на JRE, а не на CLR…

Ну это логично. Его разрабатывает JetBrains, которые свои инструменты исторически пишут на Java. Но Java как язык их не очень устраивает своей архаичностью, а Scala своей загонностью (как альтернатива), решили сделать свой, с фирменным тулингом.
По поводу CLR, по моему, Андрей Бреслав говорил что CLR не выбрали потому, что смысла нет. C# по возможностям близок Котлину, т.е. Котлин если и лучше в чем-то, то не настолько чтобы люди захотели на него пересаживаться. Поэтому выбрали JVM и JavaScript как платформы для старта.
огда наш гипотетический Блаб-программист смотрит вниз на континуум мощности языков, он знает, что смотрит вниз. Менее мощные, чем Блаб, языки явно менее мощны, так как в них нет некой особенности, к которой привык программист. Но когда он смотрит в другом направлении, вверх, он не осознает, что смотрит вверх. То, что он видит, — это просто «странные» языки. Возможно, он считает их одинаковыми с Блабом по мощности, но со всяческими сложными штучками. Блаба для нашего программиста вполне достаточно, так как он думает на Блабе.
Вот тоже не понимаю, почему столько внимания в комментариях уделено проблеме с дженериками, причем обычно от людей, которые пишут на C#. Писал и на шарпе и на джаве, за все время сталкивался несколько раз. Т.е. не могу сказать, что как перешел на Джаву так сразу type erasure стало мешать жить. Ну неудобно, да. Но вот чтобы критично… Вот, например, многословность Джавы лично меня напрягает куда больше.

DI от явовских генериков страдает очень сильно.
Оптимизация аллокаций в куче — еще сильнее.
Первое — хлеб любых приложений от среднего размера.
Второе — очень больная тема в нагруженных приложениях..

DI от явовских генериков страдает очень сильно.

Искренне хочется расшифровки или пример «сильного страдания»
Искренне хочется расшифровки или пример «сильного страдания»

Практически все функции по ссылке явовские контейнеры не потянут без дополнительных костылей, так как параметры-типы у генериков Lazy, Func, Owned, IList и т.д. после компиляции даже не превратятся в тыкву, а просто исчезнут. На практике я использовал большую часть списка хотя бы однажды, а самые ходовые варианты (Func) — ежедневно


http://autofaccn.readthedocs.io/en/latest/resolve/relationships.html#supported-relationship-types

ideone.com/eaT4pl

Почему-то первыми ругать жаву за стирание типов набегают те кто понятия не имеет что именно стирается.
А что сломалось-то?
Плюсую. Модули Java 9 — колоссальнейшая многолетняя работа по модуляризации и перепиливанию всей платформы.
Микрософт за это время успел выкинуть старый .NET.
Так же перешел на java после десятка лет на .net.

1. Про дженерики выше много написано.

2. Как связаны Reactive Streams с серверами приложений? В .net Reactive Streams тоже есть (и, кажется, уже везде есть) и сам исходный паттерн Observable встроен в сам язык с самых первых версий.

3. После знакомства с maven и gradle я начал очень сильно ценить и любить msbuild.

4. Доминирования прикладных фреймворков не наблюдаю. Наблюдаю бардак в базовых АПИ (даты, коллекции, etc) и монстроидальные монолитные EE и Spring.

5. В java есть osgi и новый jigsaw. В .net есть MEF, но я ни разу не видел, чтобы кто-то им пользовался.

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

7. В java очень любят и активно используют annotation processors для генерации кода. После .net ощущается очень свежо и интересно. Dagger удивил, например (а что, так можно было?)
Так же перешел на java после десятка лет на .net.

А какова причина перехода, если не секрет?
Дорос до проектов и компаний в которых фундаменталка, кругозор и знание предметной области важнее знания конкретных языков и фреймворков. В конце очередного собеседования узнал, что писать надо будет под JVM. Согласился. Уже больше года полет нормальный :)
Это беда рынка, что «внизу» (да и в середине и чуть выше) в почете знание конкретных версий конкретных подсистем конкретных фреймворков.

Но взросление неизбежно.

В .NET тоже есть определенный бардак в базовом API — в тех же коллекциях и датах.


Насчет коллекций — мое любимое:


А вот почему практически во всех проектах разработчики используют в открытых контрактах своих API либо List(T) (ай-ай, реализация, а не интерфейс, и при этом наиболее "полная" реализация — а как же SOLID?) либо IEnumerable(T) (ай-ай, сколько раз приходилось видеть вызов метода Count())?


Хотя в большинстве случаев по смыслу подходит использование IReadOnlyList(T) или IReadOnlyCollection(T) (список с конечным количеством элементов — упорядоченный по индексу, либо нет).


Если разобраться, то на это разработчиков провоцирует устройство базовых типов самой платформы:


  • Тип List(T) реализует интерфейсы IList(T) и IReadOnlyList(T).
    Но что будет, если одна функция возвратила экземпляр IList(T), который мы хотим передать в функцию, которая на входе требует IReadOnlyList(T) или IReadOnlyCollection(T)?
    Правильно — ошибка компиляции, т.к. интерфейс IList(T) не реализует интерфейс IReadOnlyList(T).
    Вот и получается, что, чтобы работало, везде лепят List(T).


  • А вот если вторая функция на входе требует IEnumerable(T), то подойдет любая коллекция, в т.к. IList(T).
    Кроме того, использование IEnumerable(T) провоцируется стандартной библиотекой платформы, хотя в большинстве случаев по смыслу речь идет о коллекции с конечным и известных количеством элементов (а что, если в будущем коду самой функции потребуется проверка коллекции на количество элементов? — а ведь замена типа параметра на IReadOnlyCollection(T) приведет к поломке компиляции всего написанного с ипользованием этой функции кода).


  • Та же проблема касается и словарей — Dictionary(K,V), IDictionary(K,V), IReadOnlyDictionary(K,V).



Получается, при казалось бы, такой сильной реализации Interface Segregation Principle в системе базовых коллекций, из-за такой мелочи по факту этот принцип не используется в прикладном коде.


И еще определенную путаницу вносит наличие ReadOnly- и Immutable-версий коллекций (да, мы знаем, чем они отличаются).
Последние так и не начали использоваться в проектах (у кого-то есть реальные примеры?), а еще перечень Immutable-коллекций не полностью соответствует 1-в-1 набору обычных (что-то добавлено, что-то отсутствует).

писал на джаве и скажу что с.нет работать проще, кода можно писать меньше, магии правда больше, но обычно.нет библиотеки более продуманные и в исходники почти не надо лезть, в джаве это приходилось делать постоянно, для разнообразия пробовал сделать свой проект на разных языках используя фреймворки которыми не пользовался ранее и самым простым оказался node.js потом с# и джава оказалась самой неудобной и дольше всего писал и опять пришлось лезть в исходники, одно в джаве хорошо remote debug который настраивался намного проще чем в.нет
У меня смутное дежавю, но как будто бы уже была похожая по структуре и лейтмотиву статья .NET vs Java, только N-летней давности…

По теме статьи — статья как будто хочет сказать, что после знакомства с Java — в .NET все оказывается не так плохо.

Но что по поводу проектов на рынке?

На .NET по-прежнему их меньше чуть ли не в разы, и в основном легаси.

Кое-что появляется на .NET Core, но именно что «появляется», и с качеством кодинга и архитектурой в проектах проблемы (унаследованные подходы или криво применяемые новые).

Т.е., несмотря на тенденции последних лет — развитие C# (6.0-7.x + C# 8 в черновике), взросление F#, появление .NET Core, модульности, новой экосистемы, до сих пор сохраняется неясность по поводу настоящего и будущего платформы.

И еще кое-что.

Изначально .NET затачивался под декстоп и UI, потом плавно перешел на back-end, а с появлением .NET Core стал практически полностью полноценной зрелой back-end платформой.

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

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

XSD-схемы, платформенно-независимый формат XML? — не, не слышали.

И вот из-за одной даже такой мелочи (работа со строками) — вот как это применять на back-end?

В Java функции работы со строками работают так, что типы данных представляются в том формате, в котором значения типов записываются в коде самого Java-приложения, т.е., в инвариантном.
А для UI-представления нужно использовать класс Formatter.
НЛО прилетело и опубликовало эту надпись здесь

В бэкенд-приложении можно по идее установить CultureInfo.DefaultThreadCurrentCulture.

Зарегистрируйтесь на Хабре , чтобы оставить комментарий

Публикации

Истории