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

291–300 of 317 posts

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

#291

Post by e12e »

merb wrote: post #281
e12e wrote: post #262

Earlier quoted context omitted.

This is one of those cases where distribution really matters; for quite a lot of the work we do, AGPL would probably be fine (to-order in-house business tools;client pays for development, gets source anyway). While selling those tools under AGPL certainly would be both Free and open source (but not gratis!) - the only real impact of the AGPL would be on our client - in that they'd be guaranteed the four freedoms (but…

I never said that I can't sell AGPL software. just that I can't use AGPL in a closed source project.

I didn't mean to imply you did, just that this distinction is particularly important here, as I've seen quite a few "closed" projects that do need a pdf library, and would be fine with the AGPL.

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

#292

Post by fauigerzigerk »

Const-me wrote: post #247
fauigerzigerk wrote: post #236

Earlier quoted context omitted.

>What exactly do you think is a hard problem about such interop? The problem is that .NET libraries cannot be used from C++ or Rust without depending on the entire .NET runtime, including its tracing GC, which is obviously extremely undesirable. And that is probably why Microsoft dropped their plans to write Windows userland components in .NET and decided to write them in C++ instead (exposing COM interfaces). As I s…

> cannot be used from C++ or Rust without depending on the entire .NET runtime You can compile .NET into native code if you want: MS .net native, Unity’s IL2CPP, etc. These aren’t some research projects, every Unity3D game shipped on iOS compiles with IL2CPP, most windows store apps are built with .net native. The GC probably still included in the output binary somewhere, but it does much less work than usually. > wh…

>C# and Java and strongly typed, have a lot of static information.

They may have a lot of information, but they don't have the static information required to generate reference counted COM. It's information about the lifetimes and ownership of objects.

>I think the main reason why it’s impossible to reliably recompile these languages into non-gc code — circular references.

Exactly. The information to resolve those is missing.

>Depends on use case.

This was a debate about Microsoft's decision not to build Windows userland on top of .NET after all. So it would have affected all use cases of all Windows developers.

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

#293

Post by LIV2 »

gexla wrote: post #125
cm2187 wrote: post #121

Earlier quoted context omitted.

And also items from the old control panel don't appear any more when you search in the start menu. Which would be ok if they had been replaced by an equivalent in the new menu. But they have not. So what is the point in hiding them?

Let me have their pretty UI. If you want to geek out, there's Powershell.

Powershell is shit for discovery & not useful at all for the majority of Windows consumers i.e regular users. You shouldn't need to learn powershell to switch your audio output

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

#294

Post by fauigerzigerk »

youdontknowtho wrote: post #246
fauigerzigerk wrote: post #186

Earlier quoted context omitted.

You can, but in order to translate arbitrary .NET code into reference counted COM you would need a guarantee that _all_ code is written like that or that you can statically infer the correct reference counting for _all_ code that isn't written like that.

I haven't seen the reluctance to use the runtime in interop scenarios. Is this just a personal interest or do you have a particular use case? I'm genuinely interested.

This debate is about Microsoft's decision some 14 years ago to build Windows userland components on top of C++ COM technology instead of .NET as some within Microsoft had wanted.

Those inside Microsoft who didn't want to force everyone to use a rather heavyweight runtime including a tracing GC won the debate. It would have affected almost everyone, not just those with use cases that can tolerate the significant additional resource usage.

I merely made the observation that the difficulty to infer correct reference counting information from C#/Java code is what caused this rift and a lot of unproductive duplicated effort in our industry.

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

#295

Post by nbevans »

tonyedgecombe wrote: post #126
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.

It doesn't give you structural typing, it's still normative: https://stackoverflow.com/a/3137561/57094

https://www.infoq.com/news/2019/01/fsharp-4.6-preview/

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

#296

Post by nbevans »

Dolores12 wrote: post #86
manigandham wrote: post #66

Earlier quoted context omitted.

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?

That "8 year old standard" you linked to is just a draft and proposed standard. Nobody implements draft specs in production grade libraries/frameworks. Especially not Microsoft.

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

#297

Post by TomasJansson »

Scarbutt wrote: post #248
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.

F# is a nightmare you want to use asp.net core.

What do you base that on? I have had no problem with F# and asp.net core. Just look at safe stack, it uses saturn or giraffe which in turn runs on asp.net. https://safe-stack.github.io/

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

#298

Post by apk-d »

wayneftw wrote: post #232
apk-d wrote: post #229

Earlier quoted context omitted.

I've been using VSCode for C# daily for a year or two. I'm considering switching to a non-electron editor because of how slow and sluggish it is, including IntelliSense, refactoring, syntax highlighting and the latency and frame rate of actual rendering (huge drain on the battery if you have one). The editor doesn't (seem to) support language-integrated syntax highlighting, so no ambiguous language features get recog…

Just curious: are you on a Mac or Windows? I never experienced any freezing at all on Linux.

Windows, although my experience with VSCode on Ubuntu wasn't very smooth or stable either (worked with TypeScript for a few months a while ago).

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

#299

Post by goto11 »

manigandham wrote: post #274
goto11 wrote: post #108

Earlier quoted context omitted.

Structural typing is different from dynamic typing. C# supports structural typing in the form of tuples and anonymous types. But you can't return an anonymous type from a method. This is a significant limitation. As for "free" functions: C# already recognizes the usefulness of this in the "using static" directive. This is useful for a lot more than "hello world".

Why are "free" functions useful? What actual real difference does it make compared to putting an extra word in front to call the method?

You don't need to put the extra word in front since "using static" was introduced. But you still need to define a useless static class.

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

#300

Post by goto11 »

jayd16 wrote: post #257
goto11 wrote: post #181

Earlier quoted context omitted.

Consider something like the Math class. In practice it just works like a namespace for math-related functions. The only reason to have a class is because the language requires it. It would certainly be cleaner without having to define a useless class.

Yeah, except I like that Log() isn't already a reserved function name.

I don't think anyone is suggesting the function names should be reserved names. They would still exist in a namespace.
Post reply on HN