Geekly Articles each Day
📜 ⬆️ ⬇️

“In a year or two, .NET Core will replace Java in the enterprise solution market”, - Interview with Jon Skeet, Google

Surely, you know who John Skeat is: # 1 on Stack Overflow , by C # in Depth , one of the best books on .NET, a Google developer and a 14-fold MVP. There are not so many developers of this scale, two orders are enough to list them all. May 19-20, John will arrive in St. Petersburg and will speak at the 2017 DotNext Piter .

I was able to talk with John and interview him extensively about the fate of .NET, .NET Core, the innovations in C # 7 and the overall level of development of the average developer in 2017.


')
Specifically, the following issues were discussed:


The interview turned out to be very large, but it seems to me that it is worth every minute spent on it.

About the development of .NET as a platform


- Greetings, John, let's start with simple questions. Recently, .NET Core and ASP.NET Core are developing very quickly and are constantly changing. Do you, as a developer, think that the platform has taken the right course?

- I think the question touches on two different aspects. The first is the direction of development of the platform, and the second is the process of finding this direction: Microsoft has become much more open about everything related to .NET. Now almost everything has become open source and it's great. On the other hand, this entails changes in a number of things: for example, in the decision-making process. We will observe intermediate steps, like project.json projects and KVM. In the days of the “old” Microsoft, with its traditional corporate software development, this would not have happened exactly, and perhaps we would immediately see the .NET toolkit in its current form. Yes, there was complete confusion in the community, and to me personally, much was not clear, but over time the situation became clearer. This week I asked a question on Stack Overflow about what the .NET Standard Library is, and the situation is getting better.

However, in my opinion, we, as a community, must understand that the advantage of an open platform as an opportunity to plan, see and influence what is happening is accompanied by one drawback: you must either consciously ignore changes that have not yet been finalized, or dive into them, realizing the likelihood that you just lose time if these changes are rolled back. Apparently, this is suitable for most, and openness is beneficial, but for the .NET community this is a kind of cultural shock.

Given all this, it is impossible not to note a few, how to say ... communicative misfires, which can be easily understood: it is easy to make a mistake when creating a fundamentally new version of something. Of course, there were still errors with version numbering, with the choice of release dates, with decisions about readiness. In general, things did not go as smoothly as we would like, but this is not scary: after all, no one is perfect, and we, as a community, must accept this. The more you see, the more imperfections you notice. This is regarding the development process of the platform.

If we talk about the direction of movement. NET, here I am extremely, extremely optimistic. It is nice to see the active development of .NET as a platform, and its expansion to mobile platforms, and how Xamarin falls on the whole story. All this is difficult, but inspiring, and there is also great progress in languages, in tools. In my opinion, the overall situation is beautiful. For me, this is still happening at the time when I am working on the Google Cloud Platform at Google, trying to make GCP a great environment for C # developers, and, of course, .NET Core is an important part of this.

Recently, at the Google Cloud Next 2017 conference, my manager and I discussed the possibility of running ASP.NET Core applications on the GCP, both in the App Engine Flexible Environment and in containers. And this is one of those things that just a few years ago would have been considered ridiculous. We needed to work on our part (in Google we have an extension for Visual Studio that allows us to deploy directly from VS in both environments), but this also would not make sense without what Microsoft did with .NET Core. To be honest, it seems to me that a winning situation is emerging for everyone.

- I understand correctly that you are currently involved in the Google Cloud Platform , which is a direct competitor for MS Azure?

- All so, GCP competes with MS Azure and Amazon AWS. In general, I am not directly involved in the development of the platform’s “guts”. All the cool stuff that my colleagues create — like Cloud Spanner, BigQuery, Datastore, or various machine learning APIs — is great, but doesn’t benefit the C # developer, if he can't use it. So I create a bridge: we have auto-generated class libraries and some new kinds of code generators to simplify the whole process. And I add a little handwriting code there as a glue or wrapper to make everything as seamless and elegant as possible.

Often, seeing the automatically generated code, you can understand that it is generated, as it is not very good. My part of the work is to make code generation as close to natural as possible. Imagine that you need to get a list of any resources, and at the exit you get 20 answers to remote procedure calls, although you only need to iterate them - I’m working to solve such situations seamlessly and write just such code — small the final touches, because of which the overall picture looks very different.

- So your job, in fact, is to make the auto-generated code pass the Turing test? :)

- Haha, that would be great! I do not think that we are close to this, but he passes another test: when you use a code generator, you either feel subservient to his whims, or you feel that he is working for you. I firmly believe that in our case the developer controls the process.

- Returning to the .NET platform: what are the most large-scale changes to .NET-developers in the near future? It is difficult to make plans for the years ahead, but perhaps share your expectations for the coming months?

- It all depends on where you are. If your project is stuck in the project.json epoch or “I spat on everything, I'm still on VS2013,” that is, what to catch up to the latest releases. VS2017 came out, the .NET Core SDK was released, everything was released, it's not beta anymore - and I urge everyone to figure out what that means. Yes, it takes time, and the documentation is still being actively improved. But this is a question of the path that must be done in order to catch up with the current state of affairs.

And speaking of the future, the next global thing that awaits us is .NET Standard 2.0 . We already had .NET Standard 1.0, 1.2, 1.3, etc. This is not the first attempt to facilitate cross-platform development regarding portable class libraries. But .NET Standard 2.0 is a brave new world, covering far more platforms than we are used to on the .NET desktop. There will be incredibly smart tools that allow you to use class libraries written only under .NET 4.5: their authors may not even support them anymore, but this will not prevent them from running in .NET Standard 2.0. In addition, I believe that the toolkit is becoming lower-level. The main thing is to make sure that you are not using WPF and WinForms, and everything will be fine, such a library can be used in the context of .NET Standard 2.0.

They promise us just such a development path, and the current .NET Core SDK is not just good, but really good - a huge step forward compared to what it was before. And I think Microsoft will not stop there. Therefore, if you do not write custom applications (where, obviously, the UI will be important, and much will depend on the platform), you can largely rely on the fact that .NET is .NET, and cross-platform to the fullest. What all this will mean in the context of deployments from Xamarin for Android and iOS is not yet clear, but it will be very interesting for me to see how everything will turn out.

- You recommend that everyone, as far as possible, switch to new versions of .NET Core as soon as possible, since it is already stable. And what about the ancient .NET 4.0 Legacy projects?

- In this case, there is no need to upgrade to .NET Core. I would say that if you use .NET Core with the old SDK, you use project.json , then it is definitely worth migrating to the new toolkit as soon as possible. No need to hurry, but it’s worth adding to the roadmap.

And if you only have an inherited application that only works with .NET 4 ... it all depends on the specific case: if you see it has a long-term future, then it may be worth investing time in updating it to .NET Core. If you have TargetFramework as .NET 4.0, and you are not using any dubious libraries, then most likely you can simply port it to .NET Core and find that the choice of deployment environments has greatly expanded.

Let's say you already have a number of services running on a Windows Server, and you hear a lot of good things about Linux containers (I’m aware that there are win containers, but in the case of Linux, the choice is much wider). If you are porting them to .NET Core (and if you assume that you have an ASP.NET application, then in ASP.NET Core, this is a little different), then you will benefit from improvements in tuling and the width of the choice of platforms. Say, when it comes to Continuous Integration, you will have much more accessible environments: you can use Travis , which is not supported by Windows: “Hey, this is not a problem, I can still run Travis tests as part of my regular CI.” All these things improve life.

Of course, this does not apply to all. If you have an old application in which no big changes are expected, and which ideally will be replaced at all in the near future, then all the work on porting will be meaningless. But I think we tend to underestimate the time that the project will be in production, and the amount of changes that it has to face. You shouldn't think “nothing, here I’ll finish, build a build on some old VS or something like that, in the end, there’s really no such changes anymore”. After you have to make 20 such changes, spending your energy on deployed in outdated environments year after year, you will finally come to the thought "I should have tried earlier and switched to something more modern."

Cross-platform .NET and server enterpise competition


- Clear. There is another question about .NET cross-platform: do you really think that support for many platforms is a good idea? You have already mentioned that you have a huge infrastructure, but can .NET compete with Java in the cross-platform enterprise and backend categories?

- Absolutely! I would say that this is not just a good idea for .NET, it is a necessary idea for .NET. I believe that the fate of .NET in the form of a Windows-only platform with the support of third-party non-very-very-well-supported environments, niche platforms with which people suffer more than work, has never been promising. So it was a necessary job that not only unleashed a lot of potential, but also prevented .NET from becoming obsolete in a few years. I think non-cross-platform server solutions will have a hard time. We see the same with environments that used to be Linux-only or treated the Windows environment as a “poor relative”: Windows added support for Ruby and Python, which over time has become noticeably better. The same with Git ... Yes, even Bash (Shell) is now on Windows. I think that multiplatform now is a “cost of living”.

- Clear. I can not ask a holivarny question: what do you think about .NET compared to Java? Especially in the enterprise market, which, as I understand it, looking at Microsoft’s work on Azure and the enterprise infrastructure is one of the targets for the company.

- I would say, .NET can definitely compete with Java, and to be honest, I personally always prefer to develop in C #. Just because the language itself is much better.

Nevertheless, Java has certain advantages: much more open source libraries (although not the fact that they are better), more options for solving a problem. If you choose a webservice framework, in Java you will most likely have at least 30 options, and in .NET, perhaps 5. But in any case, you will only use one of them, so in the case when in Java , and in .NET there is at least one good option, a variety of Java helps, but at the same time it can be confusing. And if there is no dominant player, diversity only complicates the process of finding good solutions. So, if you just want to find a framework with a good implementation, this is almost an advantage on the .NET side.

In addition, there is inertia. We know that there are a lot of enterprise Java programmers and applications in the world, and I don’t think many people will say, “Let's take this working Java application and rewrite it under .NET”. Rather, it will be like this: "We need to rewrite the application anyway, so we need to choose from a couple of platforms." And if you are creating a new application - it doesn't matter if a web application, service or something like that, I think, in this case, Java and .NET should go nostril to nostril. I assume that the enterprise will be careful of the .NET Core for another year or two until it proves its viability, but after that I expect an increase in use in the enterprise, and then the advantages of C # should be felt.

- Yes, I understand, thanks. I will not address more developer-friendly JVM-languages ​​here, because we are not here for holivar :) But I have one more question: do you already have a real accumulated experience of actual live experience in developing applications or services for Linux on .NET?

- Generally, I do not develop applications in their pure form, but recently for Google Cloud Next 2017, together with my manager, we implemented a very small ASP.NET Core web application, which I later put into the container in AppEngineFlexible Environment. On such a scale - yes, there is experience. Also , the Noda Time website is built on ASP.NET Core, now it is supported on Windows, but I hope to transfer it to Linux, and I see absolutely no reason why it shouldn’t work out of the box.

And in my experience, .NET Core for Linux is very good, as long as you only use it. The places where I found problems were in the build scripts: only this morning I installed VS Code on my Linux box, and with Noda Time everything was fine for netcoreapp and netstandard versions, but when I tried to build code for .NET 4.5. 1 it said: “Hey, I have no idea what .NET 4.5.1 is” - so it was necessary to include a couple of references to reference assemblies in the build. So, if you are absolutely cross-platform and focused only on the .NET Core, I think everything is fine, but if you already have several builds where some pieces are cross-platform and others are tied to the full .NET Framework, then everything is not as good as you would like would. I’m sure MS is working on this, and I myself could fix the situation by installing reference assemblies in certain places, but I don’t want to run Windows code under Linux — I just want cross-platform code. And this part, as I said, is especially good.

A couple of words about C # 7


- Let's talk about C #. Version C # 7 is already out and available in VS 2017, we have classes of tuples (tuples), pattern matching and other features. What do you think as a developer about this release and new features? Will they be widely used? Or would you prefer a tongue to get some other gadgets?

- I am extremely pleased with C # 7. Now I am writing about him in the fourth edition of “C # in Depth” , so I recognize him much better than before. Right now I am writing about tuples, a feature that looks simple, but has a lot of hidden little things. Initially, I was wary of tuples, but now I see their advantages in implementation. What I'm not sure about now is whether I would write public APIs and put tuples out. This solution restricts language developers to lightweight, non-encapsulated return type. While, if you return a certain class, this could be improved over time.

Tuples will be a great help for lazy developers, and we all have to be somewhat lazy. Within a certain class or even a library that uses tuples as a lightweight way of grouping variables together, everything should be cool.

Another important feature you mentioned is pattern matching. And the most valuable thing in pattern matching in C # 7 is not the patterns that we received, but the introduction of the very idea of ​​patterns. I consciously share these concepts. At the moment, we can use patterns in the "is" operator and in switch cases. The only patterns that we have now are equivalence and coincidence of types. So you can either set "case x is 5", and there will be a match if the value is 5, or you can search for a match by type: "x is a String". Previously, type matching raised objections, but in practice turned out to be really useful.

I have already received the first C # 7 pull request in Noda Time from my friend Bill Wagner, and this pull request demonstrates the advantages of pattern matching with specific examples. But in fact, it shows the lessons learned from F # and Haskell, which allow describing a function through how it will behave in different situations - this is a truly understandable way of describing compared to if-else-if-else-if-else. When we say “this case corresponds to such an outcome, and this to this one”, in essence, we do the same thing as an if-else, but in a much simpler form for understanding. It all looks promising, and I hope that in some intermediate releases, like C # 7.1, we will see more patterns, such as deconstructing values.

Imagine this situation. You have DateTime, you can deconstruct it and find cases with pattern matching where the year is more than 2016. You can do something similar in C # 6, but matching will not use deconstruction. So pattern matching in the future can give much more. These are the biggest features of C # 7, and they should not be underestimated.

Another big advantage for most ASP.NET Core users lies in async / await composability: if before the async method could only return Task, Task or void, now you can return anything that matches a particular pattern (but this is not the same as pattern matching!), if there is an attribute that says if you don’t create a value of this type, use this factory. ” I do not think that many people will apply this pattern in their code, but they can use the implementation of other people. And ValueTask - a more lightweight version of Task - will use almost everything, this is a structure that the ASP.NET Core team has optimized in various ways, and it will be especially useful in situations with low response times, when you want to get all the benefits of async, but not load GC care about unnecessary Task-objects. In my opinion, this is an interesting feature that many will use without going into the details of "how to implement your own return type."

If you just look at the list of features, then C #, in addition to major innovations, gets small ones, such as ref-local and ref-return, which are rather difficult to understand (at least for me). I believe they will be very useful for Unity-developers of high-performance games, which are very sensitive to certain aspects of performance, like GC and the like - there is a feeling that they use structs more than other developers.

There are also some nice little improvements like out-variables: the ability to declare a variable at the same time when you use it for an argument for an output parameter, so there is no longer any need to declare:

int x;
if (int.TryParse("some text", out x))
{
// ...
}

if (int.TryParse("some text", out int x)), . , C#: , - - , , , . out- , .

, . , , : async-, , , , iterator-, , , , , FooImpl, . FooImpl . , , , .


— , .NET, . #1 Stack Overflow — . , ?

— , . : Stack Overflow , . , — , , , . , , , . , , : « , , , , ». , , , , , . C# 7 .

, , , . … : ( ), . : « , , », — , : « , ?». , , . , , . , . , , .

- , NUnit Noda Time, - Linux , Windows. , en-uk, NUnit, , String.EndsWith() assert.EndsWith() , NUnit , . , . :

  1. ,
  2. — , - ?
  3. ,
  4. ,
  5. Noda Time, , NUnit
  6. NUnit , NUnit- «, String.EndsWith(), , , »
  7. 10 , String.EndsWith()
  8. , Linux , Windows
  9. SO, , : Windows UK English Linux
  10. US English, Linux.

, , .

, , , — . , . , , , : « . Android Java, SQLite. », — , Java, Android SQLite? . , , ? , , . , « », « » — , - .

— ? , ? ?

— -, , — , , . «# », . , , , , . , , /. , .

, . JavaScript , Node.js - . C#, Java, Ruby, Python , , . - - — . , . — , , 5 , , , .

, , , , . , . : «, , , ». -, : , , iOS-, . , iOS , , .

, , , . , , : « Strings Strings» — , . - , , , . , . . , - . « , , , ». , , — . .


— , . , DotNext «Back to Basics» , : , . - ?

— : , , /. , , , - Unicode . 65536 , , Basic Multilingual Plane. planes, « , , - , BMP», -BMP BMP. - ! 10 BMP, , , -BMP .

: , 10 , ? BMP «e» , , , . emoji: Java .NET, String.Length(), . , ? : , , . , .

, , . , , - .NET: Noda Time, . , 2.0. , , , . , JavaScript , Date JS , . JavaScript API , .

, , , , : « 5 10 0, 0.5», — , .


— , , . , , — , ?

— , :

1. , Noda Time, - . DateTime.Now() - , , . Noda Time.

2. , , . DocFX, Sandcastle, , . . , , , - Stack Overflow, , , : « , ?» , .

3. . , , , — , . , , … . , . , , , .

, — , , 2,5 . - «Everyday sexism», , . , , , .


phillennium DreamWalker . !

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

More articles:


All Articles