Yes, I'm hugely impressed by how much the teams at Microsoft have accomplished in the time, and how they have managed to change the direction of the platform without making a big mess. .NET Core could never be feature-complete on version 1, and I think that the folks involved have been very candid about the fact that it may take a while longer before it is able to support everything that many real-world projects need.

Look. People are voting me down, probably because they disagree with me. Let me explain where I'm coming from.

There's two types of programming ecosystem:

1) The wild west world. where there's no good tooling (IDEs, debuggers, etc), all libraries are provided by hundreds of random individual developers and of varying quality, vital tools (such as build systems) are a constant juggle of whatever's trendy at the moment, etc.

2) The world where there's a single comprehensive framework of extremely high compatibility managed by a single party, where tooling is excellent, where backwards compatibility is of paramount importance, and where everything you write is on a solid foundation that's not going to move out from underneath you.

If you want environment 1), you have a ton of choices. You can use Node.JS, you can use Python, you can use Ruby, you can use GoLang, Java, etc. If you want environment 2), you have exactly one choice: .Net. And in a year, based on everything I'm reading about .Net Core, you'll have zero.

The only saving grace is, being Microsoft, I can be confident that the .Net 4.5 stuff will work for at least another decade. Even if it's not the "trendy new hotness".

Maybe I'm a freak outlier, but I much much prefer the old Microsoft that wouldn't even think about releasing the product until it was 100% complete, tested, stable. I think they're moving in the exactly wrong direction, and driving full speed away from everything that made .Net such a great platform in the first place.

-----

Every time I've had to use a language where a lot of functionality is provided by "the community", it's been a constant cascade of buggy and badly-designed libraries. "The community" doesn't test their stuff before releasing it. Or the library works for the one tiny purpose it was written for, but isn't generic enough to be useful to anybody else. It's nobody's job to ensure quality or completeness, so it simply does not happen.

I'd rather have good code, even if I have to wait longer, than code from "the community".

The fix to "System.Drawing is not cross-platform" isn't just deleting it. It's to rewrite it so it is cross-platform.

I am sure there are other ways but I found using the native datavisualization library very useful and simple to use. I am one of these guys who do as little javascript as necessary.

A lot of clients want native PDF output for their reports. None of the PDF generating libraries I know of support running JS. So if you want the same charts in both, you need to generate the images server side.

If you want to draw the chart from scratch perhaps but I use a library to generate the chart then send it as an image to the client. Very few lines of code required in .net, no javascript required.

That seems valid now. But developing two runtimes in parallel doesn't seem that great of an investment. Plus there are already dotnet core contributions regarding portability, for example from Samsung, it seems reasonable to think that 2-3-5 years from now dotnet core will power Mono as well.