Hacker News Reader

Comment by nielsbot | Hacker News Reader

Sounds like they have the same problem Apple's Swift does for calling into C/Obj-C.

Two examples: My understanding is that there's a ton of code and added complexity in Swift itself to support Obj-C interoperation. And while you can call C and Obj-C APIs, as-is, there was/is basically a company-wide effort to write API wrappers (aka. overlays) for existing system APIs.

For the second part, maybe if Rust for Linux kernel programming gets to the level of popularity as, say, TypeScript in the JavaScript community, the Linux community will end up creating the needed API wrappers as an organic, group effort.

View on HN

This is mostly just a random tidbit but one of the fascinating things to me about Swift <-> ObjC interop is that it's not just that Swift was modified for ObjC, but ObjC was modified for Swift as well. In general it works pretty well and I wonder how much of that is because Apple can modify ObjC whenever it wants.

.NET <-> C++/COM also went through a similar process.

.Net is a much simpler integration, all of the support is in the CLR because COM defines a limited ABI that can be called from any language that can walk a few pointers in a C++ vtable given an interface definition.

One can even completely ignore the RCW/CCW support in .Net entirely and just hack together some struct types that match the vtable layout.

Old style COM yes, UWP supports much more, value types, enumerations, generics, partial support for implementation inheritance (in context of XAML).

Also you ignored that .NET was made to fully support C++ via Managed C++, replaced with C++/CLI on version 2.0.

The WinRT ABI does implement some new features, yes - but they’re all still implementable with nothing more than standard C# code with no special support from WinRT itself (in fact, the WinRT ABI integration is being stripped out of the runtime and cswinrt is the way forward).

C++/CLI ultimately still uses the same features the runtime uses for p/invoke calls, though it uses slightly different IL to transition to native code since it doesn’t have to worry about an external ABI within a mixed mode assembly. Sure, there’s a whole compiler that supports this weird mixed mode world from a language perspective - but it’s really boring at runtime.

All of that doesn't change the fact that there is tooling in place, and language features (e.g. dynamic for COM, upcoming C#9 improved native FFI) to ease interoperability between managed and some level of C++.

Something that no UNIX does, and we only find similar ideas in Swift/Objective-C++, IBM language environments, and the old OS/2 SOM (Smalltalk/C++).

While everyone else just writes glue code with C like interfaces, as if the world has hardly changed from UNIX V6.

Purists may hate it, but as a toy project I’ve been working on making a stripped-down version of the WinRT concepts that runs on Linux (well, anything with a c++17 compiler and a dlopen function provided by a linker). The guy behind cppwinrt started work on the Xlang project in a similar vein, but it’s currently not being worked on so I figured I’d give it a shot.

I agree that C as the lowest common denominator sucks.

Good luck with it.

Project Reunion seems to have rebooted everything, which is most likely the reason for it to have stalled.

Not even remotely as difficult as Swift. Rust can call into C at any time. It is ABI compatible and has no VM

The same is true of Swift, and Swift can also call into C whenever it likes. The difference is that Swift can do the same for Objective-C at full fidelity, including support the full Objective-C feature set (ARC, arbitrary selectors, interfaces, properties, you name it).

Reply on news.ycombinator.com