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

.NET Core 3.0 Concludes the .NET Framework API Porting Project

github.com

Post reply on HN
Print view View original

71–80 of 317 posts

Re: .NET Core 3.0 Concludes the .NET Framework API Porting Project

#71

Post by manigandham »

mariusmg wrote: post #19
jeswin wrote: post #7

Given that our deployment platform was Linux (for a .Net Core 3.0 project), I was determined to use Linux and VS Code for development. That was a fail; the verbose nature of C# and the Framework APIs make it impossible to be productive without significant help from a full-fledged IDE like Visual Studio. One might think the verbosity can be reduced by clever coding (and adopting a functional style), but that's not so…

>Btw, Linux as a deployment platform works quite well. What are you using in production for Linux ? Kestrel + Nginx ? Any problems encountered with this setup ?

We run Kestrel directly facing the internet serving http2 traffic across billions of requests per day with no issue. No need for Nginx.

Re: .NET Core 3.0 Concludes the .NET Framework API Porting Project

#72

Post by jeswin »

jayd16 wrote: post #35
jeswin wrote: post #7

Given that our deployment platform was Linux (for a .Net Core 3.0 project), I was determined to use Linux and VS Code for development. That was a fail; the verbose nature of C# and the Framework APIs make it impossible to be productive without significant help from a full-fledged IDE like Visual Studio. One might think the verbosity can be reduced by clever coding (and adopting a functional style), but that's not so…

The closest you'll get to free floating functions are methods in a static class. The static classes essentially become namespaces. Then with static using directives, you don't need to spell out the namespaces. https://docs.microsoft.com/en-us/dotnet/csharp/language-refe... You can even put every global function into a single class but still organize your code across multiple files by making them all part of the same…

> Then with static using directives, you don't need to spell out the namespaces.

Static using directives! Certainly a useful tool, thank you. I had been away from the .Net universe for a while and I think I have some more catching up to do. Some of the newer changes in C# help a lot with reducing code heft, even though it makes the language more complex.

However, the Framework seems to be headed in the opposite direction when it comes to simplicity. Here's for example the IOptions pattern: https://docs.microsoft.com/en-us/aspnet/core/fundamentals/co...

Re: .NET Core 3.0 Concludes the .NET Framework API Porting Project

#73

Post by sebazzz »

romanovcode wrote: post #57
Dolores12 wrote: post #10

>With .NET Core 3.0, we’re at the point where we’ve ported all technologies that are required for modern workloads .net HttpClient is based on outdated cookies RFC, RFC6265(that is 8 years old) is yet to be supported [1]. And what can you do today without good http library? [1] https://github.com/dotnet/corefx/issues/29651

The HTTP library is super easy to use and is very fast. I would not say that this issue makes the library bad.

Agreed. You could also use Curl bindings for .NET as an alternative.

Re: .NET Core 3.0 Concludes the .NET Framework API Porting Project

#74

Post by lultimouomo »

pjmlp wrote: post #43
jmkni wrote: post #39

Earlier quoted context omitted.

+1 for Rider. It's basically ReSharper.

Including resource usage! As anything on top of InteliJ.

JetBrains stuff does feel sluggish and occasionally hangs on my 2016 XPS-13 with 8G of ram. It gets the job done, but it's not pleasant.

On my new Ryzen 3600 with 32G of ram it runs smooth. So if you go for JetBrains, I definitely advise not to cheap out on the hardware.

Rider on Linux was very good for me, working on C# azure functions.

Re: .NET Core 3.0 Concludes the .NET Framework API Porting Project

#75

Post by SideburnsOfDoom »

jeswin wrote: post #7

Given that our deployment platform was Linux (for a .Net Core 3.0 project), I was determined to use Linux and VS Code for development. That was a fail; the verbose nature of C# and the Framework APIs make it impossible to be productive without significant help from a full-fledged IDE like Visual Studio. One might think the verbosity can be reduced by clever coding (and adopting a functional style), but that's not so…

> Allow functions outside of classes

Why? You can put them in a static class, and if C# ever had this feature, it would just be syntactic sugar for a hidden static class.

But that would mean optimising for "hello world" and other small script scenarios, which isn't a goal of the language design.

> Adopt (files and dirs) instead of forcing namespace declarations

Likewise.

> Structural typing

Like "dynamic" in C# 4 ? Been there, done that and it didn't take off really. It's useful for some interop cases and that's about it. Strong types, with type inference is more suited to the language design.

https://stackoverflow.com/questions/2690623/what-is-the-dyna...

https://docs.microsoft.com/en-us/dotnet/csharp/programming-g...

Re: .NET Core 3.0 Concludes the .NET Framework API Porting Project

#76

Post by sebazzz »

manigandham wrote: post #30
mjfisher wrote: post #6

Can anyone closer to the .NET community than I am comment on the wider adoption of .NET core on standard line of business applications? The few places I know that work with .NET are a long way from migrating yet. Are there any similarities with the Python 2/3 port? I imagine language level compatibility makes the transition much easier.

Last 5 startups have used .NET, all of them have migrated and all new projects are on .NET Core. Every major dev shop I know starts new projects on Core. It's mostly legacy and enterprise apps but it wasn't until .NET Core 3.0 (released last month) that it was viable to migrate everything perfectly anyway so it'll take time for that to filter through. This is nothing like Python 2/3. .NET Standard has been out for a…

If you have one product (like startups) it is easy to port. You have, in relative terms, nearly unlimited budget and incentive to stay on the latest and greatest.

If you work in a place where you develop many products for many clients, budgets are lower and you have much to maintain and develop. Porting is in my experience almost never done, because there is no business case to justify it.

Re: .NET Core 3.0 Concludes the .NET Framework API Porting Project

#77

Post by jeswin »

mariusmg wrote: post #19
jeswin wrote: post #7

Given that our deployment platform was Linux (for a .Net Core 3.0 project), I was determined to use Linux and VS Code for development. That was a fail; the verbose nature of C# and the Framework APIs make it impossible to be productive without significant help from a full-fledged IDE like Visual Studio. One might think the verbosity can be reduced by clever coding (and adopting a functional style), but that's not so…

>Btw, Linux as a deployment platform works quite well. What are you using in production for Linux ? Kestrel + Nginx ? Any problems encountered with this setup ?

Yes, this is what we use. So far it seems alright, and we did some load testing last week.

Re: .NET Core 3.0 Concludes the .NET Framework API Porting Project

#78

Post by pantalaimon »

gnud wrote: post #41
jug wrote: post #3

.NET Core 3.0 was major achievement for Microsoft and I like the air surrounding the project and some around it like Visual Studio Code and Windows Subsystem for Linux. The teams working for Windows development are overall on a roll these days and it's both sad and a little mysterious how Windows 10 is still struggling with QA issues, decisions like dismantling their internal testing teams, dual control panels and in…

I love it every time I get the 'old' control panel. It means I know where the switches are, and more importantly, what they do. The new UIs change with every minor update. Layout, labels and semantics. It's truly horrible. Please don't encourage Microsoft to mess it up even more.

Not to mention that the 'old' control panel has a lot more options!

Re: .NET Core 3.0 Concludes the .NET Framework API Porting Project

#79

Post by y4mi »

jug wrote: post #54
gnud wrote: post #41

Earlier quoted context omitted.

I love it every time I get the 'old' control panel. It means I know where the switches are, and more importantly, what they do. The new UIs change with every minor update. Layout, labels and semantics. It's truly horrible. Please don't encourage Microsoft to mess it up even more.

Yes, if things keep changing around or is hard to find, that's annoying but I see this as a separate problem from a bad pace and inconsistency. Nothing here in particular hinders good and well researched design.

I could find stuff in the old panel without knowing where it is. I can't in the new one. Either because the options are missing entirely or because they're too well hidden.

My biggest gripe is not being able to directly open the old settings... Always having to open "control panel" and then clicking on the correct category gets old fast, but is nonetheless more effective than fruitlessly searching in the new panels until I give up.

Re: .NET Core 3.0 Concludes the .NET Framework API Porting Project

#80

Post by FpUser »

jeswin wrote: post #60
surban wrote: post #29

Earlier quoted context omitted.

> My wishlist for C# is short: [...] F# provides all of them, is shipped with .Net Core 3.0 and also works great on Linux.

Works for personal projects and is certainly a joyful experience. But recruiting developers is near impossible - which is key for the kind of projects/companies I work with.

What's the problem asking experienced developer to learn F#? That is course assuming they do not refuse the work?
Post reply on HN