Rider на чем написан
Visual Studio Code vs Rider для Unity.
Комплексное сравнение реализации возможностей Rider и VSCode.
Несколько лет назад я перешел с Atom на VSCode просто потому, что мне нравится его блочный и плоский интерфейс, но вскоре я обнаружил, что VSCode также обладает обширным количеством функций, но они хорошо спрятаны. Ладно, что побуждает меня рассматривать Rider именно сейчас?
Visual Studio Code почти что идеален — в нем практически нет недостатков. Несмотря на это, я не считаю целесообразным платить деньги только ради того, чтобы устранить некоторые раздражающие меня моменты, которые присущи практически всем текстовым редакторам с которыми я работал.
Rider, в свою очередь, не может похвастаться отсутствием раздражающих фич, однако он известен своим IDE «интеллектом» и глубокой интеграцией с Unity. На самом деле мне все равно. Я просто хочу улучшенный и более укомплектованный текстовый редактор, такой как VSCode, но с отсутствием некоторых недостатков. В этой статье я расскажу о том, как настроить Rider и как сделать так, чтобы он был похож на VSCode, дабы я мог наслаждаться как отсутствием раздражающих моментов, так и простым и понятным интерфейсом.
Структура Rider vs VSCode
❶ Преимущества и недостатки Rider по сравнению с VSCode.
❷ Как сделать Rider более похожим на VSCode (для любителей VSCode, которые хотят избавиться от некоторых неприятных моментов VSCode).
❸ Я буду стараться рассматривать мельчайшие детали, так как практически все текстовые редакторы очень похожи друг на друга. Разницу можно заметить лишь в маленьких деталях.
P.S. В статье рассматривается версия Rider 2019.3
Бесконечная лицензия
Первое, что вы подумаете, когда посетите их вебсайт: «Я не хочу платить за подписку на обычный текстовый редактор!» Ну, текстовый редактор — это один из главных инструментов программиста, и к тому же его трудно совершенствовать, поэтому вам, возможно, придется пересмотреть его ценность.
В моем случае я бы согласился на разовый платеж. Мне понравилась модель подписки, которую предлагают разработчики Rider по причине отсутствия необходимости платить до тех пор, пока я не увижу, что они предлагают. По сути, когда вы прекращаете подписку, вы просто прекращаете получать обновления и можете продолжать использовать имеющуюся версию Rider. В Adobe, например, все иначе — по завершении подписки, вам блокируется доступ ко всем инструментам. Модель подписки Rider заставила меня задуматься о покупке. Да, эта модель больше похожа на покупку, а не на ежемесячные платежи. Больше информации здесь.
VSCodeVim vs IdeaVim
Я понимаю, что я не вправе осуждать VSCodeVim за наличие багов как минимум потому, что это проект с открытым исходным кодом, доступным на GitHub. Если я не вношу свой вклад в разработку, то я не имею права требовать от него чего-либо. Однако верно и то, что у меня может не быть времени на разработку VSCodeVim, и, в таком случае, IdeaVim — это неплохое решение, поддерживаемое коммерческой компанией, на которое я мог бы потратить деньги вместо времени. Я также полагаю, что деньги могут замотивировать вас и заставить делать продукт более изысканным.
IdeaVim быстрый!
Omnisharp vs ReSharp
В целом Omnisharp работает нормально, в том числе когда дело касается переименования переменных во всем проекте, что, лично для меня, важно. Благодаря Omnisharp я могу не тратить много времени на название переменной, а просто придумывать его на ходу, а потом, если нужно будет, я могу его(название) легко изменить. Однако в некоторых ситуациях это не работает. Например, если эта переменная в лямбда-методе не завершается автоматически, в отличие от простой лямбды. Этот шаблон важен в библиотеке ECS Unity.
JetBrains Rider и Visual Studio
Просто о NET | создано: 26.10.2020 | опубликовано: 26.10.2020 | обновлено: 01.12.2021 | просмотров: 1728
Хочется ответить на вопрос: Какая IDE лучше для C# разработчика?
JetBrains Rider и Visual Studio
Обе эти IDE зарекомендовали себя, как полноценные средства разработки приложений и написания кода. Но у всего есть свои «плюсы» и «минусы», что уж говорить про такие сложные инструменты как JetBrains Rider и Visual Studio. Не хотелось вдаваться в подробности, но в этой статье я бы хотел остановиться на такой теме как «что мне не хватает в JetBrains Rider по стравнению с Visual Studio». Я с Visual Studio работаю уже давно более 15 лет. А Rider мне по подписке JetBrains «подарили» недавно (Rider был включен в подписку ReSharper). И всем хорош Rider, но как выяснилось кроме плюсов, которые в нем действительно имеются, есть в нем еще и то, чего мне как разработчику с большим опытом, очень сильно не достает.
Что не хватает в Rider
1. Работа с шаблонами для проектов
Речь идет о возможности сохранить проект как шаблонный. Очень помогает при создании «Шаблон микросервисов»
2. Утилиты для работы с Microsoft SQL Server
4. Очень привык я к Package Management Console, которой также нет в Rider
5. Специальная вставка, для объектов типа JSON и XML, которая автоматически превращает в CSharp-классы.
Заключение
Но надо сказать, что Rider достаточно привлекательная среда разработки. Мне понравилась интеграция с TFS, а так же GIT.
2005-2021 © Calabonga SOFT
Все права защищены по лицензии Creative Commons BY-NC-SA
При использовании материалов сайта ссылка на ресурс обязательна! v.5.1.50
JetBrains Rider — теперь для Unreal Engine
На прошлой неделе, после релизов версии 2020.1, для всех наших десктопных продуктов случилось еще одно большое событие — мы открыли публичный доступ к пробной версии Rider for Unreal Engine. На данный момент это отдельный продукт, версия нашей среды для разработки Rider, но с поддержкой C++ и Unreal Engine.
Так, стоп! Среда разработки на C++. Еще одна?! Давайте разбираться по порядку.
Начнем с небольшой истории. Несколько лет назад мы собрали всех, кто в JetBrains делает инструменты для C++, чтобы обсудить, насколько пользователям тяжело ориентироваться в многообразии наших предложений. Ведь есть и CLion, и ReSharper C++, и поддержка для C++ в AppCode. Через несколько часов обсуждений пришли к таким выводам:
Заходя ко многим нашим пользователям из области разработки игр, мы заметили, что у многих студий нет четкого разделения — делать игры только на Unity или только на Unreal Engine. Сегодня у них игра на одной технологии, а завтра — на другой, или одна команда использует Unreal Engine, а другая Unity или вообще свой кастомный движок. При этом понятно, что разработчикам и компаниям в целом очень не нравится “прыгать” между разными средами разработки. И вот тут-то мы и решили, что, если мы смогли сделать Rider успешным для Unity, то мы можем пойти дальше и сделать его успешным в целом для мира игровой разработки. Так родилась идея Rider как универсальной среды разработки для Game Dev.
Из чего состоит Rider for Unreal Engine
Дальнейшее развитие событий довольно очевидно для тех, кто знаком с технологией, на которой построен Rider. Rider состоит из front-end части на базе платформы IntelliJ и back-end части на базе ReSharper. Все языковая поддержка работает на back-end. Поэтому мы просто подключили уже имеющуюся в ReSharper C++ поддержку C++ и Unreal Engine к Rider по той же технологии. Из специфичного пришлось дополнительно реализовать:
Отладчик на основе LLDB
Значительная часть разработки игр происходит сейчас на платформе Windows и в рамках тулчейна от Microsoft. Если посмотреть на то, какие инструменты для отладки существуют для кода, который скомпилирован с помощью компилятора Microsoft Visual C++, то мы увидим:
Поддержка C++
Повторю — вся функциональность языковой поддержки из ReSharper C++ теперь доступна в Rider for Unreal Engine Preview. Она включает:
Поддержка HLSL, C#, диалектов uproject/uplugin
В этом году мы начали работать над поддержкой языка для написания шейдеров HLSL в ReSharper C++, и она сразу попала и в раннее превью Rider for Unreal Engine. Поддержка включает в себя подсветку синтаксиса, тултипы с документацией, подсказки имен параметров и типов, действия навигации, автодополнение, поддержка виртуальных путей файлов, и даже рефакторинги.
Интеграция с Blueprints
Файлы Blueprints представляют собой данные в бинарном формате, редактирование которых происходит как правило в визуальном редакторе внутри Unreal Editor. Объекты в этих файлах наследуются от классов на C++, переопределяют проперти из C++ части игры. И вот тут Rider for Unreal Engine является той уникальной средой разработки, которая зачитывает все необходимые файлы Blueprints и показывает эти связи в редакторе кода на C++:
При этом, если поменять, например, значение свойства в редакторе Unreal Engine и сохранить asset, то значение тут же автоматически обновится и в Rider (у нас повешены watchers на изменение asset-файлов):
Без сохранения файлов, мы надеемся, это тоже скоро заработает (подготовка к этому сейчас ведется в плагине UnrealLink).
Вызов поиска использований (Find usages) включает не только использования в коде на C++, но и в файлах Blueprints. Двойной клик по таким использованиям открывает Unreal Editor.
Понимание механизма рефлексии UE4
Рефлексия в Unreal Engine реализована с помощью специальных макросов (UCLASS, UFUNCTION, UPROPERTY и др). Rider знает, что параметры таких макросов — это не просто текст. Парсер языка C++ в ReSharper C++ и Rider умеет действительно “понимать” значение этих макросов, даже не запуская Unreal Header Build tool (то есть еще до того, как реально сгенерируется содержимое файлов .generated.h).
Кстати, говоря про файлы .generated.h, ReSharper C++ и Rider знают, что автоматически добавляемые пропущенные директивы #include надо вставлять строго до подключения файлов .generated.h. А также учитывают эти генерируемые файлы в рефакторингах переименования.
Возвращаясь к механизму рефлексии, стоит сказать, что спецификаторы рефлексии — это в ReSharper C++ и Rider тоже не просто текст. Для них есть автодополнение и подсказки документации:
Подсказки документации доступны и для самих макросов рефлексии.
А еще анализатор кода проверяет использование макросов рефлексии и указывает на связанные с этим ошибки. Например:
Поддержка вызовов удаленных процедур (RPC) в действиях навигации и генерации кода
Знание правил именования Unreal Engine 4
ReSharper C++ и Rider осведомлены об официальных правилах именования в коде Unreal Engine. Эти правила используются средой разработки во всех действиях по работе с кодом, вроде генерации getters и setters или рефакторинге добавления переменной (Introduce Variable). А главное, что существует проверка кода Inconsistent UE4 naming inspections и соответствующее быстрое исправление, которое вызовет рефакторинг Rename и переименует все использования имени, не соответствующего правилам.
Производительность редактора
Мы довольно давно делаем поддержку разработки на Unreal Engine в ReSharper C++ и, конечно, видим, что производительность редактора является основной жалобой. Rider в силу особенностей архитектуры избавлен от многих проблем с производительностью, которые присутствуют в ReSharper (там они есть отчасти из-за ограничений студии на 32-разрядные процессы, в рамках которых происходит работа ReSharper, но не только).
Помимо этого, мы специально настраиваем работу IDE для улучшения производительности на Unreal Engine. Мы сначала индексируем код пользовательской игры, мгновенно включая все умные действия редактора на пользовательском коде. А индексация уже кода самого движка происходит после этого в фоне. Есть и еще несколько дополнительных опций по управлению индексацией:
В результате, те, кто уже начал пользоваться Rider for Unreal Engine, отзываются о производительности редактора очень положительно! А мы уверены, что можем сделать еще лучше.
Видеодемо и еще раз о том, как получить доступ
Эти и многие другие возможности можно посмотреть в действии в демо-ролике (на английском) от нашего девелопер-адвоката:
Проект Rider (.NET IDE от JetBrains) дошёл до публичной EAP-версии — самое время подробно расспросить Андрея Акиньшина, одного из его разработчиков. Но Rider стал не единственной темой нового выпуска «Без слайдов». Помимо него, поговорили:
Rider
— Андрей, мы все наслышаны, что у вас вышел публичный EAP. Ты уже больше года работаешь над этим проектом — скажи, пожалуйста, какие у вас ощущения?
— У нас как команды ощущения очень хорошие: мы все сидим на Rider, 90% времени пишем в нём. Мы самые старые пользователи Rider, потому что стали его использовать ещё с самых первых версий, когда можно стало хоть что-нибудь в нём писать.
Нам всем очень нравится, Rider — это очень клёвая IDE, и главным образом из-за того, что мы девелопим отчасти для себя. То есть все вещи, которые неудобны, раздражают или нельзя сделать, замечает вся команда, мы все страдаем от этих вещей каждый день. Спустя какое-то время у кого-то чешутся руки, он идёт и просто правит эту функциональность. Также Rider основан на кодовой базе ReSharper и IntelliJ IDEA, а это очень клёвые продукты, каждый из которых разрабатывается больше 10 лет, в каждом очень много фич, каждый очень сильно оптимизирован. В Rider ещё не всё готово, но то, что готово, работает очень хорошо, и нам очень нравится этим пользоваться.
— ReSharper работает с Visual Studio внутри процесса, или в отдельном процессе?
— Он работает внутри процесса, и это большая проблема, потому что год 2016-й, а Visual Studio — всё ещё 32-битный процесс, и многие наши пользователи жалуются, что ReSharper тормозит. ReSharper не тормозит, он работает как раньше и даже быстрее, но Студия с каждой новой версией потребляет всё больше памяти, и нам в рамках этого 32-битного процесса становится всё теснее. И в плане тормозов Rider — живое этому доказательство: мы вылезли из процесса Студии, и всё летает.
— А почему было не сделать ReSharper out of process?
— Это очень сложно, во-первых, в плане интеропа с самой Студией, а во-вторых… В Rider мы, по сути, реализовывали интероп между IDEA и ReSharper. Сделали мы это с помощью своего кастомного протокола, который мы очень долго разрабатывали, очень много тюнили.
Прекрасная работа сделана, очень удобно пользоваться, очень быстро всё работает, но всё равно есть какие-то проблемы, есть вещи, которые не продуманы, неудобно сделаны. И даже связать два продукта, каждый из которых делаем мы сами, в каждом из которых мы можем что угодно поменять — это уже очень непростая, сложная техническая задача. Со Студией крайне сложно было бы такое реализовать.
— А если чуть по-другому зайти: вот сейчас вы уже отработали для Rider out-of-process режим, и протокол у вас есть. Вот если пофантазировать: это возможно всё интегрировать в Студию, или придётся всё переделывать?
— Ну, чисто технологически — да, можно, иногда мы даже думаем про это. Но нужно понимать, что это очень большая и сложная задача. Если мы этим когда-нибудь будем заниматься, то нужно очень хорошо понимать, что это рентабельно, и тот объём труда, который мы в это вложим, себя в конечном счёте оправдает.
— Ну вот есть тренд, что Visual Studio потребляет всё больше и больше памяти. Предпосылок, что будет потреблять меньше, нет, и возникает вопрос, для чего там останется место.
— Ну, никто не знает, что будет с Visual Studio завтра, поэтому мы пока на ней сидим. Всё, что я могу сказать: cегодня таких планов нет (на самом деле есть, ребята из ReSharper об этом в открытую говорят — прим. авт.). Сегодня мы активно пилим Rider, это наш главный приоритет.
— Что вам пишут пользователи? У вас уже была закрытая early access-программа, я её участник и даже репортил вам баги — могу сказать, что я вообще early adopter. Много ли было пользователей у закрытого EAP?
— Да. Думаю, людей, которые активно разрабатывают в Rider, тысячи. Фидбэк колоссальный и очень хороший.
— «Хороший» в смысле «позитивный», или в смысле «пищу даёт»?
— И позитивный, и конструктивный. Early Access Program (EAP) позволила нам выявить на ранних этапах разработки вещи, которые мы не проработали.
— Например, поддержка Unity или Xamarin. Очень многие люди пытаются использовать Rider для этих целей, и их фидбэк был очень ценен для нас. Мы сами им каждый день пользуемся, но вот Unity или Xamarin — это не те технологии, на которых вся команда ReSharper девелопит каждый день. И мы в некоторых моментах не до конца понимаем, что нужно пользователям, чего им в этой жизни не хватает, что в текущем инструментарии их не устраивает. В этом отношении фидбэк очень ценен.
Иногда приходят просто багрепорты, что «мы сделали вот так, и у нас всё сломалось». Или приходят фича реквесты: было бы здорово, если бы была такая-то функциональность. Мы всё это слушаем, общаемся с людьми, стараемся оперативно, насколько это возможно, реализовывать.
— Сколько вас сейчас работает над Rider?
— Core Team — чуть больше 10 человек, но нужно понимать, что ещё у нас есть команды ReSharper и IDEA, с которыми мы тоже постоянно сотрудничаем. Иногда находим баги в той или иной платформе, иногда нам не хватает какого-то функционала, мы приходим к ребятам из других команд, и как-то обсуждаем эти проблемы. Поэтому можно сказать, что за сотню.
— В «Без слайдов» в своё время Дима Жемеров рассказывал про то, как IDEA превратилась из IDE в платформу через механизм Extension Points. А Сергей Шкредов рассказывал, что ReSharper умеет, условно, прогонять инспекции в nightly-билдах, всё это провязывается с TeamCity, и так далее. Правильно ли я понимаю, что примерно в этих двух местах и была сделана интеграция? То есть как вы это делали?
— У нас есть два процесса. Мы их называем «бэкенд» — это, собственно говоря, ReSharper — и «фронтенд», IDEA. Между ними осуществляется общение по нашему специальному протоколу, и по нему мы, по сути, гоняем view-model.
— А он поверх чего, поверх сокетов?
— Поверх сокетов. Мы про разные варианты думали, но этот нам подошёл больше всего. Сначала мы хотели гонять всю модель, которая есть у ReSharper. Есть, например, синтаксические деревья, которые строит IDEA для поддержки Java, но если бы мы полностью перегоняли синтаксические деревья для C#, это была бы очень дорогая операция, мы бы не вытянули перфоманс…
— То есть, трафик данных?
— Да, протокольный трафик очень велик. Поэтому мы гоняем очень легковесные модельки, только view-model, только то, что нам нужно отобразить для пользователя. Только информация для UI.
— А синтаксическое дерево лежит на стороне ReSharper-а?
— Да. То есть у ReSharper есть дерево, он его как-то обрабатывает, считает все анализы, и на сторону IDEA просто перекидывает несколько строк, например, с сообщениями из подсистемы инспекций.
— Просто, насколько я понимаю, IDEA работает именно с неким деревом, которое в том или ином языке строишь и гоняешь. Здесь, видимо, пришлось сильно переделывать, да?
— Да, мы это не используем, мы используем API’шки, например, «подчеркни красной линией здесь вот, потому что ReSharper сказал, что здесь ошибка». Мы не делаем анализа на стороне IDEA. Все анализы делает ReSharper. А от IDEA большей частью используем «показать UI».
— То есть вы интегрировались с IDEA не там, где другие языки интегрируются. Многое ли для такой интеграции пришлось переписать в IDEA?
— Нет, на удивление не так много.
— А какие части ReSharper и IDEA переписывались для того, чтобы это всё работало?
— Не так много пришлось править, больше просто подверстать некоторые API. У нас есть собственные коммиты в IDEA, но большая часть коммитов связана с тем, что мы берём какой-нибудь private и меняем его на public. Какой-нибудь метод никогда не вытаскивался вовне, а нам понадобилось его вызвать, потому что мы делаем то, что другие языки не делают. И, конечно, самая большая работа была проделана, чтобы ReSharper нормально запускался на Linux и Mac поверх Mono. Мы узнали очень много про кроссплатформенную разработку 🙂 Недавно делали семинар на тему кроссплатформенности в Rider, уже доступна видеозапись.
— У меня была история, что я ставил Mono на Mac через Homebrew, и на одном из ранних билдов у меня ReSharper просто отказался видеть такой Mono. Я понимаю, что, наверное, не самая сложная задача — пофиксить всё вот это. Но есть у тебя ощущение, что вы вот сейчас к публичному EAP с такого типа косяками справились?
— Ну, мы разгребли основную массу самых мажорных косяков. Сейчас Rider — это IDE, которой реально можно пользоваться. Там не все фичи работают идеально, иногда где-то что-то отваливается, но большинство сценариев работает.
— Понятно, что релиз — вещь продуктовая, но интересует чисто твоё субъективное инженерное ощущение: много ли ещё нужно сделать для того, чтобы уйти в продакшен? Какие вещи будете сейчас в первую очередь дорабатывать?
— Нам осталось сделать не так много. В первую очередь, нужно поработать над стабильностью…
— Не то что бы падаем, но недавно, например, пришёл реквест: вот у меня ArchLinux, я поставил туда Rider, и у меня что-то там не работает. У нас, скажем так, нет большого опыта работы с ArchLinux, мы разбираемся… Это не основная масса наших пользователей, скорее экзотические сценарии.
— Та же Java, например, сертифицируется не на всём Linux, есть очень строгое описание того, каким должен быть дистрибутив. По-моему, дело в том, что референс-платформой является Oracle Linux: условно говоря, Red Hat-подобный дистрибутив со всеми вытекающими последствиями. Про остальное Java гарантий не даёт, и интересно, что вы делаете в этом месте. Вы поставляете собственную JVM?
— Да, мы таскаем с собой собственную Java и собственную Mono, поверх которой работаем. У нас нет задачи работать абсолютно везде или поддерживать «вот эти, вот эти, вот эти» версии Линукса, а остальные не поддерживать, мы просто, насколько это возможно, пытаемся сделать максимум пользователей счастливыми, чтоб они смогли пользоваться нашей IDE.
— Mono. Ну, на macOS и Linux — Mono определённой версии, а под Windows мы запускаемся на полном фреймворке — том, который стоит у пользователя.
— C ним меньше проблем?
— Да, потому что ReSharper — изначально продукт, который работает поверх полного фреймворка. А с Linux, конечно, возникло много проблем, мы много контрибьютим в сам Mono, много патчей накатываем на Mono, которое ходит с нами, чтобы нам поверх этого хорошо работать. Это большой объём работ.
— Вы в upstream это контрибьютите?
— Да, конечно. Мы пытаемся все changeset-ы, которые мы делаем, пропихнуть.
— Много из Mono вытащили багов за этот год?
— Слушай, вот вся эта весёлая связка “Mono, Xamarin, Microsoft”, и вся история про разные рантаймы (Mono, классический, Core) — вот как вы со всем этим пёстрым зоопарком будете жить?
— Короткий ответ — как-то будем. Мы пытаемся всё это поддерживать. Больше всего проблем, конечно, с CoreCLR, потому что это вещь, которая ещё, можно сказать, до конца не вышла. Вот буквально недавно Microsoft представили новую Visual Studio 2017 и вместе с ней новый тулинг для CoreCLR, в котором они опять всё поменяли.
— То есть, подожди, была версия 1.0, про которую сказали, что стабильная, потом вышла 1.1…
— Нет, есть две разные вещи. Есть рантайм, и есть тулинг к нему. Рантайм — это VM-ка, поверх которой мы бежим. А тулинг — это как мы это всё собираем.
— То есть вышел новый тулинг.
— Да. Вот был такой формат проектов, основанный на project.json-файлах, многие про него слышали или даже работали, Microsoft этот проект очень долго продвигал, говорил «будущее в json-ах», «переводите ваш проект в json-ы». А потом внезапно они говорят «ой, чё-то не пошло, мы возвращаемся обратно на csproj». Много месяцев тому назад объявили, что project.json — это уже legacy, поддерживаться не будет, но альтернативы не представили. И вот она буквально неделю назад появилась.
— Если ты меня спросишь, какие у меня ощущения от истории с CoreCLR, то мне в голову приходит слово «хаос». Какие у вас ощущения с коллегами?
И понятно, что такое за один день не делается, это гигантский объём работы. Сделать тот же CoreCLR, сделать дотнет кроссплатформенным, чтобы на мобилках всё работало и так далее. Понятно, что ребята хотят как можно раньше всё это сделать, и естественно, что делают какие-то ошибки, которые потом приходится признавать, откатывать, что-то менять… Это разумная цена, которую приходится платить за скорость развития современного дотнета.
— Здесь всё зависит от того, что конкретно ты разрабатываешь. Если ты разрабатываешь на том же дотнете, который когда-то был и сейчас есть (полном фреймворке для Windows), у тебя не должно быть таких проблем. У тебя все те проблемы, что и раньше, может быть, немножечко меньше.
А если ты начинаешь разрабатывать на CoreCLR, то слово «preview» в названии должно тебя насторожить и подготовить к тому, что с тобой будет дальше.
Есть люди, которые пытаются сидеть на bleeding edge, на самых последних технологиях, и влиять на их развитие, потому что Microsoft сейчас очень активно слушает комьюнити: если в новом дотнете что-то не нравится, сейчас самое время написать им фидбэк. А другие люди просто ждут, когда всё это станет стабильным.
— Да! Прежде всего… У нас есть два рантайма, поверх которых мы можем бежать на Linux и Mac — это Mono и CoreCLR. Они разные, каждый интересный и заслуживает особого внимания.
Mono — это проект, который разрабатывается с начала 2000-х, и чем дальше, тем стабильнее становится, его можно рассматривать как всё более и более серьёзный рантайм. Если люди, которые пытались что-то переводить на Mono пять-десять лет назад, страдали, то сейчас… Ну, мы тоже, конечно, немножко страдаем. Но ReSharper, в котором сотни проектов, миллионы легаси-строчек кода, которые писались с начала двухтысячных, пусть и немножко скрипя, завёлся и отлично работает поверх Mono. То есть развитие идёт, баги фиксятся, и в последнее время они фиксятся очень быстро.
— По тому, что вы видите по своим клиентам: уходят ли они на CoreCLR?
— Пока что сложно сказать. Можно сказать, что интерес к CoreCLR со стороны комьюнити очень большой, очень много людей следят за развитием, пытаются что-то делать, пробуют. Но всё это ещё превью, и делать какой-то энтерпрайз поверх CoreCLR ещё рано.
— А что с Roslyn? Вышла новая Студия, что там у них с компилятором?
— Roslyn развивается. Скоро выйдет C# 7, в новой Студии уже доступна превьюшка. С Roslyn всё хорошо.
— C# 7 идёт с Roslyn — прямо из коробки? Roslyn прогрессирует за это время?
— Да. В нём фиксят баги, развивают, и… Самая главная возможность, которую мы получили, перейдя со старого легаси-компилятора на Roslyn — это то, что мы теперь можем проще развивать язык. Можем больше концентрироваться на том, какие фичи нужны с точки зрения языка и как их правильнее реализовать, чем на имплементации. На старом компиляторе было очень тяжело дописывать новые фичи, с Roslyn это стало в разы проще.
— Вы пытались затащить к себе куда-нибудь Roslyn и что-нибудь с этим сделать?
— Ну как. Мы используем его как компилятор. Он работает под MS-билдом, и с помощью него компилируются новые проекты. Но в отношении анализаторов или инспекций то, что он предоставляет, нам просто не нужно, потому что в ReSharper реализовано намного больше. Я бы сказал, в разы больше, очень крутые инспекции, более интеллектуальные. И Roslyn легко может сожрать два гигабайта памяти. В этом плане кодовая база ReSharper всё-таки поэкономнее относится к памяти, активно использует кэши и так далее. То есть у нас от перехода на Roslyn не было бы никакого профита, одни проблемы.
— Поговорим о перфомансе. CoreCLR, Roslyn по сравнению c Mono с классическим legacy-компилятором. То есть два рантайма, у них будет разный перфоманс. Как тебе это видится?
— Однозначно сказать очень сложно… С недавних пор есть новый JIT-компилятор RyuJIT. Сейчас доступна только 64-битная версия, причём как в полном фреймворке, так и на CoreCLR. И в CoreCLR 1.2.0 нам обещают ещё и x86-версию.
Но хорошая сторона в том, что RyuJIT сейчас очень активно развивается. Он очень активно разрабатывается на гитхабе, ребята улучшили архитектуру так, что, например, в RyuJIT встроена хорошая интеграция по работе с AVX и SSE-инструкциями. И оптимизации развиваются. Можно прийти на GitHub, сказать «ребята, вот есть такая хорошая оптимизация, но вы её почему-то не делаете, а вроде можно легко дописать». И вполне возможно, что они возьмут эту оптимизацию и её завтра или через месяц сделают.
— А ты сам контрибьютишь куда-то?
— Я делал пару не особо крутых коммитов в CoreCLR и CoreFX. Больше участвую в обсуждениях, завожу тикеты «ребята, давайте сделайте вот это». Потому что рантайм — это всё-таки такой большой проект, есть люди из сообщества, которые активно работают над ним, но нужно понимать, что здесь достаточно высокий порог вхождения, и прежде чем какую-то полезную оптимизацию для компилятора напишешь, нужно очень много времени изучать кодовую базу.
— Лёша Шипилёв, который был здесь года полтора назад, говорил, что есть очень серьезный порог вхождения — это несколько лет для любых компиляторщиков и вообще системщиков, а время, через которое человек начинает приносить пользу — это вообще чуть ли не десять лет. Это оень серьёзный барьер для входа.
— Очень во многом это всё было переделано и переписано как раз для того, чтобы порог входа был ниже, потому что иначе невозможно же.
— Да, абсолютно верно.
— Это абсолютно работающая схема. Microsoft сейчас — топовый контрибьютор на GitHub. Очень много обсуждений идёт со стороны сообщества. То есть люди, особенно хорошо понимающие в дотнете, которые понимают, что в нём было не так, хотят как-то на это повлиять. Сейчас любой может создать issue на GitHub, это будет рассмотрено точно так же, как issue от сотрудника Microsoft, будет вестись…
— Или не будет! Но так же, как и для любого другого сотрудника Microsoft. И реально эти issue закрывают. Также ты можешь сделать пуллреквест, если он хороший, не нарушает никакие гайды, не несёт в себе никаких проблем и ты его покрыл тестами, его вполне могут принять.
Есть ещё такая интересная история. Новый ASP.NET-сервер Kestrel сейчас в топ-10 линуксовских веб-серверов по скорости. Его разогнали по перфомансу очень сильно. Есть популярный бенчмарк, который гоняется для всех серверов…
— По всем — Java, C++, всё на свете. И Kestrel там вошёл в топ. И во многом он вошёл благодаря такому человеку, как Бен Адамс: он не из Microsoft, он пришёл со стороны комьюнити и начал контрибьютить в Kestrel.
— Это майкрософтовский проект?
— Да. То есть Сore Team майкрософтовская, а это просто человек со стороны пришёл, начал очень активно контрибьютить перфоманс-улучшения в сервер, и разогнал его.
Microsoft и Open Source
Есть ли вообще у Microsoft, по твоему ощущению, понимание того, что такое опенсорс, как это работает?
— Да. Мне очень нравится Microsoft в последние два-три года, когда Сатья пришёл, всё стало совершенно по-другому. У Microsoft есть понимание, возможно, оно не совсем было в самом начале, но сейчас есть.
— То есть они адаптировались?
— Да, они адаптировались очень круто, это не только про Open Source, но и про кроссплатформенность. Вот ты слышал, наверное, Microsoft недавно присоединилась к Linux Foundation.
— Да, это был мой следующий вопрос: зачем они это делают, на твой взгляд?
— На мой взгляд, они поняли, что раньше что-то делали не так, поняли, что Linux их тоже интересует как операционная система. Например, они продвигают такой продукт, как Azure…
— «Например»! Это сейчас вообще топовый продукт Microsoft. Если ты послушаешь их евангелистов, посмотришь их конференции и блоги, увидишь, что Azure, наверное, вообще номер один.
— Ну, я не знаю, как по номерам, но ты совершенно прав, один из топовых сервисов, они делают на нём очень большие деньги. И вот, как они недавно заявляли, у них треть серверов крутится под Linux.
— Тогда для них это прямой business value.
— То есть можем ли мы говорить, что схема такая: Microsoft двигает Azure, поскольку видит в нём деньги. Очень многие клиенты хотят Linux (потому что это дешевле, чем Windows, и по многим другим причинам). Соответственно, Microsoft пытается сделать всё, чтобы этих кастомеров не потерять и чтобы они приходили с этим линуксом в Azure.
— Ну, я думаю, это как минимум одна из причин.
— А какие ещё, на твой взгляд? Вряд ли чистым альтруизмом можно объяснить всё это движение в сторону Linux и Open Source.
— Есть ещё рынок мобильных приложений. Это приложения для телефонов и планшетов. Microsoft, мягко говоря, чуть-чуть опоздал с этим рынком. Им уже завладели Apple и Google. С этим нужно было что-то делать.
— Такой гигант — и так плохо вышел на рынок. Не секрет, что Windows Phone имеет небольшую экосистему и низкий процент популярности.
— А почему так получилось? В Windows Store мало приложений. Раз мало приложений, мало людей покупает соответствующие девайсы. Раз мало людей покупает девайсы — мало девелоперов делает приложения.
— Ну да, это замкнутый круг.
— Но есть интересный вариант, как в перспективе из него можно выйти. В частности, Microsoft сейчас приобрела компанию Xamarin и активно продвигает Mobile Development на C#.
— Мы с командой в декабре проведём уже шестой DotNext (в Хельсинки) и седьмой (в Москве), на которых ты выступишь. На DotNext периодически всплывает тема, например, Xamarin.Forms. Мы каждый раз смотрим на её популярность, и каждый раз она в самом низу. По той аудитории, которая приходит к нам, такое ощущение, что это никому не интересно.
— Ну, я бы сказал, что это специфическая аудитория. Всё-таки на DotNext больше приходят энтерпрайз-девелоперы, а людей, которые занимаются мобильными приложениями, у нас не так много, и отчасти это из-за того, что на дотнете их раньше было толком не подевелопить. А сегодняшняя тема с Xamarin идёт последние пару-тройку лет, возможно, даже меньше.
Сейчас C# — это действительно такой язык, с помощью которого можно написать для Xamarin приложение, которое будет работать сразу и под Windows, и под Android, и под iOS. Там есть проблемы, но в целом ребята хорошо сделали продукт. Что делает саму эту платформу разработки привлекательным вариантом для разработчиков.
Речь не идёт о топовых приложениях, если ты хочешь попасть в топ Google Play или App Store, тебе придётся писать native. Но если нужно простое приложение, приложение-визитка с информацией про твою компанию или с одной кнопкой «купить билеты», тебе не нужен супермощный функционал, тебе не нужна суперскорость, тебе нужно быстро наклепать приложение, которое даёт тебе простой контент, простой функционал, и желательно под все платформы, то C# — это отличный выбор.
— А почему именно в топ не попасть?
— Всё-таки есть определённые проблемы с перфомансом. Если не знаешь заранее, на какой платформе будешь запускаться, сложнее дёргать за какие-то ручки и низкоуровневые API, разные платформы предоставляют разный набор API. И не всегда получается для сложного интерфейса сделать так, чтобы приложение выглядело как родное. Всё равно в native больше API, возможностей использовать фичи нативного UI, и так далее.
По срезу аудитории того же Rider, очень много людей проявляет интерес к Xamarin, к разработке под мобилки, многие этим занимаются.
— То есть, на твой взгляд, будущее у этого всего может быть?
— Да, «может быть» — самая правильная формулировка. Происходят инвестиции в этот стек технологий, его популярность растёт.
— Это очень сложно сравнивать.
— Вы со стороны своих инструментов Xamarin поддерживаете?
— Возможно, ещё не так хорошо, как хотелось бы, но, например, к Rider 1.0 хотим сделать хорошую поддержку, чтобы можно было комфортно девелопить под мобилки.
BenchmarkDotNet
— Мы сейчас уже заговорили про перфоманс, и мы с тобой так и познакомились ещё до твоей работы в JetBrains: ты писал инструмент для перфомансных замеров, микробенчмарков и тому подобного, который сейчас называется BenchmarkDotNet. Что у тебя сейчас с ним происходит?
— А кто там, кроме BencmarkDotNet?
— Это хороший промоушен для вас, или вы пока не видите увеличенного количества скачиваний?
— А нужны ли вообще людям микробенчмарки? Условно говоря, я понимаю, зачем Шипилёв пишет микробенчмарки в Java: он разработчик платформы, и им с коллегами надо понимать, с какой скоростью в платформе работают те или иные вещи, причём делать это на микроуровне. А вот конечному разработчику приложения это нужно?
— Зависит от того, что за приложение. Мы с тобой уже обсуждали Kestrel, который выстрелил, вот там тот же Бен Адамс BenchmarkDotNet вовсю использует для тюнинга производительности. Для тюнинга того же рантайма — я видел, некоторые ребята использовали, чтобы обкатать некоторые фичи…
— Ты сейчас говоришь про рантайм и сервер, которые внутри Microsoft зародились. Я понимаю, что BenchmarkDotNet — это инструмент, который нужен людям из Microsoft. А остальным?
— Есть ещё люди, которые просто разрабатывают определённые библиотеки, и делают упор на high performance. Хотят, чтобы их библиотеки были самыми быстрыми. Потому что есть ещё 20 библиотек, которые делают то же самое, и им надо чем-то выделиться. Некоторые реально используют BenchmarkDotNet для какой-то перфоманс-работы, некоторые используют, по-моему, просто для пиара, померили и говорят «вот у нас хорошо».
— Ну это беда, потому что намерить с помощью инструмента можно что угодно — это опасно, это можно сделать это в определённых маркетинговых целях, но в реальности такие замеры ничего не скажут.
— Да, абсолютно согласен с тобой, но… Есть ещё одна проблема. В Java-мире уже достаточно давно есть JMH, и большая часть народа знает, что тебе нужен бенчмарк — бери JMH…
— Знаешь, я видел случаи, когда люди берут JMH, строят по нему графики и говорят «A быстрее, чем B». Но в реальности это ересь.
— Да, есть много таких случаев, но, как минимум, у тебя не будет большого количества детских ошибок. Если ты где-то ошибёшься, то уже на дальнейших этапах. За тебя сделают прогрев, за тебя сделают N итераций, посчитают какие-то статистики.
То, что ты используешь какой-то инструмент для бенчмаркинга, не делает твой бенчмарк автоматически правильным. Тебе всё равно нужно многое понимать о том, как работает компьютер, как устроен рантайм. Но ты избежишь простых типичных ошибок, особенно если не разбираешься в бенчмаркинге. Получишь какие-то инструменты для того, чтобы всё это автоматизировать, то есть тебе не надо будет для каждого бенчмарка руками писать прогрев, писать всю эту инфраструктуру, которая это запускает, у тебя уже есть готовая тулза.
— Ты при разработке этого смотришь на JMH?
— BenchmarkDotNet получился другим или похожим? И если другим, то в чём ключевое отличие?
— В это вкладывается много сил. Одним из главных достоинств моей бенчмаркалки я считаю то, что она позволяет сделать бенчмарк сразу для разных платформ. Навешал три атрибутика, и сразу запустил свой код для Mono, для полного фреймворка и для CoreCLR. Причём можешь больше атрибутиков написать и запускать ещё с разными параметрами, какие-то флажки повыключать-повключать. И всё это посравнивать.
Это очень удобно в том отношении, что если ты хочешь перенести какой-то код с полного фреймворка на Mono и интересуешься, как это скажется на производительности, ты можешь отдельные части аккуратно посравнивать. Это первый момент. Второй — как ты совершенно правильно отметил, люди не понимают в производительности, не понимают, как делать замеры, даже если у них есть хороший инструмент, они всё равно могут легко сделать направильные выводы. И JMH — это больше инструмент для людей, которые понимают, что они делают. Но по факту большая часть людей не понимает. Не потому что они там глупые, а просто потому что они этой темой не занимаются, а бенчмаркинг требует очень много сил и времени.
— В чём преимущество BenchmarkDotNet перед, скажем, профилировщиками от JetBrains?
— Профайлинг и бенчмаркинг — похожие деятельности, многие их путают, но это совершенно разные вещи. Профайлинг — это ты просто снимаешь профиль своего приложения, как оно бежит, один снэпшот. А бенчмарки помогают изучать разные перфомансные эффекты, разбираться, как у тебя система работает в тех или иных условиях, получать довольно высокий уровень точности.
Это не та деятельность, которая нужна всем. Если я вижу, что Rider начал очень медленно работать, я снимаю профиль, вижу, что какая-то новая функция работает десять секунд вместо одной, смотрю, что там не так, исправляю. А когда речь заходит о наносекундах и микросекундах, сравнении рантаймов и конфигураций, уже просто так не получишь с помощью профайлинга нужный уровень точности, и будет очень сложно сравнить разные конфигурации.
— Мне очень нравится в том же JMH, что там, по сути, есть интеграция профилировщиками с разного уровня. Там можно запустить с таким, с сяким, посмотреть стеки по процентам, байткод, процессорные инструкции, это позволяет на всех уровнях увидеть проблему. Есть ли у тебя какие-то такие интеграции?
— Да. Мы сейчас активно пишем плагины к BenchmarkDotNet. В частности, у нас есть диагностики, позволяющие, например, следить за размером выделенной памяти.
— Ну да, сколько памяти на метод ушло. Сейчас мы немного переписали логику, она теперь с очень хорошим уровнем точности показывает memory traffic. Другая диагностика показывает, какие у тебя методы за-JIT-ились, а какие нет. Это направление мы тоже развиваем.
— Кто работает над проектом? Наверное, главный контрибьютор — это ты, я знаю ещё Адама Ситника. Кто ещё?
— Ещё Мэтт Уоррен, хороший девелопер из Великобритании. Он многое в отношении диагностик сделал, много полезных обсуждений с ним было.
— Какие-то известные люди к вам приходили?
— Ну вот начинали это делать ещё с Джоном Скитом. Он изначально ничего не контрибьютил, но с Джоном можно очень хорошо пообщаться, он может подсказать очень хорошие вещи.
— Джон вроде бы к нам в Питер на DotNext собирается?
— Да, совершенно верно. В конце мая будет петербургский DotNext, он там один из спикеров.
— А что вы Сашу Гольдштейна не подключите, например?
— Саша нам тоже контрибьютил что-то.
— Меня удивляет его удивительное спокойствие. И у Саши есть ещё такое свойство — он знает весь стек насквозь до деталей работы в железе. Очень важная часть, когда ты работаешь над бенчмарком — понимать железо. Вот что ты сам в этом отношении чувствуешь о своём понимании?
— Я чувствую, что за последние несколько лет, за которые я написал очень много бенчмарков, я стал понимать железо намного лучше. Железо — это, наверное, такая вещь, которую никто никогда не понимает до конца, но можно бесконечно качаться.
Конечно, никакой Intel не рассказывает же, как у них всё внутри работает, потому что патенты, ноу-хау, конкуренты, AMD, ARM, Samsung— да кто угодно.
— Да. Я иногда вылавливаю хитрые перфомансные эффекты, которые не могу объяснить публичными спецификациями Intel, то есть они иногда внутри делают что-то очень хитрое…
— Ты не пытался им самим вопросы задавать?
— Ну да, «вот у нас бенчмарк тут странный, вы не могли бы подсказать». Вот ты же работаешь с Microsoft, и для тебя это естественно — работать с большим вендором. Что мешает тебе так же работать с Intel?
— Во-первых, как мы с тобой уже обсудили, Microsoft сейчас стал более открытой опенсорсной компание. Intel в этом плане, скорее всего, намного более консервативный — это раз…
— Есть же люди, которые, скорее всего, со стороны Intel контрибьютят в эти замечательные майкрософтовские проекты. В Java они точно есть, там ребята из Intel приходят и говорят: «У нас новый intrinsic, вот вам патч, который. »
— Мне кажется, между Intel и Microsoft должны быть хорошие связи.
— Неплохие. Но такого прямо открытого налаженного процесса я не наблюдаю. И я боюсь, то, что меня интересует, составляет коммерческую тайну, и мне просто об этом никто не расскажет.
Компиляция в native и подведение итогов
— Пока что нет. Там трудности в непроработанности технологии.
— То есть она просто сырая?
Ну смотри, есть разные виды нативной компиляции. NGen, который испокон веков в дотнете есть — это не очень интеллектуальная вещь, простая тупая ahead of time-компиляция.
— Что она даёт? Она же наверняка даёт не очень хороший перфоманс. Это многопроходный хотя бы компилятор? Я почему задаю этот вопрос: в современной GCC есть сценарии, на которых они делают по 70 проходов. То есть они по internal representation вот так вот много раз бегают.
— NGen в этом плане, конечно, тупее, но там есть, например, такая вещь, как profile-guided optimization: когда ты используешь профиль рабочего приложения, чтобы как-то более правильно заранее расположить.
— То есть, запускаешь своё приложение с некоторым агентом, этот агент запускает некую статистику, потом ты её на входе скармливаешь NGen’у, и он что-то делает?
— Грубо говоря, да, и по идее, это должно хорошо работать, но на практике очень мало людей этим пользуется. Выгода в основном в том, что экономишь на времени JIT-компиляции. То есть людям, которым критично время холодного старта, чтобы большая программа завелась и сразу начала что-то быстро делать, разумно это использовать. Остальным… Ну, какого-то особого профита я не наблюдаю, и никто не заморачивается.
— Но если хорошо скомпилируешь, то нет накладных расходов на компиляторные потоки. JIT-компилятор ведь работает в той же машине. Это footprint, всё это отъедает память, хочется понять, какие перспективы у этого всего.
— Перспективы немножко в других технологиях.
— Хорошо, мы поговорили про NGen, а что сейчас происходит, новая компиляция в натив?
— Предположительно в майкрософтовский.
— Нет, в обычный. Сложно ещё про эту технологию рассуждать, потому что она не готова, и непонятно, в каком виде она будет в итоге, когда и если она будет готова. Потому что Microsoft в начале начали очень радужно рассказывать, что вот, уже почти всё готово, но потом оказалось, что оно не очень готово, и как-то сейчас они эту тему замяли, тихонько что-то девелопят на гитхабе, но не особо про это рассказывают.
— У меня из нашего разговора сложилось впечатление, что в попытке покрыть всё Microsoft покрывает не ровными областями, а сначала так, потом этак, и одно и то же становится возможно сделать многими способами. И возникает вопрос: я хочу что-то написать — как мне это сделать? Какой рантайм выбрать? Я ставлю Rider, думаю «вот у меня новая крутая IDE, я C#-программист, у меня новый проект». Как мне выбрать правильную технологию для него?
— И это трудно, потому что этого как-то резко стало много. Мне тяжело ориентироваться, и думаю, что человеку, который большинство времени пишет продакшен-код для энтерпрайз-проекта, не сильно легче. И я вижу тут проблему. Прокомментируй, пожалуйста: вот тебе с этим зоопарком как живётся в Rider?
— Тяжело. Постоянно приходится держать руку на пульсе, разбираться с новыми технологиями, желательно начинать в день их выхода, потому что сразу приходят недовольные пользователи, бывает, ещё на этапе preview. Поэтому активно приходится изучать каждую новую версию тулинга, каждую версию этих рантаймов, следить за этим всем. Это вполне реально делать. Но этим, конечно, нужно заниматься.
Если мы говорим о старых проектах, их чаще всего разрабатываешь на чём-то, что хорошо понимаешь. А что касается новых, знающие люди должны делать соответствующей рисерч, на какой платформе более рентабельно делать новые проекты какого размера.
— В своё время у Джоэла Спольски была программная статья про Microsoft. Он писал, что Microsoft постоянно делает новые технологии и сама на этом зарабатывает, а всем другим не даёт. И что люди, работающие с Microsoft, вынуждены постоянно заниматься переписыванием под новые MS-стандарты, платформы и среды. Это он писал лет 15 назад, и как-то не сильно всё изменилось. Люди не business value делают, а переписывают код с одного рантайма на другой.
— Это правда. Единственный совет, который я могу дать — не использовать для серьёзного продакшена тех технологий, которые вышли вчера. Если продукт вышел 2-4 года назад и развивается — про него можно подумать.
— Есть ещё история про экосистему: если продукт существует 2-3 года, то появляется некоторое количество документации, ответов на Stack Overflow, статей на Хабре или Medium, в блогах. В общем, не перегибает ли тут Microsoft палку? Вам тут как?
— Тяжело. У нас много разработчиков ходят по офису и жутко матерятся, что вот, опять Microsoft старую технологию закрыл, новую открыл.
— За вами же легаси тянется. Вот вы делаете ReSharper, и он что-то поддерживал. И пусть Microsoft это уже не очень поддерживает, вы вынуждены это тянуть. Если в своём коде я могу при выходе несовместимого 1.1 всё переписать и 1.0 выкинуть, то у вас же будут кастомеры, которые сидят на 1.0. И как вы на это закладываетесь?
— Конечно, тяжело разрабатывать, приходится вбивать много костылей, но мне кажется, что ты всё-таки немножко драматизируешь. Если взять историю с CoreCLR, то там ещё стабильная версия тулинга не вышла. Было preview 2, недавно вышло preview 3. Мы preview 2 ещё поддерживаем, будем поддерживать, грубо говоря, N месяцев, пока все не обновятся. Потом эту поддержку можно будет выкинуть, поддержать preview 3, и в конце концов 1.0. И вот уже stable-версию будем поддерживать долго.
Но это одна-единственная подсистема Rider, ну, с небольшими костылями. Не нужно перелопачивать весь код. Анализаторы C# работают вне зависимости от того, какой у тебя рантайм, какие-нибудь инспекции тоже, им это не важно. Проблема с тем, чтобы сбилдить, запустить, и просто у нас есть там отдельные подсистемы, которые отвечают за сборку под ту или иную версию того или иного рантайма.
