Live data from Hacker News

.NET 5.0

devblogs.microsoft.com

161–170 of 466 posts

Re: .NET 5.0

#161

People who think this is actually cross-platform need to consider these points: * Debian can't package F# because it is built using MSBuild, and MSBuild is built using MSBuild. How can it be Microsoft doesn't have the resources to get it into a major distribution? * Microsoft won't commit to maintaining any cross-platform GUI libraries. You will be relying on some random community project. Compare this with e.g. Pyth…

There may well be some niggles that affect a small number of people doing some niche things under specific circumstances, but I don't think that's enough to claims it's not cross-platform. Since dotnet core became a thing, I've been building cross-platform apps with great success - mostly Windows and Linux, occasionally MacOS too, and mostly x64, but also ARM too.

A GUI application that is not web-based is not a niche use case. A build system is not a niche use case.

I see you have been posting Wintel news. Do you have any affiliation?

Re: .NET 5.0

#162
post #82

Earlier quoted context omitted.

.NET is meant for stuff like microservices; you don't see lots of those written in php, right? Also, for high-traffic websites, that's really not a great idea. You might say "but Facebook, PHP" - I'm really certain that their current codebase doesn't have a thread that blocks on DB for each user request.

I don't get why the auth being async is a hang up but at the same time, most projects can handle not scaling to Facebook-scale and the sooner developers accept that, the sooner we can escape a great gnashing of teeth. I'd be willing to bet more projects have been killed by trying to architecture for performance up front than have been killed by being too successful for their own good and keeling over. If Twitter coul…

I'd agree if you talk about "most projects". But here we're talking about a platform - you can't fault Microsoft for caring about performance! .NET is absolutely not meant only for small sites, my current employer is heavily invested in .NET and we'd probably be dead (performance-wise) without async. Definitely couldn't run our services with PHP (not without Facebook-like investments), we already outgrew that kind of traffic.

Re: .NET 5.0

#163

Earlier quoted context omitted.

I’m confused as to what you want instead of what Asp.Net core offers. Nothing is forcing you to inject configuration or to use IOptions. In most cases you don’t even need to do anything with the configuration builder because that is part of the default of how the host gets setup. You’re configuration should be automatically built from environment vars and appsettings.json. And of course you can always just access env…

I think they should have done what every other framework does and make it super easy to access, like this: Env.Config("Settings:MyEasyValue"); Or: Env.Config ().MySuperEasyTypedValue; And the Dependency Injection? Sure, add some version you can DI with. But not the default. I now know how to navigate the mess they've made, but it's not time that I feel where I gained anything in my life, it was just frustrating. Here…

The sheer length of the answer? That's because it shows optional, more advanced ways to get config stuff.

Is this so hard?

    public class AccountController : Controller
    {
        private readonly IConfiguration _config;
    
        public AccountController(IConfiguration config)
        {
            _config = config;
        }
    
        public IActionResult ResetPassword(int userId, string code)
        {
            var vm = new ResetPasswordViewModel
            {
                PasswordRequiredLength = _config.GetValue(
                    "AppIdentitySettings:Password:RequiredLength"),
                RequireUppercase = _config.GetValue(
                    "AppIdentitySettings:Password:RequireUppercase")
            };
    
            return View(vm);
        }
    }

Re: .NET 5.0

#164

Earlier quoted context omitted.

> From the previous version of .Net Core only. Which is already three major versions ahead off classic .net. You’re literally complaining about making upgrades past four major releases not being drop-in compatible. Can you show any other stack which has made such strides to modernise and maintain better compatibility?

No, I'm literally complaining about the misleading messaging surrounding .Net 5.0 "merging" .Net Framework and .Net Core. My post was very clear on that. Like this quote from the linked article: > .NET 5.0 is the first release in our .NET unification journey. We built .NET 5.0 to enable a much larger group of developers to migrate their .NET Framework code and apps to .NET 5.0.

I believe that verbage is mostly referring to options for VB.NET, Winforms, and WPF being available in Core, meaning projects that use those can be ported

Re: .NET 5.0

#165

I used to be an asp.net developer before. I appreciated the idea behind asp.net during its early years - making websites fast and with templating (or scaffolding). Later realized that it is bloat. Then asp.net mvc happened, a whole new paradigm shift. But then I disliked the idea of stuff getting inherited from somewhere. *.cshtml files and all. Soon I realized what the ide is actually doing behind the scenes. For e.…

You could combine Node.js with TypeScript to regain type safety.

See also https://deno.land

Re: .NET 5.0

#166
post #82

Earlier quoted context omitted.

That is literally how php does. Let's fire a thread for every request and block on db reading or any action that require io. And it seems it works (at least for php)

.NET is meant for stuff like microservices; you don't see lots of those written in php, right? Also, for high-traffic websites, that's really not a great idea. You might say "but Facebook, PHP" - I'm really certain that their current codebase doesn't have a thread that blocks on DB for each user request.

> .NET is meant for stuff like microservices;

What does this mean? .NET has been around before SOA was a term and microservices is an evolution of that. The concepts are orthogonal and you could write microservices in PHP, if you really wanted. Like Java, the .NET runtime and platform is highly efficient. That's what .NET has historically had over PHP/Python/Ruby, but I don't keep up with the PHP and Ruby platforms these days.

I feel like this is another one of those discussions like the "Python GIL problem." Whether it's a really a problem depends on the circumstances, and the circumstances were it is a problem affects fewer people than the HN threads suggest.

Re: .NET 5.0

#167
post #7
post #3

Earlier quoted context omitted.

No thanks. I've been writing .Net since before day one and quite frankly I've been buggered around enough now to run as far away from this as possible.

What would you choose for server code?

.NET/C# are great platforms, it's the median .NET/C# developer and the general culture of working at one of these shops that ruins it.

Just decades of over-engineering OOP "best practices" baggage that is impossible to shake off.

Why do people "move" to new languages? Mostly to leave the baggage behind.

Re: .NET 5.0

#168

Earlier quoted context omitted.

Authentication is in the request pipeline, so it makes sense that it's async if you're talking to some sort of storage engine. We're using the async APIs to pull user/client app information from our database. Why would we want that to be synchronous?

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

Re: .NET 5.0

#169

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…

I agree. The first thing I always do is make a custom Settings class which just loads settings via good old `Environment.GetEnvironmentVariable`. Super simple and never failed me. Bonus Points, by loading all settings at once into strongly typed properties at startup, it will fail fast if a setting is missing, which to me is a benefit. But I still pass this class via DI to the controllers for testability reasons. If…

>I agree. The first thing I always do is make a custom Settings class which just loads settings via good old `Environment.GetEnvironmentVariable`. Super simple and never failed me.

The .net core configuration mechanism has a hierarchy of providers it reads from, one of which is environment variables, and strongly typed configuration is supported out of the box, so you're exact use case is supported natively by it.

Re: .NET 5.0

#170
post #125

Earlier quoted context omitted.

why doesn't MS just release the SAPI wrapper as a windows only nuget package since it already exists?

One thing I've learned in my time on the accessibility team at MS is that even at a company as large as Microsoft, any given team has limited resources and only so many person-hours in a day. So every task has to have a business justification. There probably hasn't been enough demand for releasing System.Speech as a NuGet package to justify it. That's just my guess though; I haven't talked to the speech or .NET teams…

i understand that, but i'll bet if they would dump the source to dotnet/unsupported/system.speech the community would do the work for them to get squared up with dotnet core. it doesn't take a lot of demand, just 1 or 2 developers who view it as a blocking requirement for netcore migration.
Post reply on HN