3 ms·

> .NET isn’t open source friendly The language runtime might technically be open source, but it’s got a huge number of closed-source packages and the ecosystem

> .NET isn’t open source friendly The language runtime might technically be open source, but it’s got a huge number of closed-source packages and the ecosystem appears to be only begrudgingly open source. > It’s slower than Node/Python/Go/Rust One of 2 of these things, aren’t like the others. I’d believe modern .net can outpace Python, but matching or outpacing Rust is something I’d have a hard time believing, especially in the “vast majority of code” sense-I’m aware that .net can be written to stack allocate everything. I’m also aware that basically no .net code I’ve ever seen in business world has ever done that (precluding games here, because I’ve not worked with them). > It’s for boomer enterprise development Yes. Uncharitable presentation and framing, but yes. Every single place I’ve worked at that has used .Net has had the same attitude and approach to solving problems and writing code. Use Kafka for our events like every other company in industry? Nah, use some bizarre MS thing that nobody outside of .Net has heard of or can use. Use websockees or SSE? Nah, use some bizarre .Net version instead. Use Postgres because it’s more than good enough and other teams might need to use the database? Nah MSSQL, and all the tables are named and optimised according to EntityFramework and if you have to suffer through ODBC issues that’s a you problem! Never mind the obtuse naming and the dogged insistence on dependency injection at every possible turn. Am I not a fan of .Net? Correct. Is it because every time I’ve had to touch it, it’s a painful and frustrating experience.

radicalbyte 5y ago
You know that Rx in .Net kind of inspired all of the popular reactive libraries/frameworks, right? Other than that: if you go to a .Net shop who want Microsoft Certified Developers and you expect anything than low quality-stay-on-the-Enterprise-support-contract-rails then that's the problem. > Nah MSSQL, and all the tables are named and optimised according to EntityFramework and if you have to suffer through ODBC issues that’s a you problem! That's not in any way true - it's an ORM and it can handle any database naming scheme you happen to have. I still wouldn't use it - ORMs in general are a bad idea outside of a couple of use-cases (i.e. CRUD-heavy systems).
Salgat 5y ago
Look up the Microsoft Community/Open Specification Promise and their patent promise https://github.com/dotnet/runtime/blob/main/PATENTS.TXT https://github.com/dotnet/runtime/blob/main/PATENTS.TXT .NET Core is open source, free, and comes with the guarantee of no litigation from Microsoft. As far as the ecosystem, it fully embraces open source too. At my company, all .net libraries we use are free and open (AWS, Consul, Elasticsearch, EventStore, Kubernetes, etc).
cerved 5y ago
A lot of valid points. I think CSharp is a very nice language, I think dotnet has potential but there's a lot of rotten tertiary layers in the onion
aliswe 5y ago
> Never mind ... the dogged insistence on dependency injection at every possible turn. You will do yourself and your career a favor if you learn it!
- FridgeSeal 5y ago
  I did learn it when I wrote .Net. I understand it fine, but I think it's far too situational, and greatly overrated. There's so much focus on "abstraction magic" and a desire to avoid admitting you have a dependency or daring to ever actually implement something. It made writing code and debugging code more annoying (everything shows up with "0 references" in VS because...it's all behind DI magic). To say nothing of the verbose, boilerplate setups for it, which were closer to actual incantations than logical code. I'm sure there's more lightweight ways of doing it, or we should have used a different DI tool, or it shouldn't be done x/y/z-way anymore, but the reality of most DI-afflicated .Net code that I've had to deal with is that it's never done 'well' and all it did was add noise and code that was more difficult to write, debug and maintain. It falls in the same bucket as most of those other OOP/SOLID/design-pattern principles - half-decent situational guidelines for software that morphed into what amounts to 'holy covenants' that must be strictly applied at all turns.
  - DeathArrow 5y ago
    > It made writing code and debugging code more annoying (everything shows up with "0 references" in VS because...it's all behind DI magic). VS shows all references for code, even if the code is called through DI. If you highlight a method call or a property and press CTRL+F12, you will actually jump to implementation. >It falls in the same bucket as most of those other OOP/SOLID/design-pattern principles - half-decent situational guidelines for software that morphed into what amounts to 'holy covenants' that must be strictly applied at all turns. I actually dislike GoF patterns, SOLID, Uncle Bob principles and OOP in general, but DI in .NET is quite decent now. Maybe your experience is from old .NET Framework. What language have you moved on?
    - FridgeSeal 5y ago
DeathArrow 5y ago
We used .NET for writing microservices running in Kubernetes. We used Elasticsearch and Kibana to store and search logs. As data stores we used Postgres and Redis. Consul was used for configuration. For mesagging we used NATS as Kafka was too fat and slow.

radicalbyte 5y ago

You know that Rx in .Net kind of inspired all of the popular reactive libraries/frameworks, right? Other than that: if you go to a .Net shop who want Microsoft Certified Developers and you expect anything than low quality-stay-on-the-Enterprise-support-contract-rails then that's the problem. > Nah MSSQL, and all the tables are named and optimised according to EntityFramework and if you have to suffer through ODBC issues that’s a you problem! That's not in any way true - it's an ORM and it can handle any database naming scheme you happen to have. I still wouldn't use it - ORMs in general are a bad idea outside of a couple of use-cases (i.e. CRUD-heavy systems).

Salgat 5y ago

Look up the Microsoft Community/Open Specification Promise and their patent promise https://github.com/dotnet/runtime/blob/main/PATENTS.TXT https://github.com/dotnet/runtime/blob/main/PATENTS.TXT .NET Core is open source, free, and comes with the guarantee of no litigation from Microsoft. As far as the ecosystem, it fully embraces open source too. At my company, all .net libraries we use are free and open (AWS, Consul, Elasticsearch, EventStore, Kubernetes, etc).

cerved 5y ago

A lot of valid points. I think CSharp is a very nice language, I think dotnet has potential but there's a lot of rotten tertiary layers in the onion

aliswe 5y ago

> Never mind ... the dogged insistence on dependency injection at every possible turn. You will do yourself and your career a favor if you learn it!

FridgeSeal 5y ago
I did learn it when I wrote .Net. I understand it fine, but I think it's far too situational, and greatly overrated. There's so much focus on "abstraction magic" and a desire to avoid admitting you have a dependency or daring to ever actually implement something. It made writing code and debugging code more annoying (everything shows up with "0 references" in VS because...it's all behind DI magic). To say nothing of the verbose, boilerplate setups for it, which were closer to actual incantations than logical code. I'm sure there's more lightweight ways of doing it, or we should have used a different DI tool, or it shouldn't be done x/y/z-way anymore, but the reality of most DI-afflicated .Net code that I've had to deal with is that it's never done 'well' and all it did was add noise and code that was more difficult to write, debug and maintain. It falls in the same bucket as most of those other OOP/SOLID/design-pattern principles - half-decent situational guidelines for software that morphed into what amounts to 'holy covenants' that must be strictly applied at all turns.
- DeathArrow 5y ago
  > It made writing code and debugging code more annoying (everything shows up with "0 references" in VS because...it's all behind DI magic). VS shows all references for code, even if the code is called through DI. If you highlight a method call or a property and press CTRL+F12, you will actually jump to implementation. >It falls in the same bucket as most of those other OOP/SOLID/design-pattern principles - half-decent situational guidelines for software that morphed into what amounts to 'holy covenants' that must be strictly applied at all turns. I actually dislike GoF patterns, SOLID, Uncle Bob principles and OOP in general, but DI in .NET is quite decent now. Maybe your experience is from old .NET Framework. What language have you moved on?
  - FridgeSeal 5y ago

DeathArrow 5y ago

We used .NET for writing microservices running in Kubernetes. We used Elasticsearch and Kibana to store and search logs. As data stores we used Postgres and Redis. Consul was used for configuration. For mesagging we used NATS as Kafka was too fat and slow.