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

81–90 of 317 posts

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

#81

Post by pjmlp »

lultimouomo wrote: post #74
pjmlp wrote: post #43

Earlier quoted context omitted.

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.

32G?!? Where does one find such employers???

Not to mention how crazy it sounds having 32GB for an IDE.

Visual Studio, Netbeans and Eclipse run perfectly fine with 8 GB.

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

#82

Post by Dolores12 »

manigandham wrote: post #65
Dolores12 wrote: post #63

Earlier quoted context omitted.

Well, you expect http library to be as good as everywhere else.. like python requests. When library is not updated due to app compatibility issues i would not call it modern. It is good enough for basic use, tho.

HttpClient supports http2, the latest protocol features, has been rewritten in managed code with sockets, and includes advanced handling to balance connection lifetimes with DNS updates. It's about as modern as it gets and we run 10 billion requests per day through this code without issue. How does a lack of support for an RFC (which is still being revised) that outlines where a cookie should not be accepted in edge…

> Where are you running into this issue in a real app?

I had discovered few bugs in cookies handling myself, compared behavior to competitors and moved on. If cookies handling is not enough, i came across inconsistent behavior on different platforms: on Windows it uses WinHttpHandler, on Linux its curl lib(if i remember correctly). And they both handle edge cases differently.

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

#83

Post by pjmlp »

fauigerzigerk wrote: post #59
pjmlp wrote: post #12

Earlier quoted context omitted.

Windows userland is being rewritten in COM since Vista, as the Windows team picked up the Longhorn ideas and used them in COM after winning the WinDev vs DevTools politics, I doubt they will change route. The best we can hope for is that with the new AOT/JIT infrastructure, it gets more equal footing with C++/WinRT in platform APIs. After all, it has won the UI, MFC is legacy and XAML/C++ doesn't have much uptake as…

One of the key problems of our time (besides antibiotics resistance, climate change, lack of affordable housing, poverty, rise of nationalism and totalitarian ideologies, mass surveillance, etc) seems to be the impossibility of reliably generating reference counted code from code written for a tracing GC.

Nah, that key problem will eventually be sorted out with a couple of generational changes.

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

#84

Post by Digit-Al »

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…

I don't believe you will ever get functions outside of classes in C#. It is antithetical to the entire ethos of the environment.

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

#85

Post by FpUser »

manigandham wrote: post #69
sword_smith wrote: post #67

Earlier quoted context omitted.

It would seem to me that you wouldn't be able to mock all the classes if you followed this strategy.

Well do you really need to mock everything? And if so, how is that different than any other stack? Most of the time this is just "enterprise patterns" without any thought about whether it's worth it. I've seen too many small LOB apps that have 5 tiers of code for no reason.

I am seeing it all the time when consulting for companies. Their developers just love taking relatively small things and turning it into multilayered monster with insane amount of dependencies for code, development building pipelines and deployment.

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

#86

Post by Dolores12 »

manigandham wrote: post #66
Dolores12 wrote: post #64

Earlier quoted context omitted.

or use different language with good library that support 8-year old RFC.

C# is a language but .NET is a runtime and standard library. If this issue is really such a problem, you can use any of the dozens of open-source libraries available or just implement your own cookie container that follows this RFC in about a day. It sounds like you're picking on a strange issue to disparage .NET without any real experience in it.

No, i just didn't like the wording in the original post mentioning all 'modern workloads' , while ubiquitous thing like cookies in httpclient is still not according to 8 year old standard. Does it make any sense now?

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

#87

Post by simonh »

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.

>It means I know where the switches are, and more importantly, what they do

Or even more importantly than that, that they even exist in there somewhere.

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

#89

Post by jen20 »

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.

On a brand new machine (just verified), Visual Studio cannot keep up with my typing - a problem that has existed since the VS .NET days. IntelliJ may take a little extra time to start (though, not a huge amount more), but it has never suffered from that problem, even on much lower end boxes.

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

#90

Post by simonh »

pjmlp wrote: post #83
fauigerzigerk wrote: post #59

Earlier quoted context omitted.

One of the key problems of our time (besides antibiotics resistance, climate change, lack of affordable housing, poverty, rise of nationalism and totalitarian ideologies, mass surveillance, etc) seems to be the impossibility of reliably generating reference counted code from code written for a tracing GC.

Nah, that key problem will eventually be sorted out with a couple of generational changes.

Said someone in the 1960s ;)
Post reply on HN