Geekly Articles each Day
📜 ⬆️ ⬇️

“Chaos in the .NET world is a reasonable price for the speed of platform development”: an interview with Andrei Akinshin (JetBrains)



The Rider project (.NET IDE from JetBrains) reached the public EAP-version - it's time to ask Andrei Akinshin , one of its developers, in detail. But Rider was not the only theme of the new edition of No Slides. In addition to him, they talked:


As always, under the cut there is a complete transcript of the interview.
')


Rider


- Andrei, we all heard that you had a public EAP. You have been working on this project for more than a year now - please tell me how you feel?

- As a team, we have very good feelings: we all sit on the Rider, we write 90% of the time in it. We are the oldest users of Rider, because we began to use it from the very first versions, when it became possible to write at least something in it.

We all like it very much, Rider is a very cool IDE, and mainly due to the fact that we are developing partly for ourselves. That is, all the things that are inconvenient, annoying or impossible to do, the whole team notices, we all suffer from these things every day. After some time, someone scratches his hands, he goes and just rules this functionality. Rider is also based on the code base ReSharper and IntelliJ IDEA, and these are very cool products, each of which has been developed for more than 10 years, each has many features, each is very highly optimized. In Rider, not everything is ready, but what is ready works very well, and we really enjoy using it.

- Does ReSharper work with Visual Studio inside a process, or in a separate process?

- It works inside the process, and this is a big problem, because the year 2016, and Visual Studio is still a 32-bit process, and many of our users complain that ReSharper is slow. ReSharper does not slow down, it works as before and even faster, but the Studio consumes more and more memory with each new version, and within the framework of this 32-bit process it becomes ever closer. And in terms of brakes, Rider is living proof of this: we got out of the Studio process, and everything flies.

- Why wasn’t ReSharper out of process done?

- It is very difficult, firstly, in terms of interop with the Studio itself, and secondly ... At Rider, we essentially implemented interop between IDEA and ReSharper. We did this with the help of our custom protocol, which we have been developing for a very long time, a lot of tyunil.

Great work has been done, it is very convenient to use, everything works very quickly, but still there are some problems, there are things that are not thought out, inconveniently done. And even to connect two products, each of which we do ourselves, in each of which we can change anything - this is already a very difficult, complex technical task. With the Studio it would be extremely difficult to implement this.

- And if you go in a slightly different way: now you have already completed the Rider out-of-process mode, and you have the protocol. Now, if to fantasize: is it possible to integrate everything into the Studio, or do you have to redo everything?

- Well, purely technologically - yes, it is possible, sometimes we even think about it. But you need to understand that this is a very big and difficult task. If we ever do this, we need to understand very well that this is cost-effective, and the amount of labor we invest in it will justify itself in the long run.

- Well, there is a trend that Visual Studio consumes more and more memory. There are no prerequisites that will consume less, and the question arises as to why there will be room.

- Well, no one knows what will happen with Visual Studio tomorrow, so we are still sitting on it. All I can say is that there are no such plans today (in fact, there are guys from ReSharper who speak openly about this - author's note) . Today we are actively sawing Rider, this is our top priority.

- What do users write to you? You already had a closed early access-program, I’m a participant and even reported bugs to you - I can say that I’m generally early adopter. How many users have a closed EAP?

- Yes. I think there are thousands of people who are actively developing in Rider. The feedback is colossal and very good.

- “Good” in the sense of “positive”, or in the sense of “giving food”?

- Both positive and constructive. Early Access Program (EAP) allowed us to identify things that we did not work out in the early stages of development.

- Give examples?

- For example, support for Unity or Xamarin. Very many people try to use Rider for these purposes, and their feedback was very valuable for us. We ourselves use it every day, but Unity or Xamarin is not the technology on which the entire ReSharper team develops every day. And in some moments we do not fully understand what the users need, what they lack in this life, what the current toolkit does not suit them. In this regard, feedback is very valuable.

Sometimes just bug reports come, which “we did like this, and everything broke down”. Or come rekvesta feature: it would be great if there was such a functionality. We listen to all this, communicate with people, try to implement it as quickly as possible.

- How many of you are currently working on Rider?

- Core Team - a little more than 10 people, but you need to understand that we also have ReSharper and IDEA teams, with whom we also constantly cooperate. Sometimes we find bugs in one or another platform, sometimes we lack some functionality, we come to the guys from other teams, and somehow discuss these problems. Therefore, we can say that for a hundred.

- In “Without Slides” in due time Dima Zhemerov talked about how IDEA evolved from IDE into a platform through the Extension Points mechanism. And Sergey Shkredov told that ReSharper is able, conditionally, to drive inspections in nightly builds, everything is connected with TeamCity, and so on. Do I understand correctly that in these two places integration was done? So how did you do it?

- We have two processes. We call them "backend" - this is, in fact, ReSharper - and "frontend", IDEA. Between them, communication is carried out according to our special protocol, and according to it, we, in fact, are chasing the view-model.

- Is he on top of that, over sockets?

- Over sockets. We thought about different options, but this one came up to us the most. First, we wanted to drive the entire model that ReSharper has. There are, for example, syntax trees that IDEA builds to support Java, but if we completely overtook syntax trees for C #, this would be a very expensive operation, we would not have pulled a performance ...

- That is, data traffic?

- Yes, the protocol traffic is very high. Therefore, we are driving very lightweight models, only the view-model, only what we need to display for the user. Only information for UI.

- Is the syntax tree lying on the side of ReSharper?

- Yes. That is, ReSharper has a tree, it somehow processes it, counts all the analyzes, and simply throws a few lines to the IDEA side, for example, with messages from the inspection subsystem.

- Simply, as far as I understand, IDEA works with a certain tree, which you build and drive in this or that language. Here, apparently, had to redo much, right?

- Yes, we do not use it, we use API's, for example, “underline the red line here, because ReSharper said that there was a mistake”. We do not analyze on the side of IDEA. All analyzes are done by ReSharper. And from IDEA for the most part we use "show UI".

- That is, you did not integrate with IDEA where other languages ​​integrate. How much for this integration had to be rewritten in IDEA?

- No, surprisingly not so much.

- What parts of ReSharper and IDEA corresponded in order for this to work?

- I didn’t have to edit much, just to add some APIs. We have our own commits in IDEA, but most commits are related to the fact that we take some private and change it to public. Some method has never been pulled out, and we needed to call it, because we do what other languages ​​do not. And, of course, the biggest work was done to make ReSharper run properly on Linux and Mac over Mono. We have learned a lot about cross-platform development :) Recently, we did a seminar on the topic of cross-platform in Rider, video is already available .

- I had a story that I put Mono on a Mac through Homebrew, and on one of my early builds, ReSharper just refused to see such a Mono. I understand that probably not the most difficult task is to fix all this. But do you have a feeling that you coped with this type of jambs with a public EAP?

- Well, we raked the bulk of the most major jambs. Now Rider is an IDE that you can actually use. There, not all features work perfectly, sometimes something falls off somewhere, but most scripts work.

- It is clear that the release is a grocery thing, but purely your subjective engineering feeling is of interest: is there much more that needs to be done in order to go into production? What things are you going to refine first?

- We have not much to do. First of all, you need to work on stability ...

- Fall still?

- Not that we would fall, but recently, for example, a request came: I have ArchLinux, I put a Rider there, and something doesn’t work for me there. We, let's say, do not have much experience with ArchLinux, we understand ... These are not the bulk of our users, but rather exotic scripts.

- The same Java, for example, is not certified on all Linux, there is a very strict description of what the distribution kit should be. In my opinion, the fact is that the reference platform is Oracle Linux: relatively speaking, Red Hat-like distribution with all the ensuing consequences. About the rest, Java does not give guarantees, and I wonder what you are doing in this place. Do you supply your own JVM?

- Yes, we carry with us our own Java and our own Mono, on top of which we work. We do not have the task to work absolutely everywhere or support “these, these, these” versions of Linux, and do not support the rest, we just, as far as possible, try to make maximum users happy so that they can use our IDE.

- And as far as .NET, what are you carrying with you?

- Mono. Well, on macOS and Linux - Mono of a certain version, and under Windows we run on the full framework - the volume that the user has.

- C him less problems?

- Yes, because ReSharper is initially a product that runs on top of the full framework. And with Linux, of course, a lot of problems have arisen, we are contributing a lot to Mono itself, we roll a lot of patches onto Mono, which comes with us, so that we can work well on top of this. This is a large amount of work.

- Are you contributing to upstream?

- Yes of course. We are trying to push through all the changesets we make.

- A lot of Mono pulled bugs this year?

- I think a good ten of hardcore bugs found. For example, in Mono, work with mutexes was poorly implemented. There were named mutexes, which, as it were, are not found on Linux and macOS, but they are in .NET. Therefore, we had to somehow emulate work with them, it was not fully emulated, and in the NuGet source code - we must fully implement the work of our NuGet. We spent two weeks catching this Race Condition, which arose somewhere inside, then we found out that it arises not only with the named mutexes, but also with the usual ones, patched it up, then sent a fix to Mono, it already hit the master branch.



Present and Future .NET


- Listen, this whole fun bunch of “Mono, Xamarin, Microsoft”, and the whole story about different runtimes (Mono, classic, Core) - is that how you will live with all this colorful zoo?

- The short answer - somehow we will. We are trying to support all this. Most of all problems, of course, with CoreCLR, because this is a thing that, one can say, has not come to the end. That's just recently, Microsoft introduced a new Visual Studio 2017 and with it a new coreCLR tuning, in which they changed everything again.

- That is, wait, there was version 1.0, about which they said that it was stable, then 1.1 was released ...

- No, there are two different things. There is, and there is to it. Rantaym is a VM, on top of which we run. And tuling is how we collect it all.

- That is, a new tuling was released.

- Yes. There was such a format of projects based on project.json files, many people heard about it or even worked, Microsoft promoted this project for a very long time, said “the future in json”, “translate your project into json”. And then suddenly they say "oh, something did not go, we go back to csproj." Many months ago it was announced that project.json is already legacy, it will not be supported, but no alternatives have been provided. And she literally appeared a week ago.

- If you ask me how I feel about the story with CoreCLR, then the word “chaos” comes to my mind. What are your feelings with colleagues?

- Partly, of course, we agree with you, because a lot of things are happening, changing in infrastructure, in relation to .NET. But I think this is good enough. Because .NET is such a platform that has lived its life for many years in the framework of the Windows ecosystem, and suddenly Microsoft completely changed its strategy, headed for cross-platform, Open Source and all that.

And it is clear that this is not done in one day, this is a huge amount of work. Make the same CoreCLR, make it full cross-platform, so that everything works on mobile phones and so on. It is clear that the guys want to do all this as early as possible, and of course, they make some mistakes, which they then have to admit, roll back, change something ... This is a reasonable price, which has to be paid for the speed of development of a modern dotnet.

- Is there such a thing that a person writes on .NET, today hears one thing, tomorrow another, he has to redo everything several times, he just spits and says, “nafig I spend a lot of time rewriting, I’ll go to another platform”.

- It all depends on what exactly you develop. If you are developing on the same dotnet, which once was and is now (full framework for Windows), you should not have such problems. You have all the problems that before, maybe a little less.

And if you start to develop on CoreCLR, then the word “preview” in the title should alert you and prepare you for what will happen next.

There are people who are trying to sit on the bleeding edge, on the latest technologies, and influence their development, because Microsoft is now very actively listening to the community: if you don’t like something new, now is the time to write them a feedback. And other people just wait for it all to become stable.

- You touched on a very interesting topic - dotnet and cross-platform, dotnet and open-source. Let's talk about these two big blocks. That's about Linux, since we’ve touched on this: .NET and Linux have been together for some time. Has it become better during this time?

- Yes! First of all ... We have two runtime over which we can run on Linux and Mac - these are Mono and CoreCLR. They are different, each interesting and deserves special attention.

Mono is a project that has been developed since the beginning of the 2000s, and the farther, the more stable it becomes, it can be considered as more and more serious runtime. If people who tried to translate something to Mono five or ten years ago suffered, now ... Well, we, of course, suffer a little too. But ReSharper, in which hundreds of projects, millions of legacy lines of code that were written from the beginning of the two thousandth, even if creaking a little, wound up and works fine on top of Mono. That is, the development goes, bugs are fixed, and lately they are fixed very quickly.

- According to what you see in your customers: do they leave for CoreCLR?

- So far it is difficult to say. We can say that the community’s interest in CoreCLR is very large, a lot of people are following development, trying to do something, trying. But this is still a preview, and it is still too early to make some kind of enterprise over CoreCLR.

- What about Roslyn? A new Studio has been released, what do they have with the compiler?

- Roslyn is developing. Coming soon C # 7, a preview is already available in the new Studio. Roslyn is fine.

- C # 7 goes with Roslyn - right out of the box? Roslyn progressing over this time?

- Yes. It fixes bugs, develops, and ... The most important opportunity we got by switching from the old legacy compiler to Roslyn is that we can now easily develop the language. We can concentrate more on what features are needed from the point of view of the language and how to implement them more correctly than on implementation. On the old compiler it was very hard to write new features, with Roslyn it became many times easier.

“Have you tried to drag Roslyn somewhere to yourself and do something about it?”

- Well, how. We use it as a compiler. It works under MS build, and with the help of it new projects are compiled. But with respect to analyzers or inspections, what it provides is simply not necessary, because ReSharper implements much more. I would say, at times more, very cool inspections, more intelligent. And Roslyn can easily gobble up two gigabytes of memory. In this regard, the ReSharper code base still more economically relates to memory, actively uses caches, and so on. That is, we would have no profit from the transition to Roslyn, some problems.

- Let's talk about performance. CoreCLR, Roslyn compared to Mono with the classic legacy compiler. That is, two runtime, they will have a different performance. How do you see it?

- Definitely very difficult to say ... Recently there is a new JIT compiler RyuJIT. Now only the 64-bit version is available, and both in the full framework and in CoreCLR. And in CoreCLR 1.2.0, we are also promised the x86 version.

RyuJIT is a very interesting project. On the one hand, it's good that the guys started doing it, because the old JITs were hard to develop, they dragged a lot of problems with them, a lot of hacks for old .NET versions like 2.0. But what turned out badly is that RyuJIT, for example, is inferior to the old Legacy-JITs at some points in performance. That is, there the guys emphasized that the speed of JIT'ing was as much as possible. And because of this, some good optimizations do not apply.

But the good side is that RyuJIT is developing very actively now. It is being actively developed on the githab, the guys have improved the architecture so that, for example, RyuJIT has good integration with AVX and SSE instructions. And optimizations are evolving. 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.

Source: https://habr.com/ru/post/316436/

More articles:


All Articles