Live data from Hacker News

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

andrewlock.net

281–290 of 357 posts

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

#281

I spent a lot of time as a Java developer and have recently moved into a spot where I'm being asked to work with C#. A few things rub me the wrong way, and I'm wondering if it's just ignorance and / or me being stuck in my old ways. - 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 mone…

> There is no mocking of concrete implementations That's an obvious anti-pattern in the first place, especially when you know the optimizer could inline hot code and optimize the function out. > Everything feels a lot more corporartized or tied to Microsoft Remember J2EE and the confusing javax stuff? They're the same and fortunately both are waning out. > The open source ecosystem and tooling around C# isn't to the…

The Oracle situation doesn’t get heated at all, and that’s just not how Java vendors work — basically everything is 100% open-source OpenJDK, some companies just take it, add some marketing bullshit, possibly backport some bugfixes for older versions, and sell a support license for their “vendor”.

It is pretty much what Red Hat Linux does to linux.

Here I expanded a bit more on the topic: https://news.ycombinator.com/item?id=35249701

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

#282
post #274

Earlier quoted context omitted.

Jetbrains Rider is great for .NET too, although I didn't try backend developement with it.

Except botched C# style rules. Rider still insists on Java style guidelines for .net projects. And sometimes, it spawns a never ending background process that only way to get rid of is to restart the app. Otherwise, it's okay. edit: been using Rider on Linux since a few years now

> Rider still insists on Java style guidelines for .net projects.

No, it uses Resharper as the backend.

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

#283
post #232

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?

I think it's just: builder.Configuration.AddEnvironmentVariables(); Then you can use an env variable like "Foo__Bar=X" to override Foo.Bar from your appsettings json.

If using the default builder, environment variables are included automatically as a configuration provider.

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

#284
post #226
post #104

Earlier quoted context omitted.

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.

For me Blazor is a mess. It’s component system is even worse then Angular, a complete OOP-mess. Yes it’s easy to use, but some things don’t work and it takes ages to find out why.

I prefer next.js for the frontends.

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

#285
post #193
post #105

Earlier quoted context omitted.

Maybe also check PetaPoco. But at this point you're getting closer and closer to code-first EF Core anyway. :) https://github.com/CollaboratingPlatypus/PetaPoco

I haven't actually tried either Dapper or PetaPoco, only perused their documentation. But I was sold on LinqToDb after seeing how it supported CTE and seeing our close code to generate updates [1] and joins [2] ended up looking like the actual intended SQL. [1]: https://linq2db.github.io/#update [2]: https://linq2db.github.io/articles/sql/Join-Operators.html

"seeing how close"

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

#287

F# also is kicking ass. Were running .NET 6 + F# in production with ~4 developers and its been a breeze.

Exactly the same boat. About to switch to a C# role, so not exactly a world of difference, but I am going to miss F#. I can't help but feel that the success of our small team is majorly down to F# and the traps it helps you avoid.

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

#288
post #273

Earlier quoted context omitted.

I'm not sure it's 10x as nice as competitors, which is the context here. If it were just about space who cares, but when your competitor does the exact same at a much smaller size and ultimately better price too, it's a little confusing what is going on with VS.

The competitor doesn't ship a full OS SDK for all kinds of development. Go see how much GB, Apple or Android development stacks require.

    $ pacman -Qi emacs | grep Size 
    Installed Size  : 111,46 MiB

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

#289
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…

> I was surprised how much was included and "just worked". 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 a…

You can just use Kestrel without anything else.

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

#290
post #274

Earlier quoted context omitted.

Jetbrains Rider is great for .NET too, although I didn't try backend developement with it.

Except botched C# style rules. Rider still insists on Java style guidelines for .net projects. And sometimes, it spawns a never ending background process that only way to get rid of is to restart the app. Otherwise, it's okay. edit: been using Rider on Linux since a few years now

I've been using Rider style rules for two years now exclusively in a VS based team and aside from some linebreak rules I need to tweak here and there I've seen no issues ?

But I use a .editorconfig tuned stylecop and roslynator on all projects so maybe that overrides some defaults.

Mind sharing which Java style rules are you seeing ?

Post reply on HN