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

231–240 of 317 posts

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

#231

Post by vbezhenar »

fauigerzigerk wrote: post #142
vbezhenar wrote: post #137

Earlier quoted context omitted.

May be I don't understand something, but how does it differ from e.g. operating file handles? For example in Java you're supposed to use try-finally to close file handle. You should do the same with reference-counted objects, just manage their lifetime manually. And finalizers will close it for you if you forgot to do that (that should be considered as a bug, but not very serious).

It doesn't differ from that, but in languages that assume the presence of a tracing GC, that pattern is only used for resources other than memory. And therefore you can't (as far as I know anyway) compile arbitrary C#/Java/JavaScript libraries down to reference counted COM in order to make those libraries available to C++ or Rust code.

Offtopic, but I think that Rust memory model makes a perfect consumer of COM services :) May be it'll be integrated to other languages as an additional type system.

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

#232

Post by wayneftw »

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

Earlier quoted context omitted.

Thank goodness that VSCode is a different experience! VS and Rider are a pain in the ass to setup and maintain and VSCode provides the essential UX better than just about anything else at this time. I can have VSCode installed and running with my personal settings on any OS within 2 minutes flat. I don't have to find a secret license key, login with any account, or pick through a list of 100 features in the installer…

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.

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

#233

Post by Const-me »

merb wrote: post #88

sadly .net core still lacks a good pdf library that is not priced over the top. (and at least supports building pdfs and creating pdf/a 3's.)

I’ve just built iTextSharp LGPL for .NET Core 2.2: https://github.com/schourode/iTextSharp-LGPL It only needed a single dependency to build on.NET core, System.Drawing.Common from nuget, for Image and Matrix classes.

That version has a few unfixed bugs, e.g. merged table cells are sometimes broken, but the code quality is OK on average, relatively easy to fix them if you need to.

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

#234

Post by louthy »

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…

> and adopting a functional style

Although this won't solve all of your problems, if you can't use F# and want to use a more functional style, then this will help [1].

disclaimer: I'm the author

https://github.com/louthy/language-ext

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

#235

Post by huzaif »

gameswithgo wrote: post #167
dvfjsdhgfv wrote: post #119

Earlier quoted context omitted.

I can sum up the situation with two sentences: I hate writing Win32 apps, but I love using them. I love writing .NET apps but I hate using them. The problem with Win32 apps is that although they look ugly, in general they're blazing fast and work basically everywhere. The problem with .NET apps is although they're aesthetically pleasing, they require the relevant version of the framework to be installed. I remember f…

With .NET Core 3, you can deploy them standalone, and performance is much improved. So you might have a happy middle ground available now. And when I say performance is improved, there are two fronts to that. First, the compiler/jit are just better now, core library functions are sped up a ton, so just running ported old .NET Framework code will be a lot faster. But also, C# has added new features in recent years tha…

Piggy backing on this a bit..

You can now publish a .net core 3.0 app that is: 1- Ready to Run: Part AOT compiled app for the platform. 2- Trimmed: Tree shaken down to only necessary bits from the framework. 3- Single File: Self contained app.

This combination of features provides a really decent balance between size, performance and distribution.

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

#236

Post by fauigerzigerk »

Const-me wrote: post #230
fauigerzigerk wrote: post #116

Earlier quoted context omitted.

I'm serious (even if it may not sound like it). COM is a fantastic platform, because it provides simple and efficient interoperability between language runtimes. But code written for tracing GCs cannot be automatically transformed into COM's (or any) reference counting scheme. And that's why we have this endless tug of war between those who want to build on top of COM versus those who want to build on top of .NET. It…

I’ve been writing C++ COM objects for use in .NET for years now. Some are for performance-critical parts, like manually vectorized SIMD code. Another use case is interop heavy code, using Direct3D, media foundation, Eigen, other C and C++ libraries. It works even on Linux https://github.com/Const-me/ComLightInterop I also have these parts, especially about the interop. Libraries like drm, kms, gles, udev, and many ot…

>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 see it, the key theoretical issue is that neither CIL nor arbitrary code written in languages like C#, Java, JavaScript or Python contains enough static information to generate purely reference counted code.

You're seeing the same on Unix. All truly reusable code is written in languages that don't require a tracing GC. Everything that is written in other languages is duplicated for each language/runtime environment.

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

#237

Post by com2kid »

wayneftw wrote: post #150
james_s_tayler wrote: post #42

Earlier quoted context omitted.

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

Thank goodness that VSCode is a different experience! VS and Rider are a pain in the ass to setup and maintain and VSCode provides the essential UX better than just about anything else at this time. I can have VSCode installed and running with my personal settings on any OS within 2 minutes flat. I don't have to find a secret license key, login with any account, or pick through a list of 100 features in the installer…

> Luckily, I don't have to work on anything that needs a designer anymore, like WinForms, but if I did I would certainly install VS. Even then - I think I'd only use VS for the designer and go back to VSCode for everything else. (And I love Windows and I used to love VS, having used both of them for 30 years and 15 years respectively.)

The WinForms designer is wonderful. I can throw up an ugly CRUD app that works so insanely fast with it. The web-equivalents are horrible. Everyone is trying to make a rich web app to write rich web apps and IMHO they are all targeting way too low on the "technical ability" scale for their users.

Though web is harder, since apps need to be responsive, and cross plat, and automating code gen of CSS that does that cannot be easy, and having a form designer UI expose settings for how a UI resizes itself doesn't sound like a UX challenge I'd want to tackle.

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

#238

Post by wlesieutre »

DennisP wrote: post #178
AndrewDavis wrote: post #145

Earlier quoted context omitted.

My goodness. Recently I went to play a game on my laptop, something i don't normally do. I'm not even normally a windows user. It has this 'feature' where if a key is pressed then it disables all mouse clicks for X number of seconds. This is to prevent a forearm from tap to clicking on the touchpad while typing. Absolutely makes sense. Only... I had a mouse plugged in. It disabled a physical USB mouse from clicking a…

I've got a Macbook Pro and it doesn't seem to have or need this feature in the first place.

It does have an analogous feature, the MBP's trackpad is huge and you probably touch it by accident all the time.

It's just that Apple's system tries to separate deliberate touches from accidental ones, rather than disabling the trackpad input completely.

You used to be able to turn this on and off (it was called "Ignore accidental trackpad input" in the trackpad preference pane) but now it's an always on feature. The trackpad has extended so far into the palm rests that it would be very difficult to use without it, and the feature works well enough that you don't even realize it's happening.

https://support.apple.com/en-us/HT201822

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

#239

Post by avgDev »

simonh wrote: post #100
pjmlp wrote: post #81

Earlier quoted context omitted.

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 d…

I'm not even at a tech company and requested 32GBs, as I sometimes have VS and Android Studio open, running mobile emulators and checking what is going on the API end. You add VMs to the mix and one really needs 32GBs. My company had no issues providing the ram. Plus, it is insanely cheap right now.

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

#240

Post by gameswithgo »

rafaelvasco wrote: post #173
Digit-Al wrote: post #84

Earlier quoted context omitted.

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

Thank god we won't. Functions outside classes never did make sense to me. People love to hate classes sometimes. For me, everything starts at classes and structs;

in C# you can make a static class, and then put functions in it. When you do this, the class is nothing more than a namespace. But the class is already in a namespace. So you now have a redundant namespace. It isn't a big deal but its a bit silly to have to do that, when writing static functions.
Post reply on HN