5 ms·

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 comp

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.

rapsey 6y ago
Not even remotely as difficult as Swift. Rust can call into C at any time. It is ABI compatible and has no VM
- Lukasa 6y ago
  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).
why_only_15 6y ago
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.
- pjmlp 6y ago
  .NET <-> C++/COM also went through a similar process.
  - snuxoll 6y ago
    .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.
    - pjmlp 6y ago
      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.
      - snuxoll 6y ago
        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.
        pjmlp 6y ago
        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.

rapsey 6y ago

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

Lukasa 6y ago
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).

why_only_15 6y ago

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.

pjmlp 6y ago
.NET <-> C++/COM also went through a similar process.
- snuxoll 6y ago
  .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.
  - pjmlp 6y ago
    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.
    - snuxoll 6y ago
      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.
      - pjmlp 6y ago
        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.