6 ms·

> Firefox is shipping Rust code right now. It is, and that is cool. That said, what it's shipping is essentially a separate library written in Rust that expose

by DSMan195276 10y ago

> Firefox is shipping Rust code right now. It is, and that is cool. That said, what it's shipping is essentially a separate library written in Rust that exposes a C API for parsing mp4s - it replaced one libraries usage with another, with a presumably sable API consisting of nothing but C struct's and C functions. Perhaps a key to point out is that it doesn't actually interface with Firefox very much at all - it isn't capable of accessing any Firefox state for instance. I also didn't list Firefox as you'll note - it's not a C project, it's a mishmash of languages already (Mostly JS and C++ from my understanding). I'm really talking about projects that are currently C-only adding in Rust code to the mix - they are structured much differently then a project like Firefox and the interfaces are generally much more complex as far as C goes. I will add though, servo is making pretty impressive efforts. It is again a complete rewrite though, not an integration of Rust into Gecko which is the type of thing I'm talking about. A rewrite of a library in Rust against a stable API is generally possible, depending on the API - though the amount of work may make it prohibitive to get something usable. > There are various examples of Linux kernel modules written in Rust. I would like to see an example of a legitimate Linux Kernel module written in Rust that is in some form of use. I have never seen one besides a toy implementation and I can all but guarantee you it doesn't exist, for the reason that it would be way to much of a hassle to attempt to get it working with the mixture of macros, inline assembly, inline functions, gcc attributes, etc. > There are rewrites of the coreutils in Rust Coreutils is admittedly not a very good example, if only because coreutils isn't actually that big/complex of a project (Though supporting all the GNU flags and arguments is a pretty big task). They're also mostly just separate exe's anyway, so you could replace one or two with Rust code without much of a difference - I'd gladly remove Coreutils from the list if you would like.

teacup50 10y ago
> I would like to see an example of a legitimate Linux Kernel module written in Rust that is in some form of use. Seriously this. I write an awful lot of kernel code. There's absolutely no way I'd try to convince folks to accept Rust code into the OS repository, where it will have to: - Be maintained for decades - Be ported to a litany of platforms, several of which may only have decent toolchains from the GCC department. - Vend stable ABI - Not require keeping a litany of compiler versions around just to keep older code building.
- pcwalton 10y ago
  > - Not require keeping a litany of compiler versions around just to keep older code building. Do you have a single example of this? We keep very close tabs on breakage in the wild even, and especially, for changes we were allowed to make (unlike say GCC, which happily breaks code if the language standard says the code never should have compiled in the first place). There are times when we've refused to make changes that we were allowed to make (because they were changes to unspecified behavior, which C/C++ has more of than Rust, and which GCC/Clang changes all the time) out of concern for breaking existing code. As far as I'm concerned, honestly, this is just FUD.
  - teacup50 10y ago
    Your own release notes contain descriptions of breaking language changes. That may change as the language matures -- great. I keep an eye on Rust so that I can eventually try actually using it for kernel-level development work.
    - steveklabnik 10y ago
      Again, so do C compilers, so does Java, so does every language, even ones that "never break". C11 removed gets, for example.
      - teacup50 10y ago
        javac, gcc, and clang all support some form of -std=<lang_level>, and ABI/source interop between code that uses different language versions. The post-gcc 2.95 C++ ABI breakage was pretty suck, though. [edit] And please don't misinterpret my criticism as intentional FUD. I work on $MAJOR_OS and am achingly tired of writing C, so I keep my eye on Rust as one possible salvation, once it's had time to mature. It's just a very hard sell when there's no ABI stability, we're talking about code that's expected to last for decades, etc.
        steveklabnik 10y ago
Manishearth 10y ago
> That said, what it's shipping is essentially a separate library written in Rust that exposes a C API for parsing mp4s - it replaced one libraries usage with another, with a presumably sable API consisting of nothing but C struct's and C functions. This is true. However, if we put aside the Rust code that is actually shipping, there's still plenty of work going on in sharing Servo's code with Gecko's. One example of this is the ongoing experimental work to move Servo's style system into Gecko. Servo's style system doesn't have much of an "API surface"; everything is a surface. There's plenty of reaching in and grabbing Firefox state and vice versa. Some of this is just done directly by reading or writing to structs. Some of this is done by writing small wrapper C functions (https://dxr.mozilla.org/mozilla-central/source/layout/style/ServoBindings.cpp https://dxr.mozilla.org/mozilla-central/source/layout/style/...) and using bindgen. Bindgen has C++ method/ctor/dtor generation abilities that would obviate almost all of these manual bindings, though we aren't using them yet[1]. Overall, mixing C++ and Rust at a rough API surface in a large codebase hasn't been that hard. It's not easy either, but it's doable and I don't think it's anywhere close to being "nearly impossible without a complete rewrite". [1]: The reason behind this has to do with name mangling -- Rust doesn't understand C++ name mangling, so bindgen generates the mangled function names and wraps them in a nicer API. This is all great, except that it means that the generated bindings stop being cross-platform, and you need to twiddle with the build system to either dynamically generate them or have a way to statically generate them for all platforms. Right now the servo-gecko integration uses a temporary build system that will be replaced soon, so this hasn't been a priority.
pcwalton 10y ago
> macros, inline assembly, inline functions, gcc attributes, Rust supports all of these features. So your complaint is that nobody has written a translator from these things to Rust yet. That's a matter of filing PRs against bindgen, not some basic problem with the language.
- DSMan195276 10y ago
  If you think it is so trivial, then why hasn't it been done yet? Rust macros can't do all the same things that C #define macros can. You can't insert inline C code into Rust code without some serious work. And the fact is, as you pointed out, regardless of in the future, right now it doesn't work, and those features are absolutely necessary for writing something like a Linux Kernel module.

teacup50 10y ago

> I would like to see an example of a legitimate Linux Kernel module written in Rust that is in some form of use. Seriously this. I write an awful lot of kernel code. There's absolutely no way I'd try to convince folks to accept Rust code into the OS repository, where it will have to: - Be maintained for decades - Be ported to a litany of platforms, several of which may only have decent toolchains from the GCC department. - Vend stable ABI - Not require keeping a litany of compiler versions around just to keep older code building.

pcwalton 10y ago
> - Not require keeping a litany of compiler versions around just to keep older code building. Do you have a single example of this? We keep very close tabs on breakage in the wild even, and especially, for changes we were allowed to make (unlike say GCC, which happily breaks code if the language standard says the code never should have compiled in the first place). There are times when we've refused to make changes that we were allowed to make (because they were changes to unspecified behavior, which C/C++ has more of than Rust, and which GCC/Clang changes all the time) out of concern for breaking existing code. As far as I'm concerned, honestly, this is just FUD.
- teacup50 10y ago
  Your own release notes contain descriptions of breaking language changes. That may change as the language matures -- great. I keep an eye on Rust so that I can eventually try actually using it for kernel-level development work.
  - steveklabnik 10y ago
    Again, so do C compilers, so does Java, so does every language, even ones that "never break". C11 removed gets, for example.
    - teacup50 10y ago
      javac, gcc, and clang all support some form of -std=<lang_level>, and ABI/source interop between code that uses different language versions. The post-gcc 2.95 C++ ABI breakage was pretty suck, though. [edit] And please don't misinterpret my criticism as intentional FUD. I work on $MAJOR_OS and am achingly tired of writing C, so I keep my eye on Rust as one possible salvation, once it's had time to mature. It's just a very hard sell when there's no ABI stability, we're talking about code that's expected to last for decades, etc.
      - steveklabnik 10y ago

Manishearth 10y ago

> That said, what it's shipping is essentially a separate library written in Rust that exposes a C API for parsing mp4s - it replaced one libraries usage with another, with a presumably sable API consisting of nothing but C struct's and C functions. This is true. However, if we put aside the Rust code that is actually shipping, there's still plenty of work going on in sharing Servo's code with Gecko's. One example of this is the ongoing experimental work to move Servo's style system into Gecko. Servo's style system doesn't have much of an "API surface"; everything is a surface. There's plenty of reaching in and grabbing Firefox state and vice versa. Some of this is just done directly by reading or writing to structs. Some of this is done by writing small wrapper C functions (https://dxr.mozilla.org/mozilla-central/source/layout/style/ServoBindings.cpp https://dxr.mozilla.org/mozilla-central/source/layout/style/...) and using bindgen. Bindgen has C++ method/ctor/dtor generation abilities that would obviate almost all of these manual bindings, though we aren't using them yet[1]. Overall, mixing C++ and Rust at a rough API surface in a large codebase hasn't been that hard. It's not easy either, but it's doable and I don't think it's anywhere close to being "nearly impossible without a complete rewrite". [1]: The reason behind this has to do with name mangling -- Rust doesn't understand C++ name mangling, so bindgen generates the mangled function names and wraps them in a nicer API. This is all great, except that it means that the generated bindings stop being cross-platform, and you need to twiddle with the build system to either dynamically generate them or have a way to statically generate them for all platforms. Right now the servo-gecko integration uses a temporary build system that will be replaced soon, so this hasn't been a priority.

pcwalton 10y ago

> macros, inline assembly, inline functions, gcc attributes, Rust supports all of these features. So your complaint is that nobody has written a translator from these things to Rust yet. That's a matter of filing PRs against bindgen, not some basic problem with the language.

DSMan195276 10y ago
If you think it is so trivial, then why hasn't it been done yet? Rust macros can't do all the same things that C #define macros can. You can't insert inline C code into Rust code without some serious work. And the fact is, as you pointed out, regardless of in the future, right now it doesn't work, and those features are absolutely necessary for writing something like a Linux Kernel module.