What is .NET?
Who uses .NET?
Why developers like .NET?
Here are some stack decisions, common use cases and reviews by members of with .NET in their tech stack.
I use .NET Core to power my code signing service. The service is a client/server solution that enables secure and easy Authenticode, NuGet, and VSIX code signing.
On the server, it uses ASP.NET Core, Azure AD, and Azure Key Vault, to orchestrate and log all signing operations. Security is of top-priority for this application and ASP.NET Core makes it easier.
The client must run cross-platform, so it's packaged a .NET Core global tool, letting it run anywhere .NET Core does (on macOS, Linux, and Windows).
I chose .NET because allow me to use the most beautiful language that I ever work with "C#", also as a free cross platform development framework allows me to create any limitless tool for all possible devices in the market no matter if is an IoT or mobile devices, a cloud or web app or a AI/ML module, running native everywhere, you're able to do it using .NET and last but not least all folks in the community are open to help each other
I chose .NET Core (particularly ASP.NET Core) because it has some many benefits like: lightweight, built-in dependency injection and of course it's cross-platform. It’s a cross-platform meaning, my team and I can build, run and deploy whatever platform we’re using without any doubts.
I use .NET because it is one the platforms that has shown a lot of improvement and step ups in the recent years, with .Net Core improvements, being cross platform, extremely fast and going up the benchmark ladder release after release, etc. Also it has been open-sourced and they accept community contributions to shape the future of the framework.
There is also all sort of solutions available in .Net Core for all tastes. Your team likes Functional programming? no problem, use F# and still benefit from all the tooling and cross platform and the Core framework. Want to do Linux? no problem. Want to build mobile apps? use Xamarin and .Net. Want to build web applications with web assembly? use C#. Also sick of Visual Studio for some reason or using Mac? no problem, use Mac and Visual Studio or just go with Cross Platform Visual Studio Code.
Looks like .Net has had a lot of exciting movements in the past few years and I think is the best echo-system for any size software team at the moment.
Here are some stack decisions, common use cases and reviews by companies and developers who chose .NET in their tech stack.
Visual Studio Code worked really well for us as well, it worked well with all our polyglot services and the .Net core integration had great cross-platform developer experience (to be fair, F# was a bit trickier) - actually, each of our team members used a different OS (Ubuntu, macos, windows). Our production deployment ran for a time on Docker Swarm until we've decided to adopt Kubernetes with almost seamless migration process.
After our positive experience of running .Net core workloads in containers and developing Tweek's .Net services on non-windows machines, C# had gained back some of its popularity (originally lost to Node.js), and other teams have been using it for developing microservices, k8s sidecars (like https://github.com/Soluto/airbag), cli tools, serverless functions and other projects...
My first introduction to .NET was in the early alpha days, back in the early 2000s. In nearly the two decades that have passed since, it has matured into a very powerful platform. .NET as a platform has always had a great deal of polish that I haven't been able to find anywhere else. The ease of use and general technical excellence of the platform meant that I was delivering value at a consistent rate and with relatively little trouble.
That didn't make anything perfect, of course. The closed nature and the single platform that .NET was traditionally limited to took their toll. In particular, a bug fix that you found and reported might be fixed in the next release (18 months away) or not, with very little input or ability to understand what was going on.
And then the CoreCLR came along. In 2015, we made the decision to move the all of our applications and code into the CoreCLR.
That has been an amazing experience. The fact that I can dive into the source directly has made things so much simpler, and the fact that you can submit patches and interact directly with the core team has been an absolute joy. Our company has contributed several times (some code and mostly some interesting bug reproductions and perf issues) and has been continuously at awe at the level of commitment and (I have no other word) grace that we get from the team.
The fact that we can now run .NET code (and our product) on Windows, Linux, Raspberry PI(!) and Mac has been a great boon to us. We recently deployed our software to a whole lot of industrial robots running custom ARM boards. That is something that would have just been unimaginable every as much as five years ago.
In pretty much respects, the overall community, the core team, the engineering quality and the fact that it brings the polish that I've gotten so used to in environments where you are generally left cobbling things all by yourself means that it is my platform of choice for projects big and small.
The core Web application of Raygun is still a Microsoft ASP.NET MVC application. Not too much has changed from a fundamental technology standpoint. We originally built using Mono, which just bled memory and would need to be constantly recycled. So we looked around at the options and what would be well suited to the highly transactional nature of our API. We settled on Node.js, feeling that the event loop model worked well given the lightweight workload of each message being processed. This served us well for several years.
When we started to look at .NET Core in early 2016, it became quite obvious that being able to asynchronously hand off to our queuing service greatly improved throughput. Unfortunately, at the time, Node.js didn’t provide an easy mechanism to do this, while .NET Core had great concurrency capabilities from day one. This meant that our servers spent less time blocking on the hand off, and could start processing the next inbound message. This was the core component of the performance improvement.
We chose .NET because it was a platform that our team was familiar with. Also we were skilled enough with it to know many performance tips and tricks to get the most from it. Due to this experience, it helped us get to market faster and deliver great performance.
There’s no doubt WordPress is a great CMS, which is very user friendly. When we started the company, our blog wasn’t really our top priority, and it ended up being hosted on a fairly obscure server within our setup, which didn’t really change much until recently when things become harder to manage and make significant updates.
As our marketing team increased, the amount of traffic that found us through our content marketing increased. We found ourselves struggling to maintain our Wordpress install given the amount of theme updates, plugins and security patches needing to be applied. Our biggest driver to find an alternative solution however was just how slow Wordpress is at serving content to the end user. I know there will be die hard fans out there with ways to set things up that mean WordPress sites can load quickly, but we needed something a lot more streamlined.
We could see in our own Real User Monitoring tool that many users were experiencing page load speeds of over five seconds, even longer in worst case scenarios. Hugo is an open source static site generator that has enabled us to reduce load times by over 500% and make our blog far more maintainable across the whole team.
The Raygun marketing site runs on a .NET CMS called N2 but we plan to swap that out with Hugo as well in future.
#StaticSiteGenerators #SelfHostedBloggingCms #SupportSalesAndMarketing
When starting a new company and building a new product w/ limited engineering we chose to optimize for expertise and rapid development, landing on Rails API, w/ AngularJS on the front.
The reality is that we're building a CRUD app, so we considered going w/ vanilla Rails MVC to optimize velocity early on (it may not be sexy, but it gets the job done). Instead, we opted to split the codebase to allow for a richer front-end experience, focus on skill specificity when hiring, and give us the flexibility to be consumed by multiple clients in the future.
We also considered .NET core or Node.js for the API layer, and React on the front-end, but our experiences dealing with mature Node APIs and the rapid-fire changes that comes with state management in React-land put us off, given our level of experience with those tools.
We're using GitHub and Trello to track issues and projects, and a plethora of other tools to help the operational team, like Zapier, MailChimp, Google Drive with some basic Vue.js & HTML5 apps for smaller internal-facing web projects.
- Multiple languages: You can write .NET apps in C#, F#, or Visual Basic.
- Cross Platform: Whether you're working in C#, F#, or Visual Basic, your code will run natively on any compatible OS.
- Consistent API & Libraries: To extend functionality, Microsoft and others maintain a healthy package ecosystem built on .NET Standard.
- Application models for web, mobile, games and more: You can build many types of apps with .NET. Some are cross-platform, and some target a specific OS or .NET implementation.
- Choose your tools: The Visual Studio product family provides a great .NET development experience on Windows, Linux, and macOS. Or if you prefer, there are .NET command line tools and plugins.