Ask HN: Are there any startups willing to use the ASP.NET Core technology?
67 comments
> If not what are the reasons for a startup to stay away from .NET CORE?
I've been using .Net for over 10 years now, and just launched a new product on Asp.Net Web API + SQL Server + Orleans.
Whatever Microsoft says, .Net Core is not at all ready. The tooling and libraries are still undergoing major (and breaking) changes. You'll spend more time debugging it than your own code.
I (foolishly) tried to adopt it a year ago (RC), and again six months ago (1.0). Each time I ran into a critical bugs and omissions.
.Net Core will probably, eventually be great. It isn't yet.
Edit: Here's an example of the fun you'll have, published today: https://blogs.msdn.microsoft.com/dotnet/2017/01/30/announcin...
I've been using .Net for over 10 years now, and just launched a new product on Asp.Net Web API + SQL Server + Orleans.
Whatever Microsoft says, .Net Core is not at all ready. The tooling and libraries are still undergoing major (and breaking) changes. You'll spend more time debugging it than your own code.
I (foolishly) tried to adopt it a year ago (RC), and again six months ago (1.0). Each time I ran into a critical bugs and omissions.
.Net Core will probably, eventually be great. It isn't yet.
Edit: Here's an example of the fun you'll have, published today: https://blogs.msdn.microsoft.com/dotnet/2017/01/30/announcin...
I agree 100%. My last place was a 100% MS shop and while .NET core seems like it will be great we ran into endless problems, specifically with compatibility and existing libraries. We couldn't get anything more than a toy project to work.
I recommend anyone looking at .NET core to use Java for now. The languages are basically mutually intelligible and while java is a bit less syntactically pleasant it gets the job done, and the tools are quite mature. Arguably Java has, and has had, 99% of what .NET core is trying to achieve for many years. Using the right frameworks it's incredibly fast, multiplatform, and even serverless.
The biggest problem that you run into with Java is too much choice, the opposite of the .NET framework. Deciding which tools to use takes a fair amount of research because the ecosystem is so massive. I've been cutting my teeth on it for the past couple months and I would say go with these frameworks:
DropWizard Play Jersey
running on Grizzly, Jetty, or Netty depending on which project supports what.
Database-wise for ORM nothing beats Hibernate. Entity framework is basically a slower more confusing copy of hibernate, coming from someone that's used both. The main advantage of EF is LINQ which Hibernate can't quite match in theory but usually does in practice(the queries generated by HQL tend to be a lot less....stupid)
I recommend anyone looking at .NET core to use Java for now. The languages are basically mutually intelligible and while java is a bit less syntactically pleasant it gets the job done, and the tools are quite mature. Arguably Java has, and has had, 99% of what .NET core is trying to achieve for many years. Using the right frameworks it's incredibly fast, multiplatform, and even serverless.
The biggest problem that you run into with Java is too much choice, the opposite of the .NET framework. Deciding which tools to use takes a fair amount of research because the ecosystem is so massive. I've been cutting my teeth on it for the past couple months and I would say go with these frameworks:
DropWizard Play Jersey
running on Grizzly, Jetty, or Netty depending on which project supports what.
Database-wise for ORM nothing beats Hibernate. Entity framework is basically a slower more confusing copy of hibernate, coming from someone that's used both. The main advantage of EF is LINQ which Hibernate can't quite match in theory but usually does in practice(the queries generated by HQL tend to be a lot less....stupid)
>I agree 100%. My last place was a 100% MS shop and while .NET core seems like it will be great we ran into endless problems, specifically with compatibility and existing libraries. We couldn't get anything more than a toy project to work.
This has been my experience with MS in general. Initially everything seems great and you feel productive, but as soon as you decide to go off-road you lose all that you gained and more with buggy and poorly documented software.
This has been my experience with MS in general. Initially everything seems great and you feel productive, but as soon as you decide to go off-road you lose all that you gained and more with buggy and poorly documented software.
[deleted]
Standard .Net is acutally one the most well documented and stable platforms I've used.
I agree .net standard is super well documented.
What? Just use .NET standard, no need to switch to a wholly new language (unless of course if your initial goal was some kind of cross-platform requirement).
EF isn't great, but there are a ton of ORM frameworks that blow NHibernate out of the water. These days I'm just using Dapper for most projects. It's small, fast and very easy to use.
EF isn't great, but there are a ton of ORM frameworks that blow NHibernate out of the water. These days I'm just using Dapper for most projects. It's small, fast and very easy to use.
Dapper isn't an ORM in the same sense as EF and nHibernate, it's not bad, just different. There is plenty of room for both on a project.
My experience over the last few months has been v. good. Earlier (maybe even 6 months ago), my sentiment would have more mirrored that of the parent. The main downside at the moment is many of the packages on NuGet don't target dotnet core.
The above opinion is based on my experience developing a Kafka client library (I use OSX / VS Code) for Confluent https://github.com/confluentinc/confluent-kafka-dotnet as well as a substantial side project.
The above opinion is based on my experience developing a Kafka client library (I use OSX / VS Code) for Confluent https://github.com/confluentinc/confluent-kafka-dotnet as well as a substantial side project.
Can I ask what you ran into? I'm thinking about starting a side project with .Net Core for my API and React for my front end. I'm wondering if it's even worth it to use Core at this point or switch to Go or Node.
I personally hate node with all of my being, but Go is good stuff and Java has two very solid REST frameworks Jersey and Spring Boot. Depending on the project needs you could use DropWizard or Play which come with a really solid REST API framework builtin.
I was always partial to Pythons Flask as well
What did we run into? Tons of brokenness. Inability to use C# libs was the biggest problem, if you're trying to make anything significant you're going to have to roll your own everything. Java is the safest bet for large projects, I've never run into any issues finding a quality library to do anything. This is coming from a guy that's been a career C# dev for years and wishes he could defect to Java.
I was always partial to Pythons Flask as well
What did we run into? Tons of brokenness. Inability to use C# libs was the biggest problem, if you're trying to make anything significant you're going to have to roll your own everything. Java is the safest bet for large projects, I've never run into any issues finding a quality library to do anything. This is coming from a guy that's been a career C# dev for years and wishes he could defect to Java.
I have no clue if anyone really uses it, and it has a terribly un-googleable name, but the Java Spark Framework is the most beautifully simplistic REST API I have ever played with. It's the only time Java has ever felt like Node to me.
This is a little off-topic but can I ask how your experience with Orleans has been? And did you consider instead using Service Fabric Reliable Actors? If so, how did you choose between the two?
I work for a very mature startup, and recently led our first site on ASP.NET Core. The framework itself is very nice and very solid, basically a "do-over" of all the previous ASP.NET frameworks with the benefit of hindsight. Although there's been some new things to learn, I've been very pleased with how consistent and thought out the new ASP.NET Core is. We run the site in production.
Having said that, the tooling around ASP.NET Core has been an absolute disaster. They went 90% of the way with one mechanism (project.json), then decided to start over with a new mechanism (msbuild). While I believe it is ultimately for the best, the interim has been incredibly difficult to work with, as ASP.NET has been officially released now for ~8 months with neither method fully working. For example, in the current project.json stuff you cannot reference another project without first putting it into a Nuget pacakge.
Hopefully this will all be cleared up with the upcoming release of VS2017, but if you need something sooner and aren't interested in dealing with a lot of pain, I'd stick to ASP.NET classic for now.
Having said that, the tooling around ASP.NET Core has been an absolute disaster. They went 90% of the way with one mechanism (project.json), then decided to start over with a new mechanism (msbuild). While I believe it is ultimately for the best, the interim has been incredibly difficult to work with, as ASP.NET has been officially released now for ~8 months with neither method fully working. For example, in the current project.json stuff you cannot reference another project without first putting it into a Nuget pacakge.
Hopefully this will all be cleared up with the upcoming release of VS2017, but if you need something sooner and aren't interested in dealing with a lot of pain, I'd stick to ASP.NET classic for now.
Putting the words "ASP" and "Classic" that close together sent a chill down my spine. You're totally right about the tooling though. If I can't do File->New Project and get it to compile and run an empty project out of the gate, your doing it wrong. Every time I try I have to find some new forum post telling me how to fix my environment.
That's odd you should be able to reference anything in a sibling folder using a global.json in the parent folder to both projects.
They both also need to use project.json for their definition for this to work, otherwise packaging will have to be the solution.
They both also need to use project.json for their definition for this to work, otherwise packaging will have to be the solution.
Forgot to mention I also ported my personal side project to ASP.NET Core and had the same experience, it's a fairly decent sized live site.
https://communiroo.com
https://communiroo.com
StackOverflow.com [1]
I'm not certain I'd still call them a "startup" but they have been very open about their large use of .NET and the advantages it brings to bear.
[1] http://nickcraver.com/blog/2016/02/17/stack-overflow-the-arc...
Edit: More .NET information / usage.
[2] http://nickcraver.com/blog/2016/03/29/stack-overflow-the-har...
[3] http://nickcraver.com/blog/2016/05/03/stack-overflow-how-we-...
I'm not certain I'd still call them a "startup" but they have been very open about their large use of .NET and the advantages it brings to bear.
[1] http://nickcraver.com/blog/2016/02/17/stack-overflow-the-arc...
Edit: More .NET information / usage.
[2] http://nickcraver.com/blog/2016/03/29/stack-overflow-the-har...
[3] http://nickcraver.com/blog/2016/05/03/stack-overflow-how-we-...
I am a core dev at Stack Overflow. We do not work with .net core yet in production.
That said, we do maintain a number of .net libraries, such as Dapper or miniprofiler and we ported them to .net core (or we are in the process of doing that).
We are also contributing significantly, together with other community leaders, to the design and development of the .net core API.
This said, we have been having some of the pain that is mentioned in other threads. The framework is still incomplete and evolving, although a lot of what's coming out is excellent and very fast/modern.
That said, we do maintain a number of .net libraries, such as Dapper or miniprofiler and we ported them to .net core (or we are in the process of doing that).
We are also contributing significantly, together with other community leaders, to the design and development of the .net core API.
This said, we have been having some of the pain that is mentioned in other threads. The framework is still incomplete and evolving, although a lot of what's coming out is excellent and very fast/modern.
I'm pretty sure they use classic .NET on Windows and don't use .NET Core. It would likely be a very large effort for them to switch to .NET Core.
Yes, we launched our start up on ASP.NET Core - https://www.comparelearning.com.au/
(We're based out of Sydney Australia - not SF).
Overall, it was a positive experience and I think even with the current warts (in particular around tooling), it's a nicer stack than MVC5.
I blogged about some things we learned here: https://chad.tolkien.id.au/lessons-learnt-going-into-product...
(We're based out of Sydney Australia - not SF).
Overall, it was a positive experience and I think even with the current warts (in particular around tooling), it's a nicer stack than MVC5.
I blogged about some things we learned here: https://chad.tolkien.id.au/lessons-learnt-going-into-product...
[deleted]
Since it's been an hour and there hasn't been much response, I'll give my two cents.
I don't work for a startup. However, I do work in a small team of 3 developers, and have recently been faced with the decision of choosing a technology stack to start from scratch.
Before this decision, we were using PHP5; we were constantly putting out fires and couldn't ever get any actual work done because of this awful inherited codebase.
WARNING: OPINIONS AHEAD.
We decided to not go the .NET route for a few reasons.
Object-Oriented programming doesn't have a place in our hearts, as it does with a many OO-only developers. I find that object-oriented code is overly verbose and often difficult to maintain. For these reasons, we also wanted to avoid PHP, Java, and node.js. I feel like object oriented programming is more of an obstacle I have to overcome than a feature.
I hate to say it, but I just don't trust Microsoft. Yes, .NET on Linux is incredibly fast. How many years down the road until Microsoft decides to try getting their new Linux user-base onto Windows? They've done similar things before, and it'll take more than a year of a "Microsoft <3 Linux" advertising campaign to convince me to use one of their products in a Linux-only ecosystem.
Not only that, but .NET core hasn't been on Linux for a very long time. There isn't as much documentation that I can find on running, deploying, and maintaining a .NET / Linux application as many other technologies. (note: I could be wrong here after some more research, it's been out for a couple years, which is probably enough time).
We decided to go with Golang. It's a statically typed language that treats functions as first class citizens. It's not object oriented, doesn't have exceptions (yay), has an amazing standard library (including testing and benchmarking!), is easy to deploy (compiled & doesn't depend on a runtime like JVM or .NET core), and I feel like it's working with me, not against me. Plus half of our stack is already in Go (docker & kubernetes, and now Tyk).
I know that so many of you will absolutely disagree with me and that's fine. I'm not here to start fights, just giving my two cents. :)
I don't work for a startup. However, I do work in a small team of 3 developers, and have recently been faced with the decision of choosing a technology stack to start from scratch.
Before this decision, we were using PHP5; we were constantly putting out fires and couldn't ever get any actual work done because of this awful inherited codebase.
WARNING: OPINIONS AHEAD.
We decided to not go the .NET route for a few reasons.
Object-Oriented programming doesn't have a place in our hearts, as it does with a many OO-only developers. I find that object-oriented code is overly verbose and often difficult to maintain. For these reasons, we also wanted to avoid PHP, Java, and node.js. I feel like object oriented programming is more of an obstacle I have to overcome than a feature.
I hate to say it, but I just don't trust Microsoft. Yes, .NET on Linux is incredibly fast. How many years down the road until Microsoft decides to try getting their new Linux user-base onto Windows? They've done similar things before, and it'll take more than a year of a "Microsoft <3 Linux" advertising campaign to convince me to use one of their products in a Linux-only ecosystem.
Not only that, but .NET core hasn't been on Linux for a very long time. There isn't as much documentation that I can find on running, deploying, and maintaining a .NET / Linux application as many other technologies. (note: I could be wrong here after some more research, it's been out for a couple years, which is probably enough time).
We decided to go with Golang. It's a statically typed language that treats functions as first class citizens. It's not object oriented, doesn't have exceptions (yay), has an amazing standard library (including testing and benchmarking!), is easy to deploy (compiled & doesn't depend on a runtime like JVM or .NET core), and I feel like it's working with me, not against me. Plus half of our stack is already in Go (docker & kubernetes, and now Tyk).
I know that so many of you will absolutely disagree with me and that's fine. I'm not here to start fights, just giving my two cents. :)
> Object-Oriented programming doesn't have a place in our hearts,
Go is object oriented.
> I hate to say it, but I just don't trust Microsoft.
But you trust Google? well known for discontinuing products or abandoning them ( GWT?,... )
> It's a statically typed language that treats functions as first class citizens
Without some form of generics/type classes you can't fully take advantage of Go first class functions to do classical functional programming.
> It's not object oriented
it's completely object oriented, it has methods on values,composition through struct embedding and implicit interfaces for polymorphism. It ticks every box of a OO language.
> is easy to deploy (compiled & doesn't depend on a runtime like JVM or .NET core)
Go actually has its own runtime, it's just included in the binary resulting from the compilation.
> doesn't have exceptions (yay)
Go has panics which are exceptions.
I personally find Go useful but don't like the limitations of the language. And they are showing already with more and more untyped API ( context.Values(interface{})interface{} ). Go relies way to much on runtime behavior like type assertions for a so called statically typed language. Go basically asks the developer to do the compiler's job. Because the compiler doing its job would make it slow (?!?). So you find yourself doing a lot of copy paste, writing your own parsers, code generators and manifests to use go gen, use tricks that make code ugly, or just say "fuck" to types and use "interface {}" when you are tired of all that.
.net core isn't ready for production, but when it does it will support both F# and C# + a vast ecosystem of libraries useful for web development, gaming (unity), mobile and desktop apps (Xamarin GUI libs ...), while Go users will be stuck with that poor type system writing extremely verbose code because they believe that generic programming is bad.
Go is object oriented.
> I hate to say it, but I just don't trust Microsoft.
But you trust Google? well known for discontinuing products or abandoning them ( GWT?,... )
> It's a statically typed language that treats functions as first class citizens
Without some form of generics/type classes you can't fully take advantage of Go first class functions to do classical functional programming.
> It's not object oriented
it's completely object oriented, it has methods on values,composition through struct embedding and implicit interfaces for polymorphism. It ticks every box of a OO language.
> is easy to deploy (compiled & doesn't depend on a runtime like JVM or .NET core)
Go actually has its own runtime, it's just included in the binary resulting from the compilation.
> doesn't have exceptions (yay)
Go has panics which are exceptions.
I personally find Go useful but don't like the limitations of the language. And they are showing already with more and more untyped API ( context.Values(interface{})interface{} ). Go relies way to much on runtime behavior like type assertions for a so called statically typed language. Go basically asks the developer to do the compiler's job. Because the compiler doing its job would make it slow (?!?). So you find yourself doing a lot of copy paste, writing your own parsers, code generators and manifests to use go gen, use tricks that make code ugly, or just say "fuck" to types and use "interface {}" when you are tired of all that.
.net core isn't ready for production, but when it does it will support both F# and C# + a vast ecosystem of libraries useful for web development, gaming (unity), mobile and desktop apps (Xamarin GUI libs ...), while Go users will be stuck with that poor type system writing extremely verbose code because they believe that generic programming is bad.
A couple of additional points: Google and RedHat are the technical steerign group of the .net foundation (https://dotnetfoundation.org/about/tsg); Microsoft is a platinum sponsor of the Linux foundation, and by the way, google is "just" a gold member (https://www.linuxfoundation.org/members/corporate)
Can you elaborate on what you mean by Google abandoning JWT?
Maybe it was Google Wave? Not sure .. but Google definitely have a history of dumping products.
I think the parent meant GWT.
> is easy to deploy (compiled & doesn't depend on a runtime like JVM or .NET core)
.net core is exactly the same as go, it can be compiled to an exe that includes the runtime.
.net core is exactly the same as go, it can be compiled to an exe that includes the runtime.
I spearheaded the move from php(symfony) to .NET Core at the startup where I work.
We have had a pleasant experience so far. Performance is better across the board. Development is as fast or even faster in most cases. Deployment has also been simplified.
We started the port of our code base around October last year and released the update to our product at the end of December. During that time frame, we migrated from 1.0 to 1.1.
We are using some awesome libraries from the community and a few small ones we wrote internally.
Libraries include:
openiddict (for openid connect and oauth 2.0) rawrabbit (simple rabbitmq library) entity framework core with npgsql mailkit for smtp email sending
We wrote these library wrappers around third party services because they did not exist in a stable form: twilio wrapper nexmo wrapper gcm wrapper (now fcm wrapper) bitgo wrapper (hosted bitcoin wallet provider) blocker wrapper (blockchain explorer) openexchangerates wrapper api layer wrapper (mobile number verifications) ip-api wrapper
among others.
A service monitor for monitoring availability of third party services
We have also a spin off from our main product where we are using an private blockchain-like solution(openchain) for a niche market.
We have been very pleased with the overall experience using .NET core so far and we are looking forward to moving to 1.2.0 as soon as it is out.
The only real issue we've had is that the new signalr library does not have a stable release though we are using it in production. We've had to isolate it into a separate project but because of compatibility issues with 1.1 libs. Can't complain about hat though as we knew it is an unreleased pre-beta level library.
To manage the risk of using it, we try to follow the development closely and prepare in advance for any changes we can see coming.
We have had a pleasant experience so far. Performance is better across the board. Development is as fast or even faster in most cases. Deployment has also been simplified.
We started the port of our code base around October last year and released the update to our product at the end of December. During that time frame, we migrated from 1.0 to 1.1.
We are using some awesome libraries from the community and a few small ones we wrote internally.
Libraries include:
openiddict (for openid connect and oauth 2.0) rawrabbit (simple rabbitmq library) entity framework core with npgsql mailkit for smtp email sending
We wrote these library wrappers around third party services because they did not exist in a stable form: twilio wrapper nexmo wrapper gcm wrapper (now fcm wrapper) bitgo wrapper (hosted bitcoin wallet provider) blocker wrapper (blockchain explorer) openexchangerates wrapper api layer wrapper (mobile number verifications) ip-api wrapper
among others.
A service monitor for monitoring availability of third party services
We have also a spin off from our main product where we are using an private blockchain-like solution(openchain) for a niche market.
We have been very pleased with the overall experience using .NET core so far and we are looking forward to moving to 1.2.0 as soon as it is out.
The only real issue we've had is that the new signalr library does not have a stable release though we are using it in production. We've had to isolate it into a separate project but because of compatibility issues with 1.1 libs. Can't complain about hat though as we knew it is an unreleased pre-beta level library.
To manage the risk of using it, we try to follow the development closely and prepare in advance for any changes we can see coming.
> I spearheaded the move from php(symfony) to .NET Core at the startup where I work. We have had a pleasant experience so far.
Keep in mind that a rewritten system tends to be better than its predecessor, because you already know what (not) to do, so you can't really compare the two languages directly based on that.
Keep in mind that a rewritten system tends to be better than its predecessor, because you already know what (not) to do, so you can't really compare the two languages directly based on that.
While I do agree you in general, I believe the comparison is valid in this case.
The history of our product is like this.
The MVP was about 80% done in Laravel around the time I joined the company.
I joined the company as a symfony developer who was supposed to migrate the MVP to using symfony because "enterprise" and yadda yadda yadda as desired by our CEO.
We were successful in migrating to symfony 2 after about 2 months of work. From there, the system evolved over a few months going through multiple chaotic pivots. While the product worked, we had taken on a non-trivial amount of technical debt due to the rapid pace of evolution and numerous pivots.
As we were about to move to the next phase in our development, I spoke with our CEO about the technical debt we had incurred and possible ways in which we could shed it. Being a technical guy, he understood where I was coming from and allowed us a month to clean things up.
The plan was to migrate to symfony3 while cleaning up the mess we had created.
However, while were working on the update, we started experiencing some of the same pain points we had before including performance issues, composer memory issues, poor library availability, late or no feedback on github issues etc...
Since I had done a project using the rc1 bits of asp.net core and updated the application to rc2 bits after and had a good experience I suggested that we gave it a try.
The performance and dependency management issues went away. Development speed also improved as we had better tools to work with.
The history of our product is like this.
The MVP was about 80% done in Laravel around the time I joined the company.
I joined the company as a symfony developer who was supposed to migrate the MVP to using symfony because "enterprise" and yadda yadda yadda as desired by our CEO.
We were successful in migrating to symfony 2 after about 2 months of work. From there, the system evolved over a few months going through multiple chaotic pivots. While the product worked, we had taken on a non-trivial amount of technical debt due to the rapid pace of evolution and numerous pivots.
As we were about to move to the next phase in our development, I spoke with our CEO about the technical debt we had incurred and possible ways in which we could shed it. Being a technical guy, he understood where I was coming from and allowed us a month to clean things up.
The plan was to migrate to symfony3 while cleaning up the mess we had created.
However, while were working on the update, we started experiencing some of the same pain points we had before including performance issues, composer memory issues, poor library availability, late or no feedback on github issues etc...
Since I had done a project using the rc1 bits of asp.net core and updated the application to rc2 bits after and had a good experience I suggested that we gave it a try.
The performance and dependency management issues went away. Development speed also improved as we had better tools to work with.
Pre-launch startup here.
The tooling side of things is surely a pain, but it's getting better. I liked the project.json style, so i'm a little disappointed they are moving back to csproj.
Aside from that, it's a great, intuitive, fast framework that we use in production and I love it more every day. I'd chose it again and again.
Watch out for the lack of performance monitoring solutions available so far. Most of them haven't got support for .NET Core yet. New Relic does not.
The tooling side of things is surely a pain, but it's getting better. I liked the project.json style, so i'm a little disappointed they are moving back to csproj.
Aside from that, it's a great, intuitive, fast framework that we use in production and I love it more every day. I'd chose it again and again.
Watch out for the lack of performance monitoring solutions available so far. Most of them haven't got support for .NET Core yet. New Relic does not.
I never recommend up taking any MS stuff until the atleast the V2. Been programming in .net since 1.1 when i came over from java.
First off - get off the marketing bandwagon. You dont need .NET core. If you want to be "prepared" for .net core eventually, u can do this by using dependency injection, and isolating all your platform specific code - ie. Never use File. Directory. directly, always wrap them in a service, ie IFileSystemService. If u want to be mostly compliant (esp with reflection), use PCL projects as they are widely used and supported and are basically core compliant.
But yeh anyways, u need to be more specific as to WHY u need .NET core? My startup is using Owin + WebAPI + React, no need for ASP.NET/razor at all.
First off - get off the marketing bandwagon. You dont need .NET core. If you want to be "prepared" for .net core eventually, u can do this by using dependency injection, and isolating all your platform specific code - ie. Never use File. Directory. directly, always wrap them in a service, ie IFileSystemService. If u want to be mostly compliant (esp with reflection), use PCL projects as they are widely used and supported and are basically core compliant.
But yeh anyways, u need to be more specific as to WHY u need .NET core? My startup is using Owin + WebAPI + React, no need for ASP.NET/razor at all.
We are all built on .net core (alvin5.com)
We have had issues with Visual Studio and Tooling between betas, but now the platform has matured considerably and with the expected release of .net standard 2.0, I would say you can go for it for prod. C#/Editor/Tooling/Access-to-low-level is better than any platform I habe used. The new MS with the open/Azure/AI investments also seems ok. We feel like we are fit for the next 10 years with .net core.
We have had issues with Visual Studio and Tooling between betas, but now the platform has matured considerably and with the expected release of .net standard 2.0, I would say you can go for it for prod. C#/Editor/Tooling/Access-to-low-level is better than any platform I habe used. The new MS with the open/Azure/AI investments also seems ok. We feel like we are fit for the next 10 years with .net core.
Yes, we are using for some APIs at https://fastsalas.com .
- Azure hosted - BizSpark supported - .netCORE still on our beta environment, but we can say its mature enough to go to prod.
- Azure hosted - BizSpark supported - .netCORE still on our beta environment, but we can say its mature enough to go to prod.
I have been using it on a project and it has caused issues. However I think once .NET Standard is released adopting .NET Core won't be a problem. Plenty of other open source frameworks and libraries have similar issues.
Also it is important to realise that ASP.NET Core is not the same as .NET Core (asp.net core can run with .net core or .net 4.5/6).
https://blogs.msdn.microsoft.com/cesardelatorre/2016/06/28/r...
https://blogs.msdn.microsoft.com/dotnet/2016/09/26/introduci...
Also it is important to realise that ASP.NET Core is not the same as .NET Core (asp.net core can run with .net core or .net 4.5/6).
https://blogs.msdn.microsoft.com/cesardelatorre/2016/06/28/r...
https://blogs.msdn.microsoft.com/dotnet/2016/09/26/introduci...
I work in ex-startup(as in it's now highly profitable and successful for quite a few years) using traditional .net on azure.
.Net core has been in quite a bit of flux recently, so we've been avoiding it. However I the next year or so, I think we are going to adopt it.
.Net core has been in quite a bit of flux recently, so we've been avoiding it. However I the next year or so, I think we are going to adopt it.
Not a startup...but I do know of (I am consulting for them on the project) an established SaaS company that is impressively large and successful in their vertical that is porting from PHP/Postgres to ASP.net core and running it all on Azure
Biggest pain so far is the versioning FUD around .Net core, standard etc. That said, it is not really an issue.
From a risk mitigation perspective we are trying to lean on some other established and long tested things like Dapper as a micro-orm and staying away from fluid elements that we really want to use like SignalR until they settle down some.
We also went as green field as we could, no attempt to port code in the classic sense, ground up rewrite.
Biggest pain so far is the versioning FUD around .Net core, standard etc. That said, it is not really an issue.
From a risk mitigation perspective we are trying to lean on some other established and long tested things like Dapper as a micro-orm and staying away from fluid elements that we really want to use like SignalR until they settle down some.
We also went as green field as we could, no attempt to port code in the classic sense, ground up rewrite.
The better question would be "If you are a startup not tied to a linux stack would you use .NET (Not necessarily core)."
.NET Core is definitely not ready for prime time. It will be eventually. I believe many are confusing what solution is correct for the job.
Most startups are not going to be purchasing hardware for a hosted solution but instead will use cloud servers ala azure or aws heck even google cloud. .NET is supported on all of them.
.NET has great tool, is now open source both standard and core, widely supported, and unless you plan on running linux or mobile then why not?
Most startups are not going to be purchasing hardware for a hosted solution but instead will use cloud servers ala azure or aws heck even google cloud. .NET is supported on all of them.
.NET has great tool, is now open source both standard and core, widely supported, and unless you plan on running linux or mobile then why not?
We plan on moving to it sometime this year, from "old" dotnet. The timings is unclear because it depends on a few factors both on our side and from Microsoft/the community. For example we are on trend of using Entity Framework less in favor of dapper, so when the bits we are still using are fully supported by entity framework core that block will be cleared. Other big dependencies like a posgresql driver are already ready to go IMO. Tooling still isn't 100% ready in visual studio 2017 with web deployment being a key problem.
My advice would be to only use it now if you are starting from scratch and you have no business goals in the next 6 months (you are building an MVP and can take the hit of some random bugs in production). I know that at least one startup is using it for critical services, but they are also committed to fixing the dotnet core source code when they run into a problem and I believe are part of the reason for the good pref of kestrel (new web server), I think unless you are willing to do that you should wait a bit longer.
https://www.ageofascent.com/category/asp-net-core/
My advice would be to only use it now if you are starting from scratch and you have no business goals in the next 6 months (you are building an MVP and can take the hit of some random bugs in production). I know that at least one startup is using it for critical services, but they are also committed to fixing the dotnet core source code when they run into a problem and I believe are part of the reason for the good pref of kestrel (new web server), I think unless you are willing to do that you should wait a bit longer.
https://www.ageofascent.com/category/asp-net-core/
I first wonder what advantages are there in using .NET Core over anything else. I personally can't think of any and I'm a fan of c#. I would love to hear and this is not sarcasm as I started out in the ASP.NET world a long long time ago in a galaxy far far away.
There isn't really. If you wanted .Net Core you'd just use Java. Its been what .Net Core wants to be but has been for a very long time but with the tooling/libraries and such. I think the ship has sailed where there is a mass of devs out there chomping at the bit for C# on Linux. It'll be moderately successful because the .Net Framework userbase is large but most people have already reached for Java, Python or Ruby if they wanted to work outside of what that provided.
C# itself is a nice advantage, it's a pretty good language in wide use. Another would be the way modern stuff like dependency injection and packaging are baked in.
We're currently evaluating ASP.NET Core for a task manager with web UI for our .NET application (a data transformation tool). Our target audience is people with little or no technical background therefore we can't ask them to setup IIS. I looked at other web-servers in .NET stack (e.g. Suave), but nothing looked sufficiently lightweight and easy to use. Although, we're looking for ASP.NET Core over .NET 4.5.1, not .NET Core.
Self hosted nancyfx?
It's a good suggestion although at this point I don't see why it would be radically better for our case than ASP.NET Core. Our application has very few API endpoints and very low qps rate, so we don't need extensive routing or balancing. At the same time, since we have previous experience with ASP.NET the learning curve would be flat, while nancyfx is a new animal for us.
Amazon AWS uses .net core to provide c# as a language in AWS Lambda
http://docs.aws.amazon.com/lambda/latest/dg/lambda-dotnet-co...
Looks pretty ready to me.
Looks pretty ready to me.
I have launched a product - engagekit.com using asp net core. Initially was faced with some package incompatibilities during the beta stage. However, things have improved since RC2. It's my personal venture, hence, there is no need to consider the impact to the existing technical team.
> If not what are the reasons for a startup to stay away from .NET CORE?
.NET's text-to-speech isn't available in .NET Core, much less on Linux.
.NET's text-to-speech isn't available in .NET Core, much less on Linux.
Isn't that because .NET's TTS is just a wrapper around OS-provided TTS services?
The mistake was having these in the core framework to begin with. It's under the System.Speech namespace and not Windows.Speech or something more appropriate.
I'm the lead developer on a startup and all of our backend code is .net core (the frontend is still 4.5)!
I love it.
Feel free to PM for more info.
I love it.
Feel free to PM for more info.
Do you use EF at all? I'm interested in DNX but only EFC works on DNX, not EF6, and EFC is missing so much necessary functionality (Lazy-loading, Linq joins, Complex types, etc) it's a total no-go for the projects I do that all tie-in with databases.
Have you looked into nHibernate's support for .net core? It was always more flexible than EF anyway, I've been watching EF slowly fix their design mistakes to be more like nHibernate since version 1.
I haven't. I've been "loyal" to EF since the LinqToSql days, though I did use NHibernate heavily about 10 years ago. My main draw is the quality of the tooling and the nice EDMX model designer. The other draw is Linq support for compile-time type-safe queries (which I've noticed are compiled into good SQL with less mangling than I'd expect).
I am guilty of not staying on top of trends outside the MS camp. I does NHibernate now offer parity with EF? I just don't want to write SQL/HQL in strings.
I am guilty of not staying on top of trends outside the MS camp. I does NHibernate now offer parity with EF? I just don't want to write SQL/HQL in strings.
I think it has full linq support now (although could be wrong), but it's had type safe queries for many years now, almost as long as .net has had lambda expressions. It's very much like using EF without linq and just using the .Where syntax. I've used it on some projects that never had any HQL (which is an abomination). There are also a bunch of stuff like future queries that could make it much more performant than EF.
If I had a startup idea, yes.
Yeah we are using a .net project on Azure...I'm not sure about what the original question is meant to get at.
I just view .net as the staple of commoditized programming language. Go to Asia, Europe, they are always there. The "Java" of Microsoft and it's powering lot of stuff out there.
I just view .net as the staple of commoditized programming language. Go to Asia, Europe, they are always there. The "Java" of Microsoft and it's powering lot of stuff out there.
Why somebody would do something like that when there are python, ruby, Django and other cool stuff.
My startup is based on Windows, the .NET Framework, ASP.NET for Web pages, and ADO.NET for interacting with SQL Server. For the programming language, I'm using Visual Basic .NET -- as Kernighan and Ritchie, IIRC, stated in their C, the lanugage has an idiosyncratic syntax, which it turns ou I don't like. Since C# borrows some of that syntax, I prefer the more traditional (like PL/I, Pascal, Fortran, Algol, etc.) syntax of Visual Basic .NET.
When I selected this collection of tools, I seemed to see that there were some big, famous, successful, busy Web sites using these tools.
So far, I'm pleased with these tools but would like much better technical writing in the documentation.
Some things about the tools are really nice. So far my code is about 100,000 lines of typing and about 25,000 programming language statements. I typed in all the code using my favorite text editor (KEdit) and have made no use of Visual Studio or any other integrated development environment. For me, KEdit and Rexx as a scripting language work fine. For a scripting language, I may convert over to Microsoft's Power Shell, but I see no big need to do that now.
For organizing my work, I make heavy use of the Windows NTFS hierarchical file system -- it looks terrific, like some of Microsoft's and/or the industry's best software.
For the CORE, I have no more than 15 seconds of understanding what the heck that is. AFAIK, I won't be using the CORE, whatever the heck it is.
When I selected this collection of tools, I seemed to see that there were some big, famous, successful, busy Web sites using these tools.
So far, I'm pleased with these tools but would like much better technical writing in the documentation.
Some things about the tools are really nice. So far my code is about 100,000 lines of typing and about 25,000 programming language statements. I typed in all the code using my favorite text editor (KEdit) and have made no use of Visual Studio or any other integrated development environment. For me, KEdit and Rexx as a scripting language work fine. For a scripting language, I may convert over to Microsoft's Power Shell, but I see no big need to do that now.
For organizing my work, I make heavy use of the Windows NTFS hierarchical file system -- it looks terrific, like some of Microsoft's and/or the industry's best software.
For the CORE, I have no more than 15 seconds of understanding what the heck that is. AFAIK, I won't be using the CORE, whatever the heck it is.
Congratulations on completely failing to answer the question.
The question was about .NET Core, and I wrote about .NET which likely is closely related. It is likely that my use of .NET is also use of some of what is in .NET Core.
So, I answered based on what I know about .NET which should be relevant to the question.
Others can be more clear on what is the same, similar, or different between .NET and .NET Core. Then the parts of .NET Core that are also in .NET can get something of a clean bill of health from me.
So, I answered based on what I know about .NET which should be relevant to the question.
Others can be more clear on what is the same, similar, or different between .NET and .NET Core. Then the parts of .NET Core that are also in .NET can get something of a clean bill of health from me.
.NET core is a complete rewrite with incompatible API, it has little to do with the old .NET legacy framework. That's MSFT, one days hip API is tomorrows legacy cruft, you better stay on the edge or choose a stable non-MSFT open source solution.
Gads: I'm ordering the parts for my first server computer and about to put my code into alpha test, and already my tools are obsolete? Gads!
Sounds like .NET Core is aimed mostly just at the Linux world or the mobile world or people who want to be able to run the same code on both Linux and Windows. But I'm staying with Windows desktop and Windows Server -- already spent too much on getting good enough with Windows.
I have to suspect that Microsoft will continue to support Windows developers, including with VB.NET. If all Microsoft does with VB.NET is fix bugs, then fine with me. I'm not sure I have yet found a bug; so, fixing bugs in VB.NET should be easy enough for Microsoft.
I'm not really a programmer; instead I'm an applied mathematician and business man who also writes software. Since this thread is about startups, the core of my startup is some applied math I derived -- and then programmed, with a Web site for the users.
I would guess that if Microsoft wants all their major languages to run on both Windows and Linux, then that will be a lot of work and something for the future that I don't have to worry about.
While I don't like the C# C-like syntax, I could use C# if I needed to. IIRC there is a source code translator from VB --> C# and, maybe, if possible, in the other direction. So, I could convert my code to C#.
I suspect that I'm not the only developer who wants to continue with VB.NET and the .NET Framework as they have been for some years now. If the .NET Core is not relevant to such developers, then so be it, and that's not a good reason for Microsoft to abandon their old developers.
Sounds like .NET Core is aimed mostly just at the Linux world or the mobile world or people who want to be able to run the same code on both Linux and Windows. But I'm staying with Windows desktop and Windows Server -- already spent too much on getting good enough with Windows.
I have to suspect that Microsoft will continue to support Windows developers, including with VB.NET. If all Microsoft does with VB.NET is fix bugs, then fine with me. I'm not sure I have yet found a bug; so, fixing bugs in VB.NET should be easy enough for Microsoft.
I'm not really a programmer; instead I'm an applied mathematician and business man who also writes software. Since this thread is about startups, the core of my startup is some applied math I derived -- and then programmed, with a Web site for the users.
I would guess that if Microsoft wants all their major languages to run on both Windows and Linux, then that will be a lot of work and something for the future that I don't have to worry about.
While I don't like the C# C-like syntax, I could use C# if I needed to. IIRC there is a source code translator from VB --> C# and, maybe, if possible, in the other direction. So, I could convert my code to C#.
I suspect that I'm not the only developer who wants to continue with VB.NET and the .NET Framework as they have been for some years now. If the .NET Core is not relevant to such developers, then so be it, and that's not a good reason for Microsoft to abandon their old developers.
[deleted]
For the past couple of years, VB.NET is becoming a deprecated second-class citizen language. While VB is supported by DNX, it isn't supported by ASP.NET Core (which can run on either DNX or the full NetFx). So you might want to consider your future language decisions in light of this.
I would like to know if there are actual startups that are using or considering to use these technologies to build their product and services, especially in the San Francisco/Silicon Valley area?
If yes how do you manage (or plan to manage) the risks associated with these relatively immature technologies?
If not what are the reasons for a startup to stay away from .NET CORE?