Live data from Hacker News

.NET 5.0

devblogs.microsoft.com

191–200 of 466 posts

Re: .NET 5.0

#191
post #41

Earlier quoted context omitted.

I use Rider now, VS got to the point of being so slow that frequently I'd have to wait 0.5 seconds for each character I was typing to appear. The performance is utterly, utterly terrible. Yet, all I see from the VS team on Twitter is "look at this new useless feature we've added", when all I needed was for the code I'm typing to appear. God help you if you ever wanted to rename a symbol, it was Schrodinger's rename,…

I'm using newest VS with Roslynator (instead of Resharper) and it doesn't feel slow once it "warms-up" I do have NVMe M2 Disk if that matters

I never used Resharper, just plain old VS. It was dog slow, I’ll never go back, it’s not just the performance, but lack of stability, crashes, lots of exceptions, etc. It just feels like a project that’s not been given the love, and one that’s just having more and more features built on top of shaky foundations.

The other day one of my team (who still uses VS) complained of cut n paste not working (it would paste half the selection).

The basics are broken in my humble opinion

Re: .NET 5.0

#192
post #51

Earlier quoted context omitted.

Agree with your complaint on async. And on asp.net, async doesn't disrupt that much the workflow (but creates the possibility for deadlocks). But if you are dealing with a UI and make a method async, then suddenly you have a ton more problems to deal with, like what happen if the user changes the state while you are waiting for an async call. That increases a lot the complexity of the code. Which is why I am lukewarm…

How does async/await introduce complexity where threading wouldn’t? In my experience, the complexity is vastly reduced by not having to implement tricky asynchronous APIs (Task Paralell, thread pools, BackgroundWorker, etc).

no, vs blocking the UI thread. Which is perfectly fine the vast majority of the cases, unless you are running something long running.

Re: .NET 5.0

#193
post #184

Earlier quoted context omitted.

Agreed. Async is nice on the server but on the desktop it’s a real problem. For a while they had both sync and async but now it’s often only async. I just finished an app that had to shutdown while some async operations were still not finished. Really hard to manage compared to using threads.

How is Task.WaitAll different from Thread.Joining a bunch of threads? Or if you were cancelling tasks, using cancellation tokens?

If you are running Task.WaitAll on a UI thread you are likely to create a deadlock.

Re: .NET 5.0

#194

Earlier quoted context omitted.

>but you also get a self-contained binary executing without the requirement of an external runtime environment. I'm not sure whether we're talking about the same thing, but you can publish Self-Contained App (basically your app and framework together) and you don't have to install anything.

This is technically true, but it's a difference of a 5 MB executable vs a 50 MB.

Is it, actually? I mean, yes of course its 45MB difference, but does this matter? We are not talking about applications downloaded to a browser (webapp) or to a mobile phone. In a time where I download >50GB+ games on Steam and deploy from CI/CD server or docker registries to my servers, is a size of 50MB or 100MB really a showstopper?

Don't get me wrong, I totally love 4k and 64k demos and am always fascinated what could be packed into such small binaries, but in my professional life I think developer productivity, code quality and tooling is way more important than filesize. This is of course different if you are a webdev that ships .js, or an App developer publishing to Appstores.

Re: .NET 5.0

#195
post #29

Earlier quoted context omitted.

I found Go to be a really nice replacement for C#. It has the static typing and garbage collection, but you also get a self-contained binary executing without the requirement of an external runtime environment. I also discovered that I don't miss classes at all.

I have migrated from C# to Node.js, my code is now 20x times shorter (from 800 files to 40 files), simpler to read and maintain, there is 100x more packages available on NPM compared to nuget. Performance is stellar, even better than in C# for my use case (Mega tons of concurrent queries executed in 1-5ms avg) And also I don't have to fight against the language to do what I want to do ... No classes, no types, no con…

Every rewrite yields better results, even if you'd have rewritten your code in (modern) C# again.

Re: .NET 5.0

#196
post #59

Earlier quoted context omitted.

And then you realize that it's 2020 and you don't want configuration files, you want environment variables. Or, now that you've hardstuck yourself on environment variables and built all this stuff around them to set and re-set them properly between tests (now running either in multi-process, which good luck in most environments, or are just running in serial ), you're using k8s and the voluming of secrets rather than…

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

A better take on DI wireups in .NET: https://nblumhardt.com/2010/01/the-relationship-zoo/

The gist:

    Relationship                                Adapter Type     Meaning
    A needs a B                                 None             Dependency
    A needs a B at some point in the future     Lazy          Delayed instantiation
    A needs to create instances of B            Func          Dynamic instantiation
    A provides parameters of types X and Y to B Func      Parameterisation
    A needs all the kinds of B                  IEnumerable   Enumeration

Re: .NET 5.0

#197
post #151

Earlier quoted context omitted.

so, i see 4 different runtime installs (base/aspnet/aspnet-hosting/desktop) here https://github.com/dotnet/core/blob/master/release-notes/5.0... . where can i find instructions for doing a side by side install? thanks

Every version of .NET Core has always installed side-by-side with previous versions. There's no way to avoid it.

perfect, ty.

Re: .NET 5.0

#198
post #151

Earlier quoted context omitted.

Yeah. I guess it depends on how it gets installed, but there’s absolutely nothing preventing it from running side-by-side. I’ve been hot-swapping 3.1 and 5.0-rc2 for projects, preparing for the final 5.0 release.

so, i see 4 different runtime installs (base/aspnet/aspnet-hosting/desktop) here https://github.com/dotnet/core/blob/master/release-notes/5.0... . where can i find instructions for doing a side by side install? thanks

This link has clearer instructions on what to install: https://dotnet.microsoft.com/download/dotnet/5.0

Just download the versions you want and install them all. Also keep in mind if you're doing actual development you need the SDK, not just the runtime.

Re: .NET 5.0

#199
post #59

Earlier quoted context omitted.

And then you realize that it's 2020 and you don't want configuration files, you want environment variables. Or, now that you've hardstuck yourself on environment variables and built all this stuff around them to set and re-set them properly between tests (now running either in multi-process, which good luck in most environments, or are just running in serial ), you're using k8s and the voluming of secrets rather than…

> DI is the removal of complication when it is done correctly. Personally, I would rephrase that as, "DI is a pattern that is designed to mitigate certain kinds of complexity when done correctly." That leaves room for two ways in which it can backfire. Doing it wrong, like you say, but also doing it in situations where you don't actually have one of the problems it's trying to solve. Cost/benefit ratios always get ou…

That is a fair edit, for sure. Many systems don't need a formal DI mechanism, though should they scale to a certain human-size they'll probably invent enough of one anyway just through composition (if they don't collapse into a ball of mud).

Re: .NET 5.0

#200

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…

Similarly, porting from HoloLens 1 (x86) to HoloLens 2 (aarch64) has been... challenging in many cases. For instance, there is no Fortran compiler easily available for Windows aarch64, but Apple has promised to ship one for the new Apple Silicon on day 1.

EDIT: Here it is, right on time -- https://www.nag.com/news/first-fortran-compiler-apple-silico...

Post reply on HN