C# development is incredibly efficient to be fair.
Have you considered not asking questions based on conjecture? No it isn’t because we are inefficient. It’s a mix of staff come first and the work comes second and a lack of greed I’d say. Most of our work comes from word of mouth and we keep client for as long as they’ll stay with us.
If a client reads a spec and get the application described and decides it’s not right we will change it for them for free to build a relationship. Which is why we get more and more requests to work with us.
As someone who has worked with a pretty large C# codebase and several smaller ones, I’ve found it to be one of the least efficient languages to program in. This is maybe not a technical fault of the language, but the way Microsoft encourages developing C# means that once you get past a certain point even simple MRs will have 10-20 files changed. There is sooooooooo much boilerplate caused by .NET that even things like Java Spring Boot just don’t have (and even then I’d consider Java to be a pretty bloated language in terms of boilerplate).
That’s ignoring the fact that the ecosystem surrounding .NET is a lot more enterprise-y, meaning a good portion of libraries require paid licenses to use.
Yeah, I totally get where you’re coming from. I think it depends on what you mean by ‘efficient.’ If we’re talking about runtime performance and memory management, C# and .NET are generally very efficient: JIT compilation, span/memory optimisations, and the garbage collector all make it competitive with Java in most workloads.
Where I agree with you is in developer efficiency: .NET projects can definitely get heavy with boilerplate, especially in enterprise setups with lots of layers, dependency injection, and config-heavy patterns. That’s not necessarily a language issue, but more a combination of the framework conventions, Microsoft’s enterprise guidance, and patterns like MVC/WebAPI scaffolding.
Have you considered that you might have too much work simply because these tools are inefficient?
C# development is incredibly efficient to be fair.
Have you considered not asking questions based on conjecture? No it isn’t because we are inefficient. It’s a mix of staff come first and the work comes second and a lack of greed I’d say. Most of our work comes from word of mouth and we keep client for as long as they’ll stay with us.
If a client reads a spec and get the application described and decides it’s not right we will change it for them for free to build a relationship. Which is why we get more and more requests to work with us.
As someone who has worked with a pretty large C# codebase and several smaller ones, I’ve found it to be one of the least efficient languages to program in. This is maybe not a technical fault of the language, but the way Microsoft encourages developing C# means that once you get past a certain point even simple MRs will have 10-20 files changed. There is sooooooooo much boilerplate caused by .NET that even things like Java Spring Boot just don’t have (and even then I’d consider Java to be a pretty bloated language in terms of boilerplate).
That’s ignoring the fact that the ecosystem surrounding .NET is a lot more enterprise-y, meaning a good portion of libraries require paid licenses to use.
Yeah, I totally get where you’re coming from. I think it depends on what you mean by ‘efficient.’ If we’re talking about runtime performance and memory management, C# and .NET are generally very efficient: JIT compilation, span/memory optimisations, and the garbage collector all make it competitive with Java in most workloads.
Where I agree with you is in developer efficiency: .NET projects can definitely get heavy with boilerplate, especially in enterprise setups with lots of layers, dependency injection, and config-heavy patterns. That’s not necessarily a language issue, but more a combination of the framework conventions, Microsoft’s enterprise guidance, and patterns like MVC/WebAPI scaffolding.
Eh C# GUI development is quite productive. I don’t think you’d get such a pleasant experience on Linux.