121–130 of 357 posts
I love c# and dotnet. I've been holding off on flutter and praying Maui becomes a real thing
Not sure about Xaml based Maui...that may well go the way of Silverlight.
Been using .NET for years now for backend web development after having taken a break from C#. It is such an improvement over the old .NET framework. When I started building my first backend with it, I was surprised how much was included and "just worked". Need to add authentication? Few lines. OAuth? Also built in. Response caching? Yes. ORM? EF Core is pretty good. Need to use env variables to override your JSON con…
A simple HTTP server? Maybe I'm missing something, but when I needed it I hadn't found one.
I believe, the closest it has is System.Net.HttpListener which is a very different thing from your typical Golang's net/http.Server or python's http.server.HTTPServer.
I believe at some point they had switched from HTTP.sys to Kestrel, so at least it doesn't need the admin privileges anymore. But this whole thing is so much related to ASP.NET it's pretty hard to figure out how to create a simplest HTTP server without anything else forced upon you (no services, no "web applications", no router, just plain and simple bare HTTP protocol handler). So my impression is that maybe .NET can make certain complex things easy, but it has some issues with keeping simple things simple.
[flagged]
But .NET 4.8.2 isn't the right name, is it? It's .NET Framework 4.8.2. .NET Standard 2.0 has also been around for six years now, so the upgrade path has been around for a while.
Earlier quoted context omitted.
>We're moving to .Net, and I was surprised by how poor the built-in DB stuff is Right now EF Core is probably the best ORM that has ever existed. What exactly is missing? Although for performance you would probably reach for something like Dapper but that is not an ORM.
For performance, .NoTracking() and not calling .SaveChanges() on every loop already does wonders. I usually call .SaveChanges() when i % 20 == 0
Earlier quoted context omitted.
Well that was my point, either you're writing a lot of code yourself ("assembly"), or you use EF ("Python"). We're not used to something like EF, perhaps it would work for us. But debugging generated queries due to performance issues is something we'd like to avoid. For now the decision was made to not use EF.
You can use EF Core also with plain SQL queries, if you don’t like/trust the query builder. You can also disable change tracking completely, if you prefer to only INSERT/UPDATE directly with SQL statements. You get a lot of awesome features, but nobody forces you to use them.
Earlier quoted context omitted.
> Usually non-technical persons do not give a faint fart about ‘major’ ‘version numbers’. This type of user is actually usually, IME, easier to explain it to: “It’s a different platform and our software will not work without changes”. The less they “give a faint fart” about details, the easy it is to tell them the effects and have them accept and move on. At most, you might occasionally need to invoke a car analogy:…
The different platform argument was easy to make when it was called ".NET Core". Almost impossible to make when it's also called ".NET", quite deliberately.
I get that techies sometimes have preferences for perfect and eternal backward compatibility within a named product line, but trying to pass this off with “how will you explain this to non-techies”, and then treating non-techies as both more ignorant and more concerned with technical details than they are, is not a good way to promote that preference.
Earlier quoted context omitted.
For performance, .NoTracking() and not calling .SaveChanges() on every loop already does wonders. I usually call .SaveChanges() when i % 20 == 0
We'll need tracking (if I understand correctly, we need previous values). When calling SaveChanges often, how do you handle rollback in case something fails?
- Unit testing with mocking is kludgy compared to Java and Kotlin (Moq vs Mockito). There's no mocking of concrete implementations for technical reasons, perhaps unless you shell out money for a paid product. This leads to folks putting interfaces everywhere so that code is testable.
- Along the lines of the above, everything feels a lot more corporatized or tied to Microsoft. The open source ecosystem and tooling around C# isn't to the same level of the JVM langs.
- The project structure feels odd. Solutions hide a lot of files from you, whereas JVM langs generally show what's actually there.
When it comes to actually writing implementations, I don't mind it, and it's far ahead of, say, Java 8. ASP.net might even be ahead of Spring in a few ways. But with Java 20 and Kotlin around, I don't feel compelled to move to it as a new default.
My big problem with .NET is that a lot of line-of-business apps were written using ASP.NET Web Forms, but there is no upgrade path other than “rewrite most of it”. It feels like the pain everyone went through upgrading from Python 2 to Python 3. It also doesn’t help that .NET Framework has its support cycle tied to the OS, and hence is 10+ years. This means that businesses can be lazy and just leave these old apps to…
The writing was on the wall a long, long time ago! These companies had 15 years to do it. And it was fairly easy to get webforms + MVC running side-by-side on the same site so you could gradually migrate. Too late for that now though, you can't run webforms + MVC Core side-by-side. You could put a load balancer in front of the old app and start moving end points to a new code base. It's akin to moaning that MS haven'…
I pointed this out in 2013 only to be literally shouted down by my manager. I did so again in 2017 under a different manager on the same team with the suggestion that we investigate using SPAs and RESTful frameworks only to be told that Razor Pages was the way forward which, while an improvement, didn't do any wonders for our ability to attract/build technical talent or create rich user experiences.
As a sibling comment points out (in a sentiment that I've echoed on HN before):
> ASP.NET Web Forms are a complete trainwreck and an abuse of HTTP and other basic web development standards (e.g. by using javascript: URLs and POSTing forms for every single interaction with the page). It is broken by design.
You can probably see why developers that chose this framework in the first place aren't interested in upgrading... learning actual web standards and state management isn't something they wanted to do in the first place.