This thread shows there is still a large amount of FUD around .NET and it’s community. Folks here still think it’s Windows-only and comparable to Java. Yet latest TechEmpower benchmarks shows .net running on Linux and being faster than Go, Python, Node, and Rust.
The Case for C# and .NET
111–120 of 376 posts
Re: The Case for C# and .NET
#112Earlier quoted context omitted.
Python, Ruby.
Obviously there is some degree of subjectivity as what a given language's competitors are. In some sense all languages compete with one another but I do think there is some natural clumping of languages/ecosystems. In my view Python and Ruby are not natural competitors to C# as they are dynamically typed and (in Python's case) interpreted. Similarly Rust, C, and C++ are not natural competitors to C# as they do not ha…
Maybe you have some legacy codebase in C# that you need to leverage.
All other reasons to chose C# over something else for web applications seem to lack evidence but certainly not conviction. So yes, Python is a direct competitor to C#, as in there are many more Python web projects out there than C# ASP.net ones.
Re: The Case for C# and .NET
#113Earlier quoted context omitted.
I use Rider on my Ubuntu machine and the dev experience for me, is even better than using VS2022 on Windows.
Quoted post unavailable.
If you want a language where not only the core and main libraries are open source, but also all the tools then C# is probably not the right choice. If free (but not open) tools for most use cases and paid tools for larger companies or higher-level demands are okay, then C# fits.
Re: The Case for C# and .NET
#114I also think that C# and .NET are awesome. Especially latest releases dotnet 6 and upcoming 7 have a ton of new things to be even more productive. I like the fact, that you can develop command line apps, Web APIs, Desktop Apps and smartphone apps all with the same toolset, including the fact that deployment is possible on nearly every major platform for every major platform (except iOS and macOS Apps, as always only…
I tried writing a simple crud api with asp.net, which should parse and respond json. It was the worst development experience I ever had while writing json apis. Validation? Not existent. OpenAPI/swagger documentation generation? Not existent. Then it also tried to force me into using MVC, while acting that it is express with its middlewares. I switched back to node.js with fastify and wrote my app in an hour. I reall…
That said, you may take a look at my small very early state pet project `tonehub`[1], which can be seen as pretty modern CRUD Web API in 2022, utilizing swashbuckle for OpenAPI, JsonApiDotNet for CRUD, Entity Framework 6 for Database, HostedServices for background tasks and some other nice concepts (DI / IoC, Options Pattern, FileStreams, etc.). I could also use SignalR for WebSockets / Realtime, integrated OpenID/OAUTH2 Authentication, FluentValidation for validation, Api Versioning and much more.
I've never accompilished something like this with this small amount of code...
Re: The Case for C# and .NET
#115Re: The Case for C# and .NET
#116Until .NET has the equivalent of Zod, I'm not that interested. Being able to write a validation schema and deriving types from it automatically - that I can share on client and server - is just too big an advantage.
Re: The Case for C# and .NET
#117Earlier quoted context omitted.
Quoted post unavailable.
VS Code has a C# debugger on Linux. There are certainly limitations to the open source C# support in VS Code, but for students it should be easily sufficient. If you want a language where not only the core and main libraries are open source, but also all the tools then C# is probably not the right choice. If free (but not open) tools for most use cases and paid tools for larger companies or higher-level demands are o…
Re: The Case for C# and .NET
#118Reading this post, it seems like the author never tried Typescript which seems to be heavily influenced by C#. I hate JavaScript as a language, but Typescript is very palatable. Like it or not JavaScript and Typescript are the franca lingua of programming for now
Re: The Case for C# and .NET
#119I also think that C# and .NET are awesome. Especially latest releases dotnet 6 and upcoming 7 have a ton of new things to be even more productive. I like the fact, that you can develop command line apps, Web APIs, Desktop Apps and smartphone apps all with the same toolset, including the fact that deployment is possible on nearly every major platform for every major platform (except iOS and macOS Apps, as always only…
I tried writing a simple crud api with asp.net, which should parse and respond json. It was the worst development experience I ever had while writing json apis. Validation? Not existent. OpenAPI/swagger documentation generation? Not existent. Then it also tried to force me into using MVC, while acting that it is express with its middlewares. I switched back to node.js with fastify and wrote my app in an hour. I reall…
As per another comment after having seen JS devs switch to F# for very large professional application and not wanting to go back I feel its fine for web. YMMV.
Re: The Case for C# and .NET
#120Earlier quoted context omitted.
> Blazor is in development and will only get better. How good can it get though? Blazor WASM suffers from the huge initial, multi-megabyte download of the .NET runtime. How is that expected to come down to something in the range of 50-500kb what we have with most JS frameworks now? I just cannot do that on public-facing parts of an application. It is unusable when accessed from a slow mobile network. Company-internal…
While the total download size is unlikely to go below 2MB with Blazor due to .NET Framework binaries, they are working hard on AOT and binary stripping, meaning your app could consist of a base framework download, served from a CDN, and subsequently cached, and a small app specific library that's comparable to a bundled JS lib in size.
Due to cache partioning in browsers now, this will still be a big issue for all clients. Don't also forget that many clients are in poor internet speed zones.
A 2MB "buy in" will be unacceptably high for lots of projects (but not all, obviously).