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

371–380 of 466 posts

Re: .NET 5.0

#371

Post by bschwindHN »

cutler wrote: post #328
Xeronate wrote: post #271

Earlier quoted context omitted.

Go seems nice, but don’t you think writing business logic feels very tedious compared to C#? Generics and linq speed development time up for me significantly.

I can't think of anything other than Java that's as tedious to write as C#/ASP.Net. With Java and C# code you spend a siginifcant amount of your time messing with the complexities of the language itself instead of dealing with your business problem. The mixture of generics and static typing is particularly pernicious. I really hope Go 2.0 doesn't end-up going down the generics rabbit hole.

I have to agree with Xeronate on this one, a lack of generics makes writing business logic in Go quite annoying. Generics and the monad-esque values it enables make it much easier to model your logic properly.

I like Go for services that just need to push bytes around to various places but otherwise it does get quite tedious for complex logic.

Re: .NET 5.0

#372

Post by Xeronate »

cutler wrote: post #328
Xeronate wrote: post #271

Earlier quoted context omitted.

Go seems nice, but don’t you think writing business logic feels very tedious compared to C#? Generics and linq speed development time up for me significantly.

I can't think of anything other than Java that's as tedious to write as C#/ASP.Net. With Java and C# code you spend a siginifcant amount of your time messing with the complexities of the language itself instead of dealing with your business problem. The mixture of generics and static typing is particularly pernicious. I really hope Go 2.0 doesn't end-up going down the generics rabbit hole.

Can you give some concrete examples of how C# is tedious compared to go?

Things like

  var filtered = purchases.Where(x => x.Name.Contains("Sean"));
and

  var grouped = purchases.GroupBy(x => x.Buyer).Where(x => x.ToList().Count > 10).ToDictionary(x => x.Buyer, x => x.ToList());
etc. come up a lot in day to day programming and always feel tedious to me in go. The first example in go looks something like

    filtered := []purchase{}
    for i := range purchases {
        if purchases[i].buyer == "Sean" {
            filtered = append(filtered, purchases[i])
        }
    }
and it only gets worse as the domain gets more complicated. I don't really know what your background is where you feel that static typing and generics are complicated. I write C# every day and spend 0% of my time fighting the language.

Re: .NET 5.0

#373

Post by Xeronate »

bschwindHN wrote: post #371
cutler wrote: post #328

Earlier quoted context omitted.

I can't think of anything other than Java that's as tedious to write as C#/ASP.Net. With Java and C# code you spend a siginifcant amount of your time messing with the complexities of the language itself instead of dealing with your business problem. The mixture of generics and static typing is particularly pernicious. I really hope Go 2.0 doesn't end-up going down the generics rabbit hole.

I have to agree with Xeronate on this one, a lack of generics makes writing business logic in Go quite annoying. Generics and the monad-esque values it enables make it much easier to model your logic properly. I like Go for services that just need to push bytes around to various places but otherwise it does get quite tedious for complex logic.

What types of services don't have complex business logic? Just trying to expand my horizons. I guess like a video transcoding service or something like maybe.

Re: .NET 5.0

#374

Post by Xeronate »

charlieflowers wrote: post #352
Xeronate wrote: post #268

Earlier quoted context omitted.

What’s not to like about DI? Makes it so much easier to wire up dependent services and refactor those wirings at a later time. If you don’t use DI you have to manually manage everything yourself.

If you go too far with DI, the saying is "everything happens somewhere else." Some feel it can be needlessly complex to troubleshoot such a system or gain understanding of it if you weren't one of the original authors.

Don't need DI to make your program so abstract no one can follow it. Wouldn't even say DI makes it easier to do because you can accomplish the same thing by just newing up objects.

Re: .NET 5.0

#375

Post by BatteryMountain »

starik36 wrote: post #295
GordonS wrote: post #127

Earlier quoted context omitted.

> My biggest bugbear is the way you access your config, which is an absolute and utter kafka-esque mess. Because someone at MS was drinking the DI kool-aid you have to add a minimum of 5 lines of code to any class you want to access config values in I'm not sure if maybe you're referring to the Options stuff? The way I do it is pretty simple. 1. Create a POCO that represents your config. You can have properties for b…

I think the OP is referring to accessing the config 5 layers down from the controller. I've run into it myself. To be able to do that, you have to add Options to the constructor of every class in the chain and then configure DI for it. It just has bad code smell. On my last project, I just assigned the configs to a static class that's available everywhere and the code was just simply much cleaner.

Code smell OR a pattern, I believe they call it the "Options Pattern". Obviously not a real pattern like other design patterns.

Re: .NET 5.0

#376

Post by masterofmisc »

FridgeSeal wrote: post #284
_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…

> Azure will win you over from AWS every time. Going to have to disagree here. That might be the case if Azure was not literally a tire-fire. I have been using Azure for work and it's the most frustrating, inconsistent, often-broken, confusing and stress-inducing cloud service that my teammates and I have ever been subjected to. It left such a bad taste that I am quite certain I would flat-out refuse to use it again…

Gee.. Sounds like you have had an awful time of it. Any chance you could speak more of some of the issues you encountered? We are looking at cloud providers and was kinda leaning towards Azure.

Re: .NET 5.0

#377

Post by qz2 »

int_19h wrote: post #239
qz2 wrote: post #22

Earlier quoted context omitted.

Probably Go at this point in time. They care about API stability, keeping scope focused and about technical improvement instead of marketing. And the language is nice to use! There are warts but they take a measured structural approach to resolving them and caring about the change.

Go might care about their own API stability, but it took them years to stop doing direct syscalls on macOS (where it is not a stable ABI ); and last I checked, they were still doing that on BSDs. As for technical improvements, well... it's a language that took, what, almost a decade to add generics? And that's because the designers were claiming that everybody else is doing them wrong, and they want to figure out how…

You have to do direct syscalls if your lowest level is not C. I don’t see your point. Perhaps vendors should have stable ABIs?

Re: .NET 5.0

#378

Post by bschwindHN »

Xeronate wrote: post #373
bschwindHN wrote: post #371

Earlier quoted context omitted.

I have to agree with Xeronate on this one, a lack of generics makes writing business logic in Go quite annoying. Generics and the monad-esque values it enables make it much easier to model your logic properly. I like Go for services that just need to push bytes around to various places but otherwise it does get quite tedious for complex logic.

What types of services don't have complex business logic? Just trying to expand my horizons. I guess like a video transcoding service or something like maybe.

Something like a WebSocket server, a load balancer, message queue, that sort of thing.

It's not that those aren't also complex, but there's less "business" in the logic, if that makes sense. Something that doesn't handle arbitrary user input or deal with the messiness of humans, like first/last names, dates and timezones, etc.

As an example, I had once written a WebSocket server in go which took a program as input, ran it in a heavily stripped down docker container, and streamed the stdout back to the client. Go was perfect for that use case. (though to be honest I'd pick Rust now because I'm past the learning curve on it)

Re: .NET 5.0

#379

Post by masterofmisc »

Longhanks wrote: post #159
soapdog wrote: post #135

Congratulations to the team but more than a year after the Surface Pro X shipped and there is still no way to build desktop applications for aarch64 using dotnet/vs2019 on the local machine. Windows on ARM has no native support for WPF, WinForms, or WinUI. Visual Studio 2019 running as x86 32bits application can't see the local machine as a target for aarch64 applications. When I asked microsoft, the response was to…

Meanwhile, this week launch three Apple products that come with a free toolchain and IDE tailored perfectly to the new architecture that supports old and new UI APIs. On the Windows side, Visual Studio is still a 32bit application, and as you have pointed out, on ARM, it supports basically nothing but the ancient Win32 C API.

Yep, they are just quietly slogging away over there on thier singular vision. They are not all over the map like Microsoft have been in the past: Throw everything against a wall and see what sticks approach!

Re: .NET 5.0

#380

Post by fuzzy2 »

Scramblejams wrote: post #202
fuzzy2 wrote: post #110

Earlier quoted context omitted.

Actually Visual Studio is quite fast again. It's just that Resharper does its very best to slow it down. I don't believe this will ever change. Well except maybe Microsoft will fully deprecate COM-based in-process extensions.

JetBrains is working hard to fix it: https://blog.jetbrains.com/dotnet/2020/02/24/update-running-...

Of course. However, I’m not sure this will achieve the desired speedup, because part of Resharper still needs to run in-process to integrate with Visual Studio. And it integrates a lot. And I’m sure at least some of the APIs it uses are actually not asynchronous. So, only limited room for improvement.
Post reply on HN