«Roslyn — еще очень сырая технология» — интервью с Сергеем Шкредовым, руководителем .NET-направления в JetBrains

    Привет, это снова Без слайдов. Я Алексей Федоров, и на этот раз в гостях у меня побывал Сергей Шкредов, руководитель всего .NET-направления в компании JetBrains.



    С Сергеем мы говорили:
    • о последних релизах ReSharer;
    • о новой схеме подписок и лицензий;
    • про непростые отношения с Microsoft;
    • о рантайме и развитии языка;
    • о том, как поменял ситуацию выход Roslyn;
    • о работе с фидбеком пользователей для улучшения продукта;
    • о планах развития других продуктов .NET стека;
    • о важности внутриотраслевого общения и обмена опытом;
    • про разработку продуктов для С++;
    • немного о ReSharper C++, на который должны подсесть даже разработчики Microsoft;
    • О том, как пользователи почувствуют изменения;
    • Как ReSharper будет развиваться дальше.


    Вот видео



    Под катом — текстовый вариант интервью.



    О новых релизах ReSharer и Update Rate


    —Сергей, у вас недавно был большой релиз, даже два.

    — Да.

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

    — За предыдущий год мы сделали три больших релиза — это ReSharper 9.1, 9.2 и 10.0. И мы на этот год взяли себе такой темп — делать релизы раз в четыре месяца, и в каждом релизе не прятать фичи, выпускать всё как можно раньше. Это лучше соответствует тому, как развивается Visual Studio — там происходят все время какие-то новые события. И с этой точки зрения релиз 10.0 мало чем по количеству фич отличался от релиза 9.2. Единственное, что на этот релиз у нас было строгое ограничение: мы вместе с выпуском всех продуктов меняли систему лицензирования всех наших IDE, поэтому дата релиза была зафиксирована задолго до этого релиза. Собственно, из-за зафиксированной даты релиза получилось два.

    — То есть, это был багфикс?

    — Да, багфикс-релиз, который вышел через две недели после 10.0.

    — Много багов пофиксили?

    — Много, порядка сотни. В основном, конечно, пользователи жаловались на Unit Testing и плохой резолвинг UWP-приложений.

    — Ну сейчас пользователи уже успокоились? Все в порядке?

    — Сейчас уже да. На самом деле следует смотреть не на то, что пишут в Твиттер, а на update rate (процент людей, которые перешли на новую версию), то он в два раза лучше, чем был для ReSharper 9. То есть, за первые три недели существования ReSharper 10 на него проапдейтилось в два раза больше людей, чем год назад.

    — А много вообще по вашим данным людей пользуется старыми версиями?

    —Я думаю, нет. То есть, к моменту релиза следующей версии предпоследней версией пользуется порядка 30%, а 70% людей уже на новой сидят. И готовы перейти на следующую, самую новую, версию.

    —То есть сейчас есть 30% которые пользуются ReSharper 8?

    — Да.

    — Понятно. А вы как-то пытались с ними общаться, понять, почему они не хотят переходить?

    — Я думаю, что это нормальное распределение такой активности разработчиков. И это мало связано с какими-то внутрепродуктовыми причинами.

    О хитрой схеме подписок и лицензий


    — Старая лицензия — она была по времени или она была по версии? Я мог, имея ту лицензию, бесплатно проапгрейдится?

    — Где-то около двух–трех лет назад мы стали продавать подписки, которые позволяли в течении года обновляться на любую версию. Покупаешь, и у тебя в течение года есть все версии, которые мы выпускаем, вне зависимости от того, как мы их называем. Таким образом мы отвязались от версионирования, что есть это позволило нам выпускать более частые релизы, не опасаясь за то, что мы не получим достаточный Upgrade Rate на мажорной версии. Ну и для коммерческих пользователей у нас еще оставались perpetual (бесконечные по сроку действия — прим. автора) лицензии без подписки на обновления. Сейчас такие лицензии уже ушли. Я могу, конечно, прокомментировать новую подписочную схему.

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

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

    Соответственно, когда мы это поняли, мы ввели подписки. Подписки всем хороши, но подписка – это штука, которую ты должен обязательно себе купить. То есть ты покупаешь себе perpetual-лицензию и к ней подписку. Мы к этому не сразу пришли. Мы на самом деле разделили сейчас плату за подписку на год вперед, и плату за perpetual-лицензию.

    Первый наш вариант схемы подписочной был такой: вы покупаете лицензию на год, и через год у вас все отнимают. И мы, конечно, встретили массу негативного фидбэка по этому поводу. Я думаю, это заслуга большая наших маркетологов, наших СЕО, что среди всего этого фидбека мы смогли понять, что именно в этой ситуации волнует пользователей. А пользователей волнует отсутствие гарантий того, что они смогут продолжить пользоваться продуктом.

    Например, были компании, которые явно писали нам, о том, их бюджет утверждает, например, конгресс Соединённых Штатов. И если он не утвердит бюджет на обновление версии, мы просто на следующий год останемся без продукта. Это самая показательная, думаю, история, которая помогла понять, что надо оставить perpetual-лицензию.

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

    — Если не купишь, то что происходит?

    — Тебе придется пользоваться через год той версией, которую ты купил.

    —То есть происходит откат назад, на версию, актуальную в момент покупке?

    —Да. Можно рассматривать это как откат, а можно рассматривать как то, что ты в течение года принимаешь решение о том, что «я хочу новую». И в таком случае платишь через год, когда продляешь подписку.

    — Слушай, эта схема какая-то не простая. Вы ее у кого-то взяли или сами придумали? Работает ли по такому принципу кто-нибудь еще на рынке?

    — Компания Adobe. Но там история проще, конечно. Мы много слушаем пользователей, и из-за этого наши решения иногда становятся иногда сложнее.

    — Окей, ну-то есть довольно уникальная история.

    — Я могу привести еще больше примеров. Два дня назад Microsoft перешел на такую же схему.

    — Интересно.

    — Абсолютно на такую же. Причем на эту тему не было ни единого большого поста в интернете.

    — А как так вышло? Почему в вашем случае были обсуждения?

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

    —То есть можно сказать, что ваш продукт-менеджмент живет фидбеком?

    — Да, в большой степени.

    Про непростые отношения с Microsoft


    — А какие у вас вообще отношения с Microsoft? Сам я — человек из мира Java, а там довольно давно, уже лет десять как, платформа более-менее открытая. Разговаривая с ребятами из JetBrains, я понял, что они в принципе хорошо осознают, что происходит внутри самой Java-платформы и могут в любой момент посмотреть любой сложный код, разобраться, даже что-то где-то попатчить.

    — Там не нужно коммуницировать с вендором.

    — Именно. А у вас, в .NET-мире, как это происходит?

    —То, как мы работаем, как мы планируем наши релизы, сильно поменялось за последние несколько лет. И поменялось из-за того, что поменялось отношение Microsoft к экосистеме, к работе с партнерами, к уровню открытости компании. Три года назад ситуация была такая: были приватные билды Visual Studio, которые выдавались только партнерам — была партнерская программа, по которой мы тесно коммуницировали с Microsoft. Мы имели право сабмитить более приоритетные баги на Visual Studio.

    То есть Microsoft целенаправленно поддерживал избранных производителей расширений для Visual Studio, порядка ста или двухсот компаний, и для этого были всякие приватные программы. Сейчас большинство фидбека, большинство изменений и билдов можно получить абсолютно легально через открытые источники, а большинство команд с которыми мы общаемся, разрабатывают в Open Source. Сейчас всё меньше и меньше Visual Studio становится закрытым продуктом, который требует достукиваться до Microsoft для того, чтобы принести фидбэк, или что-то поменять, или что-то узнать новое.

    —Получается, что многие вещи вы стали делать самостоятельно?

    — Visual Studio Industry Partner (VSIP) Program, можно сказать, перестала быть каким-то большим бенефитом для нас. Мы ездим на мероприятия, где можно пообщаться с командой, и это практически единственная просьба от VSIP Program.

    — А почему они так изменили свой подход, как ты думаешь?

    — Они стали терять разработчиков. Microsoft долго был вендором, который представлял инструменты для разработчиков, которые покрывали все нужды для всех сценариев. С появлением мобильных платформ все изменилось. Инструментария Microsoft стало не хватать, чтобы клиентам Microsoft свои программы писать под Android, под iOS. Это первая причина, которая запустила этот сдвиг.

    Второй, наверное, фактор, который повлиял на открытость, это наверное, Azure. Чтобы затащить как можно больше разработчиков, причем не только .NET, а Java, Python, PHP, Ruby — всех разработчиков в свой Cloud, нужно представлять им инструменты. Есть четкая политика — инструменты для разработчиков Microsoft предоставляет сейчас условно бесплатно. Хотя есть случаи, когда не бесплатно (например, Visual Studio), а есть случаи, когда далеко не бесплатно (например, Visual Studio Enterprise). Хотя 6000 долларов это не 14000 долларов, как она стоила год назад.

    — Год назад и рубль был другой. А вот, допустим, приход в Microsoft нового СЕО год назад повлиял ли на ситуацию?

    — Я думаю, что сильно повлиял, и он в таком смысле продолжил, дал дальше делать инструменты для разработчиков более открытыми. И двигаться в сторону того, что Microsoft – это облачный провайдер и будет укреплять эту свою позицию. Развивать именно экосистему на базе тулов Microsoft, экосистему разработки под все платформы.

    — Была еще очень интересная история, связанная с кросс-платформенностью. Вот есть Mono, который под Linux, и есть что-то в этом месте от Microsoft, которая как-то будет конкурировать. Ничего про это не знаешь?

    — С Mono история такая, что это как раз та самая дырка в стеке технологий Microsoft, про которую я говорил. Так же как дела обстоят: в Microsoft приходит клиент с тремя тысячами лицензий на Visual Studio, говорит: «нам нужно программу под iOS писать. Я сижу на ваших инструментах уже 10 лет, что мне делать?» Обращается к консультанту Microsoft, и тому нужно дать ответ. Поэтому у Microsoft есть бизнес-задача – обеспечить разработку под iOS.

    Соответственно, какие есть варианты? Есть Xamarin, вполне работающая штуковина, есть Apache Cordova, есть нативная компиляция С++ под разные устройства. Вот три инструмента, которые будем развивать, для того, чтобы покрыть этот сценарий. То есть кроссплатформенная разработка — это такое затыкание дырок с помощью внешнего партнера.

    Обычно в Microsoft это так происходит, что сначала они затыкают дырки с помощью внешнего партнера, потом сами выпускают продукт и занимают это место. Но сейчас я не вижу таких тенденций, не вижу, чтобы Microsoft пытался бы перетянуть кроссплатформенную разработку к себе. Пока они на стадии кооперации находятся. Те библиотеки, которые написаны на Mono, подтягивают к себе. Core CLR, виртуальные машины, какие-то элементы фреймворка…

    —То есть это взаимный процесс?

    – Да, это сейчас очень взаимный процесс. Я надеюсь, конечно, что оно унифицируется в какой-то точке.

    —Сейчас у них есть собственная реализация виртуальной машины .NET под Linux. Довольно сырая, так?

    — У нее есть шанс стать нормальным продуктом.

    — Но Microsoft об этом рассказывает как о готовой экосистеме, как будто это готовый продукт, бери и пользуйся. Видимо, это не совсем так?

    — Чтобы пользователей на него перетащить, его нужно так позиционировать. Я не вижу перетекания пользователей с классического ASP.NET на ASP.NET на базе Core .NET. Просто еще не готовы. Я думаю, что это будет происходить, но не сейчас. Сейчас есть проблемы с перетаскиванием своего кода.

    Дело в том, что сейчас есть существенные проблемы на пути к перетаскиванию своего кода под DNX, под .NET Core. Они связаны с отсутствием вышедшей в релиз версии фреймворка, под который ты можешь таргетить свои библиотеки, чтобы они работали и в классическом ASP, и под полный .NET фреймворк, и в Core CLR. Для этого у Microsoft существует много версий .NET: есть Silverlight в браузерах, есть Windows Phone, есть Desktop-приложения, есть «полный» .NET Framework.

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

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

    — Это у них получается, но, видимо, не очень быстро. Да?

    — Очень много дизайн-решений меняется буквально на глазах. Сейчас та версия, которая есть, она не является финальной, Microsoft уже работает над другой версией.



    О рантайме и развитии языка


    — Насколько, по-твоему, .NET — это legacy-технология, насколько это живая технология? Я сейчас объясню свой вопрос. До какого-то момента, может быть, года до 2008-го, было очень мощное развитие языка. Про Runtime я не могу сказать, мне не хватает экспертизы. Мне кажется, Runtime не очень сильно продвигается вперед. А вот язык в то жесамое время очень сильно развивался. C Java — прямо противоположная история, там язык очень долго тупил, а Runtime развивался дикими темпами. Интересно, что, по моему ощущению, в последнее время с C# тоже ничего глобального не происходит. Изменения были раньше более заметны. Как ты считаешь?

    — Совершенно верно. Я думаю, что Runtime отстает от JVM очень сильно. Виртуальная машина в .NET обладает очень плохим сборщиком мусора и очень слабым JIT-компилятором. В итоге получается медленно исполняющийся код, в котором приходится вставлять затычки на затычки, чтобы избежать лишних аллокаций и справиться с теми функциями, которые автоматически не инлайнятся. Код автоматически не оптимизируется на должном уровне. В Java такой проблемы нет.

    — А язык?

    — Был период, когда язык мало развивался — до выпуска C# 6. Он связан с переходом на новый компилятор Roslyn, который задержался на несколько лет. Года на два, по ощущению.

    — То есть, язык не развивался примерно версии с третьей или четвертой?

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

    В итоге заданной цели достигли в режиме компиляции. То есть, когда сейчас С# 6 и C# 5 используешь — Разница в скорости не заметна. По сравнению с остальными этапами сборки компиляция не стала занимать больше времени.

    А вот с точки зрения поддержки в IDE — налицо массивный провал. С точки зрения поддержки C# 6 в Visual Studio 2015 — это полный fail. Мы не можем редактировать проект ReSharper Visual Studio в релизе 2015 без ReSharper. Оно выжирает всю память, виснет и все. Такая ситуация.

    — Да, это довольно интересно. Особенно на первых этапах, когда вы увидели первые билды, наверно, были бурные эмоции. Как вы жили с этим?

    — Волосы дыбом вставали.

    — Да. Понятно, что в какой-то момент вы, видимо, там все мажорные проблемы пофиксили и как-то дальше смогли хотя бы внятно с этим жить?

    — Сейчас мы поддерживаем Visual Studio 2015, грубо говоря, с закрытыми глазами. Мы сами ей не пользуемся. Планируем переезд потихоньку на нее, там в апдейте стало получше. Мы порезали ReSharper так, чтобы можно было кусочками его запускать. Мы создаем меньшие Solution’ы, чтобы можно было начинать всем этим пользоваться.

    — У IntelliJ IDEA, с точки зрения восприятия ее как инструмента, случился колоссальный прогресс в 2007 году, сразу после выхода на рынок процессоров Core 2 Duo. Был очень сильный (по сравнению с Pentium D) performance-рывок. Соответственно, IntelliJ IDEA из положения «IDEA тормозит» перешел в положение «О, IDEA— отличный инструмент. Теперь можно работать!» IDEA стала работать быстрее просто потому, что железо резко стало лучше. Этого хватило. С тех пор люди на производительность IDEA особо не жалуются. Правильно я понимаю, что в .NET стеке производительность IDE— это все еще головная боль?

    — К сожалению, да. Мы находимся в довольно тяжелом положении. У нас примерно половина багов с производительностью вызваны работой Visual Studio, а вторая половина — вызвана нами. Мы очень часто не можем отличить одни от других. Может быть, в ReSharper typing происходит медленно, потому что сейчас в бэкграунде Roslyn анализирует файлы и аллоцирует сотни мегабайт в секунду, отчего просто GC помирает?

    Когда ты находишься «как бы внутри своего кода», Microsoft сделал некоторые оптимизации специальные, которые учитывают то, как typing в IntelliSense взаимодействует с фоновым анализатором кода. Соответственно, когда мы запускаем наши активности по автодополнению и type assist, мы влияния на то, как работает Roslyn background thread, не имеем.

    — Они намеренно так сделали?

    — Я думаю, что они решали свою проблему. Конечно же, о нас они не думали. Это естественно.

    О том, как поменял ситуацию выход Roslyn


    — А насколько выход Roslyn изменил положение дел? Это для вас головная боль?

    — Нам стало полегче. Дело в том, что мы лучше стали понимать разные виды проектов, в которых Roslyn используется как Language-сервис. Мы оттуда вытаскиваем модель компиляции, файлы, референсы, идущие в компиляцию. В предыдущих версиях Visual Studio, когда не было Roslyn, это был довольно трудоемкий момент, связанный с вызовом билда, вытаскиванием референсов из Visual Studio напрямую. Это было сложно и с багами. Сейчас это гораздо более прямой процесс. Мы используем Roslyn для того, чтобы создать модули и то, как они будут взаимодействовать с компилятором.

    — А как Visual Studio взаимодействует с компилятором? Студия использует для построения собственной модели кода сам компилятор?

    — Visual Studio — да. In process загружает Roslyn.

    — А в старом случае?

    — В старом случае было тоже самое, только в нативном коде на С++. Можно было только догадываться, что он делает и где. Но он не влиял на Garbage Collector никак, мы его не видели никогда в профайлерах. Он, может быть, там был, но он был очень быстрый.

    — Связано ли это с тем, что Roslyn — это еще сырая технология? Или связано с тем, что она как-то в корне неправильно спроектирована?

    — Да, конечно. Очень сырая. В плане оптимизации конструктора данных, который используется в Roslyn для простейшей функциональности Rename или при нахождения ошибок во всем Solution’е — это прямые алгоритмы, которые тупо работают. Но, понятное дело, влияют на производительность в конце концов.

    — То есть, в принципе, шанс того, что разработчики Microsoft ускорят Roslyn, есть?

    — Шанс есть, конечно. Но может возникнуть проблема с компанией Microsoft, где такая необходимость может быть не осознана на должном уровне. И не будут выделятся время, и деньги на это.

    — Понятно. А тот Open Source, который сейчас происходит, он Open Source только с точки зрения «я могу посмотреть» или «я могу законтрибьютить»?

    — Контрибьюшенов я видел очень мало. Сейчас, в основном Core CLR, это все такой показанный исходный код, который ты можешь скомпилировать или просто посмотреть, почитать. Я не слышал, чтоб их массово кто-то принимал.

    — То есть, в принципе шансов, что вы придете и поможете им, пофиксите им все проблемы с перформансом, тоже не очень много, судя по всему?

    — Эти проблемы с перформансом часто лежат в области компиляции студии именно с Roslyn. Шанс на то, что мы придем и будем в Roslyn что-то изменять есть, конечно. Мы смотрим, анализируем, что и как происходит. Мы имеем представление об архитектуре, об архитектурных проблемах.

    Как ReSharper будет развиваться дальше


    — Значит, Roslyn строит свою собственную модель, свое собственное дерево, да? Это, видимо, что-то типа Concrete Syntax Tree.

    — Да. Очень специфичное, с пробелами, с комментариями… Конкретный синтаксис, так, как он написан в редакторе. То, что в IDE используется — это очень конкретное синтаксическое дерево, ни в коем случае не AST.

    — Вы строите модель кода. У вас это свое дерево?

    — Да.

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

    — У нас сейчас есть несколько направлений. Первое — это не использовать Visual Studio. Второе — это использовать Visual Studio, но запускать ReSharper отдельным процессом. У нас есть видение, есть дизайн, решение, когда все ReSharper’овские модели кода, все синтаксические деревья, индексы, кэши и все, что касается семантической модели, хранится в отдельном процессе.

    — Мы с Кириллом Скрыганом это обсуждали, когда он рассказывал, что ReSharper сильно упирается в ограничение по памяти 32-битной Visual Studio. Я ему сказал, что очевидно тогда делать ReSharper out-of-process, на что он ответил, что да, надо, но это чревато Memory Traffic’ом.

    — Собственно, дизайн-решение заключается в том, чтобы минимизировать этот Memory-Traffic. Работает это примерно так: мы можем воспринимать студию как UI-приложение. То есть, сделать MVVM. Можно рассматривать, что бэкэнд ReSharper’а — это такая ViewModel для студии, которая является View. Если рассматривать трафик между ними, то это будет трафик тех данных, которые достаточны для того, чтобы отобразить изменения в UI. Ты никогда не найдешь массированную пересылку данных на уровня UI. Всегда надо применять два символа, две подсветочки…

    Это все живет на стороне студии, на стороне UI. Данных, которые нужно пересылать для того, чтобы отобразить UI, мало. Тысячи объектов переслать — это мгновенно. Переслать изменения в документе при тайпинге — тоже мгновенно. На этой идее можно так построить код, чтобы синхронизировалось только те данные, которых достаточно для отображения UI.

    — Насколько Visual Studio хорошо спроектирована, насколько она позволит вам это сделать?

    — Это исключительно вопрос нашего кода, то есть интеграция наша со студией никак не поменяется.

    — Ты очень красиво все описал. А в реальности это заработает? Visual Studio позволит вам всю работу с UI куда-то вытащить?

    — Этот вопрос написания наших элементов UI. Давайте приведем пример. Вот, например, показывается «бульбочка». Для того, чтобы показать ее, сейчас используется PSI, синтаксические деревья, документы, вся проектная модель. Если мы оставим то, что есть и будем пересылать эти синтаксические деревья целиком – то это, конечно, никуда не взлетит. Но вообще, чтобы нарисовать «бульбочку», нам нужны иконка, текст и все.

    Когда мы нажали Alt + Enter, мы передали item в виде текста и иконы, когда мы нажали «применить какую-то бульбочку», мы на бекэнд, который работает out-of-process, отослали на исполнение одну команду. Все изменения данных в синтаксических деревьях и документах – они все произошли Out-of-process. Теперь на фронтенд в качестве результата нужно вернуть новое положение курсора и поменять те документы, которые были открыты в редакторах. И всё.

    — Задача сводится к тому, чтобы разработать протокол обмена данными между ReSharper’ом и тем, что видит пользователь на UI, причем минимальный по трафику.

    — У нас есть наработки по протоколу. Протокол очень интересный, реактивный. Мы синхронизируем одинаковую структуру данных, которая будет работать с обеих сторон. Это большое изменение — нужно изменить весь исходный код ReSharper’а.

    Это изменение заключается в том, что ViewModel надо переписать так, чтобы они не держали в себе ссылки на сематические модели кода. Это огромное изменение, поэтому придется делать его постепенно. Мы потихоньку начнем делать так, чтобы наш продукт работал и так и так. И будем архитектуру приводить к тому, что UI не будет зависеть от семантической модели. И это опять инверсия зависимости.

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

    — В конце концов, это должен быть тот же самый User Experience.

    — Пользователь не должен ощущать, что бэкенд другой у всей этой истории?

    — Конечно. В какой-то момент мы подменим старый новым. И всё.

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

    — Конечно. В ReSharper сейчас кода, который непосредственно парсит, резолвит что-то —порядка 10%.

    — Насколько имеет смысл вообще заниматься всей возней c Visual Studio, учитывая, что у вас в компании офигенный опыт и очень успешный спрос по построению собственных IDE?

    — Visual Studio, конечно, имеет смысл, с нее мы никуда не слезем. Это инструмент, который обеспечивает разработку на всех платформах, которые нужны для Microsoft. Он меняется раз в три месяца и поддерживает новые платформы от Microsoft. Повторять эту работу — вовсе не наш приоритет.

    В первую очередь нужно понимать, что Visual Studio решает внутренние задачи Microsoft. Вот, например, вышла Universal Windows Platform, а под нее нужно все программы дебажить, запускать, профилировать, настраивать проекты, которые будут работать под разные платформы… Это мы повторять не будем.



    Немного о ReSharper C++, на который должны подсесть даже разработчики Microsoft


    — Пользуются ли разработчики Microsoft, которые все это делают, ReSharper?

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

    — Значит, разработчики Microsoft заинтересованы в том, чтобы ReSharper работал и развивался. Наверное, это очень большое подспорье — если вы их подсадили на ваш инструмент.

    — А сейчас хотим подсадить их на ReSharper C++ — это наша большая цель.

    — А расскажи, пожалуйста, об этом проекте.

    — Начали мы писать ReSharper С++ года 3-4 назад. Зарелизили весной. Мы его продаем как отдельный продукт, такой фигурно выпиленный язык C++ без всего остального. Из тех, кто пользуется ReSharper C++ — примерно 2/3 пользуются им без ReSharper, а треть ставит себе ReSharper C++ в составе ReSharper Ultimate.

    — Насколько вообще люди, которые пишут на C++ под Windows, пользуются именно Visual Studio?

    — Я думаю, очень много людей пользуются Visual Studio для разработки на С++ в абсолютно разных сценариях.

    — Это именно Managed С++ или любой?

    — Managed С++ — это абсолютно тупиковая ветвь развития технологий Microsoft, которая была призвана упростить интеграцию Managed кода с не-Managed кодом.

    — А,-то есть нужно было как-то С++, что бывают там какие-то

    — Просто сделать маршаллинг, сделать взаимодействие проще. Когда у тебя есть header, описанный для С++, ты его можешь прямо использовать в Managed С++ проекте — это удобно. Я вижу, что сейчас большинство людей которым нужен interop, используют либо COM, либо Implicit PInvoke. Наш опыт использования Managed C++ скорее негативный — в компиляторе баги и пр.

    Возвращаясь к твоему вопросу, люди используют Visual Studio не для Managed C++, а для нативного С++ — это разработка под различные устройства, картографические приложения, игры и т.д. — в общем, для всего, что на C++ пишется.

    — Можно сказать, что для программирования на C++ под Windows Visual Studio — это основной инструмент разработки?

    — Конечно. Да и не только под Windows. Люди, которые программируют под Linux, тоже очень часто сидят в Visual Studio — и это нормально. Просто это хороший редактор.

    Про разработку других продуктов для С++


    — У меня есть вопрос, связанный с разработкой других ваших продуктов для С++, в частности CLion — от ведь тоже поддерживает С/C++. А есть еще AppCode для Objective-C. Как ReSharper живет параллельно с этими IDE? Есть ли что-то общее в этих продуктах? Обмениваетесь ли вы опытом с разработчиками этих IDE?

    — Мы ориентируемся на две вещи. Во-первых, на стандарт языка C++, а во-вторых — на компилятор Microsoft. У CLion и AppCode приоритеты немного другие. Опытом c ними мы обмениваемся. Есть довольно много дизайн-решений, которые плавно перетекают в CLion из ReSharper. Когда начинали писать ReSharper C++ — уже был опыт написания ReSharper C++ в CLion.
    Вообще, С++ в AppCode начался абсолютно фееричным образом. Там был Objective C, и в какой-то момент мы поняли, что там есть header-файлы, которые используются и для Objective C и для С++. То есть там где-то под define'ами написаны большие конструкции на С++, на которых парсер ломался, просто потому, что их не понимал. И тогда пришлось как-то поддерживать С++ для того, чтобы поддерживать Objective C. И с этого началась поддержка С++ в AppCode.

    Разрабочики CLion и разрабочики AppCode между собой общаются, обмениваются опытом?

    — Они, конечно, общаются между собой.

    — У трех ваших инструментов много общего кода?

    — Его вообще нет. ReSharper С++ был написан сильно позже, и его писал человек, который до этого делал поддержку С++ в AppCode. И поэтому изначально ReSharper С++ дизайнился лучше, то есть архитектурно он правильней.

    — А это «правильней» выражается в чем? В том, что меньше костылей приходится вставлять для того, чтобы все работало?

    — Да. В конце концов, просто меньше ошибок кодов и багов в поддержке IDE.

    — А насколько на самом деле компилятор Microsoft поддерживает стандарт языка C++?

    — Уже лучше и постоянно улучшают.

    — Реальность такова, что реализация не всегда соответствует стандарту.

    — С этой точки зрения С# ничем не отличается от языка, который в реализации часто не соответствует стандарту. Сейчас, с открытием исходного кода, стало, конечно, гораздо проще. Когда что-нибудь ведет себя не так, как написано в спецификации — мы смотрим код, как оно написано в компиляторе, и вcё.

    — А для вас, что важнее — соответствие спецификации или реализации?

    — Смотрим каждый раз на Use Case. В тех местах, где спецификация не соответствует реализации, скорее всего, если мы покажем ошибку там, где ее нет, пользователь ее поправит, просто перепишет код как-нибудь по-другому, это будет совершенно нормально. Т.е. это будет действительно какой-то сложный случай.

    — А как вообще появился сам ReSharper в JetBrains?

    — Он появился еще до меня: я в ReSharper только в 2007 году пришел уже на 3 версию или на 4-ую. ReSharper появился тогда, когда появился Eclipse. То есть, компании потребовалось диверсификация деятельности, поскольку возникла серьезная угроза основному продукту: все-таки бесплатные платформы, бесплатные IDE для Java – это серьезный конкурент.

    — То есть, это было бизнес-решение?

    — Думаю, что да.

    — А сейчас вы с коллегами по JetBrains чувствуете, что выиграли войну у Eclipse?

    — Да, чувствуем.

    О важности внутриотраслевого общения и обмена опытом


    — А что насчет ReSharper? Есть разные люди, в том числе, в России, которые делают инструменты для разработки на C#: например, ребята из DevExpress делают CodeRush, который с Roslyn работает. Вы с ними общаетесь, обмениваетесь опытом или нет?

    — Я думаю, что DevExpress как-то подзабил на разработку инструментов, разочаровался. CodeRush — это больше сайд-проект: уже в конце 2000-х стало уже понятно, что ReSharper доминирует.

    — Вопрос в том, как они у себя решают указанные тобой ранее проблемы. Вы общаетесь с ними? Не общаетесь?

    — Они переезжают на Roslyn и пишут те фичи, которые не были написаны на Roslyn. Архитектурно, мне кажется, это невозможно. Написать функциональность ReSharper поверх Roslyn нельзя, не изменяя Roslyn. У нас слишком много структур данных внутренних компиляторных, которые используются для реализации фич анализа. Фича не пишется поверх какой-то код модели, которая зафиксирована. В процессе работы программиста в Visual Studio код модели постоянно немного меняется, меняются индексы, меняется то, что мы храним, то как мы храним. Чтобы корректно производить рефакторинги, мы используем компиляторную инфраструктуру, которая у нас написана. Те проверки, которые мы делаем для проверки ошибок компиляции, мы используем потом в том, чтобы написать предложение о том, что, например, «этот тип может быть заменен на var». И это всюду.

    —А теперь у вас есть Roslyn. И вроде как вам нужно жить параллельно.

    — Да, мы живем.

    — Вы вообще не планируете его использовать?

    — Нет.

    —На данном этапе вы выиграли войну. И вы доминируете. Но сейчас с выходом Roslyn у остальных появляется шанс.

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

    — У вас и так сложные продукты, а сейчас они будут еще сложнее.

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

    Компилятор работает просто. И это у нас хорошо написано, хорошо поддержано. Сейчас проблема в платформах. И проблемы с производительностью. Их мы собираемся решать вот таким ультимативным способом – выйти из процесса Visual Studio.



    О планах развития других продуктов .NET-стека


    — Кроме ReSharper, про которые мы поговорили, у вас в .NET-стеке есть и другие продукты. Что происходит сейчас с ними и что вы планируете с ними делать?

    — История началась давно, когда мы написали профилировщик dotTrace. Первую версию профилировщик dotTrace написал Миша Сеньков, который пишет сейчас ReSharper С++. В какой-то момент мы решили форкнуть нашу кодовую базу. В ReSharper’е было много кода, в котором написаны UI, коллекции, примитивы, Application-модели и т.п. Для выпуска продукта dotTrace мы форкнули платформу, и с этого момента у нас происходили несинхронизированные релизы на базе одной и той же платформы разных продуктов: dotTrace и ReSharper.

    — То есть, внутри вашей кодовой базы была сущность, которая называется «платформа», и с ней оперировали оба этих продукта?

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

    Если в предыдущих версиях интеграция dotTrace состояла из двух частей: из плагина к ReSharper и отдельного Extension’a для Visual Studio, потому что для того, чтобы интегрироваться с Visual Studio, нужно интегрировать менюшки, сделать манифест, package – все атрибуты Visual Studio экстеншена. В новой схеме мы сделали один продукт, который целиком интегрируется в Visual Studio, но собирается по частям. ReSharper — наверное, единственный Extension, который так делает в Visual Studio. Наш инсталлятор позволяет выбрать несколько продуктов и собирает Extension на лету. То есть, все атрибуты экстеншена у нас генерируются и компилируются. Прямо в инсталляторе написан код, который в Runtime интегрирует несколько продуктов в студию side-by-side.

    Мы сделали кнопки, позволяющие включать и выключать каждый продукт. Если рассматривать архитектуру этого решения в принципе, то разные программы, например, ReSharper, Command Line Inspect Code Tool (это утилита для запуска анализа кода на билд-сервере), dotPeek, dotTrace, dotCover, dotMemory, — они запускаются все одинаковым кодом в абсолютно одинаковых условиях, просто с разными параметрами. То есть это фактически одна программа, которая запускается с разными параметрами, и эти программы можно запускать на всех наших сборках.

    Когда-то на DotNext я делал доклад про то, как устроена Application-модель, основанная на зонах, которая позволяет все это делать. Собственно, все стало проще. Релизы стали проще. Программы стали все интегрированными теперь. Пользователи теперь не спрашивают: «Какой dotCover совместим с вот этой вот версией ReSharper?» Все это нам позволило выпустить ReSharper C++ как отдельный продукт, который может работать и вместе с ReSharper, и ReSharper без него может работать, и вместе они тоже могут работать.

    — Насколько ваша новая модель уже сидит в головах у пользователей?

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

    — Здесь хороший потенциал для всяких там кросс-продаж.

    — Кросс-продажи привели к тому, что мы продажи профайлеров прекратили совсем, и их просто не купить как отдельные продукты. Потому, что это больше приводит к проблемам, чем к пользе. Проблема заключается в том, что у меня есть лицензия на ReSharper, отдельно на dotTrace, я хочу поставить новую версию продукта, а версии синхронизированы. И вот эти лицензии на отдельные версии не работали совсем. Они могут быть несовместимы, могут отличаться, могут кончаться – одна позже, другая раньше… Чтобы избавиться от этих всех проблем, просто сделав более дорогую версию.

    О работе с фидбеком пользователей для улучшения продукта


    — Мы с тобой постоянно говорим про Performance. Специфика ReSharper’а такова, что в приложении много разной функциональности, и каждый пользователь использует свое собственное ее подмножество. А большинство людей, которые пишут на .NETe, они пишут программы с вполне обозримой кодовой базой, где есть фиксированный workload, где по циклу выполняются одни и те же операции, где действительно можно снять какой-то профиль и посмотреть горячие методы. У вас это как-то совершенно не так. Как вы с этим живете? Как вы все это держите в голове?

    — Есть несколько вещей. У нас есть такая кнопка – Profile Visual Studio. Ты, как пользователь, можешь записать кусок времени, когда ReSharper тормозил, отослать это нам и мы, скорее всего, что-то с этим сделаем. Это механизм, который работает. С его помощью мы, версия за версией, исправляем баги. А дальше… дальше сложно.

    Как программист походит к оптимизации, желательно обозримой? Find Usage, анализ файла, навигация, может, в каких-то сложных местах. И смотрит, сколько времени потратилось на эту операцию. Find Usage сейчас у нас занимает 10 секунд, а должен занимать семь. Но в процессе изменений мы делам кэши, меняем структуруыданных, которые тоже нужны. И можно легко потерять производительность в каком-нибудь другом сценарии, например, в код Code Completion, а еще хуже в какой-нибудь синхронной части его части, который работает у тебя в Foreground и напрямую влияет на время отклика при печати.

    Соответственно, сделав какую-то оптимизацию или запустив какую-то активность в бэкграунде, которая плодит много объектов, или заняв статическую память, ты, как программист ReSharper, можешь задеть самую чувствительную часть, к которой пользователи наиболее трепетно относятся – typing, переключение между редакторами, движение каретки — то, что должно работать вообще без каких-либо задержек.

    — Как это вообще можно тестировать?

    — Это практически не поддается регрессионному тестированию. Одним из важнейших критериев корректности любого теста на производительность является повторяемость результата. Это работает, если у тебя стабильная виртуальная машина на сервере, на котором нет другой нагрузки. А когда у тебя typing тормозит на каждый 10-й символ, а девять проходят — это довольно тяжело уловить.

    — Непонятно, как сформулировать метрику, в которой это можно увидеть.

    — И не всегда просто фиксится, когда влияние одного кода на другой происходит. И если ты занимаешься Code Completion’ом, а он тормозит из-за того, что окошко юнит-тестинга, например, сейчас работает юнитест, который в бэкграунде отображает свой output. Вполне реальный сценарий.

    — Правда ли, что это лечится иными подходами к самой разработке, как примерно Дима Иванов рассказывал? И второе — правда ли, что в этом месте единственное, что работает – это пользовательский фидбек?

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

    — Много таких скриншотов?

    — Несколько в день. Часто бывает, что тормозит не ReSharper, а какой-нибудь экстеншн к ReSharper’у, экстеншен к Visual Studio или сама Visual Studio. Ну или что-нибудь, что вообще не поддается никакому анализу.

    — Вы в этом случае идет в Microsoft или к тому, кто делал этот экстеншн для ReSharper?

    — В Microsoft очень тяжело достучаться, и мы не тратим время на это. Если ты хочешь чтобы Microsoft что-то пофиксил, тебе нужно быть очень активным. Грубо говоря, взять свой компьютер и отослать в Microsoft, чтобы они его проанализировали. А когда к нам приходит фидбэк, со сценарием, который мы даже толком не можем воспроизвести, никто из Microsoft смотреть его не будет. Потому что у них своего фидбека хватает.




    Другие выпуски «Без слайдов» вы можете найти на нашем Youtube-канале, а расшифровки — на хабре, просто поискав в нашем блоге или по соответствующей метке.
    Метки:
    JUG.ru Group 739,18
    Конференции для взрослых. Java, .NET, JS и др. 18+
    Поделиться публикацией
    Комментарии 69
    • +7
      У нас нет проблем с производительностью.
      Ну-ну
      • +20
        Ай-яй-яй. Вырвали из контекста фразу:
        —У нас нет проблем с производительностью. У нас нет сомнений в том, что мы сможем в том же темпе писать новые анализы или еще более умные completion’ы и еще более умные рефакторинги.
        Тут не было речи о производительности их инструмента. Был лишь ответ о производительности их работы.

        Про производительность их продукта был другой, вполне честный, ответ:
        — К сожалению, да. Мы находимся в довольно тяжелом положении. У нас примерно половина багов с производительностью вызваны работой Visual Studio, а вторая половина — вызвана нами…
        • –8
          Ну вот спорно. Там обсуждается конкуренция рослина и решарпера, и я понял фразу как аргумент «за» решарпер и «против» рослина (то есть, весь посыл статьи, фактически) — «у нашего продукта, в отличии от другого продукта, нет проблем с производительностью, и мы готовы развивать наш продукт дальше».
          • +6
            В этом ответе действительно имеется в виду производительность разработки.
            • +1
              Ок, спасибо. Добро пожаловать на хабр.
      • +4
        >Managed С++ — это абсолютно тупиковая ветвь развития технологий Microsoft, которая была призвана упростить интеграцию Managed кода с не-Managed кодом.
        он сам в это верит?

        >Я вижу, что сейчас большинство людей которым нужен interop, используют либо COM, либо Implicit PInvoke
        com еще жив?
        Implicit PInvoke если нужно вызвать метод или два, в случае если методов штук 10 — 20 в классах, гораздо удобней в C++/CLI обернуть и потом вызывать из c# как родного

        > Совершенно верно. Я думаю, что Runtime отстает от JVM очень сильно. Виртуальная машина в .NET обладает очень плохим сборщиком мусора и очень слабым JIT-компилятором. В итоге получается медленно исполняющийся код.

        студия 2013 или 2015 работают гораздо шутрее чем идея (24гига озу, ssd, corei5 2500k разогнан до 4.3), net работает быстрее как на десктопе (wpf) так и на серваке asp.net mvc.

        давненько пробовал ReSharper, студия тоже начинает тормозить… наверное да виноват gc в net )

        вообщем ни о чем
        • +2
          > студия 2013 или 2015 работают гораздо шутрее чем идея (24гига озу, ssd, corei5 2500k разогнан до 4.3), net работает быстрее как на десктопе (wpf) так и на серваке asp.net mvc.

          Вот это высказывание «ни о чём», как Вы выразились. Сможете доказать?
          • 0
            ни о чем возможно слишком абстрактно, ощущения юзера при использовании без спец тестов.
            в идее больше функционала сразу это да.
            зависит от окружения задачи и тд… что тут доказывать
            • +5
              Ну тогда я, как юзер, с Вами не соглашусь. Сейчас я, в основном, использую VS, но когда нужно что-то написать на Java, использую IDEA, и это как глоток свежего воздуха — всё буквально летает. Ваше субъективное восприятие против моего — это я и называю «ни о чём». Нужны объективные тесты производительности.
              Про VS + R# — да, есть проблемы, о которых разработчики в JetBrains не скрывают. Но этому есть объективные причины, о которых и говорится в данном интервью. Roslyn построен на immutable-структурах данных, которые дают огромный memory footprint, с которым GC не справляется. В проекте, над которым я сейчас работаю (UI, WPF), stop-the-world GC, порой, работает больше, чем 4 секунды, из-за чего сервер теряет хартбиты, а трейдеры — ордера на сотни тысяч долларов. Из-за этого мы тратим огромное количество времени на оптимизацию расхода памяти. В Java я ни разу не видел FullGC больше секунды.
              • 0
                Если так сложно, зачем на .NET?
                • +5
                  На сегодняшний день WPF — де-факто наиболее популярная технология для UI в свере банкинга. Я не могу сказать, хорошо это или плохо, но так оно есть, и не мне менять правила. А что бы Вы предложили взамен?
                  • 0
                    Хорошо что WPF популярен. Другое я не могу посоветовать, не проектировщик, но нагуглил что UI для трейдеров пишут на чем душе угодно.

                    Наверняка уже собрали или в ближайшем будущем соберете все лучшие техники оптимизации в одном месте.
                    Интересно почитать о том как Вы справились с этими проблемами на практике.
                    • +2
                      Если с самого начала при построении архитектуры грамотно продумать менеджмент памяти, таких проблем не возникает. Но проект старый, и в нём есть множество наслоений функционала, поэтому и возникают подобные проблемы с GC. Универсального решения, увы, нет. Надо профилировать и находить узкие места.

                      В моём конкретном случае зависание приложения больше чем на 2 секунды было критичным. Мы потратили уйму времени на профилирование и оптимизации, но в результате пришли к выводу, что проще искусственно ограничить возможности системы. Трейдеры хотят видеть на мониторе (вернее, на 5-10 мониторах) по 50 окон, в каждом из которых будет открыто по несколько сотен инструментов с данными, обновляющимися по 10 раз в секунду. Это, если и реализуемо, то на чистом Ассемблере.

                      Про будущее: как это ни странно, видел пару экспериментальных проектов, написанных под Awesomium (поделка, выросшая из Chromium), где за доступ к данным отвечает C#-код, а за отображение — чистый JS). Не знаю, может быть, и правда будущее за этим.
                      • 0
                        Не думаю, что перегонка данных между двумя виртуальными машинами есть добро. Если уж и рассматривать аппаратно-ускоренный гуй, то, имхо, QML сейчас один из самых шустрых. Шустрота, правда, заработана ценой скудного функционала и «мы прибили гвоздями все, что можно».
                    • +4
                      Вот эти две фразы выносят мой мозг:
                      WPF — де-факто наиболее популярная технология для UI в свере банкинга.

                      … stop-the-world GC, порой, работает больше, чем 4 секунды, из-за чего сервер теряет хартбиты, а трейдеры — ордера на сотни тысяч долларов

                      Вы там что, торгуете прямо из WPF? Остается надеяться что не из code behind, хотя бы. Сергей вот говорит, что они уже для решарпера начинают строить по сути view server, а вы смешиваете WPF и ордера.

                      Если без стеба: никто не торгует из клиента. Ну вот вообще никто. Работаю в инвест-банкинге несколько лет. Строил несколько торговых систем, у всех С# на клиенте и все что угодно, но не C#, на сервере. Клиент всегда супер-тонкий только для показа информации и ввода команд для сервера. Сервер на С++ или Java. Видел даже экзотику на Erlang. Но не C#… Так что WPF UI вообще не обязывает.

                      Прямо сейчас участвую в розработке системы алготрейдинга (эта даже не HFT) для одного крупного банка. На сервере Java. И даже с ней мы используем особую zero-GC VM. Это как раз чтобы не терять миллионы на аукционах закрытия бирж. Как бы намекает, что даже в Java не все в порядке с мусором…
                      • +2
                        Так и есть, конечно. Клиент — на C#, сервер — на Java с подтюненым GC. Клиент раз в секунду отправляет хартбиты, и при потере хотя бы двух хартбитов сервер отменяет все ордера — это специальная защита от зависших на рынке «ничейных» ордеров. Так вот, когда трейдер открывает тысячи инструментов, по каждому из которых тикает маркет-дата, нагрузка на UI такая, что GC иногда не справляется. Ещё раз уточню: да, наверно проблема в неправильной архитектуре и чрезмерном количестве аллокаций. Но то, что GC в .NET-е может стопить весь процесс на 4 секунды, — это неприятно.

                        Вот эти две фразы выносят мой мозг:
                        WPF — де-факто наиболее популярная технология для UI в свере банкинга.

                        Ну вот, Вы сами ниже подтверждаете, что
                        у всех С# на клиенте
                        • +6
                          Ну вот понимаете, это их негласное соревнование: где GC лучше в JVM или в CLR, это вообще не для нашей области. Это они больше говорят о том, где им удобнее «засирать» память мусором, в Java (когда они пишут идею) или в .Net (когда они пишут R#). Понимаете, GC — это такая приблуда для некритичных приложений. Ну тормознули раз в час на 5 секунд в студии/идее, это вообще неважно на фоне того, сколько их тулы экономят времени качественным автоматическим рефакторингом.

                          В нашей же с вами области, оба GC плохи и их необходимо избегать по-любому. Быстрый GC, медленный GC — притормаживание системы в критичный момент может привести к огромным потерям. Тут все подходы решения известны: 1. profiling, 2. pooling 3. повторить. Какая нибудь сервисная архитектура с чистыми DTO внутри системы сильно помогла бы в этом.

                          В вашем конкретном случае. Ох как это знакомо!
                          Во-первых, вроде были исследования показывающие, что трейдеры не способны реагировать на обновления данных бестрее, чем за 2 секунды. Т.е. UI обновлять чаще, чем раз в две секунды — смысла нет. На сервере надо объединять (conflate) сообщения и посылать на клиент только раз в две секунды. Heartbeat ежесекундный, соответственно, тоже не нужен — хотя бы 2 секунды.
                          Во-вторых, избавьтесь от GC на клиенте. Вообще избавьтесь. Кстати, тут в С# есть плюсы. Custom Value Types, которые аллоцируются на стеке. В Java DateTime, Price — это постоянный гемор по работе и с ними. Кроме того, иногда даже транспортные объекты удается тоже затолкать через стек и тогда каждые 2 секунды не будет образовываться мусор. Но тут, конечно, все зависит от архитектуры приложения. Но pooling для наиболее часто выделяемых объектов возможен почти всегда. Могу сразу сказать, что ваши объекты вывести из под GC значительно проще, чем отпинать WPF так, чтобы он перестал создавать UI объекты килотоннами. Вобщем, работать надо, работать :)

                          Вместо итога: в искусственном соревновании для некритичных приложений JVM GC работает лучше, чем CLR GC. Нормальные пацаны избегают GC в любом случае, даже если он белый и пушистый…
                          • +1
                            Custom Value Types, которые аллоцируются на стеке.


                            Если в поле класса есть тип значения, он будет размещен в динамической памяти или на стеке? Если на стеке, и таких объектов у меня 1000, как оно работает?

                            The Truth About Value Types, By Eric Lippert
                            Перевод где то был уже на хабре.

                            Я не имею ввиду что это не правда, просто это не вся правда. Вам я полагаю это хорошо известно, но решили не уточнять в своем сообщении такие детали.
                            • +2
                              Если в поле класса есть тип значения, он будет размещен в динамической памяти или на стеке? Если на стеке, и таких объектов у меня 1000, как оно работает?

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

                              Вот если подытожить статью Липперта в одной фразе, то я бы сказал: «не думайте о том, где расположен объект: в куче или на стеке». Этот подход, такой академический, просто очень далек от реальности. Обычно к этому еще добавляют: «сборщик мусора решает все проблемы с управлением памятью». Нам этот подход продают уже лет 20. Не получается не думать о том, сколько порождается объектов и где они живут. Сама философия: «давайте забьем на управление памятью и будем полагаться на GC — его крутые программисты писали» не работает. Есть много причин задуматься. Всяческие disruptor pattern (в С++ его используют десятилетиями и не придумаывают ему модного имени), java trove, zero gc jvm — эти все вещи не просто так появились…

                              Теперь про Липпертов. Вот у меня вопрос: сколько высоконагруженных клиент-серверных систем он написал или хотя бы видел? Посмотрите на его профиль в LinkedIn и будет вам ответ. Нет, очень умный чувак и т.п. Но дизайнить языки и писать на них большие высокопроизводительные системы — это две большие разницы. Я таких экспертов называю — «академики». Попробуйте спросить на stackoverflow: «Стоит ли беспокоится о мусоре, когда пишем new Double(...)» и огребете от академиков по полной. Они этот свой неуравновешенный подход рекламмируют на всех углах. А потом такие как lam0x86 разгребают после программистов, которые не думали про мусор и задизайнили систему так, что уже и простейший пуулинг не внедрить.
                      • +2
                        То, что Java используется в гораздо большем количестве проектов, чем C#, это не означает, что она быстрее и лучше, просто на то были объективные причины. Сейчас все уже намного лучше.
                        Я сомневаюсь, что С# работает на сервере медленнее Java, даже если он работает на старом JIT, а не новом RyuJIT.
                        В .NET 4.5 новый фоновый сборщик мусора, с ним тоже все плохо?
                        Борьба со сборкой мусора напоминает проблемы с блокировками при многопоточности. Потом вдруг все осознали, что нужно использовать другие структуры данных и другие паттерны и дело пошло куда лучше.
                        • +1
                          В .NET 4.5 новый фоновый сборщик мусора, с ним тоже все плохо?

                          Не уверен, но похоже, эта часть комментария была адресована мне. Мы перепробовали все возможные настройки GC, которые только есть. Были даже попытки оценивать Memory Pressure и вручную вызывать GC заблаговременно, пока не стало совсем плохо. Ничего не помогало. Ситуацию спас банальный переход на x64 (ещё до RyuJIT). В x86, какой режим сборщика ни включай, всё-равно есть вероятность схватить stop-the-world сборку. Правда, в .NET 4.5 это действительно происходило реже.
                  • 0
                    >всё буквально летает.
                    странно такое слышать после того что я вижу у себя каждый день

                    >В проекте, над которым я сейчас работаю (UI, WPF), stop-the-world GC, порой, работает больше, чем 4 секунды…
                    это не показатель gc, а всего лишь данного приложения.

                    тестировался функционал без wpf? если это возможно
                    на java тоже был гуи на swing или подобном? и тд… примеры у каждого найдутся различных сценариев
                    • –8
                      Ой, всё просто — отключите ReSharper в Visual Studio — она вам покажется глотком свежего воздуха после IDEA.
                      Львиная доля функционала resharper либо уже втащена нативно в VS 2015 либо реализуется точечными экстеншнами. Которые быстры именно за счёт неперегруженности.
                      Сам же resharper это долбанный комбайн, который ещё надо мучительно резать, отрубая ненужные свистоперделки низкоприоритетные и малоиспользуемые функции, чтоб получить только тот функционал, который нужен. И в этот момент понимаешь, что resharper-то не нужен!
                • +1
                  студия 2013 или 2015 работают гораздо шутрее чем идея (24гига озу, ssd, corei5 2500k разогнан до 4.3)

                  Сравните количество предлагаемых фич по работе с кодом в IDEA и в VS. В VS15 фич стало больше, чем ноль, но это далеко не та же функциональность. Естественно за неё нужно платить производительностью.
                • –4
                  Честно говоря, скучно слушать подобных менеджеров. Сплошное лицемерие и проталкивание корпоративной визийной бессмыслицы.
                  Например, по поводу подписок. Снова что-то выдумывается в оправдание, типа белое — это, по-сути, чёрное, только наоборот. Хвалятся вышестоящие и придумываются заслуги. Вместо того, чтобы просто признать, что хотелось больше денег.
                  Интересно слушать людей, которые реально что-то делают.
                  • +3
                    А мне наоборот понравилось. Если не вдаваться в финансовый вопрос (Мне не особо интересно кто хочет бабла, а кто не хочет. Все хотят.), видно, что менеджмент в JetBrains весьма компетентен в технической части.
                    По поводу людей, которые что-то делают — не совсем понял. Вы считаете, что программисты, которые написали R#, делают больше, чем руководитель отдела разработки?
                    • +16
                      Этот, как вы выражаетесь, «менеджер» даст нам всем фору в плане кодинга сто очков вперед — будьте уверены!
                      • +4
                        Про подписки — вопрос уже оскомину набил. Но все-таки,
                        Снова что-то выдумывается в оправдание
                        не похожи ответы ни на «оправдание», ни на «выдумывается» (все уже давно выдумано).

                        Хвалятся вышестоящие и придумываются заслуги
                        Ребята из JetBrains частенько хвалятся не только вышестоящими, но и собой, своей командой, и своими продуктами (не без оснований). Насчет придумывания — вопрос сильно холиварный.

                        Честно говоря, скучно слушать подобных менеджеров…
                        Интересно слушать людей, которые реально что-то делают.
                        Послушайте Сергея на dotNext, очень даже познавательно.
                      • 0
                        а когда dotTrace/dotPeek начнёт понимать async/await?

                        • 0
                          А не могли бы пояснить, что значит «понимать async/await»?
                            • +2
                              Пока эта фича пока не запланирована на следующую версию. Более долгосрочный планов мы не делаем. Внутри команды мы много раз обсуждали что нужно сделать для того чтобы анализировать async было проще, но в конкретные фичи ничего пока не превратилось. Пользуясь случаем, могу я попросить вас описать задачи которые хотелось бы решать? (какой-нибудь типичный баг в асинхронном коде которые не видно просто в dotTrace timeline) Если какая-то проддержка будет, то скорее всего только в режиме профиляции Timeline.
                          • +3
                            Вот мне что интересно:

                            1. Был freeze UI при сохранении XAML в VS 2015. Так я в гугле не нашел, у кого бы проявлялась такая проблема. А проявлялась она у всех наших сотрудников. В update 1 вроде бы починили, но все равно бывает проскакивает это зависание. Это проявлялось без решарпера, но с ним всё только усугублялось. Мы одни такие или это общая проблема? Можно как-то решить?
                            2. С точки зрения UI freeze очень сильно напрягает окошко тестирования. К примеру, у меня есть 500+ разных тестов. Как только пытаешься их прогнать перед отправкой кода на сервер — видно, как решарпер упирается в количество тестов и обновление их результатов занимает время примерно N^2, где N — количество тестов (т.е. не 500^2 секунд, а субъективное ощущение, что зависания UI увеличиваются в N^2 раз в зависимости от числа тестов). Именно обновление UI тестов. Я знаю, что вы используете компоненты DevExpress. Может вам стоит переписать часть контролов с использованием WriteableBitmap(Ex)? Мне кажется, что это могло бы избавить вас от лишних задержек.
                            3. В офисах JetBrains раздают бесплатные мандаринки к Новому Году?


                            Я никоим образом не пытаюсь сказать, что ReSharper плохой продукт. Он многим нравится и без него как без рук. Порой действительно трудно понять, то ли это студия тормозит, то ли стоит… отключить еще что-нибудь.
                            Взываю к mezastel и другим сотрудникам, чтобы прояснили ситуацию :)
                            • +1
                              На сколько я понимаю, freeze UI происходит из-за перекомпиляции xaml-файлов во всём солюшне на каждый чих, даже при переключении между табами. Это нужно для корректной работы IntelliSense. Если проект большой, VS будет тормозить. Вроде бы, когда-то давно на коннекте был заведен баг, и его обещали пофиксить, но не помню в какой версии. В последнее время я с ним не сталкивался.
                              • +1
                                1. UI freeze во время сохранения XAML как написал товарищ lam0x86 не только у вас, наверное у всех кто пишет большое WPF приложение с кучей xaml файлов. Я сам от этой проблемы страдаю. Избавиться помогает только распиливание солюшена на более мелкие. С решарпером усугубляется может потому, что свободной памяти в 32-битном процессе становится еще меньше и GC возникает чаще.
                                2. В окошке UT свой контрол, DevExpress там нет. Контрол в 10 версии был переписан и сейчас как раз ведутся работы по сглаживанию острых углов и улучшению производительности.
                                3. Конечно, каждый день! И не только к Новому Году.

                                Я программист из dotTrace.
                                • +1
                                  1. Т.е. распиливание именно xaml содержащих сборок?
                                  2. Но он все равно через ItemsControl написан :) Большой производительности из этого не выжмешь. Ну да ладно.
                                • +3
                                  Спасибо, все очень актуально.
                                  1. Баг есть, при сохранении xaml файлов студийный Language Service для xaml вызывает перекомпиляцию. Это действительно нужно для работы VS IntelliSense, так как из xaml можно использовать C# код и наоборот, компиляция происходит сложно, в два прохода. Но сами тормоза обусловлены тем, что при недостатке памяти MsBuild, который работает in-process в devenv.exe, пытается освободить память путем сериализации на диск 10% из своих внутренних структур данный. И проверяет результат, вызывая GC 2. По тем же причинам может втыкать добавление и удаление файлов или ссылок в проектах.
                                  Из рекомендаций — переключить дефолтный редактор на source code editor (вместо xaml editor), перенести общие контролы (использующиеся в xaml в другой проект чтобы избежать 2-стадийной компиляции). Уменьшать количество проектов (если это возможно) для экономии памяти. Отключать фичи решарпера которыми Вы не пользуетесь в окошке опций.
                                  2. В 10.0.2 нет DevExpress уже. Пожалуйста, присылайте профили если что-то все еще тормозит.
                                  • 0
                                    Спасибо за ответы. Будем экспериментировать :)
                                • +7
                                  Почему-то про проблемы Java (зачастую мнимые) знают даже те, кто не пишут на нем, не говоря о том, что в самом сообществе практически только это и обсуждается (сборка мусора, темп развития, легаси технологии, страхи и ужасы энтерпрайза..) А .Net (со стороны) представляется как что-то более, что ли, «правильно сделанное», но по чисто историческим причинам не такое популярное, как Java. А там вон сколько проблем.
                                  • +5
                                    Общее мнение, которое складывается после четырех DotNext — с языком все довольно хорошо, а с рантаймом все довольно плохо.
                                    • +1
                                      Во-первых, хочу поблагодарить за отличное интервью, лично мне оно показалось очень содержательным. Во- вторых у меня возникла пара вопросов:
                                      1. Возможно вы или Сергей знаете или предполагаете, почему МС почти не вкладывается в рантайм? Ведь казалось бы, рантайм джавы открыт, бери и перенимай лучшие практики и если у тебя есть достаточный бюджет и умные люди, то твой рантайм должен быть как минимум не хуже.
                                      2. Насколько я понял Сергей технарь до мозга костей и плюс еще тех менеджер, но я не совсем понял, могут ли тех менеджеры в JetBrains влиять на политику компании в отношении лицензий? Или этим вопросом занимаются люди из отдела продаж?
                                      • +3
                                        Microsoft в последнее время вместо runtime'а очень сильно вложились в собственно компилятор, досконально его переписав. Это титаническая работа. На это время было много чего приостановлено, в т.ч. радикальные фичи C# (вспомним релиз C#5). Помимо этого, Microsoft начали писать новый Jitter (RyuJIT), который призван улучшить производительность, например с использованием JIT.

                                        Также, не будем забывать, что в «кухне» МС очень много других около-.NET технологий связанных с различными фреймворками (WP8, Windows Store, etc.) который тоже забирают много ресурсов, а также новые релизы вроде Core CLR. Вот и имеем, в результате, ситуацию в которой все уже чем-то заняты и на основной runtime не осталось ресурсов.
                                        • 0
                                          Команды разработки Майкрософт постоянно активно просят сообщество делиться своим мнением, найденными ошибками, предложениями по улучшению и тп. И насколько я наблюдаю, они этот фидбек учитывают при планировании дальнейшей разработки своих продуктов. Так что если что-то не нравится, есть мысли как сделать правильно, или есть какая-то досадная ошибка, которая мешает вам жить — имеет смысл воспользоваться системой Microsoft Connect, в частности для Visual Studio это connect.microsoft.com/VisualStudio/Feedback Там можно как просто проголосовать за имеющиеся тикеты, так и добавить новый.
                                          • +3
                                            1. Совершенно согласен, просят. Активно.
                                            2. При планировании новых продуктов действительно учитывают и принимают баги в развивающихся продуктах.
                                            3. Проблема в том, что есть продукты уже развившиеся и есть направления, которые находятся вне фокуса, в режиме поддержки. Приведу пример проблем в VS 2010-2015 которые не являются приоритетными и не исправляются:
                                            — перезагрузка проектов после изменения проектных файлов. так квадратичная зависимость от количества проектов. в более или менее больших солюшенах единственный способ обновится из vcs — перезапуск студии.
                                            — DirectoryWatcher. при билде он не дает ничего делать, так как заничет UI поток обработкой изменения на диске. Там проблема стандартная в том, что переполняется кэш File system watcher-а и происходит обход большого поддерева файловой системы полностью. (сейчас — в 2015 upsate 1, добавились memory leaks: twitter.com/serjic/status/670190879089520641)
                                            — запуск MsBuild при редактировании проекта (добавление файлов или ссылок) может вызвать паузы в искусственно вызванном GC в десятки секунд.
                                            — уже упомянутое здесь редактирование xaml файлов.
                                            — сейчас добавились многочисленные проблемы с производительностью roslyn.
                                            — и еще безумно много мелких проблем…
                                            Я соглашусь, что баги есть у всех. Да, VS — качественный продукт. Там мало фич, но то что есть сделано качественно. Это качество дается не бесплатно, мой опыт показывает что добиться исправлений или улучшений в некоторых областях невозможно.
                                            • 0
                                              Ну так запостить проблему и организовать мощный флэшмоб с целью сбора голосов за исправление бага — дело нехитрое.

                                              Вот кого бесят тормоза XAML — проголосуйте по разу, добавьте свой фидбек. Или переоткройте эти тикеты, или найдите подобные и переоткройте, или создайте новые. В общем чтобы что-то поменялось, надо что-то предпринять. :)

                                              • +2
                                                Большинство из вышеперечисленного я лично (при личных встречах) озвучивал разработчикам и менеджерам из соответствующих команд. И мы соглашались с тем, что это важные баги. Не знаю, что я могу еще сделать? То есть что я могу сделать я знаю и делаю, мы находим пути как обойти отсутствующие точки расширения, заткнуть мешающую функциональность и перекрыть фичи, которые не предназначены для того чтобы их перекрывать. Приведу пример: для того чтобы FTS понимал что мы программно перемещаем файл, мы в нашем коде эмулируем drag-and-grop в solution explorer. чтобы делать рефакторинги и темплэйты в xaml файлах мы при опять же программном изменении тэгов боремся с фичей студии по синхронному редактированию тэгов. Сколько людей поддержат реквест про то что какой-то API не выдает события в каких-то случаях? У нас такие проблемы возникают каждую неделю. И для нас это business critical. И пользователи ждут что все заработает сразу после выхода очередной версии студии. Добиться разъяснений сложно, добиться изменений невозможно.
                                                • 0
                                                  Да, я тоже возился с TFS. По поводу VSX — пишите прямо в команду VSX Team — поройтесь в авторах (блог правда обединился с Visual Studio давно). Можно полистать посты тут и связаться с авторами — их несложно найти в соцсетях или связаться через коментарии к постам. Разумеется приходится срочные моменты рещать самостоятельно. Но это уже другая история :)
                                    • +2
                                      Roslyn — может и сырая, но крайне любопытная технология с точки зрения создания разнообразных расширений Visual Studio — и всяких помогалок вроде ReSharper и других. Сырая — лучше чем отсуствие какой-либо и работа с COM архитектурой IDE.

                                      Проблема со всякими нагружающими бекграунд-процессами решается их отключением, если они не нужны. Тут я проблемы не вижу.
                                      • 0
                                        Не подскажите, как выключить полностью бэкграунд-анализ солюшена Roslyn'ом, а также компиляцию xaml в бекграунде в VS2015 Update 1? Меня в высшей степени раздражают дикие тормоза по 2-5 минут на простых операциях — вроде навигации по файлам, а также изредка случающиеся зависания длительностью в несколько часов при билде или отладке. А когда в такой момент профилируешь студию и видишь что-нибудь вроде SimplifyNameDiagnostics — то трудно сдерживать негативные эмоции в себе.
                                        • +2
                                          Архитектура Visual Studio прекрасна, когда поймешь ее суть. Все собирается в кучу на основе конфигурации хранящейся в реестре.

                                          В VS2013 была галочка «Show live semantic errors» которую можно было отключить. В VS2015 с интерфейса ее убрали.

                                          Поэтому:
                                          1. Идем в реестр, находим (или создаем если нету) ключ HKEY_CURRENT_USER\Software\Microsoft\VisualStudio\14.0\Roslyn\Internal\OnOff\Features
                                          2. Прописываем значение Squiggles типа DWORD и ставим для него 0 чтобы выключить. Ну 1 чтобы включить сответственно.
                                          3. Перезапускаем студию (убедиться что в процессах devenv действительно выгрузился перед повторным запуском студии)

                                          Можеет тут поковыряться в прочих настройках. Включать и выключать их можно аналогично.
                                          • +2
                                            этой настройкой мы даже пользовались до 10.0 для отключения студийной подсветки. К сожалению Language service обслуживает еще очень много фич в VS начиная с IntelliSense и заканчивая диаграммами, дебаггером итд. То есть, отключая отдельные фичи, мы не остановим Roslyn, не заставим его потреблять меньше памяти. Ну или что-то отломаем для пользователей. Из действенного есть галочка в опциях (что-то типа analyze files opened in editor) — она заставляет студию не анализировать файлы которые не открыты в редакторе с целью показать там ошибки в errors view.
                                            • 0
                                              да минусы, разумеется, есть. честно говоря, интеллисенс, когда он заставляет ждать, скорей раздражает, чем помогает. при повседневной работе с XML-подобными исходниками, достаточно просто подсветки разметки, поэтому достаточно (субъективно, разумеется) выбрать в качестве редактора по умолчанию максимально простой из имеющихся. студия и ее возможности плохо задокументированы (по крайней мере так было несколько лет назад, когда я активно работал с VSSDK, MPF и ядром автоматизации на базе макросов), о многом приходилось догадываться самому :) но в целом — отключить и включить можно было так или иначе почти все. в ближайшее время попробую эту область опять — интересно даже — многое ли изменилось.
                                            • 0
                                              Вот бы подобные настройки были документированы с возможностью настройки для солюшена, со включением в репозиторий…
                                              • 0
                                                Напишите плагин с студии, который добавляет новый Options Page для узла Text Editor — General — есть даже пример как добавить свой собственный узелю Вам понадобится для общего Text Editor узла из рееста найти и использовать его GUID-ы просто. В логике напишете управление ключами рееста. На UI сможете переключать галочки :) Думаю сложностей большых возникнуть не должно. Встроить в имеющие табики галочку конечно не выйдет, но думаю это не проблема — отдельный таб — вполне нормально.
                                            • 0
                                              Про XAML — есть парочка советов как себе немного облегчить ежедневную боль.
                                          • +3
                                            Сильно удивился, узнав, что .Net медленнее джавы…
                                            • –2
                                              Ощущение, что это очень, такая, рекламная статья, обернутая в форму интервью.
                                              • 0
                                                Скажите, а EAP в решарпере будет?
                                                • 0
                                                  Почему dotPeek такой тормозной? Невозможно им пользоваться. Даже просто запуск происходит около минуты.
                                                  • –4
                                                    При всём уважении к JetBrains вместо того, чтобы заниматься бесполезным развитием решарпера, лучше бы они бросили всю команду на более полезные вещи. Например поддержку C# в Idea.
                                                  • +2
                                                    декабрь 2015
                                                    — Насколько имеет смысл вообще заниматься всей возней c Visual Studio, учитывая, что у вас в компании офигенный опыт и очень успешный спрос по построению собственных IDE?

                                                    — Visual Studio, конечно, имеет смысл, с нее мы никуда не слезем. Это инструмент, который обеспечивает разработку на всех платформах, которые нужны для Microsoft. Он меняется раз в три месяца и поддерживает новые платформы от Microsoft. Повторять эту работу — вовсе не наш приоритет.

                                                    В первую очередь нужно понимать, что Visual Studio решает внутренние задачи Microsoft. Вот, например, вышла Universal Windows Platform, а под нее нужно все программы дебажить, запускать, профилировать, настраивать проекты, которые будут работать под разные платформы… Это мы повторять не будем.


                                                    январь 2016
                                                    blog.jetbrains.com/dotnet/2016/01/13/project-rider-a-csharp-ide
                                                    Today, at NDC London, we announced a new project that we’ve been working on for a little while – a cross-platform C# IDE, based on the IntelliJ Platform and using ReSharper technology.


                                                    Как-то некрасиво получилось…

                                                    Остальному сказанному, видимо, стоит так же доверять.
                                                    • 0
                                                      А никто и не повторяет — текстовый редактор в IJ был, а поддержку UWP, например, никто особо делать не собирается. ;)
                                                      • –2
                                                        1. Релиз этот — последовательное развитие логики «С Visual Studio трудно работать», которая прослеживается и в этом интервью и в интервью Дмирия Нестерука.

                                                        2. Такие вещи не раскрываются заранее по многим соображениям — коммерческим, политическим. Или банально из-за отсутствие финального решения на момент интервью.

                                                        Оба этих момента кажутся мне настолько очевидными, что я даже не знаю, стоит ли на них останавливаться.

                                                        Вы намекаете, что вас обманули. Я бы скорее заходил с другой стороны — привлекли ваше внимание к проблеме, объяснили эту проблему и, три недели спустя, дали решение. Большего и требовать сложно.
                                                        • +2
                                                          Я ни на что не намекаю, я говорю, что говорить одно, а делать другое, некрасиво. Даже если вещь хорошая (коей безусловно будет являться новая IDE от JB).

                                                          > Такие вещи не раскрываются заранее по многим соображениям
                                                          Тогда бы оно звучало как-то так:

                                                          — Насколько имеет смысл вообще заниматься всей возней c Visual Studio, учитывая, что у вас в компании офигенный опыт и очень успешный спрос по построению собственных IDE?

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

                                                          • 0
                                                            Так они вроде и не писали, что не делают, просто написали, что это не является приоритетным направлением для них — это все-таки разные вещи.
                                                            • +2
                                                              Они не говорили что не будут писать свою IDE. Они говорили, что не будут слезать с вижуал студии, так как там куча всякого для поддержки технологий MS. То есть для того, чтобы противоречить своим словам им надо было прекратить поддержку VS а не начать поддерживать не-VS.

                                                              Насколько я понял новая IDE нужна для поддержки той части микрософтовского стека, которая кроссплатформенна (фактически сам язык, может Katana) — всякие там WPF и UWP не поддерживаются и, судя по интервью, не планируются. (В противном случае им пришлось бы безжать на перегонки с о студией а не сидеть на ней сверзху в этом вопросе).

                                                              Сейчас скорее всего он конкурируют с VS code в каком-то смысле.

                                                              Интересно также зачем им отдельная IDE а не Resharper-for-IDEA (наверное маркетинг?)
                                                              • +1
                                                                >Интересно также зачем им отдельная IDE а не Resharper-for-IDEA (наверное маркетинг?)
                                                                Ну а что еще :-) Думаю будет отдельная, для тех кому нужна работа только с C#, и возможность работать с C# в IDEA, для тех, кому нужно с большим количеством языков одновременно работать.

                                                        Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                                                        Самое читаемое