Wait a bit until the RTM, right now it's a mess, but in 6 month frankly, you can consider starting new projects with asp.net core.
I successfully wrote an app with asp.net core, mvc6 , entity framework (ORM) backed by Postgresql from scratch on Linux and deployed it on Heroku (with Mono, I wasn't able to run all my dependencies with CoreCLR). The app was fairly complex, with a big DB schema, it wasn't a toy and I did it in a week (without the tests).
It worked great and was pretty fast, I used the RC1 release though, the RC2 has a completely different tool chain so everything breaks. But aside from breaking API, great experience. C# is great.
Frankly, no question, for me it's a replacement for PHP+Symfony, Rails and Java on the long run. I initially wanted to move to Go but I wont, I prefer to take a small hit in term of performances and use a good language, rather than having optimal performances with a language I fight every second.
Performance was terrible, critical strange bugs were everywhere, and documentation was awful. But most importantly they would completely change important APIs every month. I'd have update almost every file in my project. And they would change the same API again the next month...
Rails, Django, Sinatra, Express, all started with a clear vision of what they wanted to be. This made all the little details support the frameworks big idea. You could use prerelease and beta versions and be fine.
.NET Core, though, hasn't decided yet whether it wants to be baboon or a firetruck.
You should never rely on early versions of something for critical, production projects without recognizing the risk.
Microsoft was open very quickly that they were making big changes and that RC1 was going to look very different from 1.0. There has been some chaos but it means we are all going to end up with a 1.0 release that is much better, rather than getting a breaking 2.0 release in short order afterwards.
It should never be assumed that a Release Candidate is going to make it into production, especially from an enterprise software vendor launching a new product. If the lasting legacy of this is more people taking that on board then that will be a good thing.
I think they messed up calling it a RC1 and leaving it as it is for so long. People started writing drivers and what not and were confident that the stack wouldn't change too much, now they are going to wait the official release (i.e. at least a year) because the trust is broken. They should have called it a beta and not let it live for like a year. You don't do that.
> It should never be assumed that a Release Candidate is going to make it into production
Of course, but release candidate also means that there wont be any significant change in the tooling or philosophy. RC2 has completely different tooling and the code is completely incompatible. It doesn't build up trust.
For example, working with Roslyn was a great experience even though we started our project when it was still in beta. Simply because the developers noted that even though it's beta the API is already fairly stable. There were a few things that still changed, but nothing that wasn't fixed in our code ten minutes later.
However I've shipped a Rails application that's started from a zip file I begged off DHH before Rails was even publicly available, and maintained it for years. I've used Django for a real app within a month or two of the first available Django release, and maintained to this day. Etc.
.NET Core goes beyond bleeding edge to point at which you start to wonder in your more crazed hours if it's actually just a parody of a poorly developed node.js library.
They clearly stated that it is in development and would drastically change as the development went on.
Aside from the ServiceStack dude making an extended sales pitch for his overwrought schlocky toolkit, the most disturbing thing in there is the massive dissonance between the experience of professional programmers and what really appears to be an endless throng of happy hobbyists who are excited to "follow the ride" of this thing through clumsy (but Open--yay!) development.
You get the impression that people at Microsoft are being rewarded for the number of issues being raised on GitHub for a not-ready-for-prime-time technology ecosystem--under the guise of "building a community." It's... odd.
Do you think hobbyists would really waste their time with Linux and Command Line tools when they can just download Visual Studio on Windows ? You seem to misunderstand why asp.net chose to go open source at first place.
> You get the impression that people at Microsoft are being rewarded for the number of issues being raised on GitHub for a not-ready-for-prime-time technology ecosystem, in the guise of "building a community." It's... odd.
They basically had to rewrite the entire framework + .net to run it on Linux. I'm pretty sure they are working quite hard and not wasting their time on Github social gimmicks to try to deliver the product in time. Why are you so angry against MS ? Because they break stuff? they always did that. Except now it's open source so if you don't like where it is going you can fork it.
Instead they got Redis limping on it and so decided to release everything as part of an extended tradeshow demo. But months later they realized that it can't handle files that end in a period -- after the community alerted them. This is an absurd way to approach building a critical compatibility layer. It's a waste of everyone's time.
But they're over-excited about community input now. They said they were listening with Windows 8, too -- and now Sinofsky's new career is writing LinkedIn articles all day, pretending he didn't drive a $100 billion ecosystem into the ground for three years. Likewise does the OneDrive team really need a UserVoice site to tell them the thing simply doesn't work? A terabyte an hour of error logs and telemetry isn't enough I guess.
When RC2 is released in the near future the upgrade path from RC1 currently isn't that bad as a one off process. That they produced something good enough that the rest of the .Net team wanted to make use of it as well is a good thing and is going to be of benefit to .Net devs in general.
As for upgrades looking back through things like Rails early release notes there were plenty of "you'll need to do these things to upgrade" notices.
But working with .NET core was about an early rails year's worth of breakage every month.
Also, there is a new API-only mode in Rails 5 which could come in handy for your case (API development): http://edgeguides.rubyonrails.org/api_app.html
On the other hand, for the next year at least, non-IIS hosting for ASP is second class. You can host sites on Linux, but there will be gaps. When you upgrade the site, do you need to turn that server on and off again, or it manage the change in excusables automatically?
The opensource library scene for .net is not as good as for some other languages.
Finally, Microsoft has a plan for making money out of ASP.Net Core, and if it seems like a route to run ASP applications somewhere that isn't Azure, we are missing something.
I expect the "issues" to be something related to development process and running the code in prod.
Plus more generally it is a pre-1.0 product which, while having a go live licence, means it isn't for everyone especially if you're not happy potentially doing some digging through code to work out undocumented features.
The OP doesn't say if they are a C# dev or a Ruby dev or neither. To be honest that is likely to be the biggest driver of things. Both are good enough that it isn't really worth paying the price of switching between two ecosystems for.
I would suggest looking into Django and Django REST Framework. I'm loving using it in my off-time. I'm personally not a fan of Ruby, so I wanted to through my personal suggestion out there.
If you're considering deploying to Windows/Azure then .NET Core is a little more temping but otherwise...
[1]: https://blogs.msdn.microsoft.com/dotnet/2016/02/10/porting-t...
I would go with rails or alternatively Java with jax-rs if you want something somewhat similar to .net.
EDIT: typo.
Hell, if you're choosing the latter get yourself an Azure description, build a new Mobile Services host and off you go -- Everything you would ever want is included out of the box (including client to server datasync), you only need to figure out what storage and other services you want to use (e.g. Microsoft's PN service for easy crossplatform notifications) and bring along your business logic.
For production use, wait a while to use .Net Core.. It's awesome, but not there yet.
Why .NET Core instead of just .NET? Is Linux hosting of the backend a requirement?
Even if it's not, I wouldn't put myself in the corner by being dependent on windows hosting. Linux on the server is a norm nowadays.
Also, .NET Core is obviously the future. Yeah, they will keep Full .NET around, but... It's the same story as it was with WebForms vs MVC. WebForms is still supported, but who starts new projects with it?