Comment by rubber_duck | Hacker News Reader

Comment by rubber_duck | Hacker News Reader

Parent Full thread

Honestly the lag between the ".NET core 1.0" and "tools 1.0" is kind of a joke at this point. Why advertise .NET core as 1.0 when it's obviously not production ready (in terms of .NET standards/expectations) almost half a year after the release. Why introduce all those breaking architectural changes in the "RC" versions ?

I've used .NET Core after 1.0 expecting it to be "production ready" for a new project, but so far from my expirience the 1.x releases have been like working with RC product and it should have been labeled as that with a clear note that the tooling is not done. RC versions should have been labeled as betas. There are so many moving parts (EF Core, .NET Standard Library vs PCL) and ambiguities (what tooling versions are supported in which VS, how does upgrading to a new preview affect old projects - can I safely use VS2017 and 15 on the same project, when 15 won't support MSbuild integration yet ?) it's a mess and it turns people off, even most .NET devs I know don't have a positive image of .NET core ATM.

A shame because it's doing some really exciting stuff, the communication is kind of disappointing because it makes it harder to convince other people it's actually exciting stuff.

The tools story that you raise is a real challenge, for users and for the team. I agree with you. As we were reaching RTM, we realized we had gotten ourselves wedged, pretty significantly. We had fortune 500 customers in production on our pre 1.0 RTM betas who were pushing hard for a 1.0 RTM runtime stack. At the same time, we came to the conclusion that the tools were not ready and needed significant changes (many of them breaking, as you call out). We decided to ship the runtime as RTM (now twice) and leave the tools in preview. The customers who were pushing hard are now happy (modulo the tools changes) and we're continuing to push forward.

If we were to do it all again with the knowledge we have now, we would skip all the changes and move directly to the final plan. We're sad about the resets, both to our users and because we were not nearly as efficient as we could otherwise have been. We're now on a much more solid plan and are working to land it.

Intrresting, I always assumed that the whole mess was caused by management pressure to ship something ASAP, I just didn't figure it was outside management pressure :)

Anyway .NET is too big for this to be detrimental and I'm only complaining because I like the work being done and the situation is turning off more traditional enterprise devs who have different expectations (eg. tooling in VS is still iffy but on 1.0 it wasn't even working when a colleague tried it). You guys still deserve a huge pat on the back - you used to be a pot smoking hippie if you used OSS in the .NET side of enterprise, now those people are contributing on GH, using git on VSO, using CLI tools that can be automated easily, etc.

Software is never done. At some point you have to ship something. As a .Net Core user I say that this is mature enough to get started, and to have feedback flowing to the developers to develop something the users actually want.

You may have more enterprise-like experience, thus expectations, but frequent releases based on feedback are usually better for the users than a project manager trying to guess the needs of the users by some magical, or other means.

I rather live with this kind of projects, but I have been a desktop Linux user for half a decade (when it was more painful), so I may be missocialized :D

As stated in another comment, I also think that the communication could be improved, but I'm hoping the best, the new more direct means of communication are really promising for me personally.

Reply on news.ycombinator.com