
Objective-Rust - ingve
https://belkadan.com/blog/2020/08/Objective-Rust/
======
cornstalks
Funny enough, this is exactly what my objrs crate is meant for:
[https://gitlab.com/objrs/objrs](https://gitlab.com/objrs/objrs)

You can implement new Objective-C classes directly in Rust. Or use Objective-C
classes/methods from Rust. objrs is mostly a collection of macros that
transforms the Rust code to be ABI-compatible with normal Objective-C code.
There isn't any runtime work done by objrs. It's all done at compile time.

Here's an example of creating an new class:

    
    
      #[objrs(class, super = NSObject)]
      pub struct StringCollection {
        strings: Vec<String>,
      }
    
      #[objrs(impl)]
      impl StringCollection {
        #[objrs(selector = "new", no_impl)]
        pub fn new() -> objrs::Strong<StringCollection> {}
    
        #[objrs(selector = "printStrings")]
        pub fn print_strings(&self) {
          for string in self.strings.iter() {
            println!("String: {}", string);
          }
        }
      }
    

I'm still slowly rewriting it. It requires nightly Rust, and unfortunately
doesn't compile with the latest nightly. And it doesn't currently build from
HEAD. But it's been a fun hobby project.

~~~
epage
This is reminding me that I'd love to see experiments with macro's for
implementing Swift's ABI, not for Swift interop but to explore the space of a
more native, unsafe-free SO/DLL ABI for Rust than what C offers.

~~~
terhechte
[https://github.com/rustswift/swift-
bindgen](https://github.com/rustswift/swift-bindgen)

tries to offer #[repr(Swift_5)]

------
raphlinus
I hope Rust / Objective-C interop gets some more love soon. There are a number
of pain points, including inconsistent wrapping styles (the "cocoa" crate
implements things like NSView as traits on id), autorelease pools always being
a pain, and a fair amount of bloat from the msg_send! macro (a lot of which is
boilerplate error handling).

Not exactly obj-C, but there are also problems two inconsistent ways of
wrapping other macOS types: some (like the Metal crate) use foreign_types,
while others use the TCFType mechanism. Among other things, these have two
different meanings for "Ref" types, which can be very confusing.

So it's possible to get stuff done, but it doesn't feel nice. By contrast, the
Rust/Windows world pretty well organized, with Peter Atashian's winapi
providing a solid foundation, the wio crate being a good way to get ComPtr and
other utilities, and Microsoft's com-rs coming soon as a standard way to do
Rust-side implementation of COM interfaces.

~~~
Klonoar
I experimented with this in cacao:
[https://github.com/ryanmcgrath/cacao](https://github.com/ryanmcgrath/cacao)

I just need to get around to "finishing" it. I think most of the other
approaches miss what people would realistically need out of ObjC/Rust interop,
so... well, that's my hat in the ring.

~~~
raphlinus
Yup, that is a promising direction. I think a lot of my concern is around
building a consensus and getting people on the same page.

------
samatman
Seeing the headline gave me an immediate rush, mixing horror and fascination.

The article did not disappoint.

------
jasonhansel
I actually think this could be developed into something very useful. Rust is a
lot cleaner than Swift, and proper Objective-C interop could make it a viable
alternative for app development.

(I'd avoid trying to replicate ObjC's syntax, though, since it's the worst
part of that language.)

~~~
saagarjha
Swift and Objective-C share a memory model, though, which Rust does not. I
suspect that any Rust code that interoperates with Objective-C will never be
"cleaner" than the corresponding Swift code.

~~~
Klonoar
I mean, it depends on the Swift code you write - basic example which could be
done fairly closely:
[https://github.com/ryanmcgrath/cacao/blob/trunk/examples/aut...](https://github.com/ryanmcgrath/cacao/blob/trunk/examples/autolayout.rs)

Having written my fair share of both languages, I don't think they're as far
apart as people think... yet, anyway.

I doubt my response will age well.

------
xixixao
I tried something similar in Nim. While fun, ultimately I was faced with the
reality of a lack of proper typing and other tooling support, which would be a
mountain of work to add on top.

------
JacobCarlborg
D has had native interoperability support for Objective-C for a couple of
years now:
[https://dlang.org/spec/objc_interface.html](https://dlang.org/spec/objc_interface.html).

------
Trufa
Sometimes I’m truly amazed with what fellow programmers are able to do.

