- The mature frameworks (e.g. ASP.NET with razor pages) are great. Microsoft still have the same issue of pushing new and different ways of doing web things, but you do see a lot of that on the web platform in general.
- CLI workflow for compilation/build/deployment is now there and works smoothly. VS Code extensions for a bit of intellisense without requiring a full IDE (if that's the way you work).
The thing I enjoy most about modern C# is the depth/levels of progressive enhancement you can do.
Let's say in the first instance, you write a proof of concept algorithm using basic concepts like List<T>, foreach, stream writing. Accessible to a beginner, safe code, but it'll churn memory (which is GC'd) and run using scalar CPU instructions.
Depending on your requirements you can then progressively enhance the memory churn, or the processing speed:
Eventually getting to a point where it's nearly the same as the best C code you could write, with no memory churn (or stop-the-world GC), and SIMD over all CPU cores for blisteringly fast performance, whilst keeping the all/most of the safety.
this performance aspects is interesting. So time to try C# again. I;m learning Zig for some of those reasons, but also because the language has a small scope and the language features will be smaller
If you are leaning towards Zig, I don't think C# will be what you are looking for. It is a good option along with Java and Go, but not in Zig, C, Rust territory if that is what you want.
At my daily job, our production servers are Linuxes, and we deploy our .NET code (fairly complex web app) just fine, using the same techniques you would with other technologies like CLI GitLab CI/CD, Docker, Kubernetes... Forget about GUI if you're not into it.
The web framework craze is settling down. Microsoft seems to have consolidated into two web frameworks: Blazor (improved/extended Razor Pages) and ASP.NET for MVC, and APIs. I personaly don't expect another U-turn for the coming years.
Blazor is really nice, and ready for production. The only downside I see is that Visual Studio (vanilla) struggles compared to another MSFT technologies. You don't need Visual Studio, though.
I am a full time .NET developer, experienced with both newer and older .NET versions.
They are confusingly named, but this is the gist:
- .NET Framework is the older version that is tied to Windows.
- .NET is the newer version that is cross platform, and was renamed from .NET Core.
Linux support is pretty good on .NET. I don't have as much experience with this personally since most of my company is still using .NET Framework, but I was able to get a simple .NET app running on Linux without any hassle.
The main web frameworks I am aware of are Blazor and MVC. Blazor behaves more like a single-page application (without needing JavaScript!) and abstracts away most of the headache of making dynamic web pages, but generally doesn't scale as well from what I have seen. MVC is a little more traditional but you need to write some JavaScript for interactivity.
I'm not fully sure what you mean by GUI heavy. Everything I am aware of can be accomplished with the CLI tooling.
There is only one relevant web framework: ASP.NET Core. Microsoft is as bad at naming things as it has always been, so that hasn't changed. They're pretty good about not deprecating too much in the web area now, the big disruptive change was from .NET Framework to .NET Core. The Windows UI stuff seems to be a bit of a shitshow in terms of deprecations, but I've no direct experience with it.
It has been very good since around 2007/8 when ASP.NET MVC released. That was the first good MS web framework. You needed to avoid EntityFramework / WCF / Unity and anything coming from the Enterprise group. There were some amazing OSS frameworks and libraries.
Then when .Net Core happened it was compelling and once that matured a no-brainer. On the MSFT the Alt.Net side won, MS hired many of the good people and the Alt.Net supporters inside Microsoft run the show nowadays. So now it's fine to run a largely MS stack on .Net.
I use .NET at $job, and have been running arch for the last few years, without any problems.
I also have two collegues using Apple silicon, also no problems there.
The official aspnet core web framework is (in my opinion) good enough that you don't need anything 3rd party.
The GUI story is not a good one though, and if I were to write a GUI program I'd reach for Avalonia (3rd party, free).
I use Rider as IDE, but there are multiple other options.
With the recent performance improvements (Span, Memory, Intrinsics, etc) it's possible to write quite performant C# these days, and with low GC pressure.
> Subpar tooling outside of Windows (I'm looking at you C# Dev Kit)
JetBrains Rider is excellent and runs on Windows, Mac and Linux. It has a few Windows only features but nothing important for me, it's the best IDE for C#/.NET you can get on non-Windows platforms imo. And it's free for non commercial use.
The Linux story is much better now. Back end the day it was necessary to try to use Mono which wasn't fully compatible and the code had to have #if defs all over the place. That is thankfully all gone now.
Most things can be done with the dotnet cli but for editing code, realistically you will want to use an editor like vscode, Rider or Visual Studio itself. I found the LSP support in vim quite bad for C#.
Honestly, .NET should be the default choice for any non-trivial backend or non-GUI application. I assume the legacy (outdated/inaccurate) perception of MSFT's stewardship is the only reason anyone reaches for something else.
AOT is a game changer for native binaries, but even with fw dependence, the cross platform support is excellent (we deploy to Linux servers frequently.)
>> .NET should be the default choice for any non-trivial backend or non-GUI application
I personally wouldn't go that far. If you know well, it makes sense to use it, but you already know Java or Go, would the benefit delta isn't going to be that high.
Somewhat famously, even Anders Hejlsberg decided to use Go vs .NET for the new Typescript compiler. .NET is fine (and I have personally used it a lot) but that doesn't mean it is net better than other options out there.
Not really. They're independent languages with different design goals. You're exact questions in this thread would have been just as relevant without bringing it up.
> - Enterprise Devs as the core user (Type safety, great stdlib)
> - High level OO based interfaces
> - Allows for low enough level programming that you can reasonably use in place of C/C++
This can reasonably said about any programming language that is popular. These points could also reasonably match Go.
C# and Java have had completely opposite design goals. C#'s design goals are to have a more powerful/complex language with a not as advanced runtime. Java is the exact opposite. They favor having a slower moving language while pushing the edge on having a very advanced runtime. They're only similar on the surface level being C-Like languages with a GC. The design philosophies have created very different languages with different implementations, for example async/await in C# vs virtual threads in Java.
Green threads in Java are only there because the async model implementation of the JVM is trash, don't even talk about generics
Also, Java didn't move for a very, very, very, very, very, very, very, long time because nobody cares. It took Microsoft to reinvest in it, and make things moving. Basically they took a bunch of C# specifications and translate them to JSR format.
Before that they port Rx from .NET Framework, to Java and Javascrit.
It is only the .NET tooling. The software that runs on the C64 is still Commodore BASIC or 6502 assembly.
Similarly a couple of years ago someone claimed to be able to play MP3 on the C64, but it was just a custom compression using some modern knowledge. Ultimately it had next to nothing in common with real MP3.
> Ultimately it had next to nothing in common with real MP3.
Designing a custom compression format that could be decompressed with C64 resources while still achieving good compression is still a very meaningful achievement.
Which reminds me, maybe I should think more about that idea for a custom compression for GBA 4bpp graphics....
Absolutely and so is enabling people to program the C64 with modern tooling many are familiar with. The misleading is not only uncalled for but also completely unnecessary - and that is the saddest part.
Dotnet is an incredible platform ahead of its time. I use it for everything and never get disappointed. Also, i'm currently building a startup and everything is dotnet.
Same. I will say that dotnet for mobile development hasn’t kept up so I’ve gone react-native on that front for my startup. All dotnet on the backend though, and it’s great.
It would have been cool to get some subset of the dotnet runtime running on the C64.
This is not it. It's a desktop IDE built using dotnet that just assembles 6502 instructions with some extra awkward syntax.
Many more elaborate projects exist. My favorite is the one that compiles something similar to Turbo Pascal to C64 6502. It's implemented in C++/Qt, but noone ever tried to market it that way, because why would they?
> Many more elaborate projects exist. My favorite is the one that compiles something similar to Turbo Pascal to C64 6502
It depends on the purpose. The reference IDE is intended to produce real-world programs (it includes tools for sprites, music etc.), while high level language compilers are mostly academic, as they're not performant enough.
llvm-mos https://github.com/llvm-mos/llvm-mos seems to generate good enough code - more than competitive with other high-level languages for the 6502, though perhaps not so much with manual assembly coders.
Programming for the C64 CPU is terrible. You couldn't even attempt to port a dotnet subset.
There isn't a multiplication instruction, so you have to painstakingly reinvent all useful algorithms from the last 40 years from nearly scratch and by the time you want to implement a hash you notice you're running out of RAM.
A generation of programmers might disagree with you.
Multiplication instructions and hash tables (!) are easily worked around, as evidenced by decades of art and innovation programmed on that "terrible" CPU. There are still 6502 programmers today delivering games, art, demoscene, etc.
That CPU was a foundation of the home computer and console revolution: BBC, Commodore, Atari (consoles and computers), Apple, and Nintendo (NES).
It's just not the same class of devices. The tiniest IoT-focused subsets of .NET will still require more than 64KB of RAM and 192KB or so of mass storage. You could try and implement some minimum viable WASM subset (I think the issues that made WASM non-viable on microcontrollers and the like have been addressed by now) since the overall architecture is likely simpler, but even that is rather dubious and more like something that could be appropriate on slightly newer 16-bit machines.
I don't think that games, art and the demoscene can be used as evidence here. Implementing something like C# means you have a spec to implement. You have to be creative with the implementation without violating that spec.
All the three of games/art/demoscene on something like the C64 have a rough idea as the spec, but then you'll get creative about how much of that "spec" you can bend and violate to meet the technical limitations of the C64, while still being fun.
Yeah it pays to have a huge library of routines...e.g. multiplication for every size combo of number sizes, signedness. Also sorts...everything, but if you scour youll find many :)
Question to HN .NET Devs
Its been a long time since I was in the MSFT ecosystem (left just as wsl was getting popular).
I remember thinking C#, F#, .NET and LINQ was a pretty robust set of tooling that was ahead of its time and certainly ahead of Java.
At the time, the things that were holding it back was:
- Poor to non existant linux support
- A confusing labyrinth of MSFT web frameworks that were nonsensically named and often deprecated
- A very GUI heavy dev and production setup
I know a lot has changed since then. So how is it in 2025?
It's a huge leap forwards from those days.
- Works on linux/macos, x86/ARM64.
- The mature frameworks (e.g. ASP.NET with razor pages) are great. Microsoft still have the same issue of pushing new and different ways of doing web things, but you do see a lot of that on the web platform in general.
- CLI workflow for compilation/build/deployment is now there and works smoothly. VS Code extensions for a bit of intellisense without requiring a full IDE (if that's the way you work).
The thing I enjoy most about modern C# is the depth/levels of progressive enhancement you can do. Let's say in the first instance, you write a proof of concept algorithm using basic concepts like List<T>, foreach, stream writing. Accessible to a beginner, safe code, but it'll churn memory (which is GC'd) and run using scalar CPU instructions.
Depending on your requirements you can then progressively enhance the memory churn, or the processing speed:
for(;;), async, LINQ, T[], ArrayPool<T>, Span<T>, NativeMemory.Alloc, Parallel.For, Vector<T>, Vector256<T>, System.Runtime.Intrinsics.
Eventually getting to a point where it's nearly the same as the best C code you could write, with no memory churn (or stop-the-world GC), and SIMD over all CPU cores for blisteringly fast performance, whilst keeping the all/most of the safety.
this performance aspects is interesting. So time to try C# again. I;m learning Zig for some of those reasons, but also because the language has a small scope and the language features will be smaller
If you are leaning towards Zig, I don't think C# will be what you are looking for. It is a good option along with Java and Go, but not in Zig, C, Rust territory if that is what you want.
At my daily job, our production servers are Linuxes, and we deploy our .NET code (fairly complex web app) just fine, using the same techniques you would with other technologies like CLI GitLab CI/CD, Docker, Kubernetes... Forget about GUI if you're not into it.
The web framework craze is settling down. Microsoft seems to have consolidated into two web frameworks: Blazor (improved/extended Razor Pages) and ASP.NET for MVC, and APIs. I personaly don't expect another U-turn for the coming years.
Blazor is really nice, and ready for production. The only downside I see is that Visual Studio (vanilla) struggles compared to another MSFT technologies. You don't need Visual Studio, though.
I am a full time .NET developer, experienced with both newer and older .NET versions.
They are confusingly named, but this is the gist: - .NET Framework is the older version that is tied to Windows. - .NET is the newer version that is cross platform, and was renamed from .NET Core.
Linux support is pretty good on .NET. I don't have as much experience with this personally since most of my company is still using .NET Framework, but I was able to get a simple .NET app running on Linux without any hassle.
The main web frameworks I am aware of are Blazor and MVC. Blazor behaves more like a single-page application (without needing JavaScript!) and abstracts away most of the headache of making dynamic web pages, but generally doesn't scale as well from what I have seen. MVC is a little more traditional but you need to write some JavaScript for interactivity.
I'm not fully sure what you mean by GUI heavy. Everything I am aware of can be accomplished with the CLI tooling.
It runs perfectly fine on Linux since .NET Core.
There is only one relevant web framework: ASP.NET Core. Microsoft is as bad at naming things as it has always been, so that hasn't changed. They're pretty good about not deprecating too much in the web area now, the big disruptive change was from .NET Framework to .NET Core. The Windows UI stuff seems to be a bit of a shitshow in terms of deprecations, but I've no direct experience with it.
It has been very good since around 2007/8 when ASP.NET MVC released. That was the first good MS web framework. You needed to avoid EntityFramework / WCF / Unity and anything coming from the Enterprise group. There were some amazing OSS frameworks and libraries.
Then when .Net Core happened it was compelling and once that matured a no-brainer. On the MSFT the Alt.Net side won, MS hired many of the good people and the Alt.Net supporters inside Microsoft run the show nowadays. So now it's fine to run a largely MS stack on .Net.
TBF EF Core has turned out to be very good and very performant.
I use .NET at $job, and have been running arch for the last few years, without any problems. I also have two collegues using Apple silicon, also no problems there.
The official aspnet core web framework is (in my opinion) good enough that you don't need anything 3rd party.
The GUI story is not a good one though, and if I were to write a GUI program I'd reach for Avalonia (3rd party, free).
I use Rider as IDE, but there are multiple other options.
With the recent performance improvements (Span, Memory, Intrinsics, etc) it's possible to write quite performant C# these days, and with low GC pressure.
You can read an overview of what's new with the language (although missing C#14 which was released days ago) here: https://learn.microsoft.com/en-us/dotnet/csharp/whats-new/cs...
Citing my own comment from another thread:
I've worked with .NET for over 10 years and we built our startup on top of it. Here are my thoughts: Pros:
* Stability
* Very decent standard library
* Good balance between productivity and robustness
* Great package management
* Extremely easy to upgrade, so essentially free goodies (performance) every year or so
Cons:
* Very MSFT dominated (obviously)
* Subpar tooling outside of Windows (I'm looking at you C# Dev Kit)
* C# has way to many features, it feels bloated
* Culturally, it feels like .NET devs are less "passionate" about their work
* The freaking stigma of being a .NET dev: you will never be as cool as the guys who work with Node/Python/whatever
Edit: Also I'd like to add EFCore as one of the pros of the ecosystem. Hands down the best ORM. Others don't come close.
> Subpar tooling outside of Windows (I'm looking at you C# Dev Kit)
JetBrains Rider is excellent and runs on Windows, Mac and Linux. It has a few Windows only features but nothing important for me, it's the best IDE for C#/.NET you can get on non-Windows platforms imo. And it's free for non commercial use.
You're probably right. I haven't tried it thoroughly
> you will never be as cool
I quoted that on x a few days ago and got some fun replies :)
https://x.com/vyrotek/status/1988737638682296388
The Linux story is much better now. Back end the day it was necessary to try to use Mono which wasn't fully compatible and the code had to have #if defs all over the place. That is thankfully all gone now.
Most things can be done with the dotnet cli but for editing code, realistically you will want to use an editor like vscode, Rider or Visual Studio itself. I found the LSP support in vim quite bad for C#.
I've been running .NET web apps on Linux since 2018 (early .NET Core versions)
ASP.NET is stable and really good web framework
Honestly, .NET should be the default choice for any non-trivial backend or non-GUI application. I assume the legacy (outdated/inaccurate) perception of MSFT's stewardship is the only reason anyone reaches for something else.
AOT is a game changer for native binaries, but even with fw dependence, the cross platform support is excellent (we deploy to Linux servers frequently.)
>> .NET should be the default choice for any non-trivial backend or non-GUI application
I personally wouldn't go that far. If you know well, it makes sense to use it, but you already know Java or Go, would the benefit delta isn't going to be that high.
Somewhat famously, even Anders Hejlsberg decided to use Go vs .NET for the new Typescript compiler. .NET is fine (and I have personally used it a lot) but that doesn't mean it is net better than other options out there.
[dead]
Everybody's gotta bring Java into it.
Kind of like if im talking about VRBO, I should mention Airbnb.
Similar in the heavy weight enterprise programming language space. If im talking about .NET I should mention Java.
>> If im talking about .NET I should mention Java
I think you should. After all, Java, C# and Go all occupy essentially the same space.
Not really. They're independent languages with different design goals. You're exact questions in this thread would have been just as relevant without bringing it up.
Open to you educating me here! I (maybe naively) see their design goals being very similar:
- Enterprise Devs as the core user (Type safety, great stdlib)
- High level OO based interfaces
- Allows for low enough level programming that you can reasonably use in place of C/C++
The differences seem to be more minor:
- opinionated (C#) vs unopinionated (Java) when it comes to what tools / libraries you reach for.
- Conservative (Java) vs Experimental (C#) when it comes to releasing new language features
- Execution model: Java seems like a better choice for "run anywhere" but C# has been indexing more in this direction
> - Enterprise Devs as the core user (Type safety, great stdlib)
> - High level OO based interfaces
> - Allows for low enough level programming that you can reasonably use in place of C/C++
This can reasonably said about any programming language that is popular. These points could also reasonably match Go.
C# and Java have had completely opposite design goals. C#'s design goals are to have a more powerful/complex language with a not as advanced runtime. Java is the exact opposite. They favor having a slower moving language while pushing the edge on having a very advanced runtime. They're only similar on the surface level being C-Like languages with a GC. The design philosophies have created very different languages with different implementations, for example async/await in C# vs virtual threads in Java.
To be fair. I'd be fine lumping Golang in this camp as well.
Theyre all different languages and ecosystems.
But in terms of what use cases they fill? Theyre more similar that not.
In otherwords if I'm evaluating Java for a use case, in many situations, I'd also be evaluating C# and/or Golang along side it.
Where as it would be less common for me to compare Java against Python, Javascript, Elixir, Erlang, Rust etc..
>This can reasonably said about any programming language that is popular
C++ does not have great stdlib, lol. Maybe "recently" it improved, but still.
Green threads in Java are only there because the async model implementation of the JVM is trash, don't even talk about generics
Also, Java didn't move for a very, very, very, very, very, very, very, long time because nobody cares. It took Microsoft to reinvest in it, and make things moving. Basically they took a bunch of C# specifications and translate them to JSR format.
Before that they port Rx from .NET Framework, to Java and Javascrit.
It is only the .NET tooling. The software that runs on the C64 is still Commodore BASIC or 6502 assembly.
Similarly a couple of years ago someone claimed to be able to play MP3 on the C64, but it was just a custom compression using some modern knowledge. Ultimately it had next to nothing in common with real MP3.
> Ultimately it had next to nothing in common with real MP3.
Designing a custom compression format that could be decompressed with C64 resources while still achieving good compression is still a very meaningful achievement.
Which reminds me, maybe I should think more about that idea for a custom compression for GBA 4bpp graphics....
Absolutely and so is enabling people to program the C64 with modern tooling many are familiar with. The misleading is not only uncalled for but also completely unnecessary - and that is the saddest part.
Such a cool side project. And with LiveReload!
Super cool, this is what HN is all about for me.
I've sworn to myself I will learn 6510/6502 assembly and make 1 simple game for the C64 before I die.
And the ZX Spectrum, and hopefully the SNES/GBA too.
As an exercise to "catch up" with gaming/computing history if nothing else :')
Dotnet is an incredible platform ahead of its time. I use it for everything and never get disappointed. Also, i'm currently building a startup and everything is dotnet.
Same. I will say that dotnet for mobile development hasn’t kept up so I’ve gone react-native on that front for my startup. All dotnet on the backend though, and it’s great.
It would have been cool to get some subset of the dotnet runtime running on the C64.
This is not it. It's a desktop IDE built using dotnet that just assembles 6502 instructions with some extra awkward syntax.
Many more elaborate projects exist. My favorite is the one that compiles something similar to Turbo Pascal to C64 6502. It's implemented in C++/Qt, but noone ever tried to market it that way, because why would they?
https://github.com/leuat/TRSE
Turbo Rascal Syntax Error
> Many more elaborate projects exist. My favorite is the one that compiles something similar to Turbo Pascal to C64 6502
It depends on the purpose. The reference IDE is intended to produce real-world programs (it includes tools for sprites, music etc.), while high level language compilers are mostly academic, as they're not performant enough.
llvm-mos https://github.com/llvm-mos/llvm-mos seems to generate good enough code - more than competitive with other high-level languages for the 6502, though perhaps not so much with manual assembly coders.
Imo, this is actually way more interesting.
Programming for the C64 CPU is terrible. You couldn't even attempt to port a dotnet subset.
There isn't a multiplication instruction, so you have to painstakingly reinvent all useful algorithms from the last 40 years from nearly scratch and by the time you want to implement a hash you notice you're running out of RAM.
A generation of programmers might disagree with you.
Multiplication instructions and hash tables (!) are easily worked around, as evidenced by decades of art and innovation programmed on that "terrible" CPU. There are still 6502 programmers today delivering games, art, demoscene, etc.
That CPU was a foundation of the home computer and console revolution: BBC, Commodore, Atari (consoles and computers), Apple, and Nintendo (NES).
It's just not the same class of devices. The tiniest IoT-focused subsets of .NET will still require more than 64KB of RAM and 192KB or so of mass storage. You could try and implement some minimum viable WASM subset (I think the issues that made WASM non-viable on microcontrollers and the like have been addressed by now) since the overall architecture is likely simpler, but even that is rather dubious and more like something that could be appropriate on slightly newer 16-bit machines.
I don't think that games, art and the demoscene can be used as evidence here. Implementing something like C# means you have a spec to implement. You have to be creative with the implementation without violating that spec.
All the three of games/art/demoscene on something like the C64 have a rough idea as the spec, but then you'll get creative about how much of that "spec" you can bend and violate to meet the technical limitations of the C64, while still being fun.
Yeah it pays to have a huge library of routines...e.g. multiplication for every size combo of number sizes, signedness. Also sorts...everything, but if you scour youll find many :)
> You couldn't even attempt to port a dotnet subset.
Because of the lack of a multiplication op code? Hmm.
[flagged]
I think you're in the wrong place for that sort of nonsense
What a dumb comment