3 ms·

How could a safe dynamic linking API ever work? I think you're moving the goalposts significantly here.

by duped 8mo ago

pizlonator 8mo ago
> How could a safe dynamic linking API ever work? Fil-C solves it. I think Swift solves it, too. So it's solvable. No fundamental reason, that I know of, why Rust or any other safe language can't also have some kind of story here. > I think you're moving the goalposts significantly here. No. I'm describing a problem worth solving. Also, I think a major chasm for Rust to cross is how defensive the community gets. It's important to talk about problems so that the problems can be solved. That's how stuff gets better.
- merb 8mo ago
  Swift and fil-c are only pseudo safe. Once you deal with the actual world and need to pass around data from memory things are always unsafe since there is no safe way of sharing memory. At least not in our current operating systems. Swift and fil-c can at least guard to some extent the api.
ninkendo 8mo ago
I don’t think GP is moving the goalposts at all, rather I think a lot of people are willfully misrepresenting GP’s point. Rust-to-rust code should be able to be dynamically linked with an ABI that has better safety guarantees than the C ABI. That’s the point. You can’t even express an Option<T> via the C ABI, let alone the myriad of other things rust has that are put together to make it a safe language. You can look to Swift for prior art on how this can be done: https://faultlore.com/blah/swift-abi/ https://faultlore.com/blah/swift-abi/ It would be very hard to accomplish. Apple was extremely motivated to make Swift have a resilient/stable ABI, because they wanted to author system frameworks in swift and have third parties use them in swift code (including globally updating said frameworks without any apps needing to recompile.) They wanted these frameworks to feel like idiomatic swift code too, not just be a bunch of pointers and manual allocation. There’s a good argument that (1) Rust doesn’t consider this an important enough feature and (2) they don’t have enough resources to accomplish it even if they did. But if you could wave a magic wand and make it “done”, it would be huge for rust adoption.
- pizlonator 8mo ago
  > I don’t think GP is moving the goalposts at all Thank you :-) > It would be very hard to accomplish. Yeah it's a super hard problem especially when you provide safety using the type system! The work the Swift team did here is hella impressive. > But if you could wave a magic wand and make it “done”, it would be huge for rust adoption. Yeah!
- jabl 8mo ago
  > You can look to Swift for prior art on how this can be done: https://faultlore.com/blah/swift-abi/ https://faultlore.com/blah/swift-abi/ > It would be very hard to accomplish. Since Rust cares very much about zero-overhead abstractions and performance, I would guess if something like this were to be implemented, it would have to be via some optional (crate/module/function?) attributes, and the default would remain the existing monomorphization style of code generation.
  - ninkendo 8mo ago
    Swift’s approach still monomorphizes within a binary, and only has runtime costs when calling code across a dylib boundary. I think rust could do something like this as well.
- zozbot234 8mo ago
  > You can’t even express an Option<T> via the C ABI But you can express Option<Foo> for a concrete Foo. Do you really need any more than that?
  - ninkendo 8mo ago
    > But you can express Option<Foo> for a concrete Foo I don’t think that’s true? https://users.rust-lang.org/t/option-is-ffi-safe-or-not/29820/5 https://users.rust-lang.org/t/option-is-ffi-safe-or-not/2982... You could maybe say that a pointer can be transmuted to an Option<&T> because there’s an Option-specific optimization that an Option<&T> uses null as the None value, but that’s not always guaranteed. And it doesn’t apply to non-references, for instance Option<bool>’s None value would be indistinguishable from false. You could get lucky if you launder your Option<T> through repr(C) and the compiler versions match and don’t mangle the internal representation, but there’s no guarantees here, since the ABI isn’t stable. (You even get a warning if you try to put a struct in your function signatures that doesn’t have a stable repr(C).)

How could a safe dynamic linking API ever work? I think you're moving the goalposts significantly here.

by duped 8mo ago

How could a safe dynamic linking API ever work? I think you're moving the goalposts significantly here.

> How could a safe dynamic linking API ever work? Fil-C solves it. I think Swift solves it, too. So it's solvable. No fundamental reason, that I know of, why Rust or any other safe language can't also have some kind of story here. > I think you're moving the goalposts significantly here. No. I'm describing a problem worth solving. Also, I think a major chasm for Rust to cross is how defensive the community gets. It's important to talk about problems so that the problems can be solved. That's how stuff gets better.

merb 8mo ago
Swift and fil-c are only pseudo safe. Once you deal with the actual world and need to pass around data from memory things are always unsafe since there is no safe way of sharing memory. At least not in our current operating systems. Swift and fil-c can at least guard to some extent the api.

ninkendo 8mo ago

I don’t think GP is moving the goalposts at all, rather I think a lot of people are willfully misrepresenting GP’s point. Rust-to-rust code should be able to be dynamically linked with an ABI that has better safety guarantees than the C ABI. That’s the point. You can’t even express an Option<T> via the C ABI, let alone the myriad of other things rust has that are put together to make it a safe language. You can look to Swift for prior art on how this can be done: https://faultlore.com/blah/swift-abi/ https://faultlore.com/blah/swift-abi/ It would be very hard to accomplish. Apple was extremely motivated to make Swift have a resilient/stable ABI, because they wanted to author system frameworks in swift and have third parties use them in swift code (including globally updating said frameworks without any apps needing to recompile.) They wanted these frameworks to feel like idiomatic swift code too, not just be a bunch of pointers and manual allocation. There’s a good argument that (1) Rust doesn’t consider this an important enough feature and (2) they don’t have enough resources to accomplish it even if they did. But if you could wave a magic wand and make it “done”, it would be huge for rust adoption.

pizlonator 8mo ago
> I don’t think GP is moving the goalposts at all Thank you :-) > It would be very hard to accomplish. Yeah it's a super hard problem especially when you provide safety using the type system! The work the Swift team did here is hella impressive. > But if you could wave a magic wand and make it “done”, it would be huge for rust adoption. Yeah!
jabl 8mo ago
> You can look to Swift for prior art on how this can be done: https://faultlore.com/blah/swift-abi/ https://faultlore.com/blah/swift-abi/ > It would be very hard to accomplish. Since Rust cares very much about zero-overhead abstractions and performance, I would guess if something like this were to be implemented, it would have to be via some optional (crate/module/function?) attributes, and the default would remain the existing monomorphization style of code generation.
- ninkendo 8mo ago
  Swift’s approach still monomorphizes within a binary, and only has runtime costs when calling code across a dylib boundary. I think rust could do something like this as well.
zozbot234 8mo ago
> You can’t even express an Option<T> via the C ABI But you can express Option<Foo> for a concrete Foo. Do you really need any more than that?
- ninkendo 8mo ago
  > But you can express Option<Foo> for a concrete Foo I don’t think that’s true? https://users.rust-lang.org/t/option-is-ffi-safe-or-not/29820/5 https://users.rust-lang.org/t/option-is-ffi-safe-or-not/2982... You could maybe say that a pointer can be transmuted to an Option<&T> because there’s an Option-specific optimization that an Option<&T> uses null as the None value, but that’s not always guaranteed. And it doesn’t apply to non-references, for instance Option<bool>’s None value would be indistinguishable from false. You could get lucky if you launder your Option<T> through repr(C) and the compiler versions match and don’t mangle the internal representation, but there’s no guarantees here, since the ABI isn’t stable. (You even get a warning if you try to put a struct in your function signatures that doesn’t have a stable repr(C).)