15 ms·

Rust had to be dragged kicking and screaming into integration with other languages, and its C++ compatibility is a joke compared to Swift. It's absolutely true

Rust had to be dragged kicking and screaming into integration with other languages, and its C++ compatibility is a joke compared to Swift. It's absolutely true that you need integration and compatibility to enable iterative improvements, but Rust historically has been hostile to anything besides unsafe C ABI FFI, which is not suitable for the vast majority of incremental development that needs to happen. Luckily, this is starting to change.

Philpax 2y ago
"Hostile" is assigning intent that was not present. C++ ABI integration was and is extremely difficult; you need to be able to fully handle C++ semantics and to target each platform's take on the ABI. Most C++ competitors have struggled with this for much the same reason. This means that "solving this" requires partial integration of a C++ compiler; it's not a coincidence that the languages with the most success have been backed by the organisations that already had their own C++ compiler. A much easier solution is to generate glue on both sides, which is what `cxx` does.
- bluGill 2y ago
  If the intent was to interoyerate with c++ then not supporting the api is hostile. I have a lot of code using vector, if I have to convert that to arrays then you are hostile and worse that is new code which per the article makes it suspect d does support c++ abi. It seems almost dead now but it is possible. realistically there are two c++ abis in the world. Itanimum and msvc. both are known well enough that you can imblement them if you want (it is tricky)
  - Philpax 2y ago
    > If the intent was to interoyerate with c++ then not supporting the api is hostile. I have a lot of code using vector, if I have to convert that to arrays then you are hostile and worse that is new code which per the article makes it suspect It's not hostile to not commit resources to integrating with another language. It might be shortsighted, though. > d does support c++ abi. It seems almost dead now but it is possible. That was made possible by Digital Mars's existing C++ compiler and their ability to integrate with it / borrow from it. Rust can't take the same path. Additionally, D's object model is closer to C++ than Rust's is; it's not a 1:1 map, but the task is still somewhat easier. (My D days are approaching a decade ago, so I'm not sure what the current state of affairs is.) > realistically there are two c++ abis in the world. Itanimum and msvc. both are known well enough that you can imblement them if you want (it is tricky) The raw ABI is doable, yeah - but how do you account for the differences in how the languages work? As a simple example - C++ has copy constructors, Rust doesn't. Rust has guarantees around lifetimes, C++ doesn't. What does that look like from a binding perspective? How do you expose that in a way that's amenable to both languages? `cxx`'s approach is to generate lowest-common denominator code that both languages can agree upon. That wouldn't work as a language feature because it requires buy-in from the other side, too.
    - pjmlp 2y ago
      As long as Rust depends on GCC and Clang, it can surely take the same path. I don't see Cranelift ever replacing them as the main backend.
    - bluGill 2y ago
      I'm not arguing rust made the wrong decisions. I'm arguing the concequences of those decisions is hostile to C++ interoperability.
nindalf 2y ago
> Rust had to be dragged kicking and screaming into integration On what basis do you make this flagrant claim? There is certainly an impedance mismatch between Rust and C++, but "kicking and screaming" implies a level of malice that doesn't exist and never existed. Such a low quality comment.
bobajeff 2y ago
>has been hostile to anything besides unsafe C ABI FFI As opposed to integrating with a whole C++ frontend? Gee, I wonder why more languages haven't done this obvious idea of integrating a whole C++ frontend within their build system.
- dadrian 2y ago
  This is the exact attitude I am referring to. Also, Rust already uses LLVM.
  - kibwen 2y ago
    Unfortunately, sharing a codegen backend is neither necessary nor sufficient to enable the sort of seamless high-level cross-language integration that you appear to be requesting.
SkiFire13 2y ago
> Rust had to be dragged kicking and screaming into integration with other languages Rust has integration with the C ABI(s) from day 1, which makes sense because the C ABI(s) are effectively the universal ABI(s). > and its C++ compatibility is a joke I'm not sure why you would want Rust to support interoperability with C++ though, they are very different languages. Moreover why does this fall on Rust? C++ has yet to support integration with Rust! > compared to Swift Swift bundled a whole C++ compiler (Clang) to make it work, that's a complete deal breaker for many. > Rust historically has been hostile to anything besides unsafe C ABI FFI Rust historically has been hostile to making the Rust ABI stable, but not to introducing other optional ABIs. Introducing e.g. a C++ ABI has just not been done because there's no mapping for many features like inheritance, move constructors, etc etc. Ultimately the problem is that most ABIs are either so simple that they're the same as the C ABI or they carry so many features that it's not possible to map them onto a different language.
- maxk42 2y ago
  I would like to point out also that C++ is not yet compatible with itself. Even GCC has dozens of C++ features it doesn't implement and it was the first compiler to implement 100% of C++11: https://gcc.gnu.org/projects/cxx-status.html https://gcc.gnu.org/projects/cxx-status.html
  - bluGill 2y ago
    Technically true but in the real world those are rare edge cases.
    - maxk42 2y ago
      Only because they're not used. If you're not going to implement the spec then is it really a spec?
      - SkiFire13 2y ago
        It could also be argued that they aren't used because not all major compilers implement them.
steveklabnik 2y ago
That was created with the intention of being integrated into a very large C++ codebase. I do agree that they could do more. I find it kind of wild that they haven’t copied Zig’s cross compilation story for example. But this stuff being just fine instead of world class is more of a lack of vision and direction than a hostility towards the idea. Indifference is not malice. Also, you seem to be ignoring the crabi work, which is still not a thing, of course, but certainly isn’t “actively hostile towards non-c ABIs”.
- samatman 2y ago
  I think they had to get over the knee-jerk reaction that Zig was a, quote, "massive step back for the industry", frowny face. It seems they have, which is all to the good: the work to make custom allocators practical in Rust is another example. Rust still doesn't have anything like `std.testing.checkAllAllocationFailures`, but I expect that it will at some future point. Zig certainly learned a lot from Rust, and it's good that Rust is able to do the same. Zig is not, and will not be, a memory-safe language. But the sum of the decisions which go into the language make it categorically different from C (the language is so different from C++ as to make comparisons basically irrelevant). Memory safety is a spectrum, not a binary, or there wouldn't be "Rust" and "safe Rust". What Rust has done is innovative, even revolutionary, but I believe this also applies to Zig in its own way. I view them as representing complementary approaches to the true goal, which is correct software with optimal performance.
  - steveklabnik 2y ago
    While Patrick played a critical role in Rust's history, he said that years after he stopped working on Rust. I haven't seen people still involved share strong opinions about Zig in either direction, to be honest. I've known Andrew for a long time, and am a big fan of languages learning from each other. I have always found that the community of people working on languages is overall much more collegial to each other than their respective communities can be to each other, as a general rule. Obviously there are exceptions.
- dadrian 2y ago

Philpax 2y ago

"Hostile" is assigning intent that was not present. C++ ABI integration was and is extremely difficult; you need to be able to fully handle C++ semantics and to target each platform's take on the ABI. Most C++ competitors have struggled with this for much the same reason. This means that "solving this" requires partial integration of a C++ compiler; it's not a coincidence that the languages with the most success have been backed by the organisations that already had their own C++ compiler. A much easier solution is to generate glue on both sides, which is what `cxx` does.

bluGill 2y ago
If the intent was to interoyerate with c++ then not supporting the api is hostile. I have a lot of code using vector, if I have to convert that to arrays then you are hostile and worse that is new code which per the article makes it suspect d does support c++ abi. It seems almost dead now but it is possible. realistically there are two c++ abis in the world. Itanimum and msvc. both are known well enough that you can imblement them if you want (it is tricky)
- Philpax 2y ago
  > If the intent was to interoyerate with c++ then not supporting the api is hostile. I have a lot of code using vector, if I have to convert that to arrays then you are hostile and worse that is new code which per the article makes it suspect It's not hostile to not commit resources to integrating with another language. It might be shortsighted, though. > d does support c++ abi. It seems almost dead now but it is possible. That was made possible by Digital Mars's existing C++ compiler and their ability to integrate with it / borrow from it. Rust can't take the same path. Additionally, D's object model is closer to C++ than Rust's is; it's not a 1:1 map, but the task is still somewhat easier. (My D days are approaching a decade ago, so I'm not sure what the current state of affairs is.) > realistically there are two c++ abis in the world. Itanimum and msvc. both are known well enough that you can imblement them if you want (it is tricky) The raw ABI is doable, yeah - but how do you account for the differences in how the languages work? As a simple example - C++ has copy constructors, Rust doesn't. Rust has guarantees around lifetimes, C++ doesn't. What does that look like from a binding perspective? How do you expose that in a way that's amenable to both languages? `cxx`'s approach is to generate lowest-common denominator code that both languages can agree upon. That wouldn't work as a language feature because it requires buy-in from the other side, too.
  - pjmlp 2y ago
    As long as Rust depends on GCC and Clang, it can surely take the same path. I don't see Cranelift ever replacing them as the main backend.
  - bluGill 2y ago
    I'm not arguing rust made the wrong decisions. I'm arguing the concequences of those decisions is hostile to C++ interoperability.

nindalf 2y ago

> Rust had to be dragged kicking and screaming into integration On what basis do you make this flagrant claim? There is certainly an impedance mismatch between Rust and C++, but "kicking and screaming" implies a level of malice that doesn't exist and never existed. Such a low quality comment.

bobajeff 2y ago

>has been hostile to anything besides unsafe C ABI FFI As opposed to integrating with a whole C++ frontend? Gee, I wonder why more languages haven't done this obvious idea of integrating a whole C++ frontend within their build system.

dadrian 2y ago
This is the exact attitude I am referring to. Also, Rust already uses LLVM.
- kibwen 2y ago
  Unfortunately, sharing a codegen backend is neither necessary nor sufficient to enable the sort of seamless high-level cross-language integration that you appear to be requesting.

SkiFire13 2y ago

> Rust had to be dragged kicking and screaming into integration with other languages Rust has integration with the C ABI(s) from day 1, which makes sense because the C ABI(s) are effectively the universal ABI(s). > and its C++ compatibility is a joke I'm not sure why you would want Rust to support interoperability with C++ though, they are very different languages. Moreover why does this fall on Rust? C++ has yet to support integration with Rust! > compared to Swift Swift bundled a whole C++ compiler (Clang) to make it work, that's a complete deal breaker for many. > Rust historically has been hostile to anything besides unsafe C ABI FFI Rust historically has been hostile to making the Rust ABI stable, but not to introducing other optional ABIs. Introducing e.g. a C++ ABI has just not been done because there's no mapping for many features like inheritance, move constructors, etc etc. Ultimately the problem is that most ABIs are either so simple that they're the same as the C ABI or they carry so many features that it's not possible to map them onto a different language.

maxk42 2y ago
I would like to point out also that C++ is not yet compatible with itself. Even GCC has dozens of C++ features it doesn't implement and it was the first compiler to implement 100% of C++11: https://gcc.gnu.org/projects/cxx-status.html https://gcc.gnu.org/projects/cxx-status.html
- bluGill 2y ago
  Technically true but in the real world those are rare edge cases.
  - maxk42 2y ago
    Only because they're not used. If you're not going to implement the spec then is it really a spec?
    - SkiFire13 2y ago
      It could also be argued that they aren't used because not all major compilers implement them.

steveklabnik 2y ago

That was created with the intention of being integrated into a very large C++ codebase. I do agree that they could do more. I find it kind of wild that they haven’t copied Zig’s cross compilation story for example. But this stuff being just fine instead of world class is more of a lack of vision and direction than a hostility towards the idea. Indifference is not malice. Also, you seem to be ignoring the crabi work, which is still not a thing, of course, but certainly isn’t “actively hostile towards non-c ABIs”.

samatman 2y ago
I think they had to get over the knee-jerk reaction that Zig was a, quote, "massive step back for the industry", frowny face. It seems they have, which is all to the good: the work to make custom allocators practical in Rust is another example. Rust still doesn't have anything like `std.testing.checkAllAllocationFailures`, but I expect that it will at some future point. Zig certainly learned a lot from Rust, and it's good that Rust is able to do the same. Zig is not, and will not be, a memory-safe language. But the sum of the decisions which go into the language make it categorically different from C (the language is so different from C++ as to make comparisons basically irrelevant). Memory safety is a spectrum, not a binary, or there wouldn't be "Rust" and "safe Rust". What Rust has done is innovative, even revolutionary, but I believe this also applies to Zig in its own way. I view them as representing complementary approaches to the true goal, which is correct software with optimal performance.
- steveklabnik 2y ago
  While Patrick played a critical role in Rust's history, he said that years after he stopped working on Rust. I haven't seen people still involved share strong opinions about Zig in either direction, to be honest. I've known Andrew for a long time, and am a big fan of languages learning from each other. I have always found that the community of people working on languages is overall much more collegial to each other than their respective communities can be to each other, as a general rule. Obviously there are exceptions.
dadrian 2y ago