Live data from Hacker News

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

andrewlock.net

321–330 of 357 posts

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

#321

Earlier quoted context omitted.

I've used EF quite a bit in the past. While there may be some features missing, Lucid an ActiveRecord implementation, which I would figure would fall into the "ORM" category. Which features would you say are the key ones that make Lucid seem more like a query mapper (Dapper, Knex) than an ORM (ActiveRecord, EF)? Specifically, in my Adonis projects, I'm mostly working with the Model objects through the ORM methods, an…

Context tracking - selecting multiple entities, updating and pushing them back to the db. Selecting complex dtos, this isn’t query building. A lot of magic turns this into sql. TopPaidMayors = Cities .where(c => c.state.govoner.party ==‘dem’) .select(c => c.name, highestPaid = c.mayors .orderByDesc(m => salary) .take(10)) .orderBy(c => highestPaid.First().salary)

Well you put a fairly normal select query there, which is can be accomplished in Lucid as well. Additionally change tracking exists since it's an ActiveRecord implementation.

It's not all magic as well. Looking into the internals of EF, ActiveRecord, Hibernate, or other ORMs reveal patterns that once familiarized can help reason about the behavior of complex queries. I only state this to try to work against the commonly found wisdom of "big frameworks are magic" that tends to scare away learning developers from hoping to understand them.

There are intersections and disjunctions of feature sets between the various ORMs, with some features for EF still only available via extensions (or nonexistent). I don't think this makes the Lucid ORM any less of an ORM.

Again, I like EF Core. I simply think that as far as node-based ORMs go, that Lucid is the one I've had the best experience with, so wanted to highlight it.

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

#322
post #299

Earlier quoted context omitted.

If people are looking at what technologies and companies to invest in, knowing that they may be left high and dry with a "full rewrite"-level of breaking changes is a valid and relevant critique. You want to know you'll be supported through difficult transitions, and that isn't unreasonable. I don't understand why people are coming out of the woodwork to tell everyone that full rewrites are a perfectly normal and exp…

Do you have any example what technology gave you a clean upgrade path from 2005 until now, without the need to do major changes? With .NET you can still, use most of your code from 2001, just the UI frameworks (and WCF) are not supported anymore on .NET 5+. They are supported at least until 2031 on .NET 4.8. So you can easily move your business logic to a newer version and leave the UI on an older version. But seriou…

Even many of the desktop UI frameworks are supported on .NET 5+ (on Windows only). Both WinForms and WPF are back in "support" in .NET 5+ (.NET 8 includes [small] updates for both WinForms and WPF). Not every UI component moves forward, but a crazy amount of them are still compatible after decades.

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

#323
post #10

Earlier quoted context omitted.

Northern Europe runs on C# and .Net. I am not joking. There are more C# jobs in Denmark than Python, Node.js, Ruby, and PHP jobs combined.

It is surprising to me that C# and .NET is comparatively under-represented in North America where it was born. Nothing but good experience in developing and operating software with it, both desktop apps (Win/Mac) and backend services (Linux).

I don't think it is that under-represented in North America. There are large swaths of "flyover country" that are deeply invested in .NET and C#. It was never "hip" or "cool" for Silicon Valley, but a lot of the Fortune 500 outside of FAANG/GAFAM/what-have-you is quietly built on it. Scott Hanselman termed it the "dark matter developer" experience that most .NET stuff just doesn't trend on Reddit or HN, it just kind of quietly exists and gets things done.

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

#325

I love the new dotnet ecosystem and use it professionally but am I the only one who thinks two years isn’t long enough for a “long term support” release? Obviously you’ll be able to run older versions of the framework so long as the underlying OS supports it but depending what type of environment you’re in this means you’re likely going to have to update perfectly working applications every two years. Do I think that…

>> 6 to 8 If you are using BinaryFormatter you certainly will have some work ahead of you.

It's been suggested to avoid BinaryFormatter since well before WCF was built and WCF itself has since been deprecated after a decade or so of service.

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

#326

Earlier quoted context omitted.

So the bottom line is that .NET Core can't call a .NET Framework library. It must be converted to .NET Standard first. And despite deprecation (let's call it that), .NET 5, 6, 7, 8 will continue to support calling into .NET Standard libraries.

I am not sure this is (still) correct - I am able to call into a .NET framework 4.8 library from .NET 7.

Since .NET Fx 4.7 or 4.8 libraries consumed via NuGet are "assumed" .NET Standard 2.0 unless proven otherwise for maximal compatibility with old code.

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

#327

Earlier quoted context omitted.

That’s super helpful, thank you. Where it still gets a bit murky is: > “ .NET has many different implementations, including the .NET Framework, Mono, and Unity. Each of these is a separate platform with separate Base Class Libraries (BCLs) and app models. .NET Core is another separate platform.”

You don’t really interact with or care about mono as A normal c# dev

Mono is almost entirely merged in .NET 8. Very few parts of "mono" exist now as a separate runtime.

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

#328

Earlier quoted context omitted.

1. .NET "Core" ... I tell myself "C is for Cross platform." This is usually what people seem like they mean now when they talk about ".NET". 2. .NET "Framework" ... I tell myself "F is for Former." This is the older, Windows specific version. 3. .NET "Standard" ... I tell myself "S is for Specification." This is just the spec which defines what Core and Framework must implement.

What about Mono and Unity?

As of .NET 8 most of what "mono" was has merged directly into one cross-platform .NET runtime. There's very little "mono" left, and most of it is on the path to disappearing/further merging, including the parts of mono that Unity uses.

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

#329
post #147
post #36

Earlier quoted context omitted.

Another good question would be - if you were Microsoft and wanted to plan a roadmap to take the .NET ecosystem forward from a couple of separate implementations (Windows-only .NET Framework, Cross-platform Xamarin) how would you go about this in a way that doesn't cause a big furore like Python 2->3 did? Because I imagine you end up with what MS did - define a standard that can be used for building common code betwee…

The only frustration I've experienced in actually working with it is that it leads to polluted search results. Trying to find solutions to ASP.NET Framework problems usually requires discarding a whole bunch of irrelevant ASP.NET Core/.NET ones. It's the same with Visual Studio/Visual Studio Code.

> Trying to find solutions to ASP.NET Framework problems usually requires discarding a whole bunch of irrelevant ASP.NET Core/.NET ones.

My experience was this was always a problem even before later versions of ASP.NET. There was so much backwards incompatible changes between ASP.NET 3/4/5 and ASP.NET MVC 3/4/5 and even things that searching for ASP.NET MVC 3/4/5/6 would disagree with ASP.NET 3/4/5 non-MVC recommendations.

If there was a point where googling ASP.NET problems was clean and unpolluted it probably only existed briefly in 1.0.

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

#330
post #11

I am mostly a Python person, but I must confess I'm impressed by both modern .NET and Java's Spring Boot. I architect for two teams, one using Java, the other using C#, for building services and the amount of boilerplate code, that used to be a huge turnoff for me, has been impressively reduced. There's still a lot, but it's now more or less comparable to what you'd expect you'd end up with on a similar app built on,…

[deleted]
Post reply on HN