Комментарии 174
В серверном мире предполагается, что приложение будет активно жить без перезапусков месяцами. Поэтому стартовый разогрев кэша не является критической проблемой. Для serverless или кейсов с быстрым стартом Java конечно не особо подходит, хотя и там можно использовать GraalVM и AOT-компиляцию
активно жить без перезапусков месяцами
Иногда такие приложения, в зависимости от фазы луны, начинают выедать память, и сожрав её всю доставляют неимоверную радость.
Долгий старт ява приложений
-> приложения которые грузятся и висят в памями прогретыми обрабатывая запросы, вмсесто простых быстро загружаемых
-> мега комбайны которые могут всёбольше
-> такие собирают из сотен и тысяч сторонних библиотек
-> уследить за каждым практически не возможно
-> где-то да текёт
-> имеем то что имеем если текёт быстро чаще watchdog перезапускает инстанс.
Ява же не должна течь by design. Ну вроде как ее так раньше рекламировали, рассказывая про преимущества управляемого кода.
Не должна течь, если работать с ней правильно, а кривыми руками можно что угодно поломать.
Ну вот вы решили релизовать кеш объектов, сделали глобальную мапу и сохраняете туда все созданные объекты, но про удаление совсем забыли. Ну и как Java (или любой другой язык) сможет понять, что эти объекты не нужны и их можно удалить, если будет нехватка памяти?
P.S. В целом, тут как и с машинами — какую хорошую марку вы не купите, если водитель будет жечь и бросать сцепление, переключать на задную до остановки — можно угробить любую за полгода.
А что, в Java нету weak map?
Но это все про программистов с «прямыми руками»… а вот «by design» магического способа делать все криво, но чтобы работало все нормально — нет.
Увы, даже с управляемым кодом нужно помнить о нескольких простых правилах, нарушения, которых приведет у утечкам памяти.
Забыли написать, что виртуальная машина java весьма тормознутая
Интересно, у Вас есть какие-то подтверждающие аргументы? Современная JVM порой дает прикурить даже C++ коду (не на чисто алгоритмических задач конечено) за счет рантайм оптимизаций.
очень мало новых проектов сейчас пишутся на Java
Это тоже крайне спорное утверждение. Реальную картину конечно сложно оценить, но если например взглянуть на движуху вокруг относительно молодых фреймворков типо Quarkus или Micronaut (да что уж там говорить — даже Jakarta, которая стала наследницей Java EE), то можно увидеть, что интерес совсем не упал. И это даже если не брать в расчет Kotlin...
Мне кажется, рекрутерки прям с ног уже сбились в поисках джавистов. Плюс недавно мой друган-джавист из РФ хотел уйти в управленцы, так его уговорили остаться в разработчиках, дав денег как менеджеру.
А на сишарпе все на сияющих неткорах пишут? А то озон вот недавно приглашал, у них там оказывается ещё .net 2.0 и дельфи компоненты вполне себе в проде живут. Но мне пообещали что мне туда лазить практически не придется — для этого есть специальные люди. Ну спасибо, что сказать)
Мне кажется что на джаве что на дотнете легаси и новых проектов примерно одинаково. И если в СНГ как раз шарп ещё популярен и считается модненьким, то на западе он воспринимается примерно так же как VB — непонятная ерунда, а люди которые на нем пишут — странные персонажи, не осилившие джаву. Сам шарпистом всю жизнь был и почувствовал на себе такое отношение.
Так что вот думайте
Еще огромный пласт это Sharepoint
Ой. Я это слово проклял, заковал в цепи и закопал на глубину 7 метров. Чего и вам желаю.
Я не спорю что в банковском секторе куча .Net софта, особенно этого самого нечистивого, но там как раз-таки обычно столетнее легаси и есть.
А можно поинтересоваться: как у вас с .net 5? подумываете про .net6? Как происходит деплой — докер-не докер? Как вообще происходит процесс обновления приложения?
Просто в моем видение как в банке обычно это происходит тут на каждом этапе куча препон. В лучшем случае согласуют перенос с 4.5-4.7 на какйо-нибудь 3.1 и ещё лет на 5+ на этом все заглохнет пока не придет инициатива переходить с 3.1 на какой-нибудь .net9.
Поправьте, пожалуйста, если не прав. Расскажите про процессы у вас в банке. (Ну и если банк не секрет то про него тоже можно. Тот же Тинек вполне себе адекватный работодатель кмк даже среди обычных фирм, а на фоне остальных банков очень выгодно отличается, в частности Нижником).
В кор бизнесе все тускло. Но вокруг кор бизнеса миллиард проектов, где вполне бодро можно обновить версии. Да и вообще сейчас у всех «трансформация»
Простите, а что не так с SharePoint?
То, что там всё сделано через какое-то странное место. Буквально всё. Нет ни одной задачи, которую бы он упрощал вместо усложнения.
Вот примеры:
Раз. Нужно опубликовать статическую страницу? Никакого копирования одного файла, вам понадобится собрать wsp, содержащий одну фичу, после чего добавить wsp в каталог решений, установить его и активировать фичу.
И да, даже не думайте что эта самая фича из одного файла будет такой простой, там куча подводных камней, начиная от обязательного использования ASP.NET WebForms, и заканчивая недокументированной проверкой регистра тэга asp:ContentPlacehohder
(вообще-то имена тэгов в WebForms регистронезависимые, но не в шарике!).
Два. Нужно задеплоить что-то? Ну, если вы будете делать это мышкой — шарик для вас, а в противном случае вам понадобится:
- (выгрузить старый wsp из каталога решений);
- загрузить новый wsp в каталог решений;
- установить wsp;
- (рестартануть свои службы на всех серверах фермы, иначе dll в GAC не обновятся — если вам не повезло написать службу которая использует ваши dll);
- дождаться окончания установки wsp, причём команды на это никакой нет — тренируйтесь писать циклы (и упаси боже если кто-то загрузит dll из GAC во время этого шага!);
- активировать нужные фичи на нужных сайтах — тренируйтесь писать кастомизируемые скрипты, потому что этот шаг наверняка будет отличаться на стейджинге и проде;
- дождаться окончания активации фич — снова цикл, впрочем вы его уже написали;
- выполнить действия по настройке, которые не вошли ни в одну фичу.
И да, в любой момент установка может зависнуть по куче разных причин — на любом из серверов фермы может оказаться остановлена служба администрирования, служба планировщика или может быть повреждено локальное хранилище конфигурации.
Три. Просто нужно разрабатывать решение? Ну, это довольно просто, только не забудьте поставить Sharepoint на свой компьютер, иначе компилятор не найдёт зависимости (и да, напоминаю что шарик требует серверной винды) — и не забудьте отменять деплой своего решения перед каждой сборкой если у вас более одной библиотеки, иначе компилятор будет находить старую версию бинарников вместо свежей.
Четыре: попробуйте прочуствовать когда нужно создавать контексты а когда нет, когда нужно имперсонировать клиента а когда нет и т.п. В каких случаях нужно использовать только OpenWeb в каких new SPWeb(), в каких можно и то и то, а в каких оба не заработают.
Пять: попробуйте в 11 часов вечера когда вы уже на протяжении 7 часов бытаетесь залить фичу уровня "одна статическая страничка" а она не заливается, и на ~40 раз "удалили пакет — поставили пакет" она внезапно начинает работать (без каких-либо изменений в коде, просто методичное удалил-установил-удалил-установил).
Из моей жизни: клиент просил чтобы один столбец в одном месте на сайте назывался не так, как в админке. Ну типа в админке колонка называется "Игры" а на этой странице должно было называться "Ваши доступные игры". Вот сколько нужно времени, чтобы изменить статический текст на одной страничке?
ЕМНИП я делал задачу полтора месяца. Ведь нужно создать шаблон списка, добавить в него нужные поля, и причем поля же пронизыают весь шарик насквозь. Нужно было предусмотреть режим рендеринга во время "редактирования страницы", режим рендеринга при просмотре обычным юзером. В итоге я это захачил путем залезания в системные шаблоны и хака в XSLT if (pagename == .. && fieldname = ..) ..
. Ибо способа из коробки назвать поле по-другому только на одной странице — нет никакого.
Уххх как вспомнил так вздрогнул.
на западе он воспринимается примерно так же как VB — непонятная ерунда, а люди которые на нем пишут — странные персонажи
А вы точно на шарпе-то писали? Или может быть это лично к вам относились как к странному персонажу?
Странно, ни разу не сталкивался с таким мнением. Проектов на .NET было предостаточно. Северная Америка, Южная, Европа, Океания. От мелких бизнесов до транснациональных. В одном только ООН его море. Кто-то из доверия к бренду, кто-то в силу остального ландшафта в компании, кто-то из-за инструментов. WebForms/WPF были особенно в ходу, поскольку Delphi был не так распространён за пределами СНГ, а какой-нибудь MFC давался сильной болью. Огромное количество бизнес-софта, скажем тот же немецкий Sage (что-то в духе нашего 1С).
дав денег как менеджеру.как топ-менеджеру, я надеюсь?
Это очень спорное утверждение) HotSpot крутая штука на самом деле)
Hadoop, Spark, Kafka, Cassandra, Lucene, ElasticSearch, Solr - вот первое что вспомнил из Highload и BigData на Java.
Тормознутая по сравнению с чем? И тормознутая насколько?
Про «очень мало новых проектов» даже не смешно. Очередная смерть джавы не за горами, видимо :)
бардак в API при работе с датами и временем;
Java уже много лет. Бардак там не только с датами и временем, но и с desktop-ым UI, Есть устаревшие классы для работы с коллекциями. С логированием вообще просто кошмар.
Два способа работы с файлами (Java.io и java.nio). И т. д. Всё это за 26 лет накопилось.
Вспоминаю как познакомился впервые с JodaTime и хотел плакать)
Ага, бардак с 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 <...> — из библиотеки Noda Time.
Уже нет, если поставить 6.0 превью 4: https://github.com/dotnet/runtime/issues/45318
DateOnly/TimeOnly — из .NET6
Есть Calendar
Есть библиотека JodaTime, которую сейчас уже не актуально использовать.
Есть java.time, который создан под впечатлением JodaTime со своими Instant, LocalDate, LocalTime, ZonedDateTime, OffsetDateTime и методами конвертации в java.util.Date.
В Java более прозрачная работа с асинхронностью: когда пишешь код действительно приходится о многом думать
это должно быть шутка? Никакой поддержки асинхронного программирования на уровне языка java НЕТ. Всё что есть — это библиотеки где можно писать отвратительную колбасу с коллбэками. «приходится о многом думать» — круто-то как, надо такого побольше и везде, а то ж мало о чем думать и без этого! Надо полагать что те кто пытаются уменьшить интеллектуальную сложность систем и инструментов — просто ленивые дураки
Возможно автор перепутал асинхронность с многопоточностью
Впрочем, у меня это старые воспоминания, двадцати-почти-летней давности.
Я J2EE в целом не люблю. Мне "посчастливилось" недолго познакомиться с ним в одном зеленом банке и впечатления остались как об огромном непонятном монстре с кучей неявного и скрытого поведения
Ну и за встроенное управление многопоточностью я готов был убить явотворцев, в серверах это было просто миной.
С# — не просто сделан из явы, это ява, улучшенная дельфями, именно из этого растёт значительная часть его преимуществ. 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?
в качестве примера попробуйте набросать на 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.
По поводу IDE, есть Rider от JetBrains. Если я и пишу под дотнет, то только там)
Ну, конечно есть платные библиотеки, но всё чаще платной там становится только поддержка.
Вы имеете в виду .NET библиотеки, написанные каким-то сообществом разработчиков с репутацией (типа Apache, в которых на основные грабли уже наступили до Вас и можно более-менее полагаться на качество этих компонент)? Или просто нечто бесплатное, что какой-то Вася написал за выходные, и мы не знаем, как хорошо оно работает, какие там баги, есть ли поддержка и т.д.?
Да, я — бекенд разработчик и не трогал frontend уже лет 10. Я к тому что в жаве есть куча всего с MIT лицензиями от Google, Apache и т.д. — Spark, Velocity, Guice, Dagger и т.д. Есть DBMS типа, допустим, PostgreSQL.
Если в .NET есть бесплатные фреймворки и продукты такого масштаба — ну ок. Но кажется, что нет.
github.com/JamesNK/Newtonsoft.Json/blob/master/LICENSE.md
Судя по минусам, на хабре преобладают .NET разработчики :)
Но 10 лет назад у меня сложилось впечатление, что любая мало-мальски приличная библиотека стоит денег за лицензию, никаких вам MIT и т.п.
Ну, 10 лет назад так и было. Хотя проблема там была не самим наличием бесплатных библиотек, а с их доступностью.
Однако, сейчас ситуация совершенно другая.
Ну например логгирование в fluentd из серилог — и то и то супер-распространенные вещи. Лично мы сейчас используем либу с гитхаба в которой 5 звезд — и то я в нее фиксы заливал потомум что там куча приколов было а-ля "храним всё как строки" (в итоге нельзя в логе найти по предикату "число от 5 до 57").
Библиотеки в дотнете почти всегда есть нужные, но джава куда богаче конечно на выбор, а сами библиотеки обычно более заматеревшие.
Я не работал с 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МБ/с, что конечно же никуда не годится. Но я на винде — а там докер, это накладывает свои особенности. Есть подозрение что докер на один-два порядка быстрее писать будет. Ну или хотя бы надежда на это)
github.com/serilog/serilog-sinks-elasticsearch
В эластик напрямую слать это смерть, поэтому и сделали логстеш/флюент — не от хорошей жизни, а потом что от прямой записи в эластик он загибается.
Самое забавное, что в данном случае — точно так же, 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 это далеко не «поделка».
Если я хочу морочиться с плагинами я возьму VS Code.
Не понимаю в чем разница если честно. Ту же студию я давно задвинул в дальний конец. Для джавы есть IDEA, для шарпа — райдер, которая та же идея только в профиль. Студия ощутимо проигрывает и по скорости, и по функционалу. Чтобы догнать по функционалу нужно ставить решарпер, но тогда перф из просто "не очень" уходит куда-то в "катастрфически низкий".
В 2019 есть почти все, что нужно, пара плагинов и codemaid мне достаточно. И работает это быстрее чем любой Rider
Пятнадцать лет пишу без решарпера, что я делаю не так?
Видимо тратите время на выполнение руками операций, которые могла бы выполнить машина) Я просто после решарпера пробовал пользоваться голой студией и у меня буквально каждые 5 минут был момент когда я хочу что-нибудь сделать (например, сгенерировать реализацию IEquitable для типчика или там переисать пачку ифов на паттерн матчинг) а вот нет такого функционала, не может студия. Постепенно старые рефакторинги появляются в ней, но и райдер/решарпер на месте не стоят. По ощущениям отставание идет на 5-7 лет по фичам. И фичей не из каких-то там марекитнговых проспектов, а те которые нажимаешь кейворд — ничего не происходит — идешь искать как делается в студии и понимаешь, что никак. И очень печально от этого на душе становится в этот момент.
Видимо тратите время на выполнение руками операций, которые могла бы выполнить машина
У меня постоянное ощущение, что машина стараниями решарпера выполняет слишком много операций)) Уже не первый год пытаюсь заставить себя на него пересесть. Рефакторинг, подсказки, неплохой тест-раннер, всё круто, беру. Но как начинается суровая работа… он своей скоростью убивает на порядок больше, чем даёт производительности труда. Буквально на днях пришло очередное обновления, после которых он любит опять включаться, хотя я ему сказал суровое "disable". Не очень большой проект, гдето 150K LoC. Вытерпел первую загрузку, с тотальным фризом секунд на десять и минутным подтормаживанием то там, то сям. Думаю, сейчас прокэшируется и дальше должно быть лучше. Но любой чих, любая навигация, любая подсказка — это +0.5-2с (Ryzen 5950X, RAM 128G, NVMe PCIe 4.0). Вроде казалось бы ерунда, но лично меня просто жутко выбешивает. Прыжки между фичами вообще беда. Может это исключительно мой паттерн. У меня в силу SRP/ISP огромное количество навигаций. А для рефакторинга я его могу раз в неделю включить и спокойно навести красоту.
Ну вот у меня 3800х, проекта до миллиона строк вполне себе шустро открываются.
А от решарпера со студией я отказался из-за тормозов, да. Хотя даже когда сидел на студии предпочитал иметь тормоза чем не иметь фичи. Ну да, неприятно если фриз на рефакторинг занимает 10-20 секунд, но руками-то я буду это делать полчаса. Лучше уж подождать.
Ну а потом райдер подъехал и теперь вроде как лучшее из двух миров имеем.
Так шустро в райдере или в решарпере? Райдер у меня достаточно бодро работает, правда там другие заморочки. Но это уже моя специфика, не всем нужна поддержка iOS Local Device с hot reset.
+ там 64 бита есть, насколько я помню VS была всю жизнь 32 бита?
И да, я разрабатываю под винду, с WSL2 теперь даже смысла нету в иной системе, даже докер работает почти нативно.
Якорь в связке VS + Resharper это Решарпер. Удалите его и будете удивлены, насколько быстро все работает.
Но и фичей не будет. Если по чистой скорости сравнивать то Блокнот ничего не превзойдет. Только сидеть в нем все же больно почему-то. Видимо, не в одной скорости дело.
А что вам и без решарпера было норм — тут скорее парадок блаба. Вы не знаете, чего у вас нет, если у вас этого нет. Нужно попробовать, а потом лишиться, чтобы понять.
Из распространенного самый заметный пример с SSD был, когда пересел — ну да, чуть шустрее стало работать, норм. Но самый цимес когда нужно было пересаживаться обратно на машину с HDD. И тогда можно было прочувствовать всю боль старого незнания, которое впрочем воспринималось как само собой разумеющееся, сравнить-то было не с чем.
У меня в команде 7 человек, на выбор была студия ( + опционально решарпер) и райдер. Изначально все сидели на студии, райдер купили 2 года назад и сказали "кто хочет — юзайте студи. кто хочет — райдер."
Прошло 2 года. На студии не сталось ни одного человека. Последний перешел пару месяцев назад, когда в райдере появилась наконец кнопочка "сгенерировать докерфайл по проекту" (в студии-то она давно была). ИСЧХ сидел на студии без плагинов, прям как вы.
И пока отзывы команды исключительно положительные.
Вы знаете, на все это уходит примерно 1% моего времени. У меня как-то на обдумывание и архитектуру уходит на порядок больше времени, чем автоматизация трех строчек
Знаю, а ещё знаю что во-первых в таком тривиальном коде чаще всего потом баги находишь (привет PVS), а во-вторых тут 3 минуты, там 3 минуты — выливается в десятки минут если не больше в день, на каждого разработчика. Не говоря про уровень комфорта — может набрать руками имплементацию и не очень сложно, но очень раздражает когда приходится это делать.
Все эти инструменты сильно переоценены. Возможно, если вы просто клепаете однотипные задачи сотнями в день они и полезны, но я лично такой работой уже лет 7 как не занимаюсь.
Что касается экономии времени, то из экономии с решарпером нужно вычитать время лагов и тормозов, время загрузки проекта.
Да и вообще обсуждать эту экономию на спичках, когда люди разрабатывают на ноутах вообще смешно. Компиляция проектов дома на 5950 — 15c, на ноуте — 50 сек. Сколько решарперов сэкономит это время?
За деньги на решарпер поставьте лучше десктопный процессор.
Меня забавляет, как люди строят предположения, что у кого-то, кто на дотнете 15 лет не было решарпера никогда. Я даже CodeRush пробовал.
Ну я исхожу из того, что вы пишете, другой-то информации у меня нет. Есть разные люди — кто-то всю жизнь на делфи например писал и не знает что вообще вокруг происходит. Откуда я знаю, пробовали-не пробовали? Моя цель — помочь, предложить сравнить, а дальше как уже человек сам захочет.
Все эти инструменты сильно переоценены. Возможно, если вы просто клепаете однотипные задачи сотнями в день они и полезны, но я лично такой работой уже лет 7 как не занимаюсь.
90% любых задач — это рутина. Да, это инструмент для разработчиков, а не для архитекторов. Последние 80% времени проводят в джире, зуме и майндмапах, им эти решарпер до лампочки. А вот код набирать — очень даже помогает. Но я верю, что есть люди у которых каждый день фуллтайм инновационные ресерчи. И код они при этом не набирают — просто смотрят в экран пока не снизойдет озарение. Математик заходит в комнату, видит, что решение есть и уходит.
Что касается экономии времени, то из экономии с решарпером нужно вычитать время лагов и тормозов, время загрузки проекта.
Ну решарпер и правда лагает, райдер же загружает +- как студия, чем больше проект тем быстрее грузит. Собственно, история райдера началась с того что студия не могла осилить открыть проект решарпера.
Да и вообще обсуждать эту экономию на спичках, когда люди разрабатывают на ноутах вообще смешно. Компиляция проектов дома на 5950 — 15c, на ноуте — 50 сек. Сколько решарперов сэкономит это время?
За деньги на решарпер поставьте лучше десктопный процессор.
А одно другое исключает? Естественно, достойное оборудование это такая же часть рабочего окружения как и софт. У меня рязань 3800х к примеру. И райдер, да. (Хотя если точнее у меня полный пак, потому что мне и раст нужен, и питон, и в базу лазить, одним паком дешевле выходит)
Ещё раз, не мил вам решарпер, нравится голая студия — да ради бога. Я просто вот вам написал — вдруг вы не в курсе, а я вам донесу смысл этих инструментов. А оказалось это просто способ притянуть минусов. Ну ладно, что уж тут.
50 секунд компиляции кстати это что-то очень странное и видимо с неправильно настроенными зависимоятми. Я давно больше 5-10с компиляции в дебаге (даже на ноуте) не видел. Последний раз минутные компиляции были на огромном монолите где криво были прописаны зависимости, поэтому "от греха" делался полный ребилд на каждую сборку, а то при обычном билде можно было чего-то не досчитаться в артефактах и словить проблемы.
От решарпера в студии я отказался как вышла 2019 стабильная.
Пусть даже отстает немного по всем-всем фичам. Но честно, дискомфорта не заметил.
От решарпера со студией я тоже отказался ибо тормозило безбожно. Поэтому влез в райдер — работает как голая студия по перфу (иногда лучше, изредка — хуже), зато по фичам все что нужно есть. Ну и есть знакомые в жыдбрейнсах, через них иногда получается запушить какую-нибудь мелкую фичу которая нужна или там багрепорт приоретизировать. Со студией конечно ждать приходится куда дольше.
Сравнивал я с 2019 16.6 конечно же (потому уже перешел окончательно с нее)
Так вот, в Java — есть решения, в которых все уже готово, соединение воспринимается как абстрактная сессия, готовы события, готова планировка IO, а я могу просто реализовать парсер, прикрутить БД и жить себе спокойно.
В .net я буду сидеть и с сокетами играться, реализовывать систему событий, буду делать свой пул буфферов и прочими малополезными вещами заниматься.
Да, сейчас можно костылями часть работы переложить на кестрел, но это все еще костыли.
Что-то я вас не понимаю. Какую такую систему событий надо сделать? Зачем делать пул буферов когда есть ArrayPool и MemoryPool? Зачем нужен свой планировщик IO, когда есть пул потоков?
А что такого хитрого сделано в Netty?
Так-то для HTTP есть HttpClient и Kestrel. Для Protobuf есть, э-э-э, protobuf. Поддержка TLS тоже есть. Какие ещё готовые протоколы Netty вам предоставляет?
началось активное развитие Xamarin. Разработчики получили возможность писать шустрые приложения на iOS и Android;
Развитие Xamarin началось ещё в 2011 когда это был mono.ios/mono.android и это из xamarin в .NET core тянут некоторые фичи для AOT и поддержки мобилок
Согласен. Забыл в статье сделать акцент на то, что MS по сути узаконила Xamarin, и Mono стал отличным подспорьем для вывода .NET в OpenSource
Более того, когда МС выиграла тендер на трансляцию инаугурации Обамы, они с моно поделились исходниками Silverlight, что бы последние Moonlight допилили к трансляции.
так он сходу отъедает 3,5 ГБ ОЗУ. IDE на базе Эклипса тоже сразу после запуска отнимает минимум гигабайт. 5...10 таких запущенных приложений — и приехали…
Java приложения, особенно IDE сразу забирают много памяти «про запас». Условно, крупное Java приложение может забрать практически всю свободную память ОС даже если память прямо сейчас не нужна.
Логика тут простая — так быстрее работает код и реже требуется вызывать сборщик мусора, а так как Java оптимизировано для серверных приложений одно приложение на сервер/докер контейнер — это имеет смысл.
Но есть способы ограничить апетиты Java приложений как средствами Java, так и OC.
А в целом, с памятью у Java так же как у всех — если разработчик ее не экономит и не следить за утечками — потребуются гигабайты, если экономит и следит, Java может жить на считанных мегабайтах. Но вообще, если Java приложение сразу забирает 5Гб, это не значит, что оно не сможет запуститься и нормально работать на 50Мб.
Файл подкачки отключен — SSD.
Windows Mobile разработка: она ужасна во всем.А в чем она ужасна? когда (в какой год) вы её смотрели? С чем сравниваете.
Андроид разработка стала более менее норм как раз с выходом 4.4, до этого жесть полнейшая, и детские баги в сдк, андроид студия только в 13 появилась и куча всего другого. Да и 4.4 такая себе на самом деле.
iOS разработка кажется никогда не была хорошей. Отвратительное IDE, ещё и тормозит во всём, что касается свифта. UI стрёмный был всегда в разработке, постоянные проблемы в разном поведении его между версиями iOS. Сейчас вроде swiftUI более вменяемый, но проблемы с разными версиями никуда не делись.
Если кратко: очень много нужно стараться, чтобы в Windows Mobile получилось удобное в использовании и приятное зору приложение. Конечно, есть кастомные контролы и тулкиты, которые решают эти проблемы, но как-то слишком много телодвижений, как по мне.
То ли дело в iOS — вся разработка изначально под тач-скрин, с хорошими гайдлайнами по дизайну, и это по-умолчанию (хотя старание никто не отменял, конечно).
(под Андроид не разрабатывал да и не охота)
ДИСКЛЕЙМЕР: конечно, много в таких мнениях вкусовщины, но куда ж без нее :)
И это всё под бюджет шнурка для обуви в стране, где айтишка на 97% состоит из продажи железа!
Что Java что C# — языки заходящей эпохи. Другое дело JVM — тут вопросов нет, рантайм божественный, думаю будет источников ещё многих крутых языков. CLR — meh, ничего, но не особо.
Если же ни сишарп ни джава то что? Ну, я лично присматриваю себе скалу — тот же хороший рантайм, но без проблем джавы: нормальные ду-нотации (можно писать асинки удобно), эффекты, хорошие библиотеки и коммьюнити. И платят хорошо. В общем, что ещё для счастья надо.
но чем C# — язык заходящей эпохи-то?
Ну у них груз обратной совместимости же. Из очевидного — nullable by default, то что все типы могут быть нуллами. В шарпе вкорячили NRT (который немного помогает, но глобально проблему не решает), в джаве его пока нет, но что-то подобное будет. АДТ обещают-обещают, но все ещё нет. Шейпы обещают-обещают, но все ещё нет. Концепты, макросы, инлайн дсл… Есть много вещей которые сильно бы упростили разработку, но каждую версию насыпают просто пачку сахара, у меня скоро диабет начнется )
Джава идет по тому же пути, но у нее больше легаси поэтому она идет с задержкой, но суть похожая. Там, правда, системности больше: например логика синхронных и асинхронных стримов шарится. В шарпе же она просто накопипащена. Но суть та же: фарш невозможно провернуть назад, многие старые дизайн вещи которые в текущем мире не очень удобны будут всегда просто по соображениям обратной совместимости.
Это нормально. Все же понимают что джава в 2100 году не будет супер распространенным языком, и скорее будет доживать свой век в каких-нибудь нишевых местах как сейчас кобол. Вопрос только какую дату в интервале 2021-2100 считать датой когда джава устареет. Мне кажется, что достаточно близко к его началу.
Впрочем, все это субъективные оценки, а практик посмотрит на количество библиотек/трудозатраты на реализацию фичей/сопровождаемость/наличие спецов. Тут конечно у джавы (да и у шарпа) пока все прекрасно. Но хотя каждая новая версия языков в целом становится лучше, скорость улучшения неизменно падает. Впрочем, это естественный процесс для любой области.
Оракл как с выходом java 8 очень сильно начал шевелиться, сейчас каждые пол года выкатывают новую джаву - уже скоро 17 выйдет и на неё начнут переходить как на долгоживущую.
Я отвечу так: «Java обрела популярность именно из-за OpenSource-нацеленности. Бизнес не боялся, что завтра придут какие-то чудаки из Sun или Oracle и начнут качать свои права. .Дело было вовсе не в каких-то хороших или плохих качествах. Это была сугубо корпоративная война и практически ничего, кроме корпоративной логики, там не было. Уж об облегчении жизни программистов никто точно не заботился. О качестве программ — аналогично.
И об open source тоже. Хотя — не совсем так, он использовался активно как инструмент бизнес-войн. Нужно насолить конкуренту — вкладываем прямо или косвенно сотню миллионов долларов в открытые разработки, ломая конкуренту бизнес на миллиард. Себе тоже, но, если всё равно проигрывал, то сойдёт.
С другой стороны лучше поздно, чем никогда.
С# — это улучшенная Java
Не соглашусь с вами. Так может и было до года этак 2005(Java User Migration Path — JUMP), Type Erasure ни о чем вам не говорит. Асинхронные модели очень разные, опят же.
А потом оракл таки начал качать права: )
С Jakarta EE уже тоже почти не заботишься о выборе библиотек: на сервере приложений уже есть всё необходимое.
Как я выбирал между .NET и Java