10 ms·

I have worked with .NET for a long time and recently did some work with Java, node and python. .NET has a lot going for it but i feel MS is making things more c

I have worked with .NET for a long time and recently did some work with Java, node and python. .NET has a lot going for it but i feel MS is making things more complicated than they have to be. When I need to achieve something a little off the beaten path in the non .NET technologies this is often pretty straightforward to achieve whereas in .NET I have to find some obscure interface and overrides to implement and then deal with weird side effects. I think .NET has become too big for its own good to be maintained by one party. The documentation also has a lot of volume but almost no structure. When .NET started out it was pretty coherent but in the last few years it felt very disjointed without a central design philosophy. Don’t even mention desktop development which is a complete mess since Windows 8. Maybe I am too negative on .NET but personally find the open source alternatives easier to work with and more fun.

R0b0t1 5y ago
The .NET frameworks (blazor, etc) are too complicated. Peak FizzBuzzEnterpriseEdition there. The interop layer than you have to go through to do a lot of stuff is actually quite tame. It just needs more time on Linux.
- tester756 5y ago
  >The interop layer than you have to go through to do a lot of stuff is actually quite tame. It just needs more time on Linux. What do you mean? I have software on prod on Linux for years and the only problem I had was lack of some fonts installed that made some problem when it comes to pdf generation
  - R0b0t1 5y ago
    Binding to C/C++ libraries or other system libraries is not something that's well documented, officially. On Windows there's a lot of 3rd party effort that is easily searchable. But for a long time the interop layer was not (and still may not be?) working on Linux. The first iterations of .NET were just for webapps. You could only work with and call .NET code, the only functions provided were basic IO and network.
    - nightski 5y ago
      Hmm, I've been using .NET since beta 1 in 2000. Maybe you had access to earlier bits? It was never just about webapps. In fact, Windows Forms was meant as a more sane MFC if anything. Interop with native code was always very easy. From PInvoke to managed C++ there were a lot of ways to do it with ease. Things have changed but I still think this is one area where .NET has great support.
      - emteycz 5y ago
        They probably mean .NET Core, it's somewhat true in that case.
    - immutology 5y ago
      Native interop in .NET has always been via what they call "P/Invoke". On .NET Core, P/Invoke is cross-platform and you can also call .so/.dylib functions on Linux/MacOS just like you could always call .dll functions on Windows on .NET Framework before we had .NET Core. I'm curious to know what you needed to do with native libraries. I've been programming with .NET around 20 yrs and find it fairly rare that I need to use P/Invoke... But I'm sure it depends on what you're building.
      - withinboredom 5y ago
        I maintain a thingy written in C# that does cool things with keyboard backlights on System76 machines in Linux. Like make the left-third respond to CPU usage, right third blink when you have unread notifications, etc. The biggest one was turning off the keyboard when the screen blanked[1]. Almost all of the fun stuff requires native interop. 1: https://withinboredom.info/blog/2019/11/26/detecting-if-a-screen-is-turned-off-in-linux/ https://withinboredom.info/blog/2019/11/26/detecting-if-a-sc...
      - ok123456 5y ago
        You end up using P/Invoke any time you need to control hardware. In the last few months I needed to use P/Invoke to control cameras, motors, and compute FFTs with the GPU. You need to use them if you need to control raw GDI objects like bitmaps.
- userbinator 5y ago
  That's the normal Java culture, which is not surprising given that MS created .NET as a competitor to Java.
- Shalomboy 5y ago
  > The .NET frameworks (blazor, etc) are too complicated. Peak FizzBuzzEnterpriseEdition there. I dunno, Blazor feels like the one ASP framework that makes sense. MVC, Web Apps, Web Forms all feel impenetrable to me.
- kumarvvr 5y ago
  Blazor IMV is more sane than React. It is an SPA that is structured around routing and pages, which happen to have component hierarchies in them. React is the other way around. Routing in React seems to be an afterthought. And I hate it with a passion. Page based way of thinking (or "screens" if you will) is a better way to do web dev. Also, the Dependency Injection system is extremely productive. State management in Blazor is very easy and a breeze to use. If not for the intricacies of hosting models, and a slightly large default build size for the full WASM client mode, Blazor would have replaced React / Angular / Vue by now.
  - starik36 5y ago
    > Dependency Injection system is extremely productive Sure, but there is a downside to it. You want to add a feature to the class that uses DI? Great, just add an injected object to the constructor. Except now a 100 unit tests broke because you changed the constructor. A 10 minute functionality change turns into a massive cut and paste operation in your Tests project.
    - deleted 5y ago
      [deleted]
    - kumarvvr 5y ago
      Sorry, if tests are not adaptable to changing code, why are they called tests? I thought tesring was to check software,not be a constraint on software development. Also, I think using DI in the test process itself will mitigate the issue.
      - spaetzleesser 5y ago
        Some tests are not adaptable to changing code because of the way MS uses DI. A lot of DI is done by adding new parameters to the constructor. It’s the same with async. Needing an async function somewhere can result in a huge cascade of changes.
        5y ago
- hackerfromthefu 5y ago
  Compared to JS SPAs such as React/Vue/Angular, Blazor obviates a huge amount of toolchain complexity, multi-language and transpilation impedance, and jank of leaky abstractions building a component model on top of Javascript. Having worked with a mix of these, I found Blazor to be clearly much simpler, approaching though not quite reaching the simplest possible implementation for a component based UI. I think it's probably more a matter of what you are used to than inherent complexity. The things you are familiar with seem 'easy' and the unknown seems 'hard'. Stick with it, it really pays dividends when you get good at it!
deleted 5y ago
[deleted]
kumarvvr 5y ago
I find this very intriguing. As a runtime, .NET exposes a lot of high and low level stuff to the developer. Can you give me an example of this offbeat thing you wanted to do that involves overriding an obscure interface? .NET is big, but if you are using it for web app, your focus is only on that set of libraries. Comparing with similar stacks, none of them cover the area .NET covers. Also, look at python. People don't see it as big because it does not have an IDE that asks you to select projects and what not, making it seem like it is a tool small enough for their work. However, if you combine every library or framework that covers what .NET does in Python (Web, Desktop, Gaming, System, ML) you will find Python is also just as large.
- luuio 5y ago
  I have the same experience as the parent comment. For example, I wanted to have a process that runs both the asp.net service, a background discord bot, and another asp.net service. On any other platform, it's just a good old "console app" equivalent, and you can start multiple services in your main function, catch SIGTERM, and control each service on your own. On .NET, the project type has to be some weird Microsoft.Web.SDK things if you wanna run asp.net, and the IDE/build system would figure out what dependencies to build. And if I wanna run other services in the same binary, tough luck. Why can't ASP.NET just be constructed as a regular console app, where you pull in nuget dependencies, instead of a completely different app type, for example.
  - kumarvvr 5y ago
    https://www.syncfusion.com/blogs/post/how-to-develop-an-asp-net-core-application-using-visual-studio-code.aspx/amp https://www.syncfusion.com/blogs/post/how-to-develop-an-asp-...
    - deleted 5y ago
      [deleted]
    - luuio 5y ago
      Huh? I don't think you read what I'm saying. Here's a simple challenge for you. Create a command line app (your csproj file should say Sdk="Microsoft.NET.Sdk"), ask the user to input a port number at runtime. Use this port number to start an ASP.NET service. I have not had any luck to pull all the right nuget dependencies to do that so far. The only way to run asp.net app I could find is switching your whole project to be Sdk="Microsoft.NET.Sdk.Web"
kevingadd 5y ago
I can definitely see the appeal of a simplified .NET lacking a lot of the baggage it has from 21 years. .NET core was an attempt at stripping a lot of stuff out but over time they've had to add stuff back because it turns out telling developers they have to rewrite all their code (or give up on doing things at all) is a bad idea. Node benefits from being a newer ecosystem (~2009) that started out with simpler goals, so it accumulated cruft more slowly. Ecosystems like node also deploy breaking changes more often - .NET 1.0 software can still be run on a modern Windows machine using the latest regular framework, though as of 5.0 they finally decided to kill existing .NET code (the old framework still works, 5.0 and later just use a separate one). I'm personally still writing and maintaining .NET 4.x code and some of it is working stuff I wrote in ~2005 and it has been serving me well that whole time. I have extensive experience with C++, JS, Python etc and C# is still my first choice when it comes time to solve problems (Python is a somewhat distant but still respectable 2nd place - the REPL is great.) From time to time I've been able to solve difficult problems with built-in .NET tooling - I wrote a custom compiler for a DSL from scratch entirely using built-in 4.x features and it can do hot reloading, generate debug information, allow me to set breakpoints in visual studio, etc. I simply can't get this anywhere else.

R0b0t1 5y ago

The .NET frameworks (blazor, etc) are too complicated. Peak FizzBuzzEnterpriseEdition there. The interop layer than you have to go through to do a lot of stuff is actually quite tame. It just needs more time on Linux.

tester756 5y ago
>The interop layer than you have to go through to do a lot of stuff is actually quite tame. It just needs more time on Linux. What do you mean? I have software on prod on Linux for years and the only problem I had was lack of some fonts installed that made some problem when it comes to pdf generation
- R0b0t1 5y ago
  Binding to C/C++ libraries or other system libraries is not something that's well documented, officially. On Windows there's a lot of 3rd party effort that is easily searchable. But for a long time the interop layer was not (and still may not be?) working on Linux. The first iterations of .NET were just for webapps. You could only work with and call .NET code, the only functions provided were basic IO and network.
  - nightski 5y ago
    Hmm, I've been using .NET since beta 1 in 2000. Maybe you had access to earlier bits? It was never just about webapps. In fact, Windows Forms was meant as a more sane MFC if anything. Interop with native code was always very easy. From PInvoke to managed C++ there were a lot of ways to do it with ease. Things have changed but I still think this is one area where .NET has great support.
    - emteycz 5y ago
      They probably mean .NET Core, it's somewhat true in that case.
  - immutology 5y ago
    Native interop in .NET has always been via what they call "P/Invoke". On .NET Core, P/Invoke is cross-platform and you can also call .so/.dylib functions on Linux/MacOS just like you could always call .dll functions on Windows on .NET Framework before we had .NET Core. I'm curious to know what you needed to do with native libraries. I've been programming with .NET around 20 yrs and find it fairly rare that I need to use P/Invoke... But I'm sure it depends on what you're building.
    - withinboredom 5y ago
      I maintain a thingy written in C# that does cool things with keyboard backlights on System76 machines in Linux. Like make the left-third respond to CPU usage, right third blink when you have unread notifications, etc. The biggest one was turning off the keyboard when the screen blanked[1]. Almost all of the fun stuff requires native interop. 1: https://withinboredom.info/blog/2019/11/26/detecting-if-a-screen-is-turned-off-in-linux/ https://withinboredom.info/blog/2019/11/26/detecting-if-a-sc...
    - ok123456 5y ago
      You end up using P/Invoke any time you need to control hardware. In the last few months I needed to use P/Invoke to control cameras, motors, and compute FFTs with the GPU. You need to use them if you need to control raw GDI objects like bitmaps.
userbinator 5y ago
That's the normal Java culture, which is not surprising given that MS created .NET as a competitor to Java.
Shalomboy 5y ago
> The .NET frameworks (blazor, etc) are too complicated. Peak FizzBuzzEnterpriseEdition there. I dunno, Blazor feels like the one ASP framework that makes sense. MVC, Web Apps, Web Forms all feel impenetrable to me.
kumarvvr 5y ago
Blazor IMV is more sane than React. It is an SPA that is structured around routing and pages, which happen to have component hierarchies in them. React is the other way around. Routing in React seems to be an afterthought. And I hate it with a passion. Page based way of thinking (or "screens" if you will) is a better way to do web dev. Also, the Dependency Injection system is extremely productive. State management in Blazor is very easy and a breeze to use. If not for the intricacies of hosting models, and a slightly large default build size for the full WASM client mode, Blazor would have replaced React / Angular / Vue by now.
- starik36 5y ago
  > Dependency Injection system is extremely productive Sure, but there is a downside to it. You want to add a feature to the class that uses DI? Great, just add an injected object to the constructor. Except now a 100 unit tests broke because you changed the constructor. A 10 minute functionality change turns into a massive cut and paste operation in your Tests project.
  - deleted 5y ago
    [deleted]
  - kumarvvr 5y ago
    Sorry, if tests are not adaptable to changing code, why are they called tests? I thought tesring was to check software,not be a constraint on software development. Also, I think using DI in the test process itself will mitigate the issue.
    - spaetzleesser 5y ago
      Some tests are not adaptable to changing code because of the way MS uses DI. A lot of DI is done by adding new parameters to the constructor. It’s the same with async. Needing an async function somewhere can result in a huge cascade of changes.
      - 5y ago
hackerfromthefu 5y ago
Compared to JS SPAs such as React/Vue/Angular, Blazor obviates a huge amount of toolchain complexity, multi-language and transpilation impedance, and jank of leaky abstractions building a component model on top of Javascript. Having worked with a mix of these, I found Blazor to be clearly much simpler, approaching though not quite reaching the simplest possible implementation for a component based UI. I think it's probably more a matter of what you are used to than inherent complexity. The things you are familiar with seem 'easy' and the unknown seems 'hard'. Stick with it, it really pays dividends when you get good at it!

deleted 5y ago

[deleted]

kumarvvr 5y ago

I find this very intriguing. As a runtime, .NET exposes a lot of high and low level stuff to the developer. Can you give me an example of this offbeat thing you wanted to do that involves overriding an obscure interface? .NET is big, but if you are using it for web app, your focus is only on that set of libraries. Comparing with similar stacks, none of them cover the area .NET covers. Also, look at python. People don't see it as big because it does not have an IDE that asks you to select projects and what not, making it seem like it is a tool small enough for their work. However, if you combine every library or framework that covers what .NET does in Python (Web, Desktop, Gaming, System, ML) you will find Python is also just as large.

luuio 5y ago
I have the same experience as the parent comment. For example, I wanted to have a process that runs both the asp.net service, a background discord bot, and another asp.net service. On any other platform, it's just a good old "console app" equivalent, and you can start multiple services in your main function, catch SIGTERM, and control each service on your own. On .NET, the project type has to be some weird Microsoft.Web.SDK things if you wanna run asp.net, and the IDE/build system would figure out what dependencies to build. And if I wanna run other services in the same binary, tough luck. Why can't ASP.NET just be constructed as a regular console app, where you pull in nuget dependencies, instead of a completely different app type, for example.
- kumarvvr 5y ago
  https://www.syncfusion.com/blogs/post/how-to-develop-an-asp-net-core-application-using-visual-studio-code.aspx/amp https://www.syncfusion.com/blogs/post/how-to-develop-an-asp-...
  - deleted 5y ago
    [deleted]
  - luuio 5y ago
    Huh? I don't think you read what I'm saying. Here's a simple challenge for you. Create a command line app (your csproj file should say Sdk="Microsoft.NET.Sdk"), ask the user to input a port number at runtime. Use this port number to start an ASP.NET service. I have not had any luck to pull all the right nuget dependencies to do that so far. The only way to run asp.net app I could find is switching your whole project to be Sdk="Microsoft.NET.Sdk.Web"

kevingadd 5y ago

I can definitely see the appeal of a simplified .NET lacking a lot of the baggage it has from 21 years. .NET core was an attempt at stripping a lot of stuff out but over time they've had to add stuff back because it turns out telling developers they have to rewrite all their code (or give up on doing things at all) is a bad idea. Node benefits from being a newer ecosystem (~2009) that started out with simpler goals, so it accumulated cruft more slowly. Ecosystems like node also deploy breaking changes more often - .NET 1.0 software can still be run on a modern Windows machine using the latest regular framework, though as of 5.0 they finally decided to kill existing .NET code (the old framework still works, 5.0 and later just use a separate one). I'm personally still writing and maintaining .NET 4.x code and some of it is working stuff I wrote in ~2005 and it has been serving me well that whole time. I have extensive experience with C++, JS, Python etc and C# is still my first choice when it comes time to solve problems (Python is a somewhat distant but still respectable 2nd place - the REPL is great.) From time to time I've been able to solve difficult problems with built-in .NET tooling - I wrote a custom compiler for a DSL from scratch entirely using built-in 4.x features and it can do hot reloading, generate debug information, allow me to set breakpoints in visual studio, etc. I simply can't get this anywhere else.