Why Microsoft's .NET Core is the future of its development platform It is just over a year since Microsoft announced the open sourcing of .NET Core, a cross-platform fork of the Windows-only .NET Framework. The .NET Framework is not going away, but it is now apparent that the company's focus is on .NET Core as the future of its development platform. Microsoft's .NET Framework goes back a long …
"Microsoft has ported its Entity Framework Object-Relational database library to .NET Core, but some developers avoid this for performance reasons."
Horrible performance (I've seen analysis which showed 4x to 7x slower than optimized SQL) is one reason to avoid EF. But the bigger issue is the lack of need for it to exist in the first place. It introduces an unnecessary logical black box into your code. If one were to build something from scratch with best practices (admittedly it rarely happens) then one would write backend code in C# and database code in SQL. At the end of the day EF is merely a SQL code generator. Instead of using EF you're much better off just writing proper SQL. EF makes code more readable and "easier" to develop at the expense of know WTF is happening in the db. Have you seen an EF manual? It's not simple. Why not just learn SQL and do a proper job?
How about because as a commercial programmer you spend half your life writing boilerplate code that reads data from a database into memory or writing it back (CRUD - Create, Read, Update, Delete). SQL databases don't map themselves naturally into an app, so you need a translation layer to save you all the work of doing it yourself. There are other products out there that do the same kinds of thing (nHibernate for example) and, done properly, it makes it easier to build apps using TDD principles. You don't need to use EF to build queries for you (it can call stored procedures for example), but it can do so if you're in a rush to get something out of the door.
+1 for Steve.
I have been a .net developer for 12 years now... I can count on one hand the number of times that we have been given time by the business to "do things right".
Given the choice of taking a performance hit when reading and writing to the db and use ef or waste a week writing stored procedures to read, write, update from each and every table in the database... I know what I'd choose... That's a week I can spend making sure the rest of the app works.
If the sql is sub optimal and it affects the app then yeah, maybe that ef query needs tweaked... At an extreme it needs replaced with a sproc, but the majority of stuff... Select * from users where name = 'fajita hertz' ... Let ef do that.
The other bonus with a norm of course is schema changes, new table? One new class in the model, one line in the context, ready to be used. (Probably some dto mappings too).
Straight ado? Well that's a new class (same one probably), then a sproc to select and a method in the dal, a proc to delete and method in the dal, and an insert/update proc and method in the dal... Then the same dto mappings etc..
I've been places where the DBAs ban the use of ef because it's slow and the sql is crap but the apps are riddled with inline sql, there are no indexes on the data, and what procs do exist are worse than ef would produce...
I know not everyone likes ORMs but if you ask me the benefits out weigh the downsides.
"I've been places where the DBAs ban the use of ef because it's slow and the sql is crap but the apps are riddled with inline sql, there are no indexes on the data, and what procs do exist are worse than ef would produce..."
So you're suggesting that the future belongs to slower-but-consistent code, generated by EF and the like? If so, the result of that would be an eventual decline in status and pay for those coders using it. Is that bad or good?
If programming was only about performance we'd still all be using assembler. Modern development is about cost and maintainability rather than absolute performance. Most of the time you can throw more hardware at the problem for far less than it would have cost to do it the traditional way.
Yes, that's exactly the sort of thinking that allows the managers to sleep at night while their devs continue to labour to bake in performance problems that can't actually be solved by "throwing hardware" at it. By the time the realisation dawns that the issue is actually the fundamentally broken application architecture, it's too late.
Premature optimisation is often a waste of time. But neglecting performance considerations can be equally costly and often far more so. A dev spending an extra day optimising a routine to get a 10% performance improvement costs an extra day. Not spending that day can lead to thousands of man hours in lost productivity and additional support servicing as a consequence of the results.
So why does this happen so often ?
Unfortunately it is all too easy to see how and why this occurs.
The PM and the accountants can measure the additional cost of that extra day and so will make sure that cost is not incurred. The downstream consequences of saving that cost don't fall at the feet of the PM or the accountant. It is somebody else's, later problem and is often impossibly difficult to attribute to any particular cost centre, let alone one that can be held accountable for it.
The cost of producing software is easily measured and is more or less directly proportional to the amount of time spent producing it. The cost of producing bad software is much harder to measure and the costs of the consequences much harder to directly attribute to the corners cut during it's original creation.
John, no that's not what I'm saying.. What I'm saying is that my experience has been that companies don't care so much about optimising queries to save a few ms what they care about is getting features into their apps, to make them money.
The point that was making isn't that ef is better than optimised SQL, it's clearly not... What I was saying is that given a cost benefit analysis a lot of companies will side with the quicker to develop slightly slower to execute option in a lot of cases... This is why nhibernate and ef exist... And why ef is now on version 7...
The SQL code that the EF generates is C R A P.
Any dev worth their pay packet will optomise their queries and maximise the DB throughput but thinking about things like Locking and everything else that and half decent dev does as a matter of course
We did a POC with this and gave up when the end result was 200% slower than the decently coded App,
Just like most other frameworks. Easy to code for but total shite performance. Perfect for Indian coding monkeys?
No political correctness issues here! After working extensively with such individuals in the past, my almost universal, knee-jerk reaction to them these days is general distrust, on multiple levels. (There were a few counter-examples, of course.) They now have to actually EARN any trust and respect for their "skills" from me, because I will no longer give them any benefit of the doubt here. But they're not the only group that I generally treat that way these days, either.
You don't have to use EF to generate the SQL for your queries. You can just use Entity Framework to load data from stored procedures, There are a very long list of reasons for creating strongly typed classes that represent a view of data in a database. EF is just a means of bridging one application domain with another.
@micktion
Exactly, everyone above is going on like the options are handwritten SQL OR EF... Anyone who has worked with EF knows that it can be used perfectly well with sprocs, my preference is to use EF for everything, and replace any particular areas with sprocs if performance testing shows there may be issues..
Valid points, however...
An ORM Like EF allows you to build a database driven app that's decoupled from any particular RDBMS. As such it's very popular for moduralization and open source projects, etc.
If you build an app on EF, you can move it from MS SQL Server to PostgreSQL to MySql, etc just by changing your connection string and running "dotnet ef database update" in a command line.
If you write all the SQL yourself, you have to maintain separate sets of SQL for each RDBMS you want to support in your product. Most cases, the product just get's limited to one specific RDBMS e.g. "Microsoft SQL Server".
As such, using EF cuts costs drastically in development time, and it's a lot faster in dotnet Core than it was previously on .Net with EF6. EF7 is pretty quick compared to EF6 in my opinion.
Also, there are Micro ORM's like PetaPoco which are really fast and give the same benefits of EF in terms of being able to support multiple RDBMS's. However with peta poco you are basically just making tables and not using any views or stored procedures.
Android is a mess... Java based on Linux.
Java is what it is.
.NET is the worst Microsoft facade ever. A poor clone of Java. An absolute mess. They managed to create more messed up incompatible versions of the .NET virtual machine than Sun and Oracle did to Java over the years.
Quite the contrary. They managed to sort out the mess that is Java, a language & framework that grew through evolution rather than clean design. As a result it's got all sorts of legacy horrors in it and a distinctly illogical way of doing some things.
Microsoft had the advantage of comming second, and poaching a rather good framework designer from Borland when it came to dot net.
@d3vy
I think he said that JAVA had all kinds of legacy horrors, not .NET. Unless I'm misunderstanding everyone, which isn't beyond me. I cant speak from experience coz I'm not a Java programmer. I cant think of that many horrors in .NET. Some legacy stuff but its not particularly horrid.
> I think he said that JAVA had all kinds of legacy horrors
Not really, except java.lang.Calendar and various web/ORM monstrosities.
It's just a language, and pretty straightforward, too. Though of course once you have tried languages like Groovy you see its annoying verbosity and inflexibility, which can only be said to be due to its "first order" nature (everything you write means exactly what it says, and that's all you get, and the compiler ain't gonna give you a break by inferring anything to help you write code faster).
you can't determine the type of a generic at run time.
But is it a real problem? Apparently not. Indeed, it is a solution to a problem:
"It's funny when Java users complain about type erasure, which is the only thing Java got right, while ignoring all the things it got wrong."
Erasing means we've reasoned (so let's erase)
So if we want to reason about our programs, we're strongly advised to not employ language features that strongly threaten our reasoning [i.e. runtime-usable parametrized type information, or indeed any type information]. Once we do that, then why not just drop the types at runtime? They're not needed. We can get some efficiency and simplicity with the satisfaction that no casts will fail or that methods might be missing upon invocation. Erasing encourages reasoning.
Of course, you may want to go crazy-hog self-modifying (which I like to do, too), in which case you do want runtime information and maybe inject a method or two into a class because you feel like it or want to process freshly obtained WSDL in a particularly elegant way , but then compile-time checks are useless, which may be unacceptable depending on the application.
OTOH, if clear reasoning and proving of code is demanded, I would strongly suggest to look into functional languages as well as logic programming languages. Things are pretty good on that front.
Not being able to tell if an object passed at run time is of the type your generic was designed to handle isn't a problem? Me thinks you do protest too much.
There are all sorts of gnarly bits to the language because it grew that way. Collections were an afterthought, so most but not all array-like objects now implement them. It's the exceptions that bite you in the foot.
But is it a real problem? Apparently not.
Sigh. This is just an elaboration of a specific case of the ancient (in computing-theory terms) argument that runtime evaluation interferes with static evaluation. Yes, it does. Obviously. You don't have to drag Curry-Howard in to demonstrate it (though it's worth understanding in its own right).
And that argument is just a specific case of the more general purity-and-practice argument. Do we want to write programs that are provably correct? Or do we just want to write programs that solve the problems we have to address, and have that process produce a usable output within some reasonable time horizon? Because the track record of developing real software that's provably correct is, put frankly, crap - despite a great deal of really extremely impressive research into the matter.
And yes, much of that is due to external factors, like the stubbornness of programmers and management, requirements for interoperability with existing and third-party systems, economic limitations, and the like. But the fact remains that championing an attribute of a language solely on the fact that it favors purity over practice is a contentious, and for most people rather dubious, argument.
right but wasn't it designed to be incompatible with anything other than Windows? I mean they didn't like Java because it ran on everything, they tried to make an incompatible Java which only ran on Windows, "Does anyone remember Windows?" was a famous quote of Bill Gates when MS developers were planning Java applications. At that meeting Microsoft become incompatible with Java on other platforms.
So, why in the world would anyone who is not happy being tied to Microsoft Windows care or want to touch the MS .Net stuff? Their horse is still tied to Windows so no stripes changed there.
"A poor clone of Java"
It's not, and seeing is believing. Java has always been (and for me it always will be) the "Internet language". Just take a look at the package names and you quickly see where I'm going with this. Of course another side to this was its platform independence.
.NET has always been a Windows platform so in that regard its not even trying to mimic Java. Another mistake you're making here is that .NET consists of both C# as well as Visual Basic (VB.NET). You mean to target C#, not .NET as a whole. It helps to get your facts straightened out before criticizing you know...
But yeah, the only thing which C# and .NET have in common is that there is a runtime required to use anything which was build upon it and that's it. If you know Java then you don't automatically know C#. You'll spot some vague similarities, sure, but that's where it ends. C# (.NET basically) supports standards which Java can only dream about at this time. Take for example something so simple yet so effective as partial classes. One class can be spread out in multiple files.
Maybe not useful for regular programming logic, but it's a godsend for webcoding (ASP.NET). I can split up a webpage in multiple files; thus leaving me with markup (HTML/CSS) and logic (the code file). Not having to wade through stuff which the webdesigners manage to muck up? Or not having them play webcoder while all they do is design? It's awesome.
And that is one small example which is impossible with Java. Even today. Even though this was already possible with C# and .NET as a whole 3 years ago. Longer even.
If you have a "thing" that converts C# into native code, then that "thing" is called a "compiler" and you haven't got .NET anymore
You're confusing .NET with the CLR, and the CLR with an intermediate-code VM.
The CLR already has "a 'thing' that converts [IL, which is what C# is compiled into] into native code". It's called the JIT compiler. When IL is JITted, that doesn't magically make it not .NET any more.
VB.NET , VB legacy, C# is just bad programming. How to deliver low quality products. That is what is wrong with that.
C/C++, C99, Objective-C, Swift, Assembly, in-line Assembly and then SQL queries written by hand with no frameworks is what a real programmer should be able to use. And for 3D gaming and simulations of any kind being able to understand and code OpenGL, DirectX, CUDA.
Nowadays professional 3D engines like Unreal Engine are available with visual Blueprints and script languages but anyone knowing how to properly code in C++ and in-line Assembly and the graphics APIs thanks to full access to its source code could do anything and achieve maximum performance extending what the engine programmers did whenever its needed for any project.
That is what is wrong with being a limited programmer that can't understand how to do the hard stuff.
Joerg.
Ha REAL PROGRMERS input their code directly into the front panel of the mainframe.
Get back into your box you bloody quiche eater.
:)
Ps. Using high level languages does not make us not real programmers.. Many people can do everything you mention but choose high level languages because as has been pointed out optimisation isn't the be all and end all... Alot of people want quick development and maintainable code so they can get deliverables out on time.
I wore out one of the rotary switches on our IBM 360 from doing console debugging... First thing in the morning I used to depress the Lamp Test switch just to make certain that none of the address or data indicators wasn't burnt out.
Hexadecimal forever!
Really?
My experience of the last 15 years has been pretty consistent with the exception of a bit of a switch from web forms to MVC half way through.
Win forms .net c#
Asp.net .net c#
Silverlight xaml .net c#
WPF .net c#
In fact their pushing of c# and .net has been very consistent...
We did an analysis of our product to see whether it would run on .NET Core, using the available ApiPort tool: http://jnbridge.com/blog/why-we-cannot-yet-support-net-core. We weren't surprised that our own stuff wouldn't yet work on .NET Core (as the article says, migrating existing .NET applications to .NET Core is likely to be difficult, if not impossible), but looking at the unsupported APIs, I'd be surprised if many non-trivial, enterprise applications could be created for the new platform. We can only hope that will change, and the number of missing APIs will go down over time, but that remains to be seen.
I suspect that Dotnet Core will never replace the full (legacy?) Dotnet. It may get used in some cloud deployments that were written from scratch to use it, but most of the existing business applications will either have existing dependencies (often through third party code) that require the full version, or the application developers won't be willing to foreclose the option in future versions of using stuff that requires the full version, and so will say the Dotnet Core is "not supported", even if it does work.
I think the main thing that Microsoft is looking for is to have a cut down Dotnet running on Ubuntu, Centos, etc., that they can use as a low priced option for specific workloads on MS Azure to compete with Amazon on price.
I'm not sure how well this will work. Mono was a huge flop on Linux servers, with there being little to no interest in C# or Mono amongst Linux/BSD developers, aside from some demo projects (now largely abandoned). I can't see why this would be any different for Dotnet Core.
On Linux, there is a Java community who do everything in Java and there is a "native" Linux community who do everything in Python, Ruby, NodeJS, Go, C++, Rust, etc. The Java community use Linux, but they largely sit in their own isolated Java world. They will still go on using Java until the Sun expands to engulf the earth. The "native" Linux community by and large have zero interest in either Java or C#. They are not going to start using either.
So for who will want to use Dotnet Core, that basically leaves traditional Microsoft developers who want to start dipping their toes into the open source world, or who are looking to shave some of the cost off off cloud hosting costs. In other words, it can be looked at as giving Microsoft a lower tier offering for price sensitive markets that they can use to try to persuade developers to stay with them by offering development tools that are at least someone familiar to them.
>it can be looked at as giving Microsoft a lower tier offering for price sensitive markets that they can use to try to persuade developers to stay with them
+1. This is not going to attract non-MS devs.
Has anyone ever noticed that most "appliances" run linux? Linux solves two things: proprietary licensing becomes commercially quite easy and cheap as long as your product isn't modifying GPL code; and the appliance vendor can control the platform. Not having someone else own part of your stack is important. Did you see what happened to Novell? Did you see what happened between Stonesoft and Check Point? Do you see Apple's attitude to anything which is similar to their own stuff? Remember Windows' support of HPFS?
The aggressive pursuit of profit means no-one trusts their suppliers and partners not to compete with them. What happens to .net core when it becomes so successful on linux that it starts making a significant impact on Windows sales? Ah yes, the libraries start to slip out of sync, suddenly things start to get a little easier on Windows than other platforms. Windows gets a few "released first" features and as a .net dev, you have the choice of a second rate platform or specifying Windows as the deployment platform.
Linux isn't just about being a different OS, its a different approach to IT. The open-source is not just a development and support model, its about people with common problems helping each other. That's a world away from MS' business practises. If you just replace "Windows" with "Linux" but the business model remains the same, you probably aren't going to gain the benefit you'd hoped for.
.Net Core seems to be a little late by about 10 years. My navel, not always accurate, leans towards writing code that with minimal effort is inherently cross platform. Slurp is about making everyone do it the Winblows way not necessarily the most competent or standards compliant way.
Wait, hold on. I think I'm getting getting it - "Slurp" is "Microslurp" right? Instead of Microsoft?
OH MY FUCKING GOD THAT'S HILARIOUS YOU ARE SO CLEVER
And "Winblows" is like "Windows" but you call it that because, right, it "blows"?
YOU ARE A GENIUS!
Oh wait, not genius. Cretin. That was it.
Grow the fuck up.
That's one of the standard strategies used by Microsoft. They already did that with the web, now they try to do that with the rest of computing.
Here the strategy is clear, they want to have more .net people working under Linux. Those people usually have the C++/C#/Java mindset which, which has been criticised extensively in many places. In short it leads to projects having lots of code, which take lots of developer resources to develop and lots of resources to maintain. This is why, while you can develop a simple unix flavoured operating system in less than a man year, C++/C#/Java projects typically take large teams and just go on and on for ever.
This is in a way very dangerous of the free software community. While it can currently afford to sustain projects with entities like the Mozilla Foundation, nobody knows what the future will be. Without a large (non profit) company like Mozilla, projects like Firefox would probably quickly disappear as you need large teams to maintain them. In contrast, the BSD people show that it's possible to develop and maintain a whole operating system with just a hand full of people.
Of course, will I spend mindshare on it? Probably not (maybe buy the "in Action" book, which will then rot behind a stack of old Avril Lavigne CDs, but I digress) . I'm currently at the state where I begin to retch whenever I hear the "this is the next big thing, invest in this" anthem rise its discordant tones as frankly practically nothing currently "in production" is working particularly well or even at all. But F# is nice.
It is open source though, so it is always possible that the community may come up with GUI frameworks.
How open is this? Is it Open or open?
And would your trust a guy in a GAP hoody? Reeeally???
Now, you will excuse me, I'm trying to compile the XSB compiler here.
I applaud Microsoft's efforts to be more relevant by making their development software more appealing for the Cloud Computing/Containerization, Big Data Analytics, Mobile applications and Data Center operations, all areas where Linux and Apple in Mobile completely dominate at this time.
However .Net Core provides only a small and limited benefit to those who demand robust and truly complete “cross platform” development solutions, since the environment dtill depands to a substantial on Microsoft only applications like SQL Server, Sharepoint middleware, Hyper-V and other software that do not competently or adequately support Docker Containerization or platform agnostic Virtualization stacks that work more intuitively and adhesively together.
Unless and Until Microsoft's .Net core can compete effectively with Eclipse, Python, QT based and other robust, powerful and especially more secure and complete nulti-platform development ecosystems, Microsoft will only and continually play catchup.
Already Free/Open Source Software (FOSS) based Cloud Computing of Amazon AWS and various Openstack based services comprise combined 73 plus % sales versus about 12% for Microsoft Azure, and the Mobile scene is even more dispersed with Microsoft holding about 5% sales versus more than 93% for Apple iOS and Android/ChromeOS combined, and continues to grow.
Why would any level headed development project now base their effort on faultering technology base?
AMD used to use .NET for their Catalyst drivers (ie. full desktop app). They've now switched to Qt, gone from 8 second application start-up to 0.6 seconds, with the added bonus of now being fully cross-platform, even on the desktop. It's not hard to see why they made the switch, and .NET Core won't be of any help.
There are better alternatives to .NET, even if your only platform is Windows.
Microsoft .NET as a platform which has an open source component and is an evolving platform. Not only .NET Core is an open source, but also managed by a well-managed body namely, the .NET Foundation. In short, future of.Net is really bright. To know more, keep reading.
The future of .NET Core is also very bright and exciting. Many people and organizations are getting involved in.NET Core.
This is a cross-platform, fast, lightweight, updated, open-source framework for developing mobile, Web, and Windows applications and services that can be deployed and run on Windows, Linux and Mac operating systems.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
