.NET languages are amazing. It's fairly easy to program in any style in C# now: imperative, or OO with massive inheritance hierarchies, or even functional-only with LINQ and things like switch expressions and primary constructors (mentioned in the article). C# now also has top-level statements, so no need for `public class Main { public static void main() {}}`.
The .NET standard library is by far the biggest I've ever seen—it's not merely 'batteries included'; it's 'everything under the Sun included'. NET also comes with a straightforward package manager for third party libraries (NuGet).
There are a variety of development environments available—VS2022, VS Code, Rider, command-line tools. Speaking of command-line tools, the `dotnet` bootstrapper makes it really easy to get started with any sort of project.
The compiler and static analysis tool set, Roslyn, is itself increasingly written in C#, having migrated from C++. With NET 7, code can now be compiled to native binaries ahead-of-time, and there's even an experimental LLVM backend[1].
One can write code for almost any use case (except perhaps embedded) with .NET. It really needs to be used more.
And needless to say: .NET is open-source and cross-platform.
I concur! Coming from Java world to .NET/C#, I was initially very sceptical of Microsoft's offering. Now, I expect to be paid a heavy premium if I ever have to go back to Java.
Also, there's a ton of world class third party tooling around .NET that really makes everything better.
Shout-out to LINQPad for saving me literally 100s of hours on testing, queries and quick POCs.
Is .NET a viable platform for cross-platform data analysis and visualization tool development now? Python is king here, it sure has everything, but I'm tired of its non-type-safety.
From what experience I've had, C# is a very ergonomic language, with good balance between an expressive static type system and do-whatever-when-needed dynamic features.
Another language I'm looking at is TypeScript, since everything's in browser anyway, and browsers got fast.
Plus many "embedded" scenarios have an OS capable of running regular .NET as well.
The problem of .NET versus other alternatives like Java (as an example), is the 2001 - 2014 legacy of being mostly Windows focused, which hinders the choice of libraries and tooling versus those alternatives.
For example, coming back to the embedded scenario, .NET has nothing comparable to PTC, Aicas or the endless variants of JVMs shipping on copiers, electricity meeters, M2M gateways and such.
I tried C# recently again, after having migrated to use JS/TS and Node.Js as my main stack for years.
What put me off was how cumbersome it seemed to be. Maybe I’ve just been spoiled by JS/TS, but where are the following features (which I believe to be quite basic)?
- Union types
- Object literals
- Functions as first class citizens
I get that C# is supposed to be a purely OO language, but in this day, the most useful languages are multi-paradigm.
People like to dish on JS/TS but IMHO one reason why they became so popular is overlooked. There’s just something so direct and unceremonious about programming in JS, and with TS you get strong expressiveness as well.
Until and unless the .NET languages have that it will be hard to pull me away.
How so? Do you mean it doesn't support ephemeral ftrace-based tracing or something? That seems unlikely to be true given core CLR features like reflection as well as Microsoft's extensive history of embedding .NET into services and devices.
My biggest problem with .NET, is how fast it's moving. Slow down! Also increase LTS support timelines. Default is 3 years, which is just not enough. Ubuntu LTS is the model to follow.
I'll second the request for increasing the length of LTS! While it's technically 36 months it turns out to be 24 to 28 months in practice because my shop will not upgrade our projects immediately -- and we do have to update our projects since we have a TON of AWS lambda functions in C#. After the last "Oh crap, the deadline to upgrade" death march we started having serious discussion about dropping C# for new lambda development and going with Python. If the LTS were extended to at least 5 years, or there was some sort of bug-fix-only support beyond the current 3 year TLS then the ground-swell toward python where I work would stop.
I think these are just growing pains. The migration from 6 to 7 to 8 is going to be more fully representative of how .NET is going to work. There was a lot of stuff with Core 2/3 that wasn't fully fleshed out and is generally why we avoided building anything in it. And yes, 4.8 is still getting security updates, but .NET 4.x is effectively dead and almost no new projects should be built in it (yes Winforms people I hear your screams)
Agreed! the move from 2.x to 3.x was pretty easy, but going to 6.x was painful, and why have a LTS that lasts only slightly longer than the follow-on 7.x version? Half of each cycle we don't know if we should update, to which version, or just wait.
Microsoft employee here. We were "urged" to use .NET 6 last year when starting a new project internally and the transition has been quite hard. The learning curve is extremely steep. It took us almost two weeks to work out some basics because the online documentation, a lot of open source projects and what the latest .NET templates look like are very different. The team spends a lot of time figuring out how something is done in .NET and we stumble over a lot of online advice which is dated or plain wrong because it dates back to .NET Framework or .NET Core times. .NET 6 seems to be different to .NET Framework and different to .NET Core in the way it handles even simple things like namespaces, using declarations and other language features. Maybe when we get good at it we will like it but so far it's been quite a journey and I'm not sure we would choose it again if we didn't have to.
This is just the decay of knowledge over time and laziness combined.
From a quick glance internally, the overwhelming majority of repos are using an antiquated build/packager that while it might have been useful a decade ago is a productivity killer today.
The newer build / package system used publicly is light years ahead and provides a boon in productivity.
Not really sure why so many services in MSFT still run .NetFramework when “just” migrating over can lead to sometimes order of magnitude increase runtime performance and decreased resource consumption.
I think one of the real reasons is internally, most of the leads aren’t aware of it. There should be more evangelizing of the .NET team across the different orgs
> .NET 6 seems to be different to .NET Framework and different to .NET Core in the way it handles even simple things like namespaces, using declarations and other language features.
Those are C# language features, not necessarily .NET 6 features:
This feels really incorrect or perhaps you're a complete novice to .NET or fresh out of school. .NET 6 is line-for-line compatible with nearly everything you'd encounter online. The core API hasn't changed, there's certain edges that have changed from .NET Framework to .NET, including where certain libraries might have been moved but I've migrated multiple projects now and the only issues were typically related to either using very old frameworks that had changed their API or changes to build systems (which admittedly are tedious).
I find this extremely surprising. What were you using before?
I've done multiple Framework 4.8 to .NET 6 migrations and the issue is almost always compatibility with new libraries. Language issues rarely if ever come into play.
What C# language version were you working with before?
Post author here -- There are lots of resources for teams within Microsoft. Please reach out and we can help you speed up that process. Contact info in my profile.
We work super closely with teams and often post about their fine work and even finer results on our blog.
After .NET Core I was one of the people that really thought "maybe Microsoft has changed at least in the .NET division, let's not be prejudiced, if they want to make FOSS let's give it a try". But of course they showed their hand and I'd have to be a fool to believe this is a platform worth investing myself in.
It's even killed my enthusiasm with F#, despite it almost growing into its own thing after how much MS has neglected it.
People get caught up on versions of the framework. Handy guide:
.NET Framework (v1.0-4.8) - 4.8 Currently still supported, but don't build anything new in it. It only gets very minor updates. Not cross platform (Mono can help, but euuughhh), slower, stuck with C# 7.3.
.NET Core (v1.0-3.1) - Out of support, transition period between .NET Framework and modern .NET. Cross platform support, some support for AOT compile.
.NET (v6-8) - LTS every other version starting with 6, 36 months LTS, cross platform, magnitudes faster than .NET Framework. Successor to Framework and Core. Many features of .NET Framework have been abstracted to NuGet packages.
.NET Standard (v1.0-2.1) - Interop API specification for Framework/Core/.NET. Write a class library that targets .NET Standard and you can use it in more than one runtime. You'll see a lot of NuGet packages target Standard. If you're writing a class library you should probably target Standard.
"Core" products/packages - Many packages/libraries have been renamed to include "Core" in the title. ASP.NET Core, Entity Framework Core, etc. These are libraries/packages that only have implement their core functionality. For example, ASP.NET Core has some basic implementations, but does not include things like Web API, MVC, Authorization, Razor. If you build an ASP.NET Core project you'll be pulling in a lot of packages based on your needs. The features/libraries are more atomic and less reliant on a full version update of ASP.NET Core.
Like others have chimed in here, it's really not so bad to step away from the Microsoft products while using .NET. I have worked on a solution where all the devs used MacOS running a mix of VS Code and Rider to develop on, while hosting the application on Linux with a PostgreSQL data store. None of it was difficult to setup and configure. There was consistently a bit of an on-ramp for devs who had never used MacOS before (a really common trait among .NET developers), but other than that things were peachy.
I run .NET trading and data manipulation apps on Linux 24/7, can't complain. Modern .NET is very cross-platform and was one of the motivators for my moving to Linux. I could write my code in Rider/VSCode and deploy without a lot of fluff in the background.
I didn't really encounter any issues when moving from 4.8 to Core 1.1 then 3.1 then 6. There were a few cases where a library wasn't available the first few days but that was mainly during the 4.8 transition. After that, most libraries migrated to using .NET Standard.
Probably the only gotcha when moving cross-platform was platform specific code. In my case, I had some very minor code to resize a console window when run interactively that was exploding.
Overall, I can't speak for the desktop story but services, command-line apps and web-apps were literally copy/paste binary to run or git clone and open in Rider to edit.
Lots of good feedback in this thread so far that I agree with. If I'm doing Windows stuff, yeah, it's great. Lots of new good stuff. My next project is going to be Azure based, so I'm sure I'll be back in the world a bit.
There's a lot you can do with C# with .NET, game engines, cross-platform tools and so on.
Why? Simple. It's literally the fastest framework in the world. This save us a ton of money on cloud costs.
I can support millions of DAUs with a 3-node K8s cluster running .NET7 instead of a 50+ node cluster with Python or node. Just simpler, without npm package dependency hell, and produces a nice clean single file executable.
The bulleted list in the design point section is intended as a high-level summary. We may do another post later that is part-way between the bulleted list and the post as a whole. Perhaps that would be the last post in the series.
I've been one of those purist native-first guys, but as of late I brought up a custom GUI app in question of days with XAML studio and winUI gallery (0 background), piloted with Powershell (in Notepad++), and it does the trick. happy to enter WPF and .net, almost by accident.
I’ve been serving as an architect for two teams, one working with Spring Boot and the other with .NET Core.
Quite frankly, they seem to be roughly equivalent in everything, from features to developer experience to performance. We ended up preferring Flyway for db migrations for both platforms.
[+] [-] delta_p_delta_x|3 years ago|reply
The .NET standard library is by far the biggest I've ever seen—it's not merely 'batteries included'; it's 'everything under the Sun included'. NET also comes with a straightforward package manager for third party libraries (NuGet).
There are a variety of development environments available—VS2022, VS Code, Rider, command-line tools. Speaking of command-line tools, the `dotnet` bootstrapper makes it really easy to get started with any sort of project.
The compiler and static analysis tool set, Roslyn, is itself increasingly written in C#, having migrated from C++. With NET 7, code can now be compiled to native binaries ahead-of-time, and there's even an experimental LLVM backend[1].
One can write code for almost any use case (except perhaps embedded) with .NET. It really needs to be used more.
And needless to say: .NET is open-source and cross-platform.
[1]: https://github.com/dotnet/runtimelab/tree/feature/NativeAOT-...
[+] [-] harshalizee|3 years ago|reply
Also, there's a ton of world class third party tooling around .NET that really makes everything better. Shout-out to LINQPad for saving me literally 100s of hours on testing, queries and quick POCs.
[+] [-] bob1029|3 years ago|reply
If you really want to get a sense for how broad the APIs are today:
https://learn.microsoft.com/en-us/dotnet/api/system.numerics...
I've been working on a custom game engine in .NET for about a year now, and I still haven't had to pull down a 3rd party nuget.
[+] [-] com2kid|3 years ago|reply
It is very hard explaining to Java programmers why Java is so bad. Country of The Blind (https://en.wikipedia.org/wiki/The_Country_of_the_Blind) is very apropos.
C# is an incredible language that makes it easy to express a multitude of ideas from a wide range of programming paradigms.
[+] [-] meibo|3 years ago|reply
[+] [-] ansgri|3 years ago|reply
From what experience I've had, C# is a very ergonomic language, with good balance between an expressive static type system and do-whatever-when-needed dynamic features.
Another language I'm looking at is TypeScript, since everything's in browser anyway, and browsers got fast.
Guess I just like Anders Hejlsberg.
[+] [-] pjmlp|3 years ago|reply
https://www.wildernesslabs.co/
https://sandervandevelde.wordpress.com/2022/12/15/fun-with-n...
Plus many "embedded" scenarios have an OS capable of running regular .NET as well.
The problem of .NET versus other alternatives like Java (as an example), is the 2001 - 2014 legacy of being mostly Windows focused, which hinders the choice of libraries and tooling versus those alternatives.
For example, coming back to the embedded scenario, .NET has nothing comparable to PTC, Aicas or the endless variants of JVMs shipping on copiers, electricity meeters, M2M gateways and such.
[+] [-] brainzap|3 years ago|reply
[+] [-] prmph|3 years ago|reply
What put me off was how cumbersome it seemed to be. Maybe I’ve just been spoiled by JS/TS, but where are the following features (which I believe to be quite basic)? - Union types - Object literals - Functions as first class citizens
I get that C# is supposed to be a purely OO language, but in this day, the most useful languages are multi-paradigm.
People like to dish on JS/TS but IMHO one reason why they became so popular is overlooked. There’s just something so direct and unceremonious about programming in JS, and with TS you get strong expressiveness as well.
Until and unless the .NET languages have that it will be hard to pull me away.
[+] [-] lostmsu|3 years ago|reply
[+] [-] chasd00|3 years ago|reply
[+] [-] hummus_bae|3 years ago|reply
any
use case (except perhaps embedded) with .NET.
How so? Do you mean it doesn't support ephemeral ftrace-based tracing or something? That seems unlikely to be true given core CLR features like reflection as well as Microsoft's extensive history of embedding .NET into services and devices.
[+] [-] aninteger|3 years ago|reply
https://dotnet.microsoft.com/en-us/platform/support/policy/d...
We've still got code running on .NET Framework 4.8 (supported, I think?)
We've still got code running on .Net Core 3.1 (now out of support)
We are moving to .NET 6, but given our own 6 month release cycles, and layoffs, I'm not sure we can keep up.
[+] [-] mikece|3 years ago|reply
[+] [-] pathartl|3 years ago|reply
[+] [-] skeeter2020|3 years ago|reply
[+] [-] throwawaymsft29|3 years ago|reply
[+] [-] whb07|3 years ago|reply
From a quick glance internally, the overwhelming majority of repos are using an antiquated build/packager that while it might have been useful a decade ago is a productivity killer today.
The newer build / package system used publicly is light years ahead and provides a boon in productivity.
Not really sure why so many services in MSFT still run .NetFramework when “just” migrating over can lead to sometimes order of magnitude increase runtime performance and decreased resource consumption.
I think one of the real reasons is internally, most of the leads aren’t aware of it. There should be more evangelizing of the .NET team across the different orgs
[+] [-] Mindless2112|3 years ago|reply
Those are C# language features, not necessarily .NET 6 features:
• https://learn.microsoft.com/en-us/dotnet/csharp/whats-new/cs...
• https://learn.microsoft.com/en-us/dotnet/csharp/whats-new/cs...
"global using" is a code readability regression, so I wish it had not been added and I'd recommend against using it.
[+] [-] dudeinhawaii|3 years ago|reply
There's no learning curve.
[+] [-] ivraatiems|3 years ago|reply
I've done multiple Framework 4.8 to .NET 6 migrations and the issue is almost always compatibility with new libraries. Language issues rarely if ever come into play.
What C# language version were you working with before?
[+] [-] runfaster2000|3 years ago|reply
We work super closely with teams and often post about their fine work and even finer results on our blog.
https://devblogs.microsoft.com/dotnet/category/developer-sto...
[+] [-] dustedcodes|3 years ago|reply
Shameless plug, but I've tried to cover a lot of this here:
https://dusted.codes/dotnet-basics
[+] [-] hu3|3 years ago|reply
What kind of project? GUI? Web? Infrastructure?
And what was the experience of the team with .NET when you were urged to use .NET 6?
[+] [-] skrowl|3 years ago|reply
[+] [-] mixedCase|3 years ago|reply
After .NET Core I was one of the people that really thought "maybe Microsoft has changed at least in the .NET division, let's not be prejudiced, if they want to make FOSS let's give it a try". But of course they showed their hand and I'd have to be a fool to believe this is a platform worth investing myself in.
It's even killed my enthusiasm with F#, despite it almost growing into its own thing after how much MS has neglected it.
[+] [-] pathartl|3 years ago|reply
.NET Framework (v1.0-4.8) - 4.8 Currently still supported, but don't build anything new in it. It only gets very minor updates. Not cross platform (Mono can help, but euuughhh), slower, stuck with C# 7.3.
.NET Core (v1.0-3.1) - Out of support, transition period between .NET Framework and modern .NET. Cross platform support, some support for AOT compile.
.NET (v6-8) - LTS every other version starting with 6, 36 months LTS, cross platform, magnitudes faster than .NET Framework. Successor to Framework and Core. Many features of .NET Framework have been abstracted to NuGet packages.
.NET Standard (v1.0-2.1) - Interop API specification for Framework/Core/.NET. Write a class library that targets .NET Standard and you can use it in more than one runtime. You'll see a lot of NuGet packages target Standard. If you're writing a class library you should probably target Standard.
"Core" products/packages - Many packages/libraries have been renamed to include "Core" in the title. ASP.NET Core, Entity Framework Core, etc. These are libraries/packages that only have implement their core functionality. For example, ASP.NET Core has some basic implementations, but does not include things like Web API, MVC, Authorization, Razor. If you build an ASP.NET Core project you'll be pulling in a lot of packages based on your needs. The features/libraries are more atomic and less reliant on a full version update of ASP.NET Core.
[+] [-] davidfowl|3 years ago|reply
[+] [-] jalino23|3 years ago|reply
just gift me swift + vim + linux for webdev please! no xcode and no visual studio.
[+] [-] isanjay112|3 years ago|reply
Can you elaborate on this? I develop Web API's on Linux using Rider and deploy on AWS, I never felt any pain.
[+] [-] artimaeis|3 years ago|reply
[+] [-] cebu|3 years ago|reply
[+] [-] dudeinhawaii|3 years ago|reply
I didn't really encounter any issues when moving from 4.8 to Core 1.1 then 3.1 then 6. There were a few cases where a library wasn't available the first few days but that was mainly during the 4.8 transition. After that, most libraries migrated to using .NET Standard.
Probably the only gotcha when moving cross-platform was platform specific code. In my case, I had some very minor code to resize a console window when run interactively that was exploding.
Overall, I can't speak for the desktop story but services, command-line apps and web-apps were literally copy/paste binary to run or git clone and open in Rider to edit.
[+] [-] runfaster2000|3 years ago|reply
[+] [-] garbagecoder|3 years ago|reply
There's a lot you can do with C# with .NET, game engines, cross-platform tools and so on.
[+] [-] david_allison|3 years ago|reply
I develop on a Mac (JetBrains Rider) and deploy to Ubuntu. .NET is truly cross-platform at this point.
[+] [-] CyanLite2|3 years ago|reply
I can support millions of DAUs with a 3-node K8s cluster running .NET7 instead of a 50+ node cluster with Python or node. Just simpler, without npm package dependency hell, and produces a nice clean single file executable.
[+] [-] runfaster2000|3 years ago|reply
[+] [-] sochen|3 years ago|reply
[+] [-] runfaster2000|3 years ago|reply
[+] [-] tifadg1|3 years ago|reply
1. guaranteed type safety;
2. blazor, so no more backend/frontend, js.
3. vast standard lib, so less dependencies;
Reservations I have would be that:
1. it's owned by microsoft and I'd be running on linux, so isn't it a bit of a mouse-toying-with-a-cat type of a situation?
2. libs may be aimed at enterprise - will need to provide lots of boilerplate to get minimal functionality?
[+] [-] jesuslop|3 years ago|reply
[+] [-] rbanffy|3 years ago|reply
Quite frankly, they seem to be roughly equivalent in everything, from features to developer experience to performance. We ended up preferring Flyway for db migrations for both platforms.
[+] [-] dang|3 years ago|reply
Update to the .NET language strategy - https://news.ycombinator.com/item?id=34690969 - Feb 2023 (145 comments)
[+] [-] amriksohata|3 years ago|reply
[+] [-] marsven_422|3 years ago|reply
[deleted]