6 ms·

It's not the utilities themselves that are the bigger problem - rather a library the utility uses. libbfd in this case. Problem with writing libraries in anythi

It's not the utilities themselves that are the bigger problem - rather a library the utility uses. libbfd in this case. Problem with writing libraries in anything other than C of course is that they are not very usable by a large variety of software.

gizmo686 12y ago
Most languages have some type of "extern C" as part of their FFI. It should be possible to use C as a langua franca between two non C languages.
- blinkingled 12y ago
  > It should be possible to use C Ugh, wouldn't that fall in "just because you can do something doesn't mean you actually should" category? :) Suppose I wrote the library in Go and exported some type of C wrapper and then I loaded that in Rust using Rust->C mechanism - that will load the Golang runtime in Rust! And you still got non-trivial C code to deal with anyways!
  - gizmo686 12y ago
    If you want to interface two languages, then I do not see a way arround involving the runtime of both languages (in the same way that linking to C code still uses the C runtime). However, using my method does not actually involve any C code. "extern C" makes the compiler produce object code that can be called as if it was produced by C code; it does not produce any C code that would compile to the given object code. Of course, it will also produce C headers to give the type information of the exported symbols, but I wouldn't call that code.
steveklabnik 12y ago
It's pretty easy to call into a Rust library from C. The lack of a garbage collector makes embedding Rust quite nice. Lately I've even been playing with a Ruby gem that's a C extension that calls into a Rust .a that exposes itself via extern C.
- blinkingled 12y ago
  Things get uglier when I want to then call the whole shebang from - let's say - Go! Go -> C -> Rust. Now I am paying the penalty for 2 runtimes!
  - SwellJoe 12y ago
    How high is that penalty, relative to, say, loading a variety of C shared libraries? At some point safety and security trumps saving a few kilobytes of memory...in a server environment, that point probably has already been passed a decade ago. Of course, if the penalty is hundreds of megabytes, then the equation might add up differently. But, we already have a huge number of system tools and utilities running in a huge number of languages. Python has become the lingua franca of Linux management tools; Perl was in that role in the past, and still exists in a lot of places; bash and shell are integral. All have separate runtimes, and sometimes interact with system-level C libraries, either directly or through command line interfaces. Is it really that big of a deal to have a Rust or Go shared library in a system that already has a half dozen different languages and a variety of shared and unshared libraries existing at once? I suspect it would be unnoticeable on a modern system. I'd choose safety over shaving a few kilobytes of memory used. There would be a cost in having that interface friction for developers...and we'd be paying that cost for years. But, it seems like both Rust and Go have planned for the languages to be integrated with C libraries from the beginning, so it seems less of a problem. If I were going to attempt such a thing, I'd probably start with the front end utilities that use the libraries and then work my way down to converting the libraries (even though the libraries, in this case, are where the problems lie). But, maybe it's possible to make Go or Rust code that provide the same C interface as the existing libraries...I don't know enough to even guess.
  - steveklabnik 12y ago
    Nope, you can use Rust without the runtime, so you're not _forced_ into paying the overhead.
    - blinkingled 12y ago
      So the Rust library you write is fully self sufficient without calling into any Rust stdlib functions or without using any runtime initialization mechanisms like ctors and dtors? That sounds too good to be true - If I am calling Rust then I am getting the Rust runtime just like if I can strlen I am getting the C library.

gizmo686 12y ago

Most languages have some type of "extern C" as part of their FFI. It should be possible to use C as a langua franca between two non C languages.

blinkingled 12y ago
> It should be possible to use C Ugh, wouldn't that fall in "just because you can do something doesn't mean you actually should" category? :) Suppose I wrote the library in Go and exported some type of C wrapper and then I loaded that in Rust using Rust->C mechanism - that will load the Golang runtime in Rust! And you still got non-trivial C code to deal with anyways!
- gizmo686 12y ago
  If you want to interface two languages, then I do not see a way arround involving the runtime of both languages (in the same way that linking to C code still uses the C runtime). However, using my method does not actually involve any C code. "extern C" makes the compiler produce object code that can be called as if it was produced by C code; it does not produce any C code that would compile to the given object code. Of course, it will also produce C headers to give the type information of the exported symbols, but I wouldn't call that code.

steveklabnik 12y ago

It's pretty easy to call into a Rust library from C. The lack of a garbage collector makes embedding Rust quite nice. Lately I've even been playing with a Ruby gem that's a C extension that calls into a Rust .a that exposes itself via extern C.

blinkingled 12y ago
Things get uglier when I want to then call the whole shebang from - let's say - Go! Go -> C -> Rust. Now I am paying the penalty for 2 runtimes!
- SwellJoe 12y ago
  How high is that penalty, relative to, say, loading a variety of C shared libraries? At some point safety and security trumps saving a few kilobytes of memory...in a server environment, that point probably has already been passed a decade ago. Of course, if the penalty is hundreds of megabytes, then the equation might add up differently. But, we already have a huge number of system tools and utilities running in a huge number of languages. Python has become the lingua franca of Linux management tools; Perl was in that role in the past, and still exists in a lot of places; bash and shell are integral. All have separate runtimes, and sometimes interact with system-level C libraries, either directly or through command line interfaces. Is it really that big of a deal to have a Rust or Go shared library in a system that already has a half dozen different languages and a variety of shared and unshared libraries existing at once? I suspect it would be unnoticeable on a modern system. I'd choose safety over shaving a few kilobytes of memory used. There would be a cost in having that interface friction for developers...and we'd be paying that cost for years. But, it seems like both Rust and Go have planned for the languages to be integrated with C libraries from the beginning, so it seems less of a problem. If I were going to attempt such a thing, I'd probably start with the front end utilities that use the libraries and then work my way down to converting the libraries (even though the libraries, in this case, are where the problems lie). But, maybe it's possible to make Go or Rust code that provide the same C interface as the existing libraries...I don't know enough to even guess.
- steveklabnik 12y ago
  Nope, you can use Rust without the runtime, so you're not _forced_ into paying the overhead.
  - blinkingled 12y ago
    So the Rust library you write is fully self sufficient without calling into any Rust stdlib functions or without using any runtime initialization mechanisms like ctors and dtors? That sounds too good to be true - If I am calling Rust then I am getting the Rust runtime just like if I can strlen I am getting the C library.