Проект Rider (.NET IDE от JetBrains) дошёл до публичной EAP-версии — самое время подробно расспросить Андрея Акиньшина, одного из его разработчиков. Но Rider стал не единственной темой нового выпуска «Без слайдов». Помимо него, поговорили
- о библиотеке BenchmarkDotNet, которую разрабатывает Андрей
- о движении Microsoft к опенсорсу и кроссплатформенности
- об общем состоянии .NET-мира и, конечно,
- о .NET-конференции DotNext (которая, кстати, состоится в Москве уже в эту пятницу)
Как всегда, под катом есть полная расшифровка интервью.
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.
— А в том, что касается .NET, вы что с собой таскаете?
— Mono. Ну, на macOS и Linux — Mono определённой версии, а под Windows мы запускаемся на полном фреймворке — том, который стоит у пользователя.
— C ним меньше проблем?
— Да, потому что ReSharper — изначально продукт, который работает поверх полного фреймворка. А с Linux, конечно, возникло много проблем, мы много контрибьютим в сам Mono, много патчей накатываем на Mono, которое ходит с нами, чтобы нам поверх этого хорошо работать. Это большой объём работ.
— Вы в upstream это контрибьютите?
— Да, конечно. Мы пытаемся все changeset-ы, которые мы делаем, пропихнуть.
— Много из Mono вытащили багов за этот год?
— Я думаю, добрый десяток хардкорных багов нашли. Например, в Mono была плохо реализована работа с мьютексами. Там были именованные мьютексы, которых как бы нет на Linux и macOS, но есть в .NET. Поэтому пришлось как-то эмулировать с ними работу, она была эмулирована не до конца, и в исходниках NuGet’а — мы же должны полностью реализовывать работу своего NuGet. Мы две недели ловили этот Race Condition, который где-то там внутри возникал, потом выяснили, что он возникает не только с именованными мьютексами, но и с обычными, запатчили, потом заслали фикс в Mono, он уже попал в мастер-ветку.
Настоящее и будущее .NET
— Слушай, вот вся эта весёлая связка “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, то мне в голову приходит слово «хаос». Какие у вас ощущения с коллегами?
— Отчасти, конечно, мы с тобой согласны, потому что очень много всего происходит, меняется в инфраструктуре, в отношении к .NET. Но я считаю, что это достаточно хорошо. Потому что .NET — такая платформа, которая очень много лет жила своей жизнью в рамках Windows-экосистемы, и внезапно Microsoft полностью поменяли стратегию, взяли курс на кроссплатформенность, Open Source и всё такое.
И понятно, что такое за один день не делается, это гигантский объём работы. Сделать тот же CoreCLR, сделать дотнет кроссплатформенным, чтобы на мобилках всё работало и так далее. Понятно, что ребята хотят как можно раньше всё это сделать, и естественно, что делают какие-то ошибки, которые потом приходится признавать, откатывать, что-то менять… Это разумная цена, которую приходится платить за скорость развития современного дотнета.
— Нет ли такого, что человек пишет на .NET, сегодня слышит одно, завтра другое, ему приходится всё переделывать несколько раз, он просто плюёт и говорит «нафиг я тут трачу кучу времени на переписывание, пойду-ка на другую платформу».
— Здесь всё зависит от того, что конкретно ты разрабатываешь. Если ты разрабатываешь на том же дотнете, который когда-то был и сейчас есть (полном фреймворке для Windows), у тебя не должно быть таких проблем. У тебя все те проблемы, что и раньше, может быть, немножечко меньше.
А если ты начинаешь разрабатывать на CoreCLR, то слово «preview» в названии должно тебя насторожить и подготовить к тому, что с тобой будет дальше.
Есть люди, которые пытаются сидеть на bleeding edge, на самых последних технологиях, и влиять на их развитие, потому что Microsoft сейчас очень активно слушает комьюнити: если в новом дотнете что-то не нравится, сейчас самое время написать им фидбэк. А другие люди просто ждут, когда всё это станет стабильным.
— Ты затронул очень интересную тему — дотнет и кроссплатформенность, дотнет и опенсорс. Давай про эти два больших блока поговорим. Вот про Linux, раз уж мы это затронули: .NET и Linux вместе уже какое-то время существуют. Стало ли за это время лучше?
— Да! Прежде всего… У нас есть два рантайма, поверх которых мы можем бежать на 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 — очень интересный проект. С одной стороны, хорошо, что ребята начали его делать, потому что старые JITы тяжело было развивать, они тащили с собой много проблем, много хаков для старых версий .NET вроде 2.0. Но что получилось плохо — это что RyuJIT, например, уступает старым легаси-JIT’ам в некоторых моментах по перфомансу. То есть там ребята делали упор на то, чтобы скорость JIT’инга была как можно больше. И из-за этого некоторые хорошие оптимизации не применяются.
Но хорошая сторона в том, что RyuJIT сейчас очень активно развивается. Он очень активно разрабатывается на гитхабе, ребята улучшили архитектуру так, что, например, в RyuJIT встроена хорошая интеграция по работе с AVX и SSE-инструкциями. И оптимизации развиваются. Можно прийти на GitHub, сказать «ребята, вот есть такая хорошая оптимизация, но вы её почему-то не делаете, а вроде можно легко дописать». И вполне возможно, что они возьмут эту оптимизацию и её завтра или через месяц сделают.
— А ты сам контрибьютишь куда-то?
— Я делал пару не особо крутых коммитов в CoreCLR и CoreFX. Больше участвую в обсуждениях, завожу тикеты «ребята, давайте сделайте вот это». Потому что рантайм — это всё-таки такой большой проект, есть люди из сообщества, которые активно работают над ним, но нужно понимать, что здесь достаточно высокий порог вхождения, и прежде чем какую-то полезную оптимизацию для компилятора напишешь, нужно очень много времени изучать кодовую базу.
— Лёша Шипилёв, который был здесь года полтора назад, говорил, что есть очень серьезный порог вхождения — это несколько лет для любых компиляторщиков и вообще системщиков, а время, через которое человек начинает приносить пользу — это вообще чуть ли не десять лет. Это оень серьёзный барьер для входа.
— Ну, я бы не сказал, что в новом .NET это десять лет, потому что как-то люди входят…
— Очень во многом это всё было переделано и переписано как раз для того, чтобы порог входа был ниже, потому что иначе невозможно же.
— Да, абсолютно верно.
— Вы взаимодействуете по этим вопросам с Microsoft. Вот эта их история про опенсорс, через который вы всё это делаете — GitHub, пуллреквесты — это реально работает? В разрезе .NET-вещей — это больше формальность или работающая схема?
— Это абсолютно работающая схема. Microsoft сейчас — топовый контрибьютор на GitHub. Очень много обсуждений идёт со стороны сообщества. То есть люди, особенно хорошо понимающие в дотнете, которые понимают, что в нём было не так, хотят как-то на это повлиять. Сейчас любой может создать issue на GitHub, это будет рассмотрено точно так же, как issue от сотрудника Microsoft, будет вестись…
— Или не будет.
— Или не будет! Но так же, как и для любого другого сотрудника Microsoft. И реально эти issue закрывают. Также ты можешь сделать пуллреквест, если он хороший, не нарушает никакие гайды, не несёт в себе никаких проблем и ты его покрыл тестами, его вполне могут принять.
Есть ещё такая интересная история. Новый ASP.NET-сервер Kestrel сейчас в топ-10 линуксовских веб-серверов по скорости. Его разогнали по перфомансу очень сильно. Есть популярный бенчмарк, который гоняется для всех серверов…
— Для всех для .NET-серверов или серверов вообще — типа nginx, Apache?
— По всем — 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.
— Да, причём у них теперь партнёрство с Red Hat. Red Hat теперь тоже продвигает, что .NET — это правильный путь писать под Red Hat…
— То есть можем ли мы говорить, что схема такая: 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, к разработке под мобилки, многие этим занимаются.
— То есть, на твой взгляд, будущее у этого всего может быть?
— Да, «может быть» — самая правильная формулировка. Происходят инвестиции в этот стек технологий, его популярность растёт.
— Быстрее, чем популярность .NET в целом?
— Это очень сложно сравнивать.
— Вы со стороны своих инструментов Xamarin поддерживаете?
— Возможно, ещё не так хорошо, как хотелось бы, но, например, к Rider 1.0 хотим сделать хорошую поддержку, чтобы можно было комфортно девелопить под мобилки.
BenchmarkDotNet
— Мы сейчас уже заговорили про перфоманс, и мы с тобой так и познакомились ещё до твоей работы в JetBrains: ты писал инструмент для перфомансных замеров, микробенчмарков и тому подобного, который сейчас называется BenchmarkDotNet. Что у тебя сейчас с ним происходит?
— Эта библиотека развивается, недавно нас взяли в .NET Foundation, это очень большой шаг для библиотеки, там пока не так много проектов.
— А кто там, кроме BencmarkDotNet?
— Ну, там изначально Roslyn, ColeCLR (с RyuJIT в составе), Entity Framework, и вот недавно Microsoft начал брать проекты со стороны, например, Cake, это альтернативная система сборки для .NET. Есть несколько десятков проектов.
— Это хороший промоушен для вас, или вы пока не видите увеличенного количества скачиваний?
— Резкого роста пока не произошло, но это в любом случае очень хороший шаг для библиотеки: и в плане пиара, и в плане доверия людей. Одно дело — когда это пишет какой-то непонятный Андрей откуда-то, другое дело — когда это проект .NET Foundation.
— А нужны ли вообще людям микробенчмарки? Условно говоря, я понимаю, зачем Шипилёв пишет микробенчмарки в Java: он разработчик платформы, и им с коллегами надо понимать, с какой скоростью в платформе работают те или иные вещи, причём делать это на микроуровне. А вот конечному разработчику приложения это нужно?
— Зависит от того, что за приложение. Мы с тобой уже обсуждали Kestrel, который выстрелил, вот там тот же Бен Адамс BenchmarkDotNet вовсю использует для тюнинга производительности. Для тюнинга того же рантайма — я видел, некоторые ребята использовали, чтобы обкатать некоторые фичи…
— Ты сейчас говоришь про рантайм и сервер, которые внутри Microsoft зародились. Я понимаю, что BenchmarkDotNet — это инструмент, который нужен людям из Microsoft. А остальным?
— Есть ещё люди, которые просто разрабатывают определённые библиотеки, и делают упор на high performance. Хотят, чтобы их библиотеки были самыми быстрыми. Потому что есть ещё 20 библиотек, которые делают то же самое, и им надо чем-то выделиться. Некоторые реально используют BenchmarkDotNet для какой-то перфоманс-работы, некоторые используют, по-моему, просто для пиара, померили и говорят «вот у нас хорошо».
— Ну это беда, потому что намерить с помощью инструмента можно что угодно — это опасно, это можно сделать это в определённых маркетинговых целях, но в реальности такие замеры ничего не скажут.
— Да, абсолютно согласен с тобой, но… Есть ещё одна проблема. В Java-мире уже достаточно давно есть JMH, и большая часть народа знает, что тебе нужен бенчмарк — бери JMH…
— Знаешь, я видел случаи, когда люди берут JMH, строят по нему графики и говорят «A быстрее, чем B». Но в реальности это ересь.
— Да, есть много таких случаев, но, как минимум, у тебя не будет большого количества детских ошибок. Если ты где-то ошибёшься, то уже на дальнейших этапах. За тебя сделают прогрев, за тебя сделают N итераций, посчитают какие-то статистики.
То, что ты используешь какой-то инструмент для бенчмаркинга, не делает твой бенчмарк автоматически правильным. Тебе всё равно нужно многое понимать о том, как работает компьютер, как устроен рантайм. Но ты избежишь простых типичных ошибок, особенно если не разбираешься в бенчмаркинге. Получишь какие-то инструменты для того, чтобы всё это автоматизировать, то есть тебе не надо будет для каждого бенчмарка руками писать прогрев, писать всю эту инфраструктуру, которая это запускает, у тебя уже есть готовая тулза.
— Ты при разработке этого смотришь на JMH?
— Да.
— BenchmarkDotNet получился другим или похожим? И если другим, то в чём ключевое отличие?
— Он получился другим. Во-первых, он изначально другой, потому что в Java и .NET разные проблемы, с которыми надо бороться. В Java их намного больше. Там в разы сложнее бенчмаркать. Потому что Java умеет очень хитро делать деоптимизации, может перекомпилировать методы, и очень сложно сделать прогрев.
— С другой стороны, в Java единый JVM, который отличается от платформы к платформе, но в целом и компилятор более-менее один, и рантайм один, и так далее. В .NET же есть старый CLR, новый CLR, Mono — это разные рантаймы, и наверняка там приходится разные проблемы обходить. Я не специалист по JMH, но у меня ощущение, что он очень сильно заточен под HotSpot, и что использовать его с другими виртуальными машинами будет трудно, если вообще возможно. Как ты решаешь такую задачу, ведь в .NET есть совершенно разные рантаймы?
— В это вкладывается много сил. Одним из главных достоинств моей бенчмаркалки я считаю то, что она позволяет сделать бенчмарк сразу для разных платформ. Навешал три атрибутика, и сразу запустил свой код для Mono, для полного фреймворка и для CoreCLR. Причём можешь больше атрибутиков написать и запускать ещё с разными параметрами, какие-то флажки повыключать-повключать. И всё это посравнивать.
Это очень удобно в том отношении, что если ты хочешь перенести какой-то код с полного фреймворка на Mono и интересуешься, как это скажется на производительности, ты можешь отдельные части аккуратно посравнивать. Это первый момент. Второй — как ты совершенно правильно отметил, люди не понимают в производительности, не понимают, как делать замеры, даже если у них есть хороший инструмент, они всё равно могут легко сделать направильные выводы. И JMH — это больше инструмент для людей, которые понимают, что они делают. Но по факту большая часть людей не понимает. Не потому что они там глупые, а просто потому что они этой темой не занимаются, а бенчмаркинг требует очень много сил и времени.
— В чём преимущество BenchmarkDotNet перед, скажем, профилировщиками от JetBrains?
— Профайлинг и бенчмаркинг — похожие деятельности, многие их путают, но это совершенно разные вещи. Профайлинг — это ты просто снимаешь профиль своего приложения, как оно бежит, один снэпшот. А бенчмарки помогают изучать разные перфомансные эффекты, разбираться, как у тебя система работает в тех или иных условиях, получать довольно высокий уровень точности.
Это не та деятельность, которая нужна всем. Если я вижу, что Rider начал очень медленно работать, я снимаю профиль, вижу, что какая-то новая функция работает десять секунд вместо одной, смотрю, что там не так, исправляю. А когда речь заходит о наносекундах и микросекундах, сравнении рантаймов и конфигураций, уже просто так не получишь с помощью профайлинга нужный уровень точности, и будет очень сложно сравнить разные конфигурации.
— Мне очень нравится в том же JMH, что там, по сути, есть интеграция профилировщиками с разного уровня. Там можно запустить с таким, с сяким, посмотреть стеки по процентам, байткод, процессорные инструкции, это позволяет на всех уровнях увидеть проблему. Есть ли у тебя какие-то такие интеграции?
— Да. Мы сейчас активно пишем плагины к BenchmarkDotNet. В частности, у нас есть диагностики, позволяющие, например, следить за размером выделенной памяти.
— То есть footprint?
— Ну да, сколько памяти на метод ушло. Сейчас мы немного переписали логику, она теперь с очень хорошим уровнем точности показывает memory traffic. Другая диагностика показывает, какие у тебя методы за-JIT-ились, а какие нет. Это направление мы тоже развиваем.
— Кто работает над проектом? Наверное, главный контрибьютор — это ты, я знаю ещё Адама Ситника. Кто ещё?
— Ещё Мэтт Уоррен, хороший девелопер из Великобритании. Он многое в отношении диагностик сделал, много полезных обсуждений с ним было.
— Какие-то известные люди к вам приходили?
— Ну вот начинали это делать ещё с Джоном Скитом. Он изначально ничего не контрибьютил, но с Джоном можно очень хорошо пообщаться, он может подсказать очень хорошие вещи.
— Джон вроде бы к нам в Питер на DotNext собирается?
— Да, совершенно верно. В конце мая будет петербургский DotNext, он там один из спикеров.
— А что вы Сашу Гольдштейна не подключите, например?
— Саша нам тоже контрибьютил что-то.
— Меня удивляет его удивительное спокойствие. И у Саши есть ещё такое свойство — он знает весь стек насквозь до деталей работы в железе. Очень важная часть, когда ты работаешь над бенчмарком — понимать железо. Вот что ты сам в этом отношении чувствуешь о своём понимании?
— Я чувствую, что за последние несколько лет, за которые я написал очень много бенчмарков, я стал понимать железо намного лучше. Железо — это, наверное, такая вещь, которую никто никогда не понимает до конца, но можно бесконечно качаться.
Конечно, никакой Intel не рассказывает же, как у них всё внутри работает, потому что патенты, ноу-хау, конкуренты, AMD, ARM, Samsung— да кто угодно.
— Да. Я иногда вылавливаю хитрые перфомансные эффекты, которые не могу объяснить публичными спецификациями Intel, то есть они иногда внутри делают что-то очень хитрое…
— Ты не пытался им самим вопросы задавать?
— Кому, Intel?
— Ну да, «вот у нас бенчмарк тут странный, вы не могли бы подсказать». Вот ты же работаешь с Microsoft, и для тебя это естественно — работать с большим вендором. Что мешает тебе так же работать с Intel?
— Во-первых, как мы с тобой уже обсудили, Microsoft сейчас стал более открытой опенсорсной компание. Intel в этом плане, скорее всего, намного более консервативный — это раз…
— Есть же люди, которые, скорее всего, со стороны Intel контрибьютят в эти замечательные майкрософтовские проекты. В Java они точно есть, там ребята из Intel приходят и говорят: «У нас новый intrinsic, вот вам патч, который...»
— В .NET, боюсь, это намного менее выраженно.
— Мне кажется, между Intel и Microsoft должны быть хорошие связи.
— Неплохие. Но такого прямо открытого налаженного процесса я не наблюдаю. И я боюсь, то, что меня интересует, составляет коммерческую тайну, и мне просто об этом никто не расскажет.
Компиляция в native и подведение итогов
— Ну ты попробуй, это хорошая история. А есть ещё история в современном .NET, связанная с перфомансом: компиляция в натив. Вот ты что-то меряешь в случае нативной компиляции?
— Пока что нет. Там трудности в непроработанности технологии.
— То есть она просто сырая?
Ну смотри, есть разные виды нативной компиляции. NGen, который испокон веков в дотнете есть — это не очень интеллектуальная вещь, простая тупая ahead of time-компиляция.
— Что она даёт? Она же наверняка даёт не очень хороший перфоманс. Это многопроходный хотя бы компилятор? Я почему задаю этот вопрос: в современной GCC есть сценарии, на которых они делают по 70 проходов. То есть они по internal representation вот так вот много раз бегают.
— NGen в этом плане, конечно, тупее, но там есть, например, такая вещь, как profile-guided optimization: когда ты используешь профиль рабочего приложения, чтобы как-то более правильно заранее расположить.
— То есть, запускаешь своё приложение с некоторым агентом, этот агент запускает некую статистику, потом ты её на входе скармливаешь NGen’у, и он что-то делает?
— Грубо говоря, да, и по идее, это должно хорошо работать, но на практике очень мало людей этим пользуется. Выгода в основном в том, что экономишь на времени JIT-компиляции. То есть людям, которым критично время холодного старта, чтобы большая программа завелась и сразу начала что-то быстро делать, разумно это использовать. Остальным… Ну, какого-то особого профита я не наблюдаю, и никто не заморачивается.
— Но если хорошо скомпилируешь, то нет накладных расходов на компиляторные потоки. JIT-компилятор ведь работает в той же машине. Это footprint, всё это отъедает память, хочется понять, какие перспективы у этого всего.
— Перспективы немножко в других технологиях.
— Хорошо, мы поговорили про NGen, а что сейчас происходит, новая компиляция в натив?
— Есть .NET Native. К сожалению, он пока работает только для универсальных Windows-приложений. Работает, судя по отзывам, хорошо.
Для обычного .NET, консольных приложений, пока нельзя использовать .NET Native, к сожалению. Работа над этим ведётся, есть ещё один проектик, который позволяет обычные .NET-бинарники в native компилировать. Там тоже есть разные подходы, например, есть вариант делать компиляцию через LLVM. Ещё есть вариант с использованием C++ компилятора на бэкенде, то есть мы перегоняем весь наш .NET в C++, и дальше уже компилируем.
— В какой C++?
— Предположительно в майкрософтовский.
— В managed?
— Нет, в обычный. Сложно ещё про эту технологию рассуждать, потому что она не готова, и непонятно, в каком виде она будет в итоге, когда и если она будет готова. Потому что Microsoft в начале начали очень радужно рассказывать, что вот, уже почти всё готово, но потом оказалось, что оно не очень готово, и как-то сейчас они эту тему замяли, тихонько что-то девелопят на гитхабе, но не особо про это рассказывают.
— У меня из нашего разговора сложилось впечатление, что в попытке покрыть всё Microsoft покрывает не ровными областями, а сначала так, потом этак, и одно и то же становится возможно сделать многими способами. И возникает вопрос: я хочу что-то написать — как мне это сделать? Какой рантайм выбрать? Я ставлю Rider, думаю «вот у меня новая крутая IDE, я C#-программист, у меня новый проект». Как мне выбрать правильную технологию для него?
— Прежде всего нужно всё-таки ориентироваться немножко в том, что происходит в новом .NET-мире.
— И это трудно, потому что этого как-то резко стало много. Мне тяжело ориентироваться, и думаю, что человеку, который большинство времени пишет продакшен-код для энтерпрайз-проекта, не сильно легче. И я вижу тут проблему. Прокомментируй, пожалуйста: вот тебе с этим зоопарком как живётся в 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# работают вне зависимости от того, какой у тебя рантайм, какие-нибудь инспекции тоже, им это не важно. Проблема с тем, чтобы сбилдить, запустить, и просто у нас есть там отдельные подсистемы, которые отвечают за сборку под ту или иную версию того или иного рантайма.
Пообщаться с Андреем можно будет уже в ближайшую пятницу в Москве на конференции DotNext, где он сделает доклад о скорости арифметических операций в платформе .NET.
Автор: JUG.ru Group
