Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

.NET 5.0

devblogs.microsoft.com

Post reply on HN
Print view View original

311–320 of 466 posts

Re: .NET 5.0

#311

Post by to11mtm »

eropple wrote: post #75
csharptwdec19 wrote: post #73

Earlier quoted context omitted.

> DI is the removal of complication when it is done correctly. (I have no opinion on whether ASP.NET Core does it correctly.) I do, it was done in a really weird way and I don't care for the provided DI Abstractions nor the 'Microsoft.Extensions.Configuration' namespace. To take the 'common' object used for configuration, the nuget package for IOptions requires pulling in Microsoft's DI Abstraction.. That's the first…

For sure--that sounds real smelly. (Unless it's being used to pull in attributes that are shared between and used for wire-up, but those should then be in a separate assembly.)

> (Unless it's being used to pull in attributes that are shared between and used for wire-up, but those should then be in a separate assembly.)

Right. It's primarily interfaces, but they are tangled.

This was especially painful between Net Core 2.0 and 3.1, because moving fast and breaking things is ugly when you have tangled dependencies and everyone is trying to catch up to the breaking API changes and related nuget versioning dance.

Re: .NET 5.0

#313

Post by smoothdeveloper »

gfody wrote: post #300
modernerd wrote: post #20

F# gains string interpolation and typed string interpolation: https://devblogs.microsoft.com/dotnet/announcing-f-5/#string... Knew it was coming but still really happy to see this.

if this can be used to make a type checker for SQL strings like https://github.com/MedFlyt/mfsqlchecker or https://github.com/codemix/ts-sql but for C# I will be stoked!

The closest thing is https://github.com/rspeele/Rezoom.SQL which once compiled in your F# project, can be used in C# by referencing the generated assembly.

Although this is nothing to do with string interpolation, the "typed string interpolation" refer to the F# printf format specifiers.

You could also build such tool separately using FSharp.Compiler.Service (possibly using the analyzer infrastructure for ionide: https://github.com/ionide/FSharp.Analyzers.SDK), AFAIU there will be consolidation of this type of tooling relying on FSharp.Compiler.Service in the future to make this integrated to all F# tooling.

Re: .NET 5.0

#314

Post by hackerfromthefu »

asyncawaaait wrote: post #168
jniedrauer wrote: post #140

Earlier quoted context omitted.

> Why would we want that to be synchronous? Authentication is blocked by accessing storage. You cannot proceed until the storage read operation is completed. There is no parallel work to be accomplished here. This isn't UI code. There's no event loop. Why would you want this to be asynchronous? This seems like async as a dogma, rather than as a tool to accomplish something specific.

Awaiting a storage operation (ie. look up user) in C# will allow other calls to proceed until the I/O is available to read. Synchronous code locks you into the model of handling one request per thread. Given the minor overhead (both cognitive and runtime) of a sync/await, I can’t see why you wouldn’t want to do it here.

What about the far worse stack traces and debugging?

Whats a way to get the utility of normal debugging while using async?

Re: .NET 5.0

#315

Post by henrikschroder »

_acco wrote: post #258

The future is very bright for .NET. It has the right raison d'etre - .NET is part of the growth story for Nadella-Microsoft. They already have you programming in their editors (VS/Code) and pushing to their VCS (Github). They're even teaching you the C# type system with TypeScript :) If they can just convince you to use their stack, Azure will win you over from AWS every time. As a result, I really wanted to adopt .N…

Microsoft has always, always been awful at naming things, and all the intermediate steps in this unification have all been terribly named. However, this unification removes all the intermediates, which means they can simplify the naming as well. Let's hope they can stick to it...

Re: .NET 5.0

#316

Post by recursive »

layoric wrote: post #305
recursive wrote: post #297

Earlier quoted context omitted.

The type system in typescript is a lot more advanced than the one available in C#.

Interested in what you mean by 'lot more advanced'? The optional nature of the typing can be very useful for the web for sure. From my experience that same flexibility means you can't do as much reflection at runtime as in .NET but I have been for the most part away from typescript for last couple of years, so be interested in any resources around this subject.

* Structural types rather than nominal * Type unions and intersections * Type guards * `keyof` operator * String and number literal types

See https://www.typescriptlang.org/docs/handbook/advanced-types.... for more. There are a lot of utility types in the standard library that could not be expressed in C# as well.

Reflection is very different. It kind of still exists, but in a very different way.

Re: .NET 5.0

#317

Post by dazbradbury »

flamtap wrote: post #287
bob1029 wrote: post #146

Congrats to everyone involved. This is a huge accomplishment and arguably many steps in the right direction. We are very excited to get our hands dirty with .NET 5 sometime in Q1 next year. We currently run on .NET Core 3.1. I expect our migration from 3.1=>5.0 will be a total non-event, but we don't want to risk any regressions during our current crunch phase. Our migration from 4.7=>2.0 was the most difficult, but…

>I expect our migration from 3.1=>5.0 will be a total non-event, but we don't want to risk any regressions during our current crunch phase FWIW, I just did a find/replace across 66 projects for `netcoreapp3.1` => `net5.0` and it build and passed tests first try. There were a fair few new nullable reference type warnings though!

"Our migration from 4.7=>2.0 was the most difficult"

Would love to see a write up of your challenges / approach. Seems to be a big lack of write ups on this process that I'm sure lots of devs would appreciate!

Re: .NET 5.0

#318

Post by userbinator »

mattmanser wrote: post #23

So, on the plus side with the new .net, I recently made a .net core web app on Linux, and generally it's been pretty easy. I'm also impressed at just how fast asp.net core is compared to asp.net, the time it takes to open your site in debug mode has dropped dramatically, from what used to be 1/2 minute in asp.net to a few seconds in .net core. On the bad side? Mainly the asp.net core team and their push for Dependenc…

C# is great, but the asp.net core are so obsessed with shoving DI and async down your throat and making you write really unpleasant, boilerplate code. Feels like you're back in 1990 with all the FactoryFactoryFactories.

It's been said that C# is "Microsoft's Java". That applies not only to the language, but the culture of "enterprise-ism" (insanely excessive abstraction and complexity) that seems to permeate throughout the code.

I worked briefly with Enterprise Java a long time ago, and it brings back much of those memories whenever I have to look for something in a C# codebase.

Re: .NET 5.0

#319

Post by teh_klev »

qz2 wrote: post #42
cpitman wrote: post #35

Earlier quoted context omitted.

Totally fair, anyone in the Microsoft development ecosystem has to learn to be incredibly skeptical of anything new. Anytime I spent on adopting Silverlight was essentially wasted. I had one client that had adopted a random WYSIWYG released by Microsoft to design WCF services, when anyone experienced in the ecosystem knew it had abandonware written all over it. Of course, other ecosystems have their own versions of t…

Exactly. Yes I interviewed at a company where Silverlight and WCF was the future and they'd just rewritten everything in it. I didn't see it with the way everything was going. I dread to think of what happened to their business when the rug was pulled out overnight. "Microsoft says you need to start funding your entire product to be rewritten from scratch"

I don't know how long ago you're speaking about, but Silverlight and Flash were at their end of days even back in ~2006. Apple just nailed the coffin shut. That's not Microsoft's fault, there was a sea change in the industry away from browser plugins and these types of platforms.

Apropos WCF, well we got JSON and no-one outside of "enterprises" were doing SOAP/WSDL et al any more and it was pretty much done. That's not really a fault of the vendor, the world moved on. At the end of the day, as a software development house you have to make strategic choices, regardless of vendor. And you can still build WCF apps today, sure maybe not in .NET Core, but they'll still be supported for donkeys years by MS, but who'd want to?

Re: .NET 5.0

#320

Post by asyncawaaait »

hackerfromthefu wrote: post #314
asyncawaaait wrote: post #168

Earlier quoted context omitted.

Awaiting a storage operation (ie. look up user) in C# will allow other calls to proceed until the I/O is available to read. Synchronous code locks you into the model of handling one request per thread. Given the minor overhead (both cognitive and runtime) of a sync/await, I can’t see why you wouldn’t want to do it here.

What about the far worse stack traces and debugging? Whats a way to get the utility of normal debugging while using async?

Stack traces were massively improved in 2.1.

Using a good IDE (Rider or Visual Studio), debugging async/await code works as expected.

Are you doing interop or calling unmanaged code?

Post reply on HN