3 ms·
>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 en
by fauigerzigerk 7y ago
>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.
- Const-me 7y ago> 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. > which is obviously extremely undesirable Depends on use case. You wouldn’t want to bring the runtime for a small dependency, but for a large and complex one, like PDF writer or embedded web server, it can be OK. The 2.2 runtime binaries are 25-28MB depending on the platform, not a huge deal. These days, people bring 150MB+ Electron dependency just to render a few strings and colored rectangles :-) > 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. C# and Java and strongly typed, have a lot of static information. I think the main reason why it’s impossible to reliably recompile these languages into non-gc code — circular references.
- fauigerzigerk 7y ago>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.