Комментарии 97
Google Translate сочится из всех щелей; тяжело читать
Потом мигрировали на java 1.8, 11, пошли другие проекты с spring, maven и так далее. Я свое мнение поменял. Все довольно таки круто. Cерверное приложение я предпочту делать на java, чем на node.js. Java развивается как язык.
Ява тормозит.
Современные JIT-компиляторы очень близки по производительности к нативным программам. Огромное кол-во языков умеют работать на них, даже те, которые изначально задумывались иначе.
Ява сложнее более современных языков вроде c#
Не вижу особой разницы, о чем идет речь? Есть разного рода сахар вроде свойств, linq и тд. Но с точки зрения внутренностей, между CLR и JVM для обычного пользователя особой разницы нет. Если речь идёт о бойлерплейте, то оба языка не идут ни в какое сравнение с go/python.
кросплатформенность (правда без интерфесный форм)
Особенно без интересных форм. Кроссплатформенность дотнета выросла с момента релиза net core, но все еще находится на достаточно низком уровне, для написания бэкенда есть тысячи куда более надежных решений.
Я бы сказал, что C# даже посложнее в плане языковых фич, но дает больше возможностей.
Кроссплатформенность дотнета выросла с момента релиза net core, но все еще находится на достаточно низком уровне
Почему этот уровень низкий?
Эти dll и на винде не настоящие — в них по сути запихан IL код. Вы можете скомпилить прогу в dll, а запустить ее где угодно без перекомпиляции, поэтому нужен один формат на все платформы. А само расширение сложилось исторически, переименовывать его сейчас во что-то другое нецелесообразно.
.dll в .NET это же ни разу не .so
Это как просить переименовать .jar в .so
В остальном - "так исторически сложилось" :)
А C# изначально планировался бегать под виндой онли и сейчас в него кроссплатформенность потихоньку допиливают.
Дот нет изначально планировался кроссплатформенным. Другое дело, что с точки зрения Microsoft кроссплатформенность - это способность работать только под виндой ) Что поделать, если для майкрософта до не давнего времени линукс не существовал как класс?
Как насчет System.Drawing и его альтернатив?
Процитирую комментарий из статьи про него:
NetCore требует libicu, libgssapi-krb5-2, liblttng-ust0, libssl1.0.2 и zlib1g на линуксах, лишние зависимости для вроде бы кроссплатформенного приложения, короче говоря — не нужно, при наличии альтернатив в виде Go, который собирает бинарник вообще без зависимостей, даже без libc.
Потому что GUI нужен кому?
Microsoft для Windows и Apple для Mac, никто другой инвестировать в это ресурсы не будет.
в С# больше синтаксического сахар, плюс он как более молодой язык посмотрел на некоторые грабли на которые наступила Java и сделал выводы. Его основная область применения десктопные приложения, в основном виндовые, но в последнее время сделан ряд шагов к кросплатофрменности.
в Java больше возможностей для fine-tune-инга чему способствует проработанная Memory Model и целый зоопарк Garbage Collector-ов на все случаи жизни. Очень большое количество внешних библиотек на все случаи жизни, на мой взгляд намного богаче чем у C#. Используется для серверов из которых 99% Linux.
Так вы же сравниваете теплое с мягким. Я говорю про сложность языка, а вы про обилие синтаксического сахара и многословность. При этом очевидно, что в случае перехода из одного языка в другой будет ощущаться некоторый дискомфорт. То есть вполне нормально, что я, как джавист, страдаю от шарпа, а вы, как шарпист, от джавы.
Что касается Type Erasure - это конечно неприятный эффект, но в обычной разработке сталкиваешься с ним крайне редко (я помню, что вроде как-то были с этим проблемы, но даже не вспомню когда и с чем это было связано). А по поводу многословности, то в условиях когда код пишется один раз а читается 100 и при условии, что все громоздкие конструкции за тебя генерирует IDE, лично я не считаю это хоть сколько-нибудь значимой проблемой.
У Type Erasure два минуса:
- на генерируемом и/или модифицируемом в рантайме коде можно налететь на проблемы
- есть класс задач, которые было бы легче решить, если есть возможность узнать generic класс.
И про второе аналогично. Чем не хватает текущих способов? И какие задачи это бы решило?
Первое нужно тем, кому не хватает производительность jvm и они пытаются её тюнить. Насколько это эффективно — не знаю, я в такие дебри ни разу не забирался. Среднему разработчику — это нафиг не сдалось.
Со вторым я в своей жизни разработчика сталкивался, но давно, поэтому подробностей сейчас не помню — помню, что в конечном итоге просто сменил архитектуру и получив чуть меньшую функциональность задачу всё-таки реализовал..
> Java больше возможностей для fine-tune-инга чему способствует проработанная Memory Model и целый зоопарк Garbage Collector-ов на все случаи жизни
Все как бы немного наоборот - зоопарк сборщиков это не то что бы преимущество, а просто следствие отсутствия value objects, в итоге нагрузка на сборщик неизмеримо больше, чем в C# или Go, где by value обьекты присутствуют. Я помню в Minecraft было нормой выделять 600 мб/с мусора из-за использования векторов/матриц. В библиотеке JBullet автору приходилась написать инструментацию байткода для использования пула векторов/матриц. В C#/Go такие проблемы отсутствуют как класс.
Это просто говорит о том, что Minecraft не очень хорошо написан. А зоопарк сборщиков нужен для того чтобы можно было подобрать необходимый баланс между throughput и latency или чтобы работать на куче в десяток терабайтн
>C4ET4uK 07.05.2021 в 08:04 Это просто говорит о том, что Minecraft не очень хорошо написан
Там такая история, что первоначально позиции были заинлайнены в объекты, и метод перемещения выглядет как-то вроде setPosition(1, 2, 3), что обновляло 3 поля примитивных типа без выделения памяти. Но такой подход очень неудобен, т.к. простейшие векторные вычисления превращаются в спагетти. В итоге было переписано в код вида setPosition(new Vector(1, 2, 3)) что моментально увеличило нагрузку на GC до 600 мб/с. Ну и pointer chasing если это массивы объектов (а их в Minecraft много)
Мутабельные векторы тоже так себе идея. Если где-то случайно зашарить объект по ссылке не склонировав, то внезапно позиции рандомных объектов связаны и поди отладь что не так
Просто геттер должен возвращать закэшированную немутабельную копию. Мне показалось это достаточно очевидным, чтобы не упоминать.
>Просто геттер должен возвращать закэшированную немутабельную копию
В конечном счёте много мороки на ровном месте: храним мутабельные, которые нельзя шарить, возвращаем иммутабельные (или аллокация, или оборачивать в интерфейс). Поэтому два пути: лепить трудноподдерживаемое спагетти или писать по-нормальному, но инвестировать в набор GC рантайма для файнтюнинга.
Его основная область применения десктопные приложения, в основном виндовые, но в последнее время сделан ряд шагов к кросплатофрменности.
Вот любопытно, сколько на одно выпущенное десктопное приложение сейчас приходится игр, сделанных на Unity. Не окажется ли так, что основная область применения C# сегодня ― это кроссплатформенный геймдев?
Потому что они написаны на фреймворке который умер более 10 лет назад. Хотя по сравнению с электроном все равно работает быстро.
Скажите, почему тормозит буквально любое гуевое приложение на яве?
Это не соответствует действительности.
Из примеров: idea
idea это не любое приложение, это лучшая среда разработки для java, kotlin и кучи других языков. Можно было бы сказать, что она тормозит, если бы было другое приложение со сравнимым количеством фич, которое работает быстро. Но его нет.
и родной ораклячий девелопер
Почему тормозит девелопер сказать не могу, так как не пользуюсь. У девелопера есть нетормозящие аналоги сделанные на других языках?
Ява скандально известна аффилированностью с корпорацией Oracle, которая решила внезапно повести себя по-свински.
Java — это open source под GPL, в который контрибьютят несколько десятков компаний. И сам язык, и компилятор, и виртуальная машина, и стандартная библиотека, и всё остальное свободны. Oracle принадлежит только торговая марка.
На java написано огромное количество больших сервисов, как старых так и новых.
Вполне хватает библиотек, чтобы не писать все с нуля.
Единственное что умирает, так это ваши "кросплатформенные" десктопные приложения.
Современная кроссплатформенность — это Mobile плюс Web, там C# и не пахнет.
Кому нужны скриптовые языки? Python пригоден для прикладных задач типа DevOps и ML.
Единственное с чем соглашусь что не стоит начинать новый проект на Java… когда есть Kotlin (но Java тоже придется выучить)
c# сегодня наиболее универсальный язык для всего. Есть ограничения по кросплатформенности, пока это единственный минус
Так этот минус как раз и противоречит универсальности.
А еще родная VS прекрасна. Под линуксом, правда, ее нет
Универсальна, но нигде кроме венды не кроссплатформенна, vs прекрасна, но нигде, кроме венды её нет. Шикарная штука, я щитаю — надо брать! :)
только VS Code
Отстой отстойный. Если "большой" VS на него похож, то это минус, а не плюс.
А idea платная.
В той же степени, что и VS
В бесплатной версии нет даже форм.
свингового уи дизайнера что ли? А кто-то ещё пишет на свинге?
В чем разрабатывать под явой — неясно.
вот в идее и разрабатывать. Если нужны спринговые фишечки, то пинать работодателя — пусть покупает рабочий инструмент.
Единственное с чем соглашусь что не стоит начинать новый проект на Java… когда есть Kotlin
Или дождаться рекордов с тонкими потоками (их там снова не переименовали случаем?) в основной Джаве. Это закроет подавляющую часть преимуществ Котлина.
И Вальхаллу заодно дождаться бы. Тогда по скорости перекладывания джейсонов посоревноваться можно будет много с кем. Не то чтобы это имело смысл, но приятно же.
Рекорды уже пришли.
Вальхалла по сути итеративно приезжает в джаву, часть изменений уже есть, самые интересные для меня недавно пошли в работу.
Вот лум да, растраивает, с его вечными переносами, хотя он уже должен был релизнуться, а сейчас и даты нету(официальный ответ от команды лума когда будет готов, тогда и выпустим)
А что там из Вальхаллы приехало уже? Ключевое вроде даже не начали в основные билды заносить.
Обоснований куча. Для меня это шанс обновляться маленькими шагами, а не огромным скопом. Плюс возможность иметь фишки раньше. Не надо относиться к неLTS как к бетам.
Не надо относиться к неLTS как к бетам
Увы приходится. Продакшен, деньги вот это вот все. Обоснование должно быть достаточным чтобы обосновать даунтайм и миллионы денег. Миллионы денег не из моего кармана, но обосновать зачем неLTS версия в проде надо будет.
Хорошо если на 17 удастся до НГ перейти. Даже в это слабо верится, но хотя бы надежда есть.
неLTS это именно беты. Там в каждой есть критические баги. Которые никогда не будут исправлены в текущей версии. Обновляться на следующую это ловить потенциальные новые баги.
Править jdk самим это вообще ужас. Кастомные сборки jdk, даже связываться не хочется.
Для меня это шанс обновляться маленькими шагами, а не огромным скопом.
Обосновать зачем пересаживаться на новую LTS весию я могу легко.
Начать с: Попробуй найми людей на jdk9.
И заканчивая миллионом оптимизаций между 9 и 11. Эти оптимизации экономят много серверов.
В итоге даже два месяца работы отбиваются легко. Обосновать как нефиг делать.
А вот как обосновать хотя бы пару недель два раза в год для пересаживания на неLTS с учетом потенциальных багов в ней я не знаю.
Увы приходится. Продакшен, деньги, вот это вот все.
Конечно, я не знаю конкретно вашей ситуации, но в моей (аутсорс, финтех) тоже есть продакшен, от которого зависит и финансовое положение и репутационное заказчика. Обновляемся каждый раз до свежего релиза уже 2+ года спустя примерно месяц после его выхода.
неLTS это именно беты. Там в каждой есть критические баги.
Можно примеры таких багов?
Единственный баг, который реально словили за всё время — описан в этой статье (сами с ним не разобрались, а просто на бою накинули ресурсов). При этом наверняка были какие-то тонкости, которые время от времени решали, но это было быстро и незаметно.
Поэтому я всё-таки склонен считать, что релизы это именно релизы. Для достаточной уверенности можно не использовать preview features (я использую), и подождать хотя бы первого Update.
А вот как обосновать хотя бы пару недель два раза в год для пересаживания на неLTS с учетом потенциальных багов в ней я не знаю.
Ваши "2 недели 2 раза в год" — как-то очень завышено. В среднем это от 1 часа до 1 дня. Иногда (12 -> 13 и 13 -> 14) уходило по 5 минут на Find & Replace. Как раз то, что даже можно не пропихивать бизнесу, а просто взять и сделать, потому что обсуждать дольше (естественно, речь про один среднего размера проект на единицы микросервисов, а не "целый банк").
Единственное, что меня реально пугало бы в любом отдельно взятом проекте — миграция с 8 на 9+.
Можно примеры таких багов?
Да. Можно поискать по трекеру. Все что задело 11, 16, 17 версии точно есть и во всех промежуточных. Все что задело 16 и 17 и не связанно с новым функционалом с большой вероятностью есть и в 15.
SIGSEGV bugs.openjdk.java.net/browse/JDK-8254790
GC падает bugs.openjdk.java.net/browse/JDK-8246468
Еще можно вот так по разным минорам 11 посмотреть. Они почти все есть и в более новых jdk www.oracle.com/java/technologies/javase/11-0-8-bugfixes.html
Чем свежее минор, тем более поздние версии jdk в которых баг исправлен будут.
И так далее. Понятно что вы можете никогда не встретится с ними, но сама идея что может быть баг который никогда не поправят и скажут переходите на следующую версию пугает.
Как раз то, что даже можно не пропихивать бизнесу, а просто взять и сделать, потому что обсуждать дольше (естественно, речь про один среднего размера проект на единицы микросервисов, а не «целый банк»).
У меня проект немного побольше. И времени тоже уйдет немного побольше. Я не просто так такие сроки написал.
Пусть даже я тоже могу взять и сделать. Пару недель времени спрятать мы все можем.
Проблема в обосновании возникет после того как прод развалится. Надо будет выйти и рассказать зачем я обновил jdk и что я буду делать чтобы прод так же второй раз так же не развалился. Вариант ставить сделующие неLTS jdk и верить что в них мы не развалимся очень слабый. А других в общем-то и нет. Я после такого сам себе скажу что надо откатываться на LTS.
Что делать с LTS версией в таком случае понятно. Накати последний минорный релиз, если повторяется ищи конкретику и пиши баг репрот. Поправят.
Единственное, что меня реально пугало бы в любом отдельно взятом проекте — миграция с 8 на 9+.
Миграция 9 -> 11 у нас как раз и заняла что-то ближе к 2 месяцам. На основе этого я и предсказываю сроки таких же обновлений.
Java тормозит на запуске, особенно холодном, что сильно заметно по GUI и консольным утилитам. Но горячий сервер-то не должен тормозить, особо нет причин для этого. JVM это state of the art.
JVM это state of the art
Не всякая JVM. Точнее не так — state-то они state, но каждая по-своему. Что, в общем-то, логично, разным приложениям нужны разные оптимизации. Кому-то например нужен быстрый старт — у них внутренние формы всех классов, грубо говоря, дампятся на диск, и от того Java не тормозит на запуске. А кому-то не нравится появляющаяся из-за дампа дырка в безопасности, и там загрузка множества классов идёт "честно", но подольше.
Доводилось сравнивать реализации VM различных языков (как хобби люблю ковыряться во внутрянках рантаймов) и по моему скромному мнению Hotspot это самая продвинутая VM (по крайней мере, из мейнстримовых) по числу оптимизаций и прочих плюшек (V8 наверное где-то рядом). Правда, большая часть оптимизаций это попытки исправить неудачные моменты языка...
То, что на Java часто овериндженирят - это уже другой вопрос.
Есть способы ускорить холодный запуск. Например CDS
Кому важен холодный старт те сейчас обычно компилят граалем в нативный код. Тем более что и в спринге наконец подъехала поддержка(честно говоря не ожидал с учетом того сколько у спринга завязано на рантайм)
Ява тормозит
Джава-пожалуй один из самых быстрых языков с gc, пожалуй только го может сравниться, но очень сильно зависит от сценария использования(go гибкий, но в своей нише очень хорош)
Ява сложнее более современных языков вроде c#.
Это джава-то сложная? По-моему один из самых простых языков синтаксически, большнство джаву хетят как раз за отсуствие сахара и примитный синткасис, но сам язык предельно простой.
Ява считается устаревшей и теряет популярность
Кем простите считается?
Начинать новый проект на яве выглядит безумием.
Это как с долларом/капитализмом в некоторых кругах.
Вот уже 200 лет хоронят, а похоронить не могут. С Явой также. Она нас всех переживет. И, кстати, вокруг экосистемы Явы выросли, например, Котлин. Про который слышны только хорошие отзывы. Так что есть варианты.
При использовании сторонних библиотек в Java вы всегда точно знаете, какие типы нужно передать методу
null и Object смеются над этим утверждением
они могут быть уверены, что не выстрелят себе в ногу из-за управления памятью или гонок данных.
много народу так поначалу думало
null и Object смеются над этим утверждением
Ну я лично все реже встречаю код, где Object в качестве типа данных используется. Иногда встречаю еще, в пережитках пришедших из java 1.4.
И null все чаще заменяется Optional, что имхо повышает шанс, что люди подумают, что передать в метод и что могут получить.
@NotNull и @NullableОни компайл тайм. Не влияют на скорость, отлично показывают и гарантируют ожидаемые параметры. Рекомендую.
@NotNull останавливает компиляцию с ошибкой. В лучшем случае это хак (а по-видимому это вообще не про типизацию, а про реайлтайм проверку).Java и C# отталкивают именно из-за этой особенности. Никогда целиком не понятно, какого типа у меня переменная.
Идея слишком раслабляет. Начинаешь путать что именно ту или иную штуку делает.
Хотя в общем какая разница? Когда одна IDE у всех это удобно. Одни проверки, одни дефолты. Не надо как плюсовики мучаться.
www.jetbrains.com/help/idea/nullable-and-notnull-annotations.html#nullable
@NotNull в сигнатуру функции, то Intellij станет ругаться «у этой функции есть пользователи, которые теоретически в неё могут передать null»? Любое изменение в коде должно гарантировать совместимость типов. В целом, можно конечно на основе этой аннотации придумать статический анализатор типов, который будет считать все объекты T|null, кроме помеченных @NotNull. Но… 1) Такого анализатора, наверно, нет.
2) В Java нет и не будет ничего подобного тип-суммам, поэтому такой подход чужероден
3) Нет синтаксиса разворачивать такой тип, кроме
if (a != null), который слегка неочевиден.4) В реальной разработке тип T нужен намного чаще, чем T|null, то есть именно он должен быть по умолчанию.
Лучше не жевать кактус, а сразу взять Kotlin для нового проекта, по-моему.
Ну вам же только что сказали, что есть. Да оно будет высвечивать жёлтое предупреждение об ошибке. Далее — можно в билде мавена настроить, чтобы и он тоже падал, при обнаружении нарушений данного контракта. Ну что поделаешь, Java был создан, когда нулл был в тренде. Гослинг, если мне память не изменяет тоже каялся по поводу включения понятия null в Java… но отменять десятки лет обратной совместимости… в общем не стоит оно того.
Статический анализатор тоже есть. Он как раз в Мавен плагином подключается и фейлит сборку при соответвующих настройках.
Проблема на самом деле ровно одна: Что считать дефолтом? Все Nullable и размечаем только NotNull или наоборот все не NotNull и размечаем наоборот Nullable. Размечать и то и то оверкилл.
Второе вроде как удобнее, но куча старого кода не соответствует. Приходится первое чаще использовать. И оно вообще вперемешку иногда бывает в большом проекте.
В Java нет и не будет ничего подобного тип-суммам, поэтому такой подход чужероден
Не совсем так. Multi-Catch:
try {
...
}
catch (IllegalArgumentException | IllegalStateException e) {
...
}
catch (Exception e).Нет, не просто приводится. Этот блок действительно ожидает именно один из указанных типов исключений. Более того, там есть дискриминация по типу. То есть если сделать вот так:
private void handler() throws IOException {
try {
...
} catch(IOException | SQLException e) {
throw e;
}
}То вашей ошибкой компиляции будет "Unhandled exception type SQLException".
UPD: насколько я понимаю, в Java на этом же синтаксическом принципе в итоге будет основан conditional flow из JEP-305 — правда там пока без Union.
Java и C# отталкивают именно из-за этой особенности.
Не знаю на счёт Java, но в C# эту проблему решили в 8-й версии языка. Плохо, конечно, что так не было сделано с самого начала. Но по крайней мере, прогресс не стоит на месте.
Да, type erasure портит дело в рантайме, никто не идеален, и JVM тоже. И система типов Java далеко не идеальна, хотя для практики обычно достаточна. Я бы тоже хотел систему типов, ну хотя бы как в Scala… ой, погодите, но ведь когда мне этого очень хочется — я беру и пишу на Scala? И потом это запускаю в той же JVM, вместе с кодом на Java. То есть у меня есть среда, где можно запускать код, написанный на разных языках, взаимодействующих друг с другом.
Насчет же гонок и управления памятью, хочу отметить, что подзаголовок гласит:
>Точка зрения невежественного студента информатики
что в общем есть чистая правда (там описано, какой у него опыт). Так что я бы не тратил время на споры с автором вообще. А уж тем более на споры с переводом )
>На Линуксе же он работает только пока не начнёшь подключать родные библиотеки С++
Что вы имеете в виду? Проброс исключений C++ через фреймы CLR? Конфликты между пользовательскими обработчиками сигналов и тех что устанавливает CLR? Разница в ABI у C++ библиотек? Отсутствие COM/Winapi? Отсутствие C++/CLI?
Оборачивал библиотеки на C и не увидел проблем, кроме несуразностей вроде присутствия Unicode-маршалинга как Utf16 в P/Invoke и отсутствия Utf8 (но не знаю как с этим в .net core)
>Виндовые дефолты отовсюду торчат.
Есть такое. Более того, в рантайме есть PAL (по крайне мере, раньше было) - это, по сути, реализация подмножества Windows API средствами Unix, чтобы первоначально Windows-only код весь не переписывать (этакий простецкий winelib). В итоге и семантика виндовая, зато полная совместимость... В mono тоже был слой эмуляции Виндовой подсистемы (в основном I/O)
Но это, мне кажется, обычная практика в целом. Ведь у многих остальных языков (например Go) то же самое, только наоборот - повсюду семантика Unix, которая со скрипом заводится на Windows (приходится эмулировать). Но на это мало кто обращает внимание.
JAVA преступно недооценена
По крайней мере в России, это конечно же не так. Но если будет так, то тоже не против. Меньше конкуренции, еще выше ценники.
Бедный мальчик ...
Джава это вообще не язык, это дрочево с блекджеком и всем остальным, тех, кто так и не втащил си!
Язык не должен вам оргазм ни буквальный ни интеллектуальный, а программирование это не про то кто кого забодал а про задачи и из решение, каждый день в сотнях вариаций и применений.
Джава - это священная корова которая выглядит очень красиво, мычит акт ангел поёт и кушает золото и младенцев, но никто никогда так и не дождался от нее молока, неимоверными трудами и затратами можно выделить пару жалких капель.
Студенты вообще народ восторженный и максималисты поэтому джава и родилась и проштырила индустрию так долго но теперь то с джаавой уже вообще всем все понятно!
Ан нет! Нашелся вот прозорливець )
В статике нет ничего кроме автоподстановки и за это "удобство" ты платишь кандалами типизации.
Пресловутое "изменение разработчиком реализации своей библиотеки" которое приведет к страшному: "несоответствию типов" - это бабайка , с таким же успехом можно потратить половину бюджета на защиту офиса от падения на него самолёта.
Но адепты статики предпочитают концентрироваться на детальных описаниях ужасов такого столкновения а не на ничтожных шансах его вероятности.
Язык программирования должен решать повседневные задачи и при этом вызывать минимум эмоций и хороших м плохих.
Мы все дышим воздухом каждую секунду и без воздуха никто не может прожить больше пары минут, но никто не приходит в восторг от акта дыхания и не ставит алтари "во славу живительного кислорода" зато если вдохнуть чего-то другого то да можно и кайфануть и озадачиться вопросом :зачем все эти люди просто дышут когда могли бы торчать!?
Да потому, что миру нужны уборщики и водители, массажисты и продавцы, художники и программисты а не торчки!
JAVA преступно недооценена