Comment by rogihee | Hacker News Reader

Comment by rogihee | Hacker News Reader

I have been using MVC since version 2, but I will definitely will not use Core for my first project. There are so many breaking changes that I cannot imagine a 1.0 will cut it.

Also .Net Core is a clusterfuck built from an architectonaut ivory tower, just look at all the github issues around datatables. Yes, they are perhaps old and outdated but there is a million production items relying on it. DevExpress, open-source Excel serializers, etc etc. After a decade in the framework they have earned a spot, and outright refusing them to include does NOT help you gain traction. Because it contained anti-patterns du jour or something, whatever. I have a ton of production code relying on it, that is and has been serving me and my customers very well the past 10 years.

Also, the datatables discussion raised issues about the database schema. The proposal from a softie with a 5-min stab at a generic albeit typed system for covering all use cases surrounding the data and column types in a databases, is just mind boggling naive. What is the average age of the people doing .net Core?

People relying on features that aren't in .NET Core can keep using full .NET, and that's the intended result. Full .NET is going to be supported for the foreseeable future.

However for those projects that don't need them .NET Core is an interesting alternative especially with cloud deployment to Linux or a BSD host.

I work at a large .NET based company whose core product could not work on Core, but we certainly are considering it for newer projects. I'm also many years past being a junior developer.

Well, it's fine if features are ported later or in seperate packages or in some other/better format, but what I understood around System.Data is that vital pieces are missing, without a clear vision on how to deal with these. And if they are not added before 1.0 it may have far-reaching consequences. See my comment below for references.

The data story in general for Core is something they have repeatedly said is going to be worked on incrementally. Entity Framework Core is explicitly being sold as a "use only if you have to run on Linux/Mac" otherwise stick with EF6.

They're also making it very clear that features can and will be added/ported to .Net Core in the future based on what developers need and want. The thing they are absolutely keen to avoid is any breaking changes from 1.0 onwards - the plan is that you'll see 1.1, 1.2, 1.3 not a semver 2.0 for a very long time. To that end the legacy of DataTables is "how can we do this better" not trying to support decades of old libraries from the odd. The 4.6 Framework exists to do that and isn't going away if that is what you need.

Can you go into detail or point me to links about the database problems? I've not heard of this. Are they ditching System.Data entirely or something?

Datatables are not gonna make 1.0, and I think it is underestimated how much they are still in use:

Longread which gives I nice overview: https://github.com/dotnet/corefx/issues/1039

DbProviderFactory: https://github.com/dotnet/corefx/issues/4571

Schema stuff: https://github.com/dotnet/corefx/issues/3423 https://github.com/dotnet/corefx/issues/5024

I don't care that much for schema as I'm not an ORM writer, but I do have used Datables a lot as a convenient data-mangler type for importing legacy data, converting data etc. They may be "dirty", obsolete or whatever but they get the job done.

I read it all. Seems like schema is more-or-less getting taken care of.

But I don't get the big problem here. If someone _needs_ DataSet/Table, why don't they just pull in the reference source or Mono? That beats bringing that into the new Core API and avoids bloat. If it turns out it's too critical, put it in 1.1 or something.

Mono might work, but the reference source license doesn't permit you to do what you suggest. You can't copy the reference source code into your project and use it. They're very specific about what "reference use" means.

Reply on news.ycombinator.com