6 ms·

I'm a newcomer, having been forced to use .NET for work. I really wanted to keep an open mind. But I really can't recommend .NET for web development to anybody.

I'm a newcomer, having been forced to use .NET for work. I really wanted to keep an open mind. But I really can't recommend .NET for web development to anybody. Performance is really the only benefit, and that only gets relevant if you can circumvent or take all the downsides. I really like F# as a language, but C# doesn't really do it for me. Everything else I've seen is very far behind Django/Python and probably PHP, Ruby, Go and Java, though I have less familiarity with those. Documentation and ecosystem certainly. EF as an ORM is a disappointment. Writing REST APIs is at least five to ten times as cumbersome and a lot more annoying. And I have to struggle a lot more to find libraries and support. And it's not just a problem of being anti-Microsoft. Microsoft is running the show and can decide virtually anything (but not everything). You have to be Ok with that, whatever that means for you and your business.

GOATS- 5y ago
This is really interesting to me. I was also forced to use .NET for work a few months ago, but coming from Python, I found that I tend to like rather than dislike most of the differences between the ecosystems. The whole ordeal with the enterprise application structure was a hassle for me to begin with, but after some mentoring and guidance from a senior developer, it all made sense in the end, and I started to apply the same kind of structure in my Flask projects. What is it that you found C# to be lacking in compared to what we're used to in the Python world?
- bayesian_horse 5y ago
  For me Flask is obsolete. If I want a feature-rich web framework I go with Django, if I want (more) performance and simplicity, I go with FastAPI. Comparing .NET to Flask is much easier on .NET, since it doesn't have all those Batteries included and yet doesn't reap the benefits from an async/type annotation approach like FastAPI.
- bayesian_horse 5y ago
  In general, I miss all the readability, conciseness, documentation, availability of third party packages... Also Django Rest Framework makes it a lot easier to get up and started.
thrower123 5y ago
Frankly, ASP.NET is just too full of magic. I forget sometimes how bad and confusing it is because I'm still mostly using NancyFx, which has a much simpler and explicit way of defining routes.
- oaiey 5y ago
  Try minimal apis. Is not nancyfx archived?
  - GordonS 5y ago
    It is, yes, and because everything Nancy did, ASP.NET Core can now do - it really is a vast improvement over the old ASP.NET. There is another OSS project, Carter, that builds on the ASP.NET Core goodness, allowing you to define endpoints the same way as you did in Nancy.
5e92cb50239222b 5y ago
> EF as an ORM is a disappointment How come? It's one of the few things I'm really missing since switching most of my development work away from dotnet. EF Core + LINQ give you type-safe and very compact queries. I don't think there's anything similar for Hibernate, for example: there is JPA Specification API with metamodel generation. The idea is very similar, but with much more boilerplate.
- thefz 5y ago
  Same experience here. Used EF as code-first and structuring queries with LINQ has been a breeze. Really really enjoyed working with it.
- melolife 5y ago
  There are three problems than an ORM should solve to some degree: 1. Type safety/refactorability 2. Composability (can I reuse my queries) 3. Expressivity (can I generate the queries I want) Of these, EF only solves the first, which is far and away the easiest of the three. Composability in EF is possible via expression tree splicing, however it requires such a degree of discipline and insight that I have never seen anyone do it, or even any discussion around it. Like almost everything in the .NET ecosystem, EF makes a bunch of promises that are fantastic for hello world, but are disastrous as your project grows.
  - 5e92cb50239222b 5y ago
    Do you have any specific examples of an ORM that ticks two (or all or three) of these?
    - melolife 5y ago
      It's a hard problem, NHibernate actually came a little bit closer with it's QueryOver API. The most glaring problem with the LINQ API is there is no way to OR two reusable conditions together because the only tool you have is Where. To be clear you can get a long way by abusing EF's willingness to try and interpret arbitrarily complex expressions - it just provides zero tooling or guidance on how to build those expressions. Or projections. It's possible to write a reusable projection for EF like so: class MyTableProjection { public static Expression<Func<MyTable, MyTableProjection>> Expression => t => new MyTableProjection { Id = t.Id, Str = t.Str, Flag = t.Flag }; public int Id { get; init; } public string Str { get; init; } public bool Flag { get; init; } } dbContext.MyTable .Where(...) .Select(MyProjection.Expression) .ToListAsync() But I have never seen anyone do this because it breaks the promise that you magically won't have to write any code or abstractions.
kovac 5y ago
Go really? Last I checked its impossible to write an ORM in go, didn't even have a way to do dynamic routing that I had to implement my own router using a trie. Please.
- tmountain 5y ago
  There's this. https://gorm.io/index.html https://gorm.io/index.html
- bayesian_horse 5y ago
  In my opinion Go and C# scratch one itch in common: being more productive than C(++) but still very performant. But Go has a philosophy of minimal baggage, which is quite the opposite of C#. If that means you can't build a decent ORM, maybe you either don't need an ORM or Go isn't the right fit for that project.
NicoJuicy 5y ago
What's cumbersome? EF is really great, so i don't know what could be a disappointment. ( I'm using code first fyi)
- bayesian_horse 5y ago
  I find myself writing at least 5-10 times as much code compared to Python/Django. With the Django ORM once you design your models you already have at least 80% of the logic for a CRUD REST API, form validation, CRUD admin interface (if you want that), and you can easily integrate all sorts of third party features for almost no effort. Migrations are a bit saner because of the App separation, data migrations are a possible.
  - atraac 5y ago
    You can achieve nearly the same thing by creating your Entities, generating migration from them with a single command, migrating your db with another one(or from code on startup) and returning them directly from Controller's method using DB Context. It's honestly not that much more work. It's far from a recommended approach though... Granted, Django Admin is pretty nice and although there are few nugets that try to achieve that I never found them as easy as in Django.
    - bayesian_horse 5y ago
      At least in the codebase I work on, I need to create an IRequest/IRequestHandler/Validator class triplet for every single endpoint, each in its own files, including all the lines with single braces and using statements for all the magic extension methods and dependency injection constructors. And often I need to add new ViewModels because the mapping doesn't work correctly. DRF is much more convenient.
      - atraac 5y ago
        Well this is because you decided yourself to go that route. Amount of work would be the same in Django if you decided on this particular architecture there. It doesn't change the fact that if you want to do a simple CRUD you can do it equally easy in almost every popular web framework these days, just yolo that shit into your Controller and be done with it. What you're doing is way more maintainable though, especially if you work with an actual team.

GOATS- 5y ago

This is really interesting to me. I was also forced to use .NET for work a few months ago, but coming from Python, I found that I tend to like rather than dislike most of the differences between the ecosystems. The whole ordeal with the enterprise application structure was a hassle for me to begin with, but after some mentoring and guidance from a senior developer, it all made sense in the end, and I started to apply the same kind of structure in my Flask projects. What is it that you found C# to be lacking in compared to what we're used to in the Python world?

bayesian_horse 5y ago
For me Flask is obsolete. If I want a feature-rich web framework I go with Django, if I want (more) performance and simplicity, I go with FastAPI. Comparing .NET to Flask is much easier on .NET, since it doesn't have all those Batteries included and yet doesn't reap the benefits from an async/type annotation approach like FastAPI.
bayesian_horse 5y ago
In general, I miss all the readability, conciseness, documentation, availability of third party packages... Also Django Rest Framework makes it a lot easier to get up and started.

thrower123 5y ago

Frankly, ASP.NET is just too full of magic. I forget sometimes how bad and confusing it is because I'm still mostly using NancyFx, which has a much simpler and explicit way of defining routes.

oaiey 5y ago
Try minimal apis. Is not nancyfx archived?
- GordonS 5y ago
  It is, yes, and because everything Nancy did, ASP.NET Core can now do - it really is a vast improvement over the old ASP.NET. There is another OSS project, Carter, that builds on the ASP.NET Core goodness, allowing you to define endpoints the same way as you did in Nancy.

5e92cb50239222b 5y ago

> EF as an ORM is a disappointment How come? It's one of the few things I'm really missing since switching most of my development work away from dotnet. EF Core + LINQ give you type-safe and very compact queries. I don't think there's anything similar for Hibernate, for example: there is JPA Specification API with metamodel generation. The idea is very similar, but with much more boilerplate.

thefz 5y ago
Same experience here. Used EF as code-first and structuring queries with LINQ has been a breeze. Really really enjoyed working with it.
melolife 5y ago
There are three problems than an ORM should solve to some degree: 1. Type safety/refactorability 2. Composability (can I reuse my queries) 3. Expressivity (can I generate the queries I want) Of these, EF only solves the first, which is far and away the easiest of the three. Composability in EF is possible via expression tree splicing, however it requires such a degree of discipline and insight that I have never seen anyone do it, or even any discussion around it. Like almost everything in the .NET ecosystem, EF makes a bunch of promises that are fantastic for hello world, but are disastrous as your project grows.
- 5e92cb50239222b 5y ago
  Do you have any specific examples of an ORM that ticks two (or all or three) of these?
  - melolife 5y ago
    It's a hard problem, NHibernate actually came a little bit closer with it's QueryOver API. The most glaring problem with the LINQ API is there is no way to OR two reusable conditions together because the only tool you have is Where. To be clear you can get a long way by abusing EF's willingness to try and interpret arbitrarily complex expressions - it just provides zero tooling or guidance on how to build those expressions. Or projections. It's possible to write a reusable projection for EF like so: class MyTableProjection { public static Expression<Func<MyTable, MyTableProjection>> Expression => t => new MyTableProjection { Id = t.Id, Str = t.Str, Flag = t.Flag }; public int Id { get; init; } public string Str { get; init; } public bool Flag { get; init; } } dbContext.MyTable .Where(...) .Select(MyProjection.Expression) .ToListAsync() But I have never seen anyone do this because it breaks the promise that you magically won't have to write any code or abstractions.

kovac 5y ago

Go really? Last I checked its impossible to write an ORM in go, didn't even have a way to do dynamic routing that I had to implement my own router using a trie. Please.

tmountain 5y ago
There's this. https://gorm.io/index.html https://gorm.io/index.html
bayesian_horse 5y ago
In my opinion Go and C# scratch one itch in common: being more productive than C(++) but still very performant. But Go has a philosophy of minimal baggage, which is quite the opposite of C#. If that means you can't build a decent ORM, maybe you either don't need an ORM or Go isn't the right fit for that project.

NicoJuicy 5y ago

What's cumbersome? EF is really great, so i don't know what could be a disappointment. ( I'm using code first fyi)

bayesian_horse 5y ago
I find myself writing at least 5-10 times as much code compared to Python/Django. With the Django ORM once you design your models you already have at least 80% of the logic for a CRUD REST API, form validation, CRUD admin interface (if you want that), and you can easily integrate all sorts of third party features for almost no effort. Migrations are a bit saner because of the App separation, data migrations are a possible.
- atraac 5y ago
  You can achieve nearly the same thing by creating your Entities, generating migration from them with a single command, migrating your db with another one(or from code on startup) and returning them directly from Controller's method using DB Context. It's honestly not that much more work. It's far from a recommended approach though... Granted, Django Admin is pretty nice and although there are few nugets that try to achieve that I never found them as easy as in Django.
  - bayesian_horse 5y ago
    At least in the codebase I work on, I need to create an IRequest/IRequestHandler/Validator class triplet for every single endpoint, each in its own files, including all the lines with single braces and using statements for all the magic extension methods and dependency injection constructors. And often I need to add new ViewModels because the mapping doesn't work correctly. DRF is much more convenient.
    - atraac 5y ago
      Well this is because you decided yourself to go that route. Amount of work would be the same in Django if you decided on this particular architecture there. It doesn't change the fact that if you want to do a simple CRUD you can do it equally easy in almost every popular web framework these days, just yolo that shit into your Controller and be done with it. What you're doing is way more maintainable though, especially if you work with an actual team.