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

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

Забыли написать, что виртуальная машина java весьма тормознутая. Ну и еще момент — не технический, но имеет место быть — очень мало новых проектов сейчас пишутся на Java. Другими словами, Java-программист практически всегда обречен ковырять столетний легаси, в отличии от net core-разработчика
Про тормоза вы серьезно? Как-то встречал тесты — там было наоборот.
Во всех этих тестах всегда тестится код уже на «разогретом кеше», а вот время самого разогрева, что в ява, что в дотнет всегда пячат под ковёр. В результате имеем компилятор котлин который только стартует 5-8сек. Что приводит к костылям в виде демонов которые висят с прогретым кешем и ждут заданий.

В серверном мире предполагается, что приложение будет активно жить без перезапусков месяцами. Поэтому стартовый разогрев кэша не является критической проблемой. Для serverless или кейсов с быстрым стартом Java конечно не особо подходит, хотя и там можно использовать GraalVM и AOT-компиляцию

активно жить без перезапусков месяцами

Иногда такие приложения, в зависимости от фазы луны, начинают выедать память, и сожрав её всю доставляют неимоверную радость.
А это уже в большей степени зависит от автора таких приложений. Какой бы хорошей и эффективной не была платформа и язык, всегда можно написать «текущий» говнокод.
Ява же не должна течь by design. Ну вроде как ее так раньше рекламировали, рассказывая про преимущества управляемого кода. А оно вон как, опять программисты косякнули. Эти сволочи всегда во всем виноваты: )
Так как раз «бай дизайн».
Долгий старт ява приложений
-> приложения которые грузятся и висят в памями прогретыми обрабатывая запросы, вмсесто простых быстро загружаемых
-> мега комбайны которые могут всёбольше
-> такие собирают из сотен и тысяч сторонних библиотек
-> уследить за каждым практически не возможно
-> где-то да текёт
-> имеем то что имеем если текёт быстро чаще watchdog перезапускает инстанс.
Ява же не должна течь by design. Ну вроде как ее так раньше рекламировали, рассказывая про преимущества управляемого кода.

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

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

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

А что, в Java нету weak map?

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

Но это все про программистов с «прямыми руками»… а вот «by design» магического способа делать все криво, но чтобы работало все нормально — нет.
Увы, даже с управляемым кодом нужно помнить о нескольких простых правилах, нарушения, которых приведет у утечкам памяти.
Обычно дело не в руках, а в сроках. И то что всё это пишется целым муравейником программистов.
Забыли написать, что виртуальная машина java весьма тормознутая

Интересно, у Вас есть какие-то подтверждающие аргументы? Современная JVM порой дает прикурить даже C++ коду (не на чисто алгоритмических задач конечено) за счет рантайм оптимизаций.


очень мало новых проектов сейчас пишутся на Java

Это тоже крайне спорное утверждение. Реальную картину конечно сложно оценить, но если например взглянуть на движуху вокруг относительно молодых фреймворков типо Quarkus или Micronaut (да что уж там говорить — даже Jakarta, которая стала наследницей Java EE), то можно увидеть, что интерес совсем не упал. И это даже если не брать в расчет Kotlin...

Блин, даже если очень мало проектов пишется на Java (кстати, есть пруф?), весь мой фейсбук забит вакансиями Java-разрабов.

Мне кажется, рекрутерки прям с ног уже сбились в поисках джавистов. Плюс недавно мой друган-джавист из РФ хотел уйти в управленцы, так его уговорили остаться в разработчиках, дав денег как менеджеру.
Ну все правильно, их нанимают разгребать столетний легаси, как я и писал

А на сишарпе все на сияющих неткорах пишут? А то озон вот недавно приглашал, у них там оказывается ещё .net 2.0 и дельфи компоненты вполне себе в проде живут. Но мне пообещали что мне туда лазить практически не придется — для этого есть специальные люди. Ну спасибо, что сказать)


Мне кажется что на джаве что на дотнете легаси и новых проектов примерно одинаково. И если в СНГ как раз шарп ещё популярен и считается модненьким, то на западе он воспринимается примерно так же как VB — непонятная ерунда, а люди которые на нем пишут — странные персонажи, не осилившие джаву. Сам шарпистом всю жизнь был и почувствовал на себе такое отношение.


Так что вот думайте

Вы ошибаетесь. В банковском секторе благодаря экселям очень много .Net. Еще огромный пласт это Sharepoint. Более того, в большинстве новых проектов в крупных компаниях требуется любой язык из стэка типа Java/C#/Rust/Go
Еще огромный пласт это Sharepoint

Ой. Я это слово проклял, заковал в цепи и закопал на глубину 7 метров. Чего и вам желаю.


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

Последние года 3 90% работы как раз перенос на .Net Core с распилом монолита.

А можно поинтересоваться: как у вас с .net 5? подумываете про .net6? Как происходит деплой — докер-не докер? Как вообще происходит процесс обновления приложения?


Просто в моем видение как в банке обычно это происходит тут на каждом этапе куча препон. В лучшем случае согласуют перенос с 4.5-4.7 на какйо-нибудь 3.1 и ещё лет на 5+ на этом все заглохнет пока не придет инициатива переходить с 3.1 на какой-нибудь .net9.


Поправьте, пожалуйста, если не прав. Расскажите про процессы у вас в банке. (Ну и если банк не секрет то про него тоже можно. Тот же Тинек вполне себе адекватный работодатель кмк даже среди обычных фирм, а на фоне остальных банков очень выгодно отличается, в частности Нижником).

Речь шла про запад. У меня на проекте в одном красном операторе .Net 5. Перехожу в зеленый банк там Go.
В кор бизнесе все тускло. Но вокруг кор бизнеса миллиард проектов, где вполне бодро можно обновить версии. Да и вообще сейчас у всех «трансформация»

Ну ок. Про западные банки знаю только от знакомого который в дойче работал. Буду иметь в виду, спасибо.


Но если расскажете про то что в этих миллиардах проектов будет неплохо. Про тот же деплой, процесс принятия решения об обновлении и т.п.

У нас .NET 5 в проде. Новые микросервисы пишутся на актуальном на момент времени стеке. Райф

Простите, а что не так с SharePoint?

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

В резюме указал список вещей с которыми когда-то работал, но завязал. Вдруг нужен будет перенос/интеграция. Когда приходит предложение снова поработать с SharePoint, мурашки по коже пробегают. Со остальным списком такого эффекта нет.

Вот примеры:


Раз. Нужно опубликовать статическую страницу? Никакого копирования одного файла, вам понадобится собрать wsp, содержащий одну фичу, после чего добавить wsp в каталог решений, установить его и активировать фичу.


И да, даже не думайте что эта самая фича из одного файла будет такой простой, там куча подводных камней, начиная от обязательного использования ASP.NET WebForms, и заканчивая недокументированной проверкой регистра тэга asp:ContentPlacehohder (вообще-то имена тэгов в WebForms регистронезависимые, но не в шарике!).


Два. Нужно задеплоить что-то? Ну, если вы будете делать это мышкой — шарик для вас, а в противном случае вам понадобится:


  1. (выгрузить старый wsp из каталога решений);
  2. загрузить новый wsp в каталог решений;
  3. установить wsp;
  4. (рестартануть свои службы на всех серверах фермы, иначе dll в GAC не обновятся — если вам не повезло написать службу которая использует ваши dll);
  5. дождаться окончания установки wsp, причём команды на это никакой нет — тренируйтесь писать циклы (и упаси боже если кто-то загрузит dll из GAC во время этого шага!);
  6. активировать нужные фичи на нужных сайтах — тренируйтесь писать кастомизируемые скрипты, потому что этот шаг наверняка будет отличаться на стейджинге и проде;
  7. дождаться окончания активации фич — снова цикл, впрочем вы его уже написали;
  8. выполнить действия по настройке, которые не вошли ни в одну фичу.

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


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

Четыре: попробуйте прочуствовать когда нужно создавать контексты а когда нет, когда нужно имперсонировать клиента а когда нет и т.п. В каких случаях нужно использовать только OpenWeb в каких new SPWeb(), в каких можно и то и то, а в каких оба не заработают.
Пять: попробуйте в 11 часов вечера когда вы уже на протяжении 7 часов бытаетесь залить фичу уровня "одна статическая страничка" а она не заливается, и на ~40 раз "удалили пакет — поставили пакет" она внезапно начинает работать (без каких-либо изменений в коде, просто методичное удалил-установил-удалил-установил).




Из моей жизни: клиент просил чтобы один столбец в одном месте на сайте назывался не так, как в админке. Ну типа в админке колонка называется "Игры" а на этой странице должно было называться "Ваши доступные игры". Вот сколько нужно времени, чтобы изменить статический текст на одной страничке?


ЕМНИП я делал задачу полтора месяца. Ведь нужно создать шаблон списка, добавить в него нужные поля, и причем поля же пронизыают весь шарик насквозь. Нужно было предусмотреть режим рендеринга во время "редактирования страницы", режим рендеринга при просмотре обычным юзером. В итоге я это захачил путем залезания в системные шаблоны и хака в XSLT if (pagename == .. && fieldname = ..) ... Ибо способа из коробки назвать поле по-другому только на одной странице — нет никакого.


Уххх как вспомнил так вздрогнул.

на западе он воспринимается примерно так же как VB — непонятная ерунда, а люди которые на нем пишут — странные персонажи


А вы точно на шарпе-то писали? Или может быть это лично к вам относились как к странному персонажу?

Ну не верите мне — спросите у своих знакомых. У меня 200 свидетелей и исследований статистической значимости на руках сейчас нет. Говорю то, чему был свидетелем и про что слышал от знакомых. YMMV что сказать, и VB разработчиков очень много, у них тоже будет совсем другое видение.

Странно, ни разу не сталкивался с таким мнением. Проектов на .NET было предостаточно. Северная Америка, Южная, Европа, Океания. От мелких бизнесов до транснациональных. В одном только ООН его море. Кто-то из доверия к бренду, кто-то в силу остального ландшафта в компании, кто-то из-за инструментов. WebForms/WPF были особенно в ходу, поскольку Delphi был не так распространён за пределами СНГ, а какой-нибудь MFC давался сильной болью. Огромное количество бизнес-софта, скажем тот же немецкий Sage (что-то в духе нашего 1С).

дав денег как менеджеру.
как топ-менеджеру, я надеюсь?
А уж на кобол какие вкусные вакансии… не сходна ли причина?

Это очень спорное утверждение) HotSpot крутая штука на самом деле)

Hadoop, Spark, Kafka, Cassandra, Lucene, ElasticSearch, Solr - вот первое что вспомнил из Highload и BigData на Java.

Тормознутая по сравнению с чем? И тормознутая насколько?

Про «очень мало новых проектов» даже не смешно. Очередная смерть джавы не за горами, видимо :)

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

Java уже много лет. Бардак там не только с датами и временем, но и с desktop-ым UI, Есть устаревшие классы для работы с коллекциями. С логированием вообще просто кошмар.
Два способа работы с файлами (Java.io и java.nio). И т. д. Всё это за 26 лет накопилось.

Вспоминаю как познакомился впервые с JodaTime и хотел плакать)

Особенно когда узнал, что в коде библиотеки СВОЙ маппинг таймзон, и если в регионе родное правительство сдвинуло часы — или поднимай актуальную версию либы, или ну его нафиг — прописывай GMT в параметрах запуска java машины.

Ага, бардак с API даты времени в Java, а ведь как хорошо в сишарпе где у вас есть: DateTime/DateTimeOffset/TimeSpan/DateOnly/TimeOnly/LocalDate/LocalDateTime/Duration/ZonedDateTime/…


Отдельная викторина угадать, какие из них стандартные, а какие прилетают из популярных библиотек.

Никакой викторины, DateTime/DateTimeOffset/TimeSpan — стандартные, а DateOnly/TimeOnly/LocalDate/LocalDateTime/Duration/ZonedDateTime — из библиотеки Noda Time. Кстати, я не уверен в её популярности.

DateOnly/TimeOnly/LocalDate/LocalDateTime/Duration/ZonedDateTime — из библиотеки Noda Time.
А вот и не угадали.

А нода много где используется. По крайней мере везде где нужно с таймзонами по разному работать — стд очень бедна на эти вещи. Например тот же FindSystemTimeZoneById вроде есть, но с ним не все хорошо.

Ну, это анонс же ещё. Вряд ли вы эти новые классы встретите разбирая старый код.

А я ничего не говорю про старый код, я говорю про стройность и порядок типов в .Net


Кстати, интересной является и история названий DateOnly/TimeOnly. Логичнее называть было бы немного иначе, верно? А разгадка простая: прибежал очень важный кастомер и сказал что у них код на VB сломается — ведь VB использует Date/Time как кейворды.


Так вот кишки имплементации рантайма/компилятора (им не захотелось делать полноценный ренейм как например делается для типа String) протекают в кодовую базу и рождают такие вот костыли.

А вот и не угадали.
ОК DateOnly/TimeOnly будут стандартными (хотя не совсем ясно какой именно бардак они вносят). А остальные откуда? тот же Duration, ZonedDateTime если не из ноды?

DateOnly/TimeOnly — из .NET6

В Java есть java.util.Date, который полностью устарел и сейчас подходит только как хранилище миллисекунд. Вместе с наследниками Timestamp и java.sql.Date

Есть Calendar

Есть библиотека JodaTime, которую сейчас уже не актуально использовать.

Есть java.time, который создан под впечатлением JodaTime со своими Instant, LocalDate, LocalTime, ZonedDateTime, OffsetDateTime и методами конвертации в java.util.Date.
Интересные вы себе викторины придумываете, на ровном, так сказать, месте. Стандартные библиотеки определены 100 лет назад и известны, что можно перепутать?

Я не говорю что так не должно быть или что это произошло внезапно и неожиданно. Я просто предлагаю быть объективным: да, у джавы апи может быть не идеальное, но и у шарпа то же. Так что это не может быть аргументом ни в ту ни в другую сторону.

Пока факап только один DateTime/DateTimeOffset всё остальное на своих местах вроде, TimeSpan с DateTime в одну корзину класть ну такое, это надо совсем слов не понимать
В Java более прозрачная работа с асинхронностью: когда пишешь код действительно приходится о многом думать


это должно быть шутка? Никакой поддержки асинхронного программирования на уровне языка java НЕТ. Всё что есть — это библиотеки где можно писать отвратительную колбасу с коллбэками. «приходится о многом думать» — круто-то как, надо такого побольше и везде, а то ж мало о чем думать и без этого! Надо полагать что те кто пытаются уменьшить интеллектуальную сложность систем и инструментов — просто ленивые дураки

Возможно автор перепутал асинхронность с многопоточностью

Многопоточность в J2EE — классная штука. Помню, как стоило кому-нибудь особо продвинутому использовать многопоточность в бине — и привет, сервер лежит, индикации, почему — нет. Формально — никаких ошибок.

Впрочем, у меня это старые воспоминания, двадцати-почти-летней давности.

Я J2EE в целом не люблю. Мне "посчастливилось" недолго познакомиться с ним в одном зеленом банке и впечатления остались как об огромном непонятном монстре с кучей неявного и скрытого поведения

Идея-то чрезвычайно красивая, эти внутренние и внешние интерфейсы… замечательно. Вот только всё держалось на джентльменских соглашениях, те же бины. Опечатался в имени метода — привет, это уже не сеттер или не для того свойства. Никакой индикации не будет, то, что свойство стало readonly, вылезет, скорее всего, уже в эксплуатации.
Ну и за встроенное управление многопоточностью я готов был убить явотворцев, в серверах это было просто миной.
С# — не просто сделан из явы, это ява, улучшенная дельфями, именно из этого растёт значительная часть его преимуществ. MS сманила главного разработчика дельфей Андерса Хейлсберга:
В 1996 году Андерс перешел работать в Microsoft: вместо $200 тысяч, которые он получал на старом месте, Билл Гейтс предложил $2,5 миллиона. Там он сначала работал с такими проектами, как J++ и Foundation Classes. Но потом он возглавил команду разработки языка С#

Для MS и шарпа это был очень удачный ход (не с точки зрения борландов, конечно :-).

А CompletableFuture? .NET async/await по сути красивый сахар. Единственно с чем соглашусь очень мало реализаций асинхронных либ для доступа к БД, но и они есть худо бедно) В .NET просто изначально запарились над темой асинхронности там, где это нужно из коробки)

А CompletableFuture? .NET async/await по сути красивый сахар


этот красивый сахар позволяет писать код на порядок удобнее и чище. Писать в 2021 году трэш на коллбэках — это не поддержка

UPD в качестве примера попробуйте набросать на CompletableFuture код который выполняет асинхронный ввод-вывод, ждёт результатов не съедая время потока (т.е. неблокирующе) и написать продолжение обработки после получения результатов. И таких например несколько шагов — запрос на удалённый ресурс -> получил-обработал. А потом можете поделиться прикидками что будет если такое писать регулярно и на уровне всего проекта

Единственно с чем соглашусь очень мало реализаций асинхронных либ для доступа к БД, но и они есть худо бедно)


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

А разве результат Rust/С++ в TechEmpower benchmark — не заслуга в том числе нового реактивного драйвера для Postgres?

А разве результат Rust/С++ в TechEmpower benchmark — не заслуга в том числе нового реактивного драйвера для Postgres?


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

Все это вполне пишется. Примеры.

Если ваша ремарка апеллирует к сложности такого кода — не согласен. Если к сложности понимания как его писать, используя CompletableFuture — да, есть такое, с библиотекой надо разбираться.

С другой стороны — асинхронность это всегда сложно, уже исходя из своей сути. Я бы подчеркнул, что в экосистеме есть вменяемый, но не самый простой для понимания инструмент, который, к тому же худо-бедно развивается (Future -> CompletableFuture).

Некоторые базы поддерживают настоящую реактивность, но скажем Постгрес — нет

Таки Pg умеет в реактивщину. Вероятно, вы имели ввиду, что у данной СУБД нет асинхронного API.
Если ваша ремарка апеллирует к сложности такого кода — не согласен


это же кошмар как нечитабельно и многословно. Ну да, да написать в принципе возможно, но мы же не об этом ) В этом видео только игрушечные примерчики, и уже они выглядят ужасно. А что будет если писать ВСЮ бизнес логику так (это риторический вопрос, если что) и когда объёмы кода написанного вот так, начнут исчисляться десятками и сотнями тысяч строк

это всегда сложно


конечно, только в разной степени для разных подходов ))

Таки Pg умеет в реактивщину. Вероятно, вы имели ввиду, что у данной СУБД нет асинхронного API.


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

Там ссылка на часовое видео, какой конкретно фрагмент смотреть-то? Или вы это к тому, что докладчик целый час на эту элементарную задачу убил?

А completablefuture это не сахар? CompletableFuture это более красивая упаковка над коллбеками, async await уже более серьезная упаковка в виде машины состояний. Kotlin со своими корутинами по сути взял CompletableFuture и упаковал в машину состояний, что бы не плодить колбекхелл и писать последовательный код. Просто пока вы будете писать асинхронную логику на java, программист на котлине или шарпе уже сдаст проект и улетит на Бали

НЛО прилетело и опубликовало эту надпись здесь
На самом деле, у него просто времени толком не было, чтобы полноценно погрузиться в весь зверинец утилит и библиотек. Вряд ли он реальную картину увидел.

Данная статья больше история личного опыта, у каждого человека он свой.

Она не претендует на референс ресурс при сравнении технологий :)

P.S. Представьте просто, будто мы с Вами сидим где-то в баре и я медленно рассказываю о своём опыте) Который не совсем большой, но есть что рассказать)

На мой взгляд, в статье упущен самый важный критерий — это легкость разработки. И измеряется она не наличием синтаксического сахара (т.е. и им, конечно, тоже но в последнюю очередь), а наличием библиотек, размером коммьюнити и наличием хорошей IDE.
Как язык программирования, лично мне, может, тоже C# нравится больше, чем Java. Но это не очень важно. А важно количество мощных фреймворков на жаве (Spring, Guice — это только первое что пришло в голову, список можно продолжать) и библиотек (Apache, Guava и т.д. и т.п.)
Что тут предложит .NET? Я честно признаюсь, что не заглядывал в .NET лет 10, может все и стало лучше (если да, отлично). Но 10 лет назад у меня сложилось впечатление, что любая мало-мальски приличная библиотека стоит денег за лицензию, никаких вам MIT и т.п.
Я уж не говорю про стоимость среды разработки — сравните бесплатную IntelliJ CE (Ultimate, правда, платная, но стоимость же символическая) и MS Visual Studio.

В .NET много библиотек, портированных с Java :)

Возможно. Если и так, то это показывает кто диктует моду. :) Хотя не проверял какого качества эти библиотеки — только помню Spring.NET и рядом не стоял с нормальным жавовским Spring.

Сори конечно, но зачем он .NET-у? Кстати, проект давно забросили, видимо авторы тоже решили не городить огород

По поводу IDE, есть Rider от JetBrains. Если я и пишу под дотнет, то только там)

Любопытно, я не знал о таком. Спасибо!

Visual Studio 2013 и новее бесплатна для некоммерческой разработки, и для коммерческой разработки в небольших компаниях.

Ну а IntelliJ CE бесплатна в принципе. Без оговорок. Eclipse, кажется, тоже, хотя точно не помню.

Бесплатна и опенсорсна)

Кажется сейчас сложно найти не MIT лицензию для дотнетных библиотек. И даже 10 лет назад (в 2011) было куча MS-PL-библиотек на CodePlex.
Ну, конечно есть платные библиотеки, но всё чаще платной там становится только поддержка.

Вы имеете в виду .NET библиотеки, написанные каким-то сообществом разработчиков с репутацией (типа Apache, в которых на основные грабли уже наступили до Вас и можно более-менее полагаться на качество этих компонент)? Или просто нечто бесплатное, что какой-то Вася написал за выходные, и мы не знаем, как хорошо оно работает, какие там баги, есть ли поддержка и т.д.?

Я не знаю, какие сообщества вы считаете имеющими репутацию. Тем более, что я больше погружен в клиентскую разработку, а вы видимо про бек. Так или иначе сходу вспоминаются Newtonsoft.Json, MVVMLight и другие

Да, я — бекенд разработчик и не трогал frontend уже лет 10. Я к тому что в жаве есть куча всего с MIT лицензиями от Google, Apache и т.д. — Spark, Velocity, Guice, Dagger и т.д. Есть DBMS типа, допустим, PostgreSQL.
Если в .NET есть бесплатные фреймворки и продукты такого масштаба — ну ок. Но кажется, что нет.

всё так, я её именно как пример MIT-библиотеки и привёл

а еще есть Scala. Там многое из того, что в жаве в библиотеках, идет тупо из коробки.

Да, кстати, хороший пойнт. Поэтому тем кто не любит жаву просто потому что там мало сахара (а у крутых пацанов на .NET его много), возможно, стоит посмотреть в сторону других JVM языков типа Scala/Kotlin.

Судя по минусам, на хабре преобладают .NET разработчики :)

А может просто утверждения спорные? да ну, бред какой.
Но 10 лет назад у меня сложилось впечатление, что любая мало-мальски приличная библиотека стоит денег за лицензию, никаких вам MIT и т.п.

Ну, 10 лет назад так и было. Хотя проблема там была не самим наличием бесплатных библиотек, а с их доступностью.


Однако, сейчас ситуация совершенно другая.

вы же про 2011й говорите?
О каких конкретно библиотеках идет речь. По моему опыту в dotnet core 90% функционала доступна из под коробки, либо есть библиотека от Microsoft с лицензией Apache License 2.0

Ну например логгирование в fluentd из серилог — и то и то супер-распространенные вещи. Лично мы сейчас используем либу с гитхаба в которой 5 звезд — и то я в нее фиксы заливал потомум что там куча приколов было а-ля "храним всё как строки" (в итоге нельзя в логе найти по предикату "число от 5 до 57").


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

Проблема в том, что обилие библиотек делает создание проекта с нуля очень сложным. Людям непонятно, что выбирать, какие преимущества/недостатки, как они сочетаются. В случае легаси и pom.xml все ясно, но с нуля, тут и я бы задумался, хоть опыт и есть.

Ну вот отсутствие нужной библиотеки делает создание проекта на порядок более сложным, чем если библиотек много )

Импорт логов из одной 3rd party в другую 3rd party, такого, да во фреймворке нет. То, что в гитхабе 5 звезд, может говорит, о том, что это не супер распространненая вещь?
Я не работал с fluentd, мы использовали kibana и newrelic, используем подход, похожий на dbones.github.io/2019/11/efk-with-serilog

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

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

Это ELK стек-то не супер распространенная вещь? :) А логстеш/флюент используются примерно с одинаковой частотой по моему опыту. Так что да, странно что этого нет.


Я не работал с fluentd, мы использовали kibana и newrelic, используем подход, похожий на dbones.github.io/2019/11/efk-with-serilog

Мы сейчас планируем перейти на принцип "пишем все подряд в стдаут а дальше проблемы девопсов". Одна проблема — непонятно пока, насколько перф стдаута хороший для таких делов. Локально у себя я получил 2МБ/с, что конечно же никуда не годится. Но я на винде — а там докер, это накладывает свои особенности. Есть подозрение что докер на один-два порядка быстрее писать будет. Ну или хотя бы надежда на это)

У нас докер контейнеры пишут в свои лог файлы, затем дифф этих файлов отправляются newrelic утилитой на докер хосте, все работает нормально, по крайней мере, с нашей нагрузкой

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

А как с этим в java?

Самое забавное, что в данном случае — точно так же, 4 звезды у структурного логгера :) https://github.com/nagaseyasuhito/sample-slf4j-fluentd


Даже не знаю как так получается. При этом обычный логгер который туда пишет имеет 200 звезд (что уже нормальное количество) https://github.com/fluent/fluent-logger-java

Значит, не самый удачный пример :)

Да, вот нарочно не придумаешь :)

А статистика именно по компаниям, склонным к использованию .NET или в целом? Потому что у меня эмпирические картины сильно отличаются. Там где fluentd редко наблюдается .NET. Там где .NET наиболее частая связка serilog+filebeat+logstash.

Я статистику не собирал. В моих проектах где я работал везде был ELK, на текущем L поменяли на Fluent, остальное все то же самое осталось.

Я статистику не собирал.

Значит перепутал. Адресовал вопрос этой фразе, думал частота была в смысле статистической величины:


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

А наверно речь шла о периодической. Год используют, год — нет))

Забавно, не видел такого прочтения))

Но 10 лет назад у меня сложилось впечатление, что любая мало-мальски приличная библиотека стоит денег за лицензию, никаких вам MIT и т.п.


Нам очень важно знать ваше мнение из 2011 года. Оно явно соответствует текущей обстановке.

сравните бесплатную IntelliJ CE (Ultimate, правда, платная, но стоимость же символическая) и MS Visual Studio.

Ага, давайте сравним полнофункциональную VS с поделкой, в которой нет:
— Profiling tools
— Spring, Jakarta EE, Java EE, Micronaut, Quarkus, Helidon, and more
— Swagger, Open API Specifications
— JavaScript, TypeScript
— Database Tools, SQL

Вот зачем мне IDE где нет даже подсветки JavaScript?
Вот зачем мне IDE где нет даже подсветки JavaScript?

Легко решается плагинами.

с поделкой, в которой нет

Вы ведь C#, но не Java разработчик и просто скопировали разницу между версиями, но не работали ни с одной версий на самом деле? Все эти функции опциональны, можно прекрасно разрабатывать Spring или SQL в Common версии и без них.

P.S. Я понимаю, что вы хотите заступиться за MS Visual Studio, но в данном случае, вы пишите о том, чего не знаете и нет, Common версия IDEA это далеко не «поделка».
Я 4 года писал на Java. И как уже говорил, пользовался Idea только лишь потому, что остальное еще хуже. И мне никак не хватало CE версии.
Если я хочу морочиться с плагинами я возьму VS Code.

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

Пятнадцать лет пишу без решарпера, что я делаю не так?

В 2019 есть почти все, что нужно, пара плагинов и codemaid мне достаточно. И работает это быстрее чем любой Rider
Пятнадцать лет пишу без решарпера, что я делаю не так?

Видимо тратите время на выполнение руками операций, которые могла бы выполнить машина) Я просто после решарпера пробовал пользоваться голой студией и у меня буквально каждые 5 минут был момент когда я хочу что-нибудь сделать (например, сгенерировать реализацию IEquitable для типчика или там переисать пачку ифов на паттерн матчинг) а вот нет такого функционала, не может студия. Постепенно старые рефакторинги появляются в ней, но и райдер/решарпер на месте не стоят. По ощущениям отставание идет на 5-7 лет по фичам. И фичей не из каких-то там марекитнговых проспектов, а те которые нажимаешь кейворд — ничего не происходит — идешь искать как делается в студии и понимаешь, что никак. И очень печально от этого на душе становится в этот момент.

Вы знаете, на все это уходит примерно 1% моего времени. У меня как-то на обдумывание и архитектуру уходит на порядок больше времени, чем автоматизация трех строчек IEquitable. Для меня подвисания редактора при печатании (я не знаю пофиксили ли это, но jetbrains иногда подвисает и тупо буква проглатывается, причем это и в Idea было) бесит гораздо больше.
Видимо тратите время на выполнение руками операций, которые могла бы выполнить машина

У меня постоянное ощущение, что машина стараниями решарпера выполняет слишком много операций)) Уже не первый год пытаюсь заставить себя на него пересесть. Рефакторинг, подсказки, неплохой тест-раннер, всё круто, беру. Но как начинается суровая работа… он своей скоростью убивает на порядок больше, чем даёт производительности труда. Буквально на днях пришло очередное обновления, после которых он любит опять включаться, хотя я ему сказал суровое "disable". Не очень большой проект, гдето 150K LoC. Вытерпел первую загрузку, с тотальным фризом секунд на десять и минутным подтормаживанием то там, то сям. Думаю, сейчас прокэшируется и дальше должно быть лучше. Но любой чих, любая навигация, любая подсказка — это +0.5-2с (Ryzen 5950X, RAM 128G, NVMe PCIe 4.0). Вроде казалось бы ерунда, но лично меня просто жутко выбешивает. Прыжки между фичами вообще беда. Может это исключительно мой паттерн. У меня в силу SRP/ISP огромное количество навигаций. А для рефакторинга я его могу раз в неделю включить и спокойно навести красоту.

Ну вот у меня 3800х, проекта до миллиона строк вполне себе шустро открываются.


А от решарпера со студией я отказался из-за тормозов, да. Хотя даже когда сидел на студии предпочитал иметь тормоза чем не иметь фичи. Ну да, неприятно если фриз на рефакторинг занимает 10-20 секунд, но руками-то я буду это делать полчаса. Лучше уж подождать.


Ну а потом райдер подъехал и теперь вроде как лучшее из двух миров имеем.

Так шустро в райдере или в решарпере? Райдер у меня достаточно бодро работает, правда там другие заморочки. Но это уже моя специфика, не всем нужна поддержка iOS Local Device с hot reset.

В райдере. Решарпер тормознутый капец. Но это и понятно почему: он же со студией в параллель работает. А в райдере только он.

Я наверно не в тему буду, но это вы обсуждаете только написание приложений под вендой, в то время как Rider, работает на трех платформах) И кстати, имеет в своем составе сразу все плюшки ReSharper. По производительности, пока не приведете цифр — это просто субъективное мнение)

+ там 64 бита есть, насколько я помню VS была всю жизнь 32 бита?
Якорь в связке VS + Resharper это Решарпер. Удалите его и будете удивлены, насколько быстро все работает.

И да, я разрабатываю под винду, с WSL2 теперь даже смысла нету в иной системе, даже докер работает почти нативно.
Якорь в связке VS + Resharper это Решарпер. Удалите его и будете удивлены, насколько быстро все работает.

Но и фичей не будет. Если по чистой скорости сравнивать то Блокнот ничего не превзойдет. Только сидеть в нем все же больно почему-то. Видимо, не в одной скорости дело.


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


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




У меня в команде 7 человек, на выбор была студия ( + опционально решарпер) и райдер. Изначально все сидели на студии, райдер купили 2 года назад и сказали "кто хочет — юзайте студи. кто хочет — райдер."


Прошло 2 года. На студии не сталось ни одного человека. Последний перешел пару месяцев назад, когда в райдере появилась наконец кнопочка "сгенерировать докерфайл по проекту" (в студии-то она давно была). ИСЧХ сидел на студии без плагинов, прям как вы.


И пока отзывы команды исключительно положительные.


Вы знаете, на все это уходит примерно 1% моего времени. У меня как-то на обдумывание и архитектуру уходит на порядок больше времени, чем автоматизация трех строчек

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

Меня забавляет, как люди строят предположения, что у кого-то, кто на дотнете 15 лет не было решарпера никогда. Я даже CodeRush пробовал.

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

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

Да и вообще обсуждать эту экономию на спичках, когда люди разрабатывают на ноутах вообще смешно. Компиляция проектов дома на 5950 — 15c, на ноуте — 50 сек. Сколько решарперов сэкономит это время?
За деньги на решарпер поставьте лучше десктопный процессор.
Меня забавляет, как люди строят предположения, что у кого-то, кто на дотнете 15 лет не было решарпера никогда. Я даже CodeRush пробовал.

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


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

90% любых задач — это рутина. Да, это инструмент для разработчиков, а не для архитекторов. Последние 80% времени проводят в джире, зуме и майндмапах, им эти решарпер до лампочки. А вот код набирать — очень даже помогает. Но я верю, что есть люди у которых каждый день фуллтайм инновационные ресерчи. И код они при этом не набирают — просто смотрят в экран пока не снизойдет озарение. Математик заходит в комнату, видит, что решение есть и уходит.


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

Ну решарпер и правда лагает, райдер же загружает +- как студия, чем больше проект тем быстрее грузит. Собственно, история райдера началась с того что студия не могла осилить открыть проект решарпера.


Да и вообще обсуждать эту экономию на спичках, когда люди разрабатывают на ноутах вообще смешно. Компиляция проектов дома на 5950 — 15c, на ноуте — 50 сек. Сколько решарперов сэкономит это время?
За деньги на решарпер поставьте лучше десктопный процессор.

А одно другое исключает? Естественно, достойное оборудование это такая же часть рабочего окружения как и софт. У меня рязань 3800х к примеру. И райдер, да. (Хотя если точнее у меня полный пак, потому что мне и раст нужен, и питон, и в базу лазить, одним паком дешевле выходит)




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


50 секунд компиляции кстати это что-то очень странное и видимо с неправильно настроенными зависимоятми. Я давно больше 5-10с компиляции в дебаге (даже на ноуте) не видел. Последний раз минутные компиляции были на огромном монолите где криво были прописаны зависимости, поэтому "от греха" делался полный ребилд на каждую сборку, а то при обычном билде можно было чего-то не досчитаться в артефактах и словить проблемы.

От решарпера в студии я отказался как вышла 2019 стабильная.

Пусть даже отстает немного по всем-всем фичам. Но честно, дискомфорта не заметил.

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


Сравнивал я с 2019 16.6 конечно же (потому уже перешел окончательно с нее)

НЛО прилетело и опубликовало эту надпись здесь
А я, справедливости ради, таки отмечу, что многих хороших вещей в .net'е нет. Ну, да, многие простые сценарии с CRUD — покрыты, но банально, хочу я спуститься на уровень пониже, допустим поверх TCP/IP поработать — бери сокет/TCPListener и делай все руками, ничего уровня Netty или MINA — нет, попытки портировать их — нельзя пускать в прод, NetCoreServer — сыроват и все равно намного меньше возможностей. И я могу еще сотню-другую таких же примеров из современного .net привести. Шаг влево-вправо от типовых задач — бери и делай сам.
НЛО прилетело и опубликовало эту надпись здесь
Ну вот есть сотня-другая железок китайских. Они используют свой проприетарный протокол для сетевого взаимодействия, а производитель предоставляет только описание этого протокола. Нужно сделать сервер сбора информации по этому протоколу, чтобы он не был подвержен C10k, потому что кто знает сколько этих железок будет в бедующем.
Так вот, в Java — есть решения, в которых все уже готово, соединение воспринимается как абстрактная сессия, готовы события, готова планировка IO, а я могу просто реализовать парсер, прикрутить БД и жить себе спокойно.
В .net я буду сидеть и с сокетами играться, реализовывать систему событий, буду делать свой пул буфферов и прочими малополезными вещами заниматься.
Да, сейчас можно костылями часть работы переложить на кестрел, но это все еще костыли.

Что-то я вас не понимаю. Какую такую систему событий надо сделать? Зачем делать пул буферов когда есть ArrayPool и MemoryPool? Зачем нужен свой планировщик IO, когда есть пул потоков?

А что такого хитрого сделано в Netty?


Так-то для HTTP есть HttpClient и Kestrel. Для Protobuf есть, э-э-э, protobuf. Поддержка TLS тоже есть. Какие ещё готовые протоколы Netty вам предоставляет?

Ничего что в сентябре выходит java 17 и писать статью о том какие фичи вы встретили при переходе на java 8 это слегка странно

Статья имеет большое исторический контекст) Про фичи джавы 17, Вы сможете и без меня узнать)

началось активное развитие Xamarin. Разработчики получили возможность писать шустрые приложения на iOS и Android;

Развитие Xamarin началось ещё в 2011 когда это был mono.ios/mono.android и это из xamarin в .NET core тянут некоторые фичи для AOT и поддержки мобилок

Согласен. Забыл в статье сделать акцент на то, что MS по сути узаконила Xamarin, и Mono стал отличным подспорьем для вывода .NET в OpenSource

MS купила Xamarin. Узаканивать его особо смысла не было — никто mono не притеснял. Тем более что был стандарт для C# (и сейчас его актуализировать хотят).
Более того, когда МС выиграла тендер на трансляцию инаугурации Обамы, они с моно поделились исходниками Silverlight, что бы последние Moonlight допилили к трансляции.
А как в Java обстоят дела с потреблением памяти? Периодически запускаю STM32 Cube (использую только для выбора периферии и ножек контроллера) — так он сходу отъедает 3,5 ГБ ОЗУ. IDE на базе Эклипса тоже сразу после запуска отнимает минимум гигабайт. 5...10 таких запущенных приложений — и приехали…
так он сходу отъедает 3,5 ГБ ОЗУ. IDE на базе Эклипса тоже сразу после запуска отнимает минимум гигабайт. 5...10 таких запущенных приложений — и приехали…

Java приложения, особенно IDE сразу забирают много памяти «про запас». Условно, крупное Java приложение может забрать практически всю свободную память ОС даже если память прямо сейчас не нужна.

Логика тут простая — так быстрее работает код и реже требуется вызывать сборщик мусора, а так как Java оптимизировано для серверных приложений одно приложение на сервер/докер контейнер — это имеет смысл.

Но есть способы ограничить апетиты Java приложений как средствами Java, так и OC.

А в целом, с памятью у Java так же как у всех — если разработчик ее не экономит и не следить за утечками — потребуются гигабайты, если экономит и следит, Java может жить на считанных мегабайтах. Но вообще, если Java приложение сразу забирает 5Гб, это не значит, что оно не сможет запуститься и нормально работать на 50Мб.
Иными словами, если на компьютере будет заканчиваться память, то такое приложение умерит свои аппетиты, само или силами ОС, и не начнут падать другие приложения из-за нехватки памяти? Спасибо.

Файл подкачки отключен — SSD.

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

Windows Mobile разработка: она ужасна во всем.
А в чем она ужасна? когда (в какой год) вы её смотрели? С чем сравниваете.
смотрели в 13-18м, сравниваем с андроидом и айфоном)
и в чем конкретно она ужасна-то?
Андроид разработка стала более менее норм как раз с выходом 4.4, до этого жесть полнейшая, и детские баги в сдк, андроид студия только в 13 появилась и куча всего другого. Да и 4.4 такая себе на самом деле.

iOS разработка кажется никогда не была хорошей. Отвратительное IDE, ещё и тормозит во всём, что касается свифта. UI стрёмный был всегда в разработке, постоянные проблемы в разном поведении его между версиями iOS. Сейчас вроде swiftUI более вменяемый, но проблемы с разными версиями никуда не делись.
Собственно, я старший товарищ binali в 13-16м.

Если кратко: очень много нужно стараться, чтобы в Windows Mobile получилось удобное в использовании и приятное зору приложение. Конечно, есть кастомные контролы и тулкиты, которые решают эти проблемы, но как-то слишком много телодвижений, как по мне.

То ли дело в iOS — вся разработка изначально под тач-скрин, с хорошими гайдлайнами по дизайну, и это по-умолчанию (хотя старание никто не отменял, конечно).

(под Андроид не разрабатывал да и не охота)
ДИСКЛЕЙМЕР: конечно, много в таких мнениях вкусовщины, но куда ж без нее :)
В 13м-16 уже был Windows Phone с хорошими гайдлайнами заточенными под тач. Вы под Winmo6.5 в 13м году писали?
Именно так. Это Казахстан, детка :)
Круто. Как раз в 13м году у ней поддержка закончилась… Очень актуальные сравнения.
Мы разрабатывали приложения под защищенные смартфоны одного крупного южнокорейского производителя. И почему-то очень долго на рынке не было аналогичных Android устройств по схожей цене.

И это всё под бюджет шнурка для обуви в стране, где айтишка на 97% состоит из продажи железа!
Да я понимаю, это нормально. Просто это не делает сравнение более корректным.
Что по Вашему ни ок? Что мы сравнивали: WinMobile с Android и iOS? Кстати, я принципиально молчал о Windows Phone, так как это совсем другая история. Которая кстати тоже печально закончилась.
Да, что вы сравниваете разработку под ОС, которая устарела на момент разработки и разработку под актуальную ОС. Сравнивать-то конечно можно, но кажется результат ожидаем.
Да, я просто говорил о том, с чем мне пришлось столкнуться :)
НЛО прилетело и опубликовало эту надпись здесь

Что Java что C# — языки заходящей эпохи. Другое дело JVM — тут вопросов нет, рантайм божественный, думаю будет источников ещё многих крутых языков. CLR — meh, ничего, но не особо.


Если же ни сишарп ни джава то что? Ну, я лично присматриваю себе скалу — тот же хороший рантайм, но без проблем джавы: нормальные ду-нотации (можно писать асинки удобно), эффекты, хорошие библиотеки и коммьюнити. И платят хорошо. В общем, что ещё для счастья надо.

за Java судить не буду, со стороны кажется, что если оракл не начнёт суетиться, то котлин и вправду съесть её может. Но так же кажется что оракл таки начал суетится.
но чем C# — язык заходящей эпохи-то?

Ну у них груз обратной совместимости же. Из очевидного — nullable by default, то что все типы могут быть нуллами. В шарпе вкорячили NRT (который немного помогает, но глобально проблему не решает), в джаве его пока нет, но что-то подобное будет. АДТ обещают-обещают, но все ещё нет. Шейпы обещают-обещают, но все ещё нет. Концепты, макросы, инлайн дсл… Есть много вещей которые сильно бы упростили разработку, но каждую версию насыпают просто пачку сахара, у меня скоро диабет начнется )


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


Это нормально. Все же понимают что джава в 2100 году не будет супер распространенным языком, и скорее будет доживать свой век в каких-нибудь нишевых местах как сейчас кобол. Вопрос только какую дату в интервале 2021-2100 считать датой когда джава устареет. Мне кажется, что достаточно близко к его началу.


Впрочем, все это субъективные оценки, а практик посмотрит на количество библиотек/трудозатраты на реализацию фичей/сопровождаемость/наличие спецов. Тут конечно у джавы (да и у шарпа) пока все прекрасно. Но хотя каждая новая версия языков в целом становится лучше, скорость улучшения неизменно падает. Впрочем, это естественный процесс для любой области.


image

Оракл как с выходом java 8 очень сильно начал шевелиться, сейчас каждые пол года выкатывают новую джаву - уже скоро 17 выйдет и на неё начнут переходить как на долгоживущую.

НЛО прилетело и опубликовало эту надпись здесь
так и вы заканчивайте: закончилось слиянием с .net core.
НЛО прилетело и опубликовало эту надпись здесь
в реакт нетив они только на винде вкладываются. Я так понимаю это какие-то договорённости с фейсбуком. Да и похоже им так проще найти разработчиков: стор на xbox, и приложения xbox на десктопе как раз на нём и написаны.

Но да, не клади яйца в одну корзину.
Я отвечу так: «Java обрела популярность именно из-за OpenSource-нацеленности. Бизнес не боялся, что завтра придут какие-то чудаки из Sun или Oracle и начнут качать свои права. .
Дело было вовсе не в каких-то хороших или плохих качествах. Это была сугубо корпоративная война и практически ничего, кроме корпоративной логики, там не было. Уж об облегчении жизни программистов никто точно не заботился. О качестве программ — аналогично.
И об open source тоже. Хотя — не совсем так, он использовался активно как инструмент бизнес-войн. Нужно насолить конкуренту — вкладываем прямо или косвенно сотню миллионов долларов в открытые разработки, ломая конкуренту бизнес на миллиард. Себе тоже, но, если всё равно проигрывал, то сойдёт.
По поводу войны, очень согласен. Но все же, у меня такое ощущение, что MS немного опоздали с OpenSource версией .NET.

С другой стороны лучше поздно, чем никогда.
С другой стороны, сделали они гораздо лучше. Если бы открыли лет 10 назад, могло бы быть что-то совсем убогое. А сейчас это имхо топ 1 стэк по удобству. Из коробки можно все.

Но зато концепты вроде Compiler as service подоспели ко времени, у джавы на то время костыли костылей были, вроде Eclipse Compiler. Да и сейчас я не уверен, что с этим на джаве все в порядке.

С# — это улучшенная Java

Не соглашусь с вами. Так может и было до года этак 2005(Java User Migration Path — JUMP), Type Erasure ни о чем вам не говорит. Асинхронные модели очень разные, опят же.

В том моменте я больше говорил как человек, который потрогал шарп и джаву будучи «уверенным пользователем ПК».
Холи-холи-холи-холи-варчики!
/*Бизнес не боялся, что завтра придут какие-то чудаки из Sun или Oracle и начнут качать свои права.*/
А потом оракл таки начал качать права: )
Это точно :)

А где оракл качал права?

Например вот https://habr.com/ru/company/pixonic/news/t/550886/

С Jakarta EE уже тоже почти не заботишься о выборе библиотек: на сервере приложений уже есть всё необходимое.

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