* C#/.NET is very popular in Europe and in the USA. Probably elsewhere too.
* Performance is great, and greater every November. Especially with Spans, structs for performance critical code (they use the stack and not the heap = less GC pressure), and a recent version of the .NET Runtime. Dynamic PGO (that is profile guided optimization by the .NET JIT at runtime) helps also devirtualize a lot of calls, and all we had to benefit from it was move to .NET 8. Can't wait for .NET 10 !
* Since 2016 (.NET Core) .NET is cross platform and open-source (well minus the link between the .NET debugger and the language server), and the overall SDK (the dotnet CLI tool for example) is absolutely great to work with.
* Using native libs or native memory (there are two pointers in the Spice86 applications, and one is on 'reverse: it is managed memory for the native library to use with the fixed keyword for the time of the call)
* Productivity with VS/Rider for writing/debugging .NET code is through the roof! And the docs are very comprehensive.
* Personnaly, I work with .NET daily, and reverse engineering Dune was hard enough. There's alreasdy a new language in there to understand, and that's x86 real mode ASM written by French devs pressured by time to market, and not very concerned with sane calling conventions...
My guess is portability, then obviously performance.
edit: actually there is a specific answer for this particular project - "We had to rewrite the project in C# to add automated code generation (java doesn't have the goto keyword, making automated ASM translation challenging)". There you are.
I mean, that's more or less the reason why it isn't Java, not why it's ultimately C#. My guess is that Java is just what they're most comfortable with, with C# being similar enough but avoiding specific limitations in that case.
Wasn't C# essentially microsoft throwing their hat in the ring against Oracle and to show off how cool this .net stuff is?
I dabbled in both at around the same time a long time ago for console apps and visual studio's autocomplete / assist / library fetch etc made it easier than Java to get working in but...
Its been so long I forget the origin stories sometimes.
.NET began its life as Microsoft's Java (the platform) along with C# being a mix between Java, C++, and Pascal.
Considering the timing (early 2000s), one can't help but think that it was in response to the legal actions from Sun Microsystems over their usage of the JVM in Windows.
"OK, I'll make my own Java language, with properties and an integrated DSL for queries!"
As a developer, I feel more productive after trying my workout and morning routine. this seems strange, working hours are less because of the time spent doing sports. but the results of my work are faster and less often wrong
Both, but for the backend it's an entire framework that replaces something like Express/NestJS and for the frontend it is not. In the frontend can be used the validator and serialiser, so that types can be easily shared between frontend and backend. There is also a frontend desktop UI kit, but that is not the main focus (and was mainly separeted in a package because it was developed for GUI apps like API Console and Framework Debugger in Deepkit). You should use in the vast majority of cases the regular React/Angular/Vue frontend stack.
There’s a library called @deepkit/desktop-ui and another @deepkit/mongo. I guess you can use it anywhere, just pick libraries that makes sense on your environnement.
Why slack desktop use electron? Slack mobile app using xamarin. Why they not porting from mobile app to desktop? U must learn electron, and also not running on native
I try swaggerbuckle nuget c#. It was easy to consume from ios swift. Then i try on android. Not easy. Then try again on react native js, also not easy. My suggestion is try one or two simple API.
The main reason i move from c# to “typescript js” because c# not working on client side web. I love c#, maybe if dotNetAnywhere is ready for production, i start using c# again. Keep the good work. Maybe someday aspcore, xamarin and dotNetAnywhere. It would be awesome
But because those are weekend projects. There are enough microsoft or microsoft-related people getting excited about it that I hope microsoft will put its strength behind a production version. That would certainly make a lot of sense.
reply