No longer used. NET Framework

The. NET platform is great. It's really great. Until it's no longer so great. Why am I no longer using. NET? In short, it limits our ability to choose (which is important to me), diverting our attention and making us aware of its security, instead of all the possibilities that help us to perceive the wider world outside.

　　[Fasten your seatbelt: the length of this article is almost a book ...]

Advantages

First, let me start by saying that. NET is doing the right thing, although most of it doesn't come from. NET itself, but it comes from the. NET community.

　　C#

C # is amazing. I think it's an amazing programming language. From the strong C-language background, I thoroughly like the sense of grammar, flow and the language that it brings. Of course there is something I might change, but in general it is a solid language. And based on the large percentage of programming languages used by developers and the superiority of the Windows operating system, it is a well-known language.

　　ReSharper

I also like Resharper very much. The developers who work in JetBrains are miraculous people. Without ReSharper and some related tools, I might not be so fond of C #.

　　BDD and Mspec

I also like the BDD-style framework called Machine spec (MSPEC). It's an amazing test framework that really supports testing itself with the right language in the test. Before I used Mspec, my test was a mess and it was very much in my business.

In addition, Mspec is a great inspiration to my organization when we create the goconvey-Golang-based BDD testing framework.

　　Multi-language runtime

I think the notion of a multilingual CLR (the common language runtime) really makes the world of the JVM think. I don't know any non-Java JVM language before the CLR, but with the advent of the "Common language runtime", I understand that this allows people using the JVM to move forward and eventually create great JVM programming languages such as Scala and Clojure. If I'm wrong, please correct me. Furthermore, the CLR allows Sun's people to sit down and focus on it, because Java is a bit stale and with the advent of Java 8, it's only now catching up in many ways. Competition is a very good thing.

　　NuGet

Another notable example is NuGet. This package is in Windows as a whole, especially in the development of Windows, and its management anecdotes are awful. NuGet solves a lot of problems and they do a lot of things right by borrowing a lot from Python and Ruby. Is there room for improvement? Of course. But I haven't felt much pain in using NuGet than some other package upgrades here or there.

　　Mono

For Mono's developers, I can't help but say it's great. What they have created is amazing. Without any official support and disregard for the potential legal problems hanging over them, they move forward and create an implementation that can actually replace the official runtime. I already have some applications running in the product, running in Mono for almost a year without any problems. is its product ready for the job? This may depend on your application (see "Mono" below).

　　CQRS and Event Traceability

It can be argued that one of the best things about. NET is that it is the birthplace of CQRS and has related technologies: event traceability. Even so, there is nothing new in Cqrs+es itself. As Greg Young will tell you, this is a bunch of 40-year-old raw materials that have been repackaged and renamed for us. I have some very serious problems with large code libraries, and when I used Cqrs+es 5 years ago, it completely freed up my domain. Cqrs+es is now named mode and its growth is obvious. This may be because. NET has been able to interact with other development platforms for reasons of sharing. In addition to this, most of the innovation is from the outside.

　　Disadvantages

The pros put aside first, let's see what went wrong and why I no longer use the. NET framework. The most motivating thing about my recent development platform migration is that I can use many of the best parts to drop the bad ones (see below).

　　Windows

As mentioned earlier, Windows is not a good player when faced with Web-based server software. Another real big problem with windows, in my opinion, is that traditional Windows developers are usually just good at windows, and when they leave their comfort zone they get lost quickly, which is not a problem for Linux developers. Computing is much more than Windows. One problem that developers can only operate on a single operating system is that it inevitably leads to a proliferation of Windows. In other words, Windows gave birth to Windows. There's no way to break this cycle.

On the other hand, *nix developers are usually familiar with multiple operating systems (linux,unix,osx,windows, etc.), the internal workings of an operating system, different distributions (based on Debian and Fedora based), window manager, Desktop Manager, file system, package management, Compile, recompile, repackage, command line "Fu" and so on.

One of my heart defects is the file system. NTFS is not a system-only file system, and it is hardly the best choice for any given task. Zfs,btrfs,reiserfs,ext* and so on, there are some cool features. I also like it. For various high-speed/transparent disk operations, you can create a loop device from BASH or create a RAM device. This does not happen in Windows-if there is no third-party software.

In the AWS cloud service, it takes more than 10 minutes to start a Windows machine. I can start a simple Linux machine in about 15-20 seconds. When it comes to the scale of cloud computing, it is important that it expands quickly, because 10-15 minutes is like eternity when scaling is important.

　　Visual Studio

In my other Thorn, when it belongs to Visual Studio. I need an IDE that is much more than expected to do any development, and this idea bothers me. It's just as big a resource as Windows pig. I have a core i7 3770K 3.5GHZ Desktop, with 16GB of memory and a maximum 4512GB SSD to compile. It almost blew up the Windows Experience Index, but Windows+vs is still slow. (yes, ReSharper makes it slower, but ReSharper is worth it.) )

Now I'm developing on the MacBook Pro, which has less CPU horsepower than my powerful desktop, but it runs significantly faster, and after a short learning curve, the UX (user experience) becomes infinitely better. In fact, I don't even use the mouse anymore-my hands are always on the keyboard or trackpad, I can manipulate my computer with gestures and let it respond-unlike in Windows.

One of the cool things about VS is the debugger. It's incredibly easy to view and use. Incorrect values are reported at the Watch window at intervals, resulting in more time spent debugging. At the same time, this is also a big negative, because the CLR default, multithreaded world makes me need a debugger in the beginning. No debugger is a relief experience, because it forces you to program in another way.

VS also has the bad habit of creating "csproj" and "sln" files. I hate this. Of course, C # must know what to compile and when to compile. I understand this. In Golang, references use very important statements in your code. If it is not a project file used in. NET, I might encode C # with a simple text editor and be more fluent in the language. These files also cause merge conflicts when using Git rebase operations.

Don't let me start talking about the difference between line breaks. I cannot believe that we are still dealing with such things until today. If the VS solution file ends with a Linux line terminator, you cannot load the solution by double-clicking it because the VS solution file parser cannot read it.

　　Source Code Control

Fortunately, I had already jumped out of the Microsoft Camp Source Control (versioning system VSS). I used subversion as early as 2000, after VSS lost my submissions countless times (the translator notes: Subversion is an open source version control system). After Git (translator Note: Git is open source version control system, content management system, etc.) appeared, I was fascinated with it. Unfortunately, the interface without Windows-is a typical encounter for me. Eventually someone created an interface, and I used that and didn't look back. Git is a very sharp knife, but when you use it correctly, it is a powerful and efficient tool. I used TFS in a small project (translator Note: Team Foundation Server, workflow collaboration engine), which is a monster-and all products from Redmond (Translator Note: Microsoft headquarters in the United States). It infects my project files and pollutes my source code directory. That's disgusting. No, thank you. Gave me any day with the command line git ... Or maybe it's sourcetree, if you need to get a little care from the GUI.

　　Mono

Yes, this is the second time that Mono is mentioned. Just as Mono itself is so amazing. In the world of. NET, it is still second-class citizens. Whenever I try to run anything important on Mono, I usually struggle with the loophole. Fortunately, I didn't feel uncomfortable about downloading code, finding problems, sending requests, and compiling code on Linux. But I can't remember how many times I've done it.

Yes, the CLR is a huge monster, and the same behavior for an unofficial application on different operating systems is a miracle similar to separating the Red Sea. But the truth is, I have to spend so much time filling in loopholes to make my code work correctly, it's hard to justify it.

Specific areas of Mono are also slow. Maybe it's not in the slow load, but for me the WEB server is the key. And it's very slow, and finally, it's slow to the bottom-even if it's a trivial thing. I think the good news is that it can only get better from here. I should also mention that Mono's developers may have forgotten about Linux, so I can't be too picky about it.

　　Iis

Maybe IIS is trying to do too many things for too many applications. It changes from being a Web server to an application host like the Java EE application container. It also stands on this side of the slow speed. I guess if I need higher performance, I should write my own Web server, but I really want to focus only on the code of my application. It might be nice to take advantage of Windows Event server, but Nginx (translator note: A high-performance HTTP and reverse proxy server, also a IMAP/POP3/SMTP proxy server) and other servers just don't like to produce in Windows.

A virtual JVM-based implementation, such as Netty (translator Note: A Java open-source framework provided by JBOSS), makes it easy to handle the volume of 650k+/requests per second. IIS runs a simple CLR application "hello,world!", which can be congested when it processes approximately 50K of requests per second. (Interesting digression, reference developers create a simple C # Web server with TCP sockets that can handle approximately 120K requests per second.) )

　　A narrow mind

There was a movement called alt.net in the last few years. The movement is all about finding a broader development community outside of ourselves as a whole and converging on different parts. Interestingly, that's a source of inspiration for StructureMap, AUTOFAC, NuGet, ASP. NET MVC, and many other tools. In traditional. NET circles, this movement has received a lot of disdain and contempt. I regard this as a great example of the widespread narrowness of psychology and laziness as a community as a whole. (It is true that some of them may disappear, and thus appear with different techniques, including REDIS,MONGOBD.) )

There are so many great programs out there. The idea that Microsoft is doomed to be the only right way is absurd. If that's the case, we're still using Visual Studio's design tools to drag and drop buttons and link elements to a WebForm interface, and we'll set the button and rely on ViewState to help us separate from the fear of terrible HTTP. The day I got rid of the last WebForm in one of my deployed code libraries was a glorious day to celebrate.

Who once thought that "network control" is a good idea? Apparently, I thought about it, because I drank kool-aid. (Translator Note: The beverage produced by Kraft means that it is intended or dangerous to do, has a negative meaning) and fully accepts it. It's biting me. Have you seen the ViewState of 2MB?

[Note: When I wrote this article, the original headline, "Why I no longer use. NET" means the entire. NET ecosystem. The title felt a little short so I updated to "Why I no longer use the. NET framework." I think that. NET as an ecosystem, including all the tools, engineering, platforms, organizations and many developers. That's why some of the more extensive. NET community elements are under attack in my article. ]

　　Performance killer

The use of locks and mutexes is strongly recommended in C,java and C # for typical multithreaded paradigms. There is a hidden overhead for locks: they are too slow to endure. Using the disruptor (unlocked ring buffer in the JVM [translator Note: Actually having an array of ordinal points pointing to the next available element]), you can easily handle more than 20M of events per second. Using any of the prescribed "best practices" in. NET, and any more than more than 10 transmissions per second, is considered decent and good performance, and at this point you only need bigger/better/more hardware devices. In fact, I've seen a third-party client library (Rabbit,couch,mongo, etc.) in the lock statement throughout the code. The default and preferred methods use locks, even if there is no concurrency in my code.

A lock-free, event-driven approach allows you to significantly reduce hardware and capital expenditures. Most applications can be easily run on two machines, and the second machine is only necessary for redundancy and failover, in case the hardware-related problem causes the first machine to be unavailable.

Another aspect of this problem is the traditional way of calling the network and disk subsystems: synchronous, blocking code. If you need more than one concurrent HTTP request, you need more threads. What most people don't know is that in order to maintain thread-out 1-2MB and context-switching threads, the CPU cores consume all the time bumps on context switches rather than doing real work. So now we get a hundreds of or thousands of thread in an application that takes up RAM and causes the CPU to stagnate. And there's a better way.

Netty/nio (JVM), Erlang,node,gevent (Python), and Go all support the use of event-driven subsystem operations (select/epoll[Translator Note: An extensible IO event handling mechanism in the Linux kernel]/kqueue[ Translator Note: The Extensible Event notification interface for FreeBSD]). This means that when waiting for packets to be tx/rx across the network, the CPU is free to do other, important work. Because of the maturity of the JVM, Netty can be thought of as the quickest to do the job, but I like the way Go uses Goroutines to manipulate this-it's simple, elegant, easy to reason, and there's no callback like spaghetti.

　　SQL Server

As a. NET developer, when you start a new project, there are some things you will usually do:

• Create a new solution
• Deploy it to Team Foundation Server (Translator Note: The core collaboration platform for Microsoft Application Lifecycle Management (ALM) solutions)
• Create the appropriate site entry in IIS
• To create a new SQL Server database
• Associating the Entity Framework in solution (typically a project created after 2010 years)
• Start designing your database and ActiveRecord entities

In most cases this is not the correct way to write code. Of course it might work in some cases, but as a "default schema" It's not what you want. Why did you make any technical choices before we even understood the problem areas? This is simply putting the cart before the horse.

Microsoft's ecosystem encourages everyone to use SQL Server. Interacting in Visual Studio and SQL Service or using SQL Management Studio (and its predecessor, SQL Query Analyzer) is so incredibly easy. This database-centric focus is part of the King James or the only right way. It makes you more obsessed with Microsoft. Vendor lock-In is always good for the manufacturer.

Why are we developing this? Why don't we consider the behavior of the application more than how it is stored? Now all of my projects use JSON-based key/value storage. With this feature, I can choose any storage engine I want, including SQL Server,oracle,postgresql,mysql,cassandra, CouchDB, Couchbase, Dynamo, SimpleDB, S3, Riak , BerkeleyDB, Firebird, hypertable, RavenDB, Redis, Tokyo cabinet/tyrant, Azure Blobs, plaintext JSON files in the file system, and more. Suddenly, we can start choosing the storage engine based on its merits rather than just being familiar with it.

Digression: Did you run SQL Server on the AWS RDS cloud? Don't do this. Of course it will work, but some of the simplest things, such as copying, do not exist. Articles are flooded with references to SQL Server that cannot work on AWS RDS.

Conclusion

Perhaps the two most important lessons I've learned in software development are:

• The importance of boundaries and encapsulation (in many forms)
• Pay the price to get the right model and abstraction

Many years ago I hated the word "model". Everyone throws it everywhere, it's a term so overloaded, it's hard to understand its meaning and why it's so important. In this case, I would just say that the model is a limited representation of the reality you want to encapsulate. Perhaps the simplest example is the Mercator projection of the globe. This is exactly one thing: navigation. If you use it on other things, it's not worthless. If you don't focus on paying the price to make the model right and encapsulate the business reality, then no technology can save you.

My biggest complaint about. NET is that "the only right way" is to steer you away from the ideal model and push you towards the direction of detail and technical flaws. Such attention leads to the technique of infiltrating blood and infecting the model, which eventually causes it to rot and deteriorate because it cannot adapt to changing business needs. When this happens, developers struggle and kick, like drug addicts, who shift from a new technology to another to expect the next powerful technology to heal their pain.

Technology itself is not a panacea, instead it is about trade-offs and choices. Only the right understanding of business behavior and encapsulating them into well-structured, easy-to-understand models to help keep the technology stack where it belongs-as an implementation detail.

And that's why I left the. NET Framework because it kept reasserting itself and wanting to being more than it Was:an Impleme Ntation detail. That's why I no longer use the. NET framework because it constantly reaffirms itself, constantly wanting to be more than it itself: an implementation detail.