4 ms·

> It's miles ahead of VS in every way that I can think of When I need to write advanced SIMD code, or consume C libraries like FreeType designed to be hostile

> It's miles ahead of VS in every way that I can think of 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.

piva00 5y ago
And Rider is not just Rider, it's based on the IntelliJ platform that can also support multiple different languages, including C++, Python, Java and so on.
dotancohen 5y ago
As a Linux user, what do I need to experiment with .NET 6 to replace Python for mostly simple file processing? 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.
- Scarbutt 5y ago
  Downloading .NET 6, a text editor and reading docs?
  - dotancohen 5y ago
    Yes, of course! 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.
- thrower123 5y ago
  You're probably better just sticking with Python if that is all you are doing. 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.
  - dotancohen 5y ago
    Thanks. I just figured that text scripting, which I do often enough, would be a good foot in the door. I'm not looking for a better Python replacement, rather, I'm looking to get familiar with dotnet with a small project that I would be doing anyway.
- throw1234651234 5y ago
  Absolutely no reason. I prefer .NET over Python, but for your use case, there is no point, and .NET might be a downgrade since it's more verbose. For huge projects, that verbosity is what makes it maintainable.
  - dotancohen 5y ago
    My mindset is to experiment and become familiar with .NET. Python is great and I can continue to use it, but I see text processing as a low barrier to entry way to get familiar with a new tech.
- S04dKHzrKT 5y ago
  Depending on what kinds of files you read/write, you might want to take a look at F#'s type providers. https://fsprojects.github.io/FSharp.Data/library/CsvProvider.html https://fsprojects.github.io/FSharp.Data/library/CsvProvider...
- jmnicolas 5y ago
  Right now you probably can't experiment coding with .net 6 on Linux (I'm not sure with VSCode but it didn't work for me last week with Rider so I'm still on .net 5). 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
- Const-me 5y ago
  Can’t recommend a Linux IDE. I develop quite a lot of .NET for Linux lately, but I’m using a Windows computer with visual studio 2019 to compile and debug. Only using the runtime on Linux to test things, with printf debugging when needed. Still, quite a few people on the internets, in this thread even, are saying Rider is actually good. 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.
  - dotancohen 5y ago
    Perfect, thank you. I do love the Jetbrains IDEs professionally, but its an expensive purchase for occasional use. 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.
    - Const-me 5y ago

piva00 5y ago

And Rider is not just Rider, it's based on the IntelliJ platform that can also support multiple different languages, including C++, Python, Java and so on.

dotancohen 5y ago

As a Linux user, what do I need to experiment with .NET 6 to replace Python for mostly simple file processing? 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.

Scarbutt 5y ago
Downloading .NET 6, a text editor and reading docs?
- dotancohen 5y ago
  Yes, of course! 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.
thrower123 5y ago
You're probably better just sticking with Python if that is all you are doing. 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.
- dotancohen 5y ago
  Thanks. I just figured that text scripting, which I do often enough, would be a good foot in the door. I'm not looking for a better Python replacement, rather, I'm looking to get familiar with dotnet with a small project that I would be doing anyway.
throw1234651234 5y ago
Absolutely no reason. I prefer .NET over Python, but for your use case, there is no point, and .NET might be a downgrade since it's more verbose. For huge projects, that verbosity is what makes it maintainable.
- dotancohen 5y ago
  My mindset is to experiment and become familiar with .NET. Python is great and I can continue to use it, but I see text processing as a low barrier to entry way to get familiar with a new tech.
S04dKHzrKT 5y ago
Depending on what kinds of files you read/write, you might want to take a look at F#'s type providers. https://fsprojects.github.io/FSharp.Data/library/CsvProvider.html https://fsprojects.github.io/FSharp.Data/library/CsvProvider...
jmnicolas 5y ago
Right now you probably can't experiment coding with .net 6 on Linux (I'm not sure with VSCode but it didn't work for me last week with Rider so I'm still on .net 5). 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
Const-me 5y ago
Can’t recommend a Linux IDE. I develop quite a lot of .NET for Linux lately, but I’m using a Windows computer with visual studio 2019 to compile and debug. Only using the runtime on Linux to test things, with printf debugging when needed. Still, quite a few people on the internets, in this thread even, are saying Rider is actually good. 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.
- dotancohen 5y ago
  Perfect, thank you. I do love the Jetbrains IDEs professionally, but its an expensive purchase for occasional use. 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.
  - Const-me 5y ago