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

91–100 of 317 posts

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

#91

Post by rraghur »

james_s_tayler wrote: post #42
denisw wrote: post #15

Earlier quoted context omitted.

If you install the VS Code's C# extension, you should be getting autocomplete and quick fixes such as adding impport statements automatically. https://code.visualstudio.com/docs/languages/csharp

It's still nowhere near the same level of experience that Rider or VS offer.

I use VSCode with C# extension. THe only thing I missed was the additional analysis and quick fixes that full VS provides. However, that got sorted out by installing Roslynator in VS Code (works on linux too) and I couldn't be happier.

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

#92

Post by wokwokwok »

denisw wrote: post #15
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…

If you install the VS Code's C# extension, you should be getting autocomplete and quick fixes such as adding impport statements automatically. https://code.visualstudio.com/docs/languages/csharp

Oh no, don’t do that.

The vscode integration is barely beyond autocomplete, and it uses more memory than rider does.

The c# story for vscode still has a long way to go before it’s even close to feature parity.

(...and yes, if you scrabble enough plugins you can get more features, but you get more crashes and even more memory slurping. :/)

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

#93

Post by jeswin »

FpUser wrote: post #80
jeswin wrote: post #60

Earlier quoted context omitted.

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?

Team dynamics in large companies can be quite challenging. In addition, whoever made that decision might become responsible for project delays, inability to hire, people writing bad code, destroying work-life balance etc. And not just you, everyone up the chain will get blamed for choosing a programming language with a near-zero market share.

Generally large companies and enterprises are resistant to change, and my advice will be to just ask for enough room to get the project executed somewhat within budget and schedule.

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

#94

Post by kqr »

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.

I work in a .NET shop that has done a massive push to port all of their .NET Framework code to .NET Core. I joined in at the end of it, and only helped out porting 1–2 of the central applications, so I don't know what the internal struggles were like during the main effort.

What I do know is that everyone is relieved now and incredibly happy that they did it. Hosting the applications on Linux is so much easier, and they appear to have twice the performance as well. Still not sure why, but it's definitely correlated with hosting them on Linux.

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

#95

Post by jen20 »

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.

I've heard this before, and frankly, it is not something I recognise.

A few years back, I was the VP of Engineering at a (now well-known) startup that had chosen to use .NET (on Azure, which is a whole other story). Everything was written in F# by default, _occasionally_ branching out to C# or C++ if it was proven that F# was unsuitable for the job.

We managed to hire a very large team in comparatively little time - and because people who apply for F# jobs either know it (indicating someone interested in looking forwards in the industry), or were interested in learning it (we provided training), quality was better and waste was substantially less overall than I have seen elsewhere in a rapidly scaling team.

Despite what Microsoft may think, F# is the crown jewel of the .NET world, and it is a mistake to sideline it over fears such as this.

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

#96

Post by pjc50 »

SideburnsOfDoom wrote: post #75
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 ? B…

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

That's what the Powershell integration is for.

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

#97

Post by jmkni »

pjmlp wrote: post #81
lultimouomo wrote: post #74

Earlier quoted context omitted.

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.

In my current role, I was given a laptop with 8GB. An additional 24GB mysteriously found it's way in there after a couple of days...

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

#98

Post by jopx »

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

Mads Torgersen did a proposal related to this, it's in the C# Version Planing as version X.X, so maybe in the future we're going to have those capabilities.

https://github.com/dotnet/csharplang/issues/2765

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

#99

Post by jmkni »

pjmlp wrote: post #49
jmkni wrote: post #44

Earlier quoted context omitted.

Serious question, what makes 4.7.1/4.7.2 viable, but 4.8 not? Major breaking changes?

Validation through IT images. Until IT certifies server images with .NET Framework 4.8, it doesn't get green light for new projects. So is the nature of enterprise computing, I know a couple of customers still using Red-Hat Enterprise 5 on their servers.

Ah gotcha! Fun times!

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

#100

Post by simonh »

pjmlp wrote: post #81
lultimouomo wrote: post #74

Earlier quoted context omitted.

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.

I had a 32GB dev machine in my last job at a bank. 8GB is barely enough to run a full-on IDE, but if you also need to run wireshark, Geneos, outlook, big-ass excell sheets, several browsers with over a dozen tabs each, a bunch of communications tools, other office apps etc, etc, I'd regularly go above 20GB memory usage.

I was working app support really, with a fair bit of dev work as well, so needed to run a ton of different tools.

Post reply on HN