4 ms·

So how easy would it be to use Rust to compile libraries to be called from non-Rust systems? I've seen reference to using #[start] and #[no_std] but it wasn't

by sixbrx 13y ago

So how easy would it be to use Rust to compile libraries to be called from non-Rust systems? I've seen reference to using #[start] and #[no_std] but it wasn't clear with the latter just how much of "std" I'd be giving up? Hopefully that would mean just giving up task spawning and inter-task communication (ok), or would it be everything under the std namespace (not so ok)? Making this easy would be an easy win to get Rust into active use incrementally. Rust would for example be able to do heavy lifting in computations with Python/Cython providing a web front end dispatcher.

eridius 13y ago
#[start] only applies to executables, not libraries. #[no_std] means that no part of libstd would be provided. This is typically expected to be used by, say, kernel developers. libstd itself is statically linked (by default) into your built product, so if you want you can compile your Rust library and use it on a system that has never had Rust installed.
kibwen 13y ago
It's not very difficult at all to call Rust libraries from other languages by using #[no_std] and exposing a C API. You're correct in that this does currently dispose of the entire standard library, which is rather unfortunate. We're still exploring options for partitioning the stdlib into levels such that you can lose just the stuff that needs a runtime (heap allocation, concurrency) without losing all the other goodies (overloaded operators, iterators, etc.)
- brson 13y ago
  Rust can be called from other languages even with std. The main thing you'll be missing is the ability to handle task failure (which will just cause a process abort), but also protection from stack overflow. For full integration it will require a small amount of runtime API that is yet to be determined.
  - kibwen 13y ago
    I'd really love to see an update to your "Calling Rust from Ruby" post detailing these new features.
ben0x539 13y ago
If you just link some rust code into a C program without #[no_std], once you call anything that makes use of the runtime, it will abort with a lovecraftian error message and a stack trace because it asserts that the runtime exists and has placed some info into thread-local storage. It'll run until then, though! If you'll only call into rust from a single C-created thread, you could start that thread through a shim that starts up the rust runtime. Rust code can then spawn its own threads in there and all of std might just work.
- dbaupp 13y ago
  I don't think #[no_std] has any effect here, other that guaranteeing that know runtime-using functions are called (by not linking in any runtime at all). I believe you can also just start runtimes in each call into Rust. Obviously it won't be particularly efficient.
  - ben0x539 13y ago
    That's what I meant re: no_std, yeah. Would it be possible to lazily start libnative if a call into the runtime is made but there's none there, but then keep it running for that thread for subsequent calls?
    - dbaupp 13y ago
      Maybe? The current design is starting a runtime is a blocking call, though, i.e. I think you'd call `native::run`[1] and run anything needing a runtime inside that (I haven't experimented with this part of our FFI in detail). [1]: http://static.rust-lang.org/doc/master/native/fn.run.html http://static.rust-lang.org/doc/master/native/fn.run.html
steveklabnik 13y ago
The third production deployment of Rust is as a Ruby extension. I'm on my phone, but if you look up the 'SprocketNES' edition of the Bay Area Rust Users Group, you can see wycats talk about the details.

by sixbrx 13y ago

eridius 13y ago

#[start] only applies to executables, not libraries. #[no_std] means that no part of libstd would be provided. This is typically expected to be used by, say, kernel developers. libstd itself is statically linked (by default) into your built product, so if you want you can compile your Rust library and use it on a system that has never had Rust installed.

kibwen 13y ago

It's not very difficult at all to call Rust libraries from other languages by using #[no_std] and exposing a C API. You're correct in that this does currently dispose of the entire standard library, which is rather unfortunate. We're still exploring options for partitioning the stdlib into levels such that you can lose just the stuff that needs a runtime (heap allocation, concurrency) without losing all the other goodies (overloaded operators, iterators, etc.)

brson 13y ago
Rust can be called from other languages even with std. The main thing you'll be missing is the ability to handle task failure (which will just cause a process abort), but also protection from stack overflow. For full integration it will require a small amount of runtime API that is yet to be determined.
- kibwen 13y ago
  I'd really love to see an update to your "Calling Rust from Ruby" post detailing these new features.

ben0x539 13y ago

If you just link some rust code into a C program without #[no_std], once you call anything that makes use of the runtime, it will abort with a lovecraftian error message and a stack trace because it asserts that the runtime exists and has placed some info into thread-local storage. It'll run until then, though! If you'll only call into rust from a single C-created thread, you could start that thread through a shim that starts up the rust runtime. Rust code can then spawn its own threads in there and all of std might just work.

dbaupp 13y ago
I don't think #[no_std] has any effect here, other that guaranteeing that know runtime-using functions are called (by not linking in any runtime at all). I believe you can also just start runtimes in each call into Rust. Obviously it won't be particularly efficient.
- ben0x539 13y ago
  That's what I meant re: no_std, yeah. Would it be possible to lazily start libnative if a call into the runtime is made but there's none there, but then keep it running for that thread for subsequent calls?
  - dbaupp 13y ago
    Maybe? The current design is starting a runtime is a blocking call, though, i.e. I think you'd call `native::run`[1] and run anything needing a runtime inside that (I haven't experimented with this part of our FFI in detail). [1]: http://static.rust-lang.org/doc/master/native/fn.run.html http://static.rust-lang.org/doc/master/native/fn.run.html

steveklabnik 13y ago

The third production deployment of Rust is as a Ruby extension. I'm on my phone, but if you look up the 'SprocketNES' edition of the Bay Area Rust Users Group, you can see wycats talk about the details.