4 ms·

Stop writing unmanaged code? This is just the same ol' story...

by NKCSS 11y ago

Asmod4n 11y ago
If you want interoperability you are kinda stuck with C. Nearly every Language can use C Libraries either directly or via FFI. While Rust can export functions the same way C does it you are in unmanaged land again then. With http://www.ponylang.org/ http://www.ponylang.org/ its much better, it can export functions like C does it, but its fully managed. The only limitation are the Data Types, you are restricted to those C knows.
- dbaupp 11y ago
  Do you have more info about Pony's ability to expose C-compatible functions? I can't see anything in the docs (e.g. http://tutorial.ponylang.org/c-ffi/c-abi/ http://tutorial.ponylang.org/c-ffi/c-abi/ talks about going the other direction). Also, FWIW, I don't think Rust should be considered unmanaged for these purposes: it bridges the divide between "managed" and "unmanaged" by bringing the memory safety of the former to a language that doesn't require a complicated runtime. So strictly speaking, yes, it's unmanaged, but it doesn't suffer the worst of the problems of existing unmanaged languages like C or C++.
  - Asmod4n 11y ago
    I belive all you have to do is to prefix a Actor or function with a "@" and then call ponyc with --library, which generates a header and library you can use in your c program.
- masklinn 11y ago
  > With http://www.ponylang.org/ http://www.ponylang.org/ its much better, it can export functions like C does it, but its fully managed. You can do that with most "managed" languages. You can call Python, Haskell, Go or OCaml from C, pony isn't exactly special here. One issue in all these cases is you're carrying a whole runtime with you, possibly one per library you're using, praying they don't conflict with one another[0] and limiting the portability of the whole[1]. You're also significantly increasing the cost of using the library in question as it now brings in megabytes of runtime along for the ride. [0] with conflicting signal handling for instance [1] if only because all those runtimes you're bringing in might be doing stuff like spawning their own threads and the like, so that needs to be available on the target platform
- fulafel 11y ago
  Communicating via the C ABI between safe languages isn't inherently unsafe, as long as you drop pointers and other unsafe things from the passed structures. It becomes just another protocol that you handle in your safe language.
  - masklinn 11y ago
    Communicating via the C ABI is as safe as coding in C in the first place. Possibly less as there's a pretty high chance to get the ownership rules wrong on the callee side in a way which'll fault (because the callee will have freed the structure) rather than "just" leak memory (because the caller will not send the structure back for deallocation). Example: https://blog.filippo.io/building-python-modules-with-go-1-5/ https://blog.filippo.io/building-python-modules-with-go-1-5/ in the third snippet (AddDot) the author returns a Go string which may (will?) be freed next time the GC runs[0] regardless of the caller still using it. [0] https://www.reddit.com/r/golang/comments/3ieiiu/building_python_modules_in_go_thanks_to_15/cufrz55 https://www.reddit.com/r/golang/comments/3ieiiu/building_pyt...
    - fulafel 11y ago
      Ownership rules sound a lot like pointers which I excluded. Think pass-by-value structs with only fixed size fields. Or JSON, protobufs etc. (Ok, you need the one pointer for the JSON/PB data, but it's not kept around after null check and decode)
      - masklinn 11y ago
        > Think pass-by-value structs with only fixed size fields. There are (at least) three issues with that: 1. not all FFIs can handle structs, according to the Rust FFI omnibus GHC's doesn't[0] 2. the callee side must be able to express on-stack by-value structs, many (most?) managed languages don't, either not supporting them or having them only as optimisation (based on escape analysis) 3. and finally the layout (and size) of the struct must be deterministic, which further restricts (2) > Or JSON, protobufs etc. (Ok, you need the one pointer for the JSON/PB data, but it's not kept around after null check and decode) Depending on the callee's implementation that may be too late already, there is absolutely no guarantee the data will even go through the FFI without being released, so you'd be relying on garbage data not being zeroed/reused/moved in the interval, which would be an implementation detail. [0] http://jakegoulding.com/rust-ffi-omnibus/tuples/#haskell http://jakegoulding.com/rust-ffi-omnibus/tuples/#haskell

Stop writing unmanaged code? This is just the same ol' story...

by NKCSS 11y ago

Stop writing unmanaged code? This is just the same ol' story...

If you want interoperability you are kinda stuck with C. Nearly every Language can use C Libraries either directly or via FFI. While Rust can export functions the same way C does it you are in unmanaged land again then. With http://www.ponylang.org/ http://www.ponylang.org/ its much better, it can export functions like C does it, but its fully managed. The only limitation are the Data Types, you are restricted to those C knows.

dbaupp 11y ago
Do you have more info about Pony's ability to expose C-compatible functions? I can't see anything in the docs (e.g. http://tutorial.ponylang.org/c-ffi/c-abi/ http://tutorial.ponylang.org/c-ffi/c-abi/ talks about going the other direction). Also, FWIW, I don't think Rust should be considered unmanaged for these purposes: it bridges the divide between "managed" and "unmanaged" by bringing the memory safety of the former to a language that doesn't require a complicated runtime. So strictly speaking, yes, it's unmanaged, but it doesn't suffer the worst of the problems of existing unmanaged languages like C or C++.
- Asmod4n 11y ago
  I belive all you have to do is to prefix a Actor or function with a "@" and then call ponyc with --library, which generates a header and library you can use in your c program.
masklinn 11y ago
> With http://www.ponylang.org/ http://www.ponylang.org/ its much better, it can export functions like C does it, but its fully managed. You can do that with most "managed" languages. You can call Python, Haskell, Go or OCaml from C, pony isn't exactly special here. One issue in all these cases is you're carrying a whole runtime with you, possibly one per library you're using, praying they don't conflict with one another[0] and limiting the portability of the whole[1]. You're also significantly increasing the cost of using the library in question as it now brings in megabytes of runtime along for the ride. [0] with conflicting signal handling for instance [1] if only because all those runtimes you're bringing in might be doing stuff like spawning their own threads and the like, so that needs to be available on the target platform
fulafel 11y ago
Communicating via the C ABI between safe languages isn't inherently unsafe, as long as you drop pointers and other unsafe things from the passed structures. It becomes just another protocol that you handle in your safe language.
- masklinn 11y ago
  Communicating via the C ABI is as safe as coding in C in the first place. Possibly less as there's a pretty high chance to get the ownership rules wrong on the callee side in a way which'll fault (because the callee will have freed the structure) rather than "just" leak memory (because the caller will not send the structure back for deallocation). Example: https://blog.filippo.io/building-python-modules-with-go-1-5/ https://blog.filippo.io/building-python-modules-with-go-1-5/ in the third snippet (AddDot) the author returns a Go string which may (will?) be freed next time the GC runs[0] regardless of the caller still using it. [0] https://www.reddit.com/r/golang/comments/3ieiiu/building_python_modules_in_go_thanks_to_15/cufrz55 https://www.reddit.com/r/golang/comments/3ieiiu/building_pyt...
  - fulafel 11y ago
    Ownership rules sound a lot like pointers which I excluded. Think pass-by-value structs with only fixed size fields. Or JSON, protobufs etc. (Ok, you need the one pointer for the JSON/PB data, but it's not kept around after null check and decode)
    - masklinn 11y ago
      > Think pass-by-value structs with only fixed size fields. There are (at least) three issues with that: 1. not all FFIs can handle structs, according to the Rust FFI omnibus GHC's doesn't[0] 2. the callee side must be able to express on-stack by-value structs, many (most?) managed languages don't, either not supporting them or having them only as optimisation (based on escape analysis) 3. and finally the layout (and size) of the struct must be deterministic, which further restricts (2) > Or JSON, protobufs etc. (Ok, you need the one pointer for the JSON/PB data, but it's not kept around after null check and decode) Depending on the callee's implementation that may be too late already, there is absolutely no guarantee the data will even go through the FFI without being released, so you'd be relying on garbage data not being zeroed/reused/moved in the interval, which would be an implementation detail. [0] http://jakegoulding.com/rust-ffi-omnibus/tuples/#haskell http://jakegoulding.com/rust-ffi-omnibus/tuples/#haskell