Live data from Hacker News

Understanding the .NET ecosystem: The evolution of .NET into .NET 7

andrewlock.net

221–230 of 357 posts

Re: Understanding the .NET ecosystem: The evolution of .NET into .NET 7

#221
post #26

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.

> Right now EF Core is probably the best ORM that has ever existed. What exactly is missing? Wish I could agree but they would have to fix the very slow time to first query when using big models (+500 tables in our case). Compiled models is not a solution for us since our model changes a lot and the compilation is just as slow. It's disappointing because it used to work fine under the ancient Linq2SQL library.

Can't you generate the compiled model as part of the CI/CD?

Also maybe you might find a benefit from splitting your context into multiples. I am considering this option for one of my code bases

Re: Understanding the .NET ecosystem: The evolution of .NET into .NET 7

#222
post #72

Odd question maybe, my company uses C# and I've been picking up more backend responsibilities. However, I'm a Linux and Neovim user. I do have Windows and Visual Studio available but I just find it awkward. Is anyone here having success with Linux and Neovim for C#? Even trying to learn more about the language is awkward as so many resources go straight into VS.

I mostly work with Powershell, but dabble in C#. Both omnisharp and the Powershell CoC plugins for Neovim seemed to break often. I've switched to VS Code for Powershell and Visual Studio for C#, as sad as that makes me.

Re: Understanding the .NET ecosystem: The evolution of .NET into .NET 7

#223

Earlier quoted context omitted.

… how often are you hand-parsing HTTP requests and hand-crafting HTTP responses one character at a time? Productive devs want the request/response wrapper objects and routing constructs to handler methods to get work done and can still drop down into fine-grained request/response crafting as and when required.

> how often are you hand-parsing HTTP requests That's exactly what I don't do, and what I want to see available in a standard library. But I quite frequently implement custom request handling before any routing happens (if there's even any routing). That's super easy to do in Go, Python or Rust, but when I needed something comparable in C# I haven't found any similar composable independent pieces that I can join toge…

As a sibling commenter mentioned, there’s a minimalist functional web server available out of the box, that can later have other more complex components added on:

https://learn.microsoft.com/en-us/aspnet/core/tutorials/min-...

It’s .NET 101 stuff.

Re: Understanding the .NET ecosystem: The evolution of .NET into .NET 7

#224

.NET has been doing a lot of things right. My startup's codebase is nearly all .NET 7: landing page, web app, Windows service, API. The main non-.NET code is vanilla JS in the web app. I've been keeping a close eye on Next.js, which is very well done, but I love how versatile .NET is. With one language, I can write all of the above, and my dependencies are minimal thanks to .NET's rich standard library - a refreshing…

How do the costs of running the .NET 7 codebase compare with running something open? I like .NET a lot, have worked with it a lot in the past. But when I tried my own startup, I picked node instead and don't really regret it. I'm getting back into .NET these days though at a new job again, and .NET 7 will be interesting to dive into. Still not sure I'd want to be that tightly-coupled to Microsoft subscriptions though…

It's just like any other containerized Linux app. The only thing worth noting, that base asp net core api will idle like 200mb memory.

Re: Understanding the .NET ecosystem: The evolution of .NET into .NET 7

#225
post #12

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…

nestjs provides a comparable experience for nodejs as well

It's been a few years (2018?) since I used NestJS but back then our experience with it was far from stellar. It lacked documentation beyond the basic "getting started" examples (just checked, it doesn't seem like they've improved much on that front), it had quite a few footguns and as soon as we strayed off the beaten path, things tended to become painful, especially on the GraphQL side of things and general 'plumbing' like interceptors, schemas, and data validation.

Internal error handling was sometimes abysmal too, a misconfiguration of certain dependencies in `AppModule` could leave the application in a broken state on startup where it wouldn't bind to its port and no error messages were printed to console. On a few occasions I had to spend an hour or more reading and understanding NestJS source code to resolve those issues, which could have been avoided if they had better internal validation and error logging in place.

That's not to say it was all terrible, some aspects of it were genuinely good, but the overall experience and many hours of needless pain it caused left a really bad taste in my mouth. Back then, at least, it felt like a Lego set where the pieces didn't all quite fit together.

Depressingly enough, it seemed like NestJS was the best that Node.js world had to offer which made me quit the ecosystem altogether.

Re: Understanding the .NET ecosystem: The evolution of .NET into .NET 7

#226
post #104
post #12

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…

The new asp.net took a lot of good concepts from the node ecosystem and feels really modern. It has a lot of batteries included. I think .net is an awesome platform to build backends. I wouldn’t use it for frontend though. Razor and Blazor never really convinced me.

Blazer Server is perfect for internal applications and dashboards though. It's just so easy to use, especially if you plug in any of the community made component libraries like MudBlazor. I had pure backend devs actually happily make frontend for once. It's essentially Phoenix's LiveView but in C# and that uses already proven SignalR.

Re: Understanding the .NET ecosystem: The evolution of .NET into .NET 7

#227
post #144

Earlier quoted context omitted.

Can you install it [edit: the .Net 7/8 platform that sounds interesting, not the IDE] for free on a Linux server and get the same benefits? (This isn't advocacy, it's a literal question about something I don't know.)

Yes: https://learn.microsoft.com/en-us/dotnet/core/install/linux Also VS Code, an open source IDE with first class support for .NET languages: https://code.visualstudio.com/docs/setup/linux

Also emacs has a pretty good csharp language server integration. I personally use the Spacemacs "dotnet" layer.

Re: Understanding the .NET ecosystem: The evolution of .NET into .NET 7

#228

Earlier quoted context omitted.

Yes, everything is completely free, open source.

Everything but the debugger sadly

I know! How crap is that? As a result, no debugging on a Raspberry PI.

It turned me right off C# outside of work. There are plenty of other languages that are better suited for hobby development.

Re: Understanding the .NET ecosystem: The evolution of .NET into .NET 7

#229

.NET has been doing a lot of things right. My startup's codebase is nearly all .NET 7: landing page, web app, Windows service, API. The main non-.NET code is vanilla JS in the web app. I've been keeping a close eye on Next.js, which is very well done, but I love how versatile .NET is. With one language, I can write all of the above, and my dependencies are minimal thanks to .NET's rich standard library - a refreshing…

How do the costs of running the .NET 7 codebase compare with running something open? I like .NET a lot, have worked with it a lot in the past. But when I tried my own startup, I picked node instead and don't really regret it. I'm getting back into .NET these days though at a new job again, and .NET 7 will be interesting to dive into. Still not sure I'd want to be that tightly-coupled to Microsoft subscriptions though…

.NET IS open and not really tied to any Microsoft Subscription. I really hate when people keep parroting that without understanding. Rider is nowadays a better IDE for C# and it's not owned by Microsoft. You can host it wherever because it runs wherever.

Re: Understanding the .NET ecosystem: The evolution of .NET into .NET 7

#230
post #211

Earlier quoted context omitted.

I have been having a ridiculous time trying to find out just how to override an appsettings json variable (DBConnection string) with an environment variable. Could not find any good answer. What is the right way?

Configuration is applied in layers. If you’re using the default setup you get the following layers applied in this order: 1. appsettings.json 2. appsettings.{env}.json 3. user secrets (only in Development environment) 4. environment variables 5. command line args You can full customize the setup if you desire, there are packages to support things like external secret stores. If you Google ‘Asp.Net core configuration”…

Awesome overview, stuff like this is often hard for newcomers to find/figure out. I'm sure it's in the docs somewhere but people often miss it.

One nitpick: environment vars don't have to be capitalized. You can do ConnectionStrings__MyConnection so the casing matches what you see in appsettings.json.

And a word of warning: make sure to understand how the configuration overrides work. If you have appsettings.json define an array of auth servers with 5 elements, then in appsettings.Production.json (or env variables) define an array of auth servers with only 1, auth servers 2-5 from the default appsettings.json will still be there! (something similar to this may or may not have caused a scare in the past)

Post reply on HN