3 ms·

Be prepared for issues with ABI incompatibility and all that. Rust is a low level-language, but IMO not a systems language (disclaimer: I tried rust extensively

Be prepared for issues with ABI incompatibility and all that. Rust is a low level-language, but IMO not a systems language (disclaimer: I tried rust extensively over a 2 week period, background is a blend of C, C++ and Haskell from which it draws a lot of influence).

bluejekyll 9y ago
I’m sorry. But claiming Rust is not a systems language is akin to claiming a Volvo is not a car. If you don’t consider Rust to be a systems language, then you’ve got a very skewed perception of what a systems language is. You seem to be alluding to Rusts ABI potentially being an issue, and that’s a fair criticism. Where a stable ABI needs to be exported, Rust supports the C FFI, like almost all other languages.
- frankmcsherry 9y ago
  I've had a bunch of issues getting clean statements about the ABI that actually result in usable guarantees. For example, while you are advised to put `#[repr(C)]` on types you want to have a known layout for FFI, to the best of my understanding this decoration isn't included for generic types like tuples, slices, or `Vec`. Afaiu, Rust reserves the right to change the layout of `(T1, T2)` for `#[repr(C)]` types `T1` and `T2` on a build-by-build basis, which makes a lot of the core types unsuitable for FFI. Anyhow, that's my issue with it as a "systems" language. I can't (yet) write code that compiles down to the minimal operations I believe the computer can do, without re-inventing a non-trivial hunk of the standard library. Or, if I can, I can't find the language in the spec that ensures I won't have to fix things.
  - pcwalton 9y ago
    I don't believe that Rust slices and tuples have unstable ABIs. I guess that isn't documented as well as it could be, though. File an issue perhaps? Isn't std::vector in C++ equally unspecified, though?
    - frankmcsherry 9y ago
      My understanding of the field-reordering work is that it applies to tuples. From http://camlorn.net/posts/April%202017/rust-struct-field-reordering.html http://camlorn.net/posts/April%202017/rust-struct-field-reor...: > The 2000-foot version: Rust structs, enums, and tuples are now automatically smaller in some cases. It's possible for the compiler to work with types whose in-memory field order doesn't match that of your source code. This would mean (again, as I understand it) that you cannot rely on the order of elements in a tuple, if for example you wanted to pass a `&[(T1,T2)]` to some other code (even other Rust code, but built separately). Edit: serious follow up: You've been working with Servo, and I'm assuming at various moments you (pl) need to map in shared libraries that Servo wasn't built with (e.g. codecs, whatever). Do you avoid Rust types in these FFI interfaces, do you rewrap everything, or have pervasive repr(C) type analogues instead? It might be that I'm the only person in the world trying to do Rust-to-Rust FFI, but it feels like (i) it isn't that far from being really tasteful, but (ii) it has a bunch of issues that make it seem that no one has ever tested it (e.g. default allocators being different, weak guarantees about layout).
- banachtarski 9y ago
  your volvo is a car. just not a sports vehicle. i write kernel modules and other "system" libraries. Is the problem that my definition of a "systems language" is too narrow for you? Yea you could say we resort back to the C FFI whenever i need to think about dynamic linkage with modules that may or MAY NOT have been compiled with the same version of rust but jesus is it a tedious process for me.
  - bluejekyll 9y ago
    > Is the problem that my definition of a "systems language" is too narrow for you? I'm suggesting that the exclusion of Rust from that category is wrong. Even with it as narrow as you just defined it, Rust still fits into that category. Is it the best systems language available at the moment? It depends on your context. With TockOS, if you can use that, I would say it is. With Redox and other full OS impls, it's clearly capable as a systems language. With examples of kernel modules for Linux written in Rust, it's again clear that it can work in that environment. By excluding it from that category, it continues a line of FUD against Rust and in favor of C. > Yea you could say we resort back to the C FFI whenever i need to think about dynamic linkage Yeah, this is a bummer. And for the foreseeable This is probably going to be the case (C++ has this same issue, but to less of an extent because it is generally easier to flow between C++ and C). > jesus is it a tedious process for me. Yeah, again, where a strong ABI is needed it's a problem, but there are people working on some solutions to make this easier, for example: C headers to Rust, https://docs.rs/bindgen/0.30.0/bindgen/ https://docs.rs/bindgen/0.30.0/bindgen/ C headers from Rust, https://docs.rs/rusty-cheddar/0.3.3/cheddar/ https://docs.rs/rusty-cheddar/0.3.3/cheddar/ (I'm not sure of the status of the latter, but bindgen is getting a lot of attention right now).
Ar-Curunir 9y ago
2 weeks is a bit short to judge anything by...
- banachtarski 9y ago
  It's enough if I'm using it for the EXPRESS purpose of trying to evaluate a language. If your language can't provide me with enough compelling things after two weeks of trying to like it, I'm going to move on.
banachtarski 9y ago
author's note: lot of butthurt downvotes. HN reaaaaally seems to love Rust.

bluejekyll 9y ago

I’m sorry. But claiming Rust is not a systems language is akin to claiming a Volvo is not a car. If you don’t consider Rust to be a systems language, then you’ve got a very skewed perception of what a systems language is. You seem to be alluding to Rusts ABI potentially being an issue, and that’s a fair criticism. Where a stable ABI needs to be exported, Rust supports the C FFI, like almost all other languages.

frankmcsherry 9y ago
I've had a bunch of issues getting clean statements about the ABI that actually result in usable guarantees. For example, while you are advised to put `#[repr(C)]` on types you want to have a known layout for FFI, to the best of my understanding this decoration isn't included for generic types like tuples, slices, or `Vec`. Afaiu, Rust reserves the right to change the layout of `(T1, T2)` for `#[repr(C)]` types `T1` and `T2` on a build-by-build basis, which makes a lot of the core types unsuitable for FFI. Anyhow, that's my issue with it as a "systems" language. I can't (yet) write code that compiles down to the minimal operations I believe the computer can do, without re-inventing a non-trivial hunk of the standard library. Or, if I can, I can't find the language in the spec that ensures I won't have to fix things.
- pcwalton 9y ago
  I don't believe that Rust slices and tuples have unstable ABIs. I guess that isn't documented as well as it could be, though. File an issue perhaps? Isn't std::vector in C++ equally unspecified, though?
  - frankmcsherry 9y ago
    My understanding of the field-reordering work is that it applies to tuples. From http://camlorn.net/posts/April%202017/rust-struct-field-reordering.html http://camlorn.net/posts/April%202017/rust-struct-field-reor...: > The 2000-foot version: Rust structs, enums, and tuples are now automatically smaller in some cases. It's possible for the compiler to work with types whose in-memory field order doesn't match that of your source code. This would mean (again, as I understand it) that you cannot rely on the order of elements in a tuple, if for example you wanted to pass a `&[(T1,T2)]` to some other code (even other Rust code, but built separately). Edit: serious follow up: You've been working with Servo, and I'm assuming at various moments you (pl) need to map in shared libraries that Servo wasn't built with (e.g. codecs, whatever). Do you avoid Rust types in these FFI interfaces, do you rewrap everything, or have pervasive repr(C) type analogues instead? It might be that I'm the only person in the world trying to do Rust-to-Rust FFI, but it feels like (i) it isn't that far from being really tasteful, but (ii) it has a bunch of issues that make it seem that no one has ever tested it (e.g. default allocators being different, weak guarantees about layout).
banachtarski 9y ago
your volvo is a car. just not a sports vehicle. i write kernel modules and other "system" libraries. Is the problem that my definition of a "systems language" is too narrow for you? Yea you could say we resort back to the C FFI whenever i need to think about dynamic linkage with modules that may or MAY NOT have been compiled with the same version of rust but jesus is it a tedious process for me.
- bluejekyll 9y ago
  > Is the problem that my definition of a "systems language" is too narrow for you? I'm suggesting that the exclusion of Rust from that category is wrong. Even with it as narrow as you just defined it, Rust still fits into that category. Is it the best systems language available at the moment? It depends on your context. With TockOS, if you can use that, I would say it is. With Redox and other full OS impls, it's clearly capable as a systems language. With examples of kernel modules for Linux written in Rust, it's again clear that it can work in that environment. By excluding it from that category, it continues a line of FUD against Rust and in favor of C. > Yea you could say we resort back to the C FFI whenever i need to think about dynamic linkage Yeah, this is a bummer. And for the foreseeable This is probably going to be the case (C++ has this same issue, but to less of an extent because it is generally easier to flow between C++ and C). > jesus is it a tedious process for me. Yeah, again, where a strong ABI is needed it's a problem, but there are people working on some solutions to make this easier, for example: C headers to Rust, https://docs.rs/bindgen/0.30.0/bindgen/ https://docs.rs/bindgen/0.30.0/bindgen/ C headers from Rust, https://docs.rs/rusty-cheddar/0.3.3/cheddar/ https://docs.rs/rusty-cheddar/0.3.3/cheddar/ (I'm not sure of the status of the latter, but bindgen is getting a lot of attention right now).

Ar-Curunir 9y ago

2 weeks is a bit short to judge anything by...

banachtarski 9y ago
It's enough if I'm using it for the EXPRESS purpose of trying to evaluate a language. If your language can't provide me with enough compelling things after two weeks of trying to like it, I'm going to move on.

banachtarski 9y ago

author's note: lot of butthurt downvotes. HN reaaaaally seems to love Rust.