When I need to write advanced SIMD code, or consume C libraries like FreeType designed to be hostile towards FFI, I often make C++ DLLs to be consumes from C#.
Unlike Rider, Visual Studio is not just .NET IDE, it's a C++ IDE as well. The two debuggers are integrated too, it's easy to debug both C# and C++ at the same time.
90% of my use would be to open and read/write files, read from stdin and argv, regex, maybe some http requests and math no heavier than the occasional integral or limit.
About programming, most of the things you have mentioned (except integrals and limits) are in the C# standard library. Here’s a few tips.
Be sure to handle exceptions in your Main(). On Linux, I usually printing messages into `Console.Error` stream and returning a non-zero status code. Without the top-level try/catch in the main, unhandled exceptions crash the process with no information about what happened.
Set <CheckForOverflowUnderflow>true</CheckForOverflowUnderflow> compiler switch in all your *.csproj files. It causes the runtime to detect integer overflows and throw exceptions in runtime when it happens. It’s very useful to debug things (exceptions come with stack traces, if you keep the *.pdb files they will even contain source file names and line numbers), but I usually keeping the setting in release builds too, for a bit of extra safety. The performance overhead is negligible on modern computers.
About the I/O, use modern APIs, the usability’s better. For instance, when you need to read a text file line by line, call File.ReadLines() method, returns a lazily-evaluated sequence of these lines. Also, modern .NET supports spans pretty much everywhere and therefore you can read/write stack allocated buffers or unmanaged memory. Albeit depending on your use cases, stack allocated buffers might be a premature optimization.
About web request, the standard library has two HTTP clients, older WebClient, and newer HttpClient. For many use cases the functionality is equivalent, pick whichever API you like better. In both cases, I recommend their async-await APIs to make requests. The language supports async main for a few versions now.
I much appreciate the mention of catching exceptions. For my own programs I usually don't catch exceptions because I want the failure to be hard and informative. It seems that dotnet is the exception here.
Don’t abuse LINQ. It’s awesome, but I can only recommend for simple use cases. For advanced ones, too easy to screw up, and too hard to debug. When that’s the case, I’m usually writing a foreach loop instead, and/or generator methods. Also, when I do use LINQ I prefer the C# syntax like `seq.Select( x => x.something )` instead of the SQL syntax `select something from seq`. It’s a matter of taste but IMO compiler is doing too much magic with the SQL syntax.
A few years ago, .NET finally got what MS calls string interpolation. Good stuff, can recommend, I think Python has an equivalent for a decade: https://docs.microsoft.com/en-us/dotnet/csharp/language-refe...
Most articles on the internets view C# as an object-oriented language. That’s only part of the story. In the typical code I’m writing, at least 50% of code is pure functions (in FP sense) in static classes. And at least 50% of non-static classes are structures (these are value types, an array or List<> of them will keep items at sequential memory addresses, good for performance) with all the fields marked readonly, i.e. immutable types. .NET 6.0 even has record structs now, with automatic readonly.
https://fsprojects.github.io/FSharp.Data/library/CsvProvider...
So if you wait a few weeks to get full support assuming you want an IDE experience and not running everything from the console:
- if you want free (as in beer): Visual Studio Code - if you have a Jetbrains license or don't mind paying for one: Rider
DotNet and C# works fine for all of those things, but it's definitely simpler to get spun up with a Python script for the quick and dirty. DotNet really shines as things get bigger and you need to have more structure.
For huge projects, that verbosity is what makes it maintainable.
There was much mention in this thread of the docs being out of date, referring mostly to older dotnet APIs. Also, by mentioning specific use cases, I was hoping - and got - very specific and helpful recommendations.
It has tons of features missing for Windows development, debugging across .NET languages, C++, COM and WinRT.
Debugging of GPU code, parallel code, integration with mocking frameworks like Fakes, architecture modeling even for files without source available (code maps).
I know I don't.
Most people just responded by not using those APIs or recreating them.
I never felt I was lacking anything in stock Visual Studio and since my company won't pay for anything I never considered Resharper.
Fwiw I have Linux at home and trying Rider (I have used Android Studio before) I much prefer Visual Studio.
At the top right of each window pane is a popup menu that let's you change the window mode, it's that simple.