5 ms·

Great, now I want the same for Rust <-> C++

LegionMammal978 5y ago
I've asked around a bit, and so far I've found no language or tool that can directly access C++ libraries without manually writing bindings. I hope that can change sometime in the near future.
- pzo 5y ago
  There is one -> Objective-C++ - interop is very seamless (just change file extension from .m to .mm). I do hope as well that will change and we will see some other languages speaking to c++ so easily.
- gavinray 5y ago
  I know of two languages: 1. D (https://dlang.org/spec/cpp_interface.html https://dlang.org/spec/cpp_interface.html) 2. Nim. Though this is a bit cheap because Nim is a frontend to C(++), so you're really writing C++ that calls other C++ when it boils down to it. See https://nim-lang.org/docs/manual.html#implementation-specific-pragmas-importcpp-pragma https://nim-lang.org/docs/manual.html#implementation-specifi...
torquemodwanted 5y ago
Not a working group, but a library does exist: https://cxx.rs/ https://cxx.rs/
- dljsjr 5y ago
  The difference is that cxx is doing codegen to create a C ABI compatible bridge. So the same thing most people already do when they want to interact w/ C++ over FFI. I believe that TFA is actually saying that the Swift compiler speaks C++ directly without doing any codegen and just handles everything at the compilation level. Same end result but a lot of subtle differences. Not having to do codegen is a big win, especially in Rust where compile times aren't terrific and binary sizes can already bloat up due to the statically linked nature.
- rvz 5y ago
  I hope one does not need to write the signatures manually and tweak the cxx generator, for detecting flags, types and the like just to get it properly working. If that's the case, then that would be tons of maintenance and more trouble than its worth for a more complex C++ codebase. Best to make that a first party feature built into the language compiler and have it do the majority of the work automatically rather than manually define the C++ types, functions, etc using a third party library.
- dureuill 5y ago
  Yes, cxx.rs is really good for what it is! There's also autocxx that aims at generating cxx bridges directly. What Rust lacks is, to my knowledge, a C++ interoperability working group. cxx.rs (which is useable but by no means finished) could be a topic of such a working group. Direct compiler support of C++ could be another. A better C++ rust interop story is a critical piece for Rust's success IMO
lowbloodsugar 5y ago
Funny, my cynical brain read the Swift/C++ announcement as two dead languages fighting for relevance, in the face of Rust, by banding together. Fuck Rust <-> C++. Let C++ die! ;-) (only half joking)
- HNSucksAss 5y ago
- pjmlp 5y ago
  So when is Apple going to rewrite IO and Driver Kit, and re-base Metal Shading Language in Rust? If C++ dies Rust will have a hard time replacing its GCV/LLVM backends. Cranelift as it stands today won't do it.
  - estebank 5y ago
    >> Let C++ die! > So when is Apple going to rewrite IO and Driver Kit, and re-base Metal Shading Language in Rust? Death of a language isn't a clear cut thing that really happens, so everyone has their own definition. Some consider a language dead when they fall from former glory, so for a popular language they don't need to disappear, they can even have multiple thriving niches and still be considered "dead" because they are a portion of the usage they used to have (see Python 2, still widely in use, but I can make argument to call it "dead"). Others consider a language dead when direct competitors are used instead of them for new projects (see Perl). Yet others consider a language dead when there's an active and thriving effort to migrate existing applications to other languages. All of these are varying interpretations of "dead language". I would call Delphi, Perl, Python 2 "dead", yet there are plenty of projects in use out there written in those languages, and in some cases even thriving communities. But even if their absolute numbers don't decrease, the rest of the world might continue to out grow them into "irrelevance" (whatever one might want to consider that to be). All that to say: C++ doesn't need to disappear to "die", it doesn't need to die for other langs to thrive, and it doesn't need to "die" even if other languages thrive. It is not a zero-sum game. > If C++ dies Rust will have a hard time replacing its GCV/LLVM backends. > Cranelift as it stands today won't do it. You're comparing a 20 year old project (LLVM) with a 4 year old project (cranelift) that have different goals. It's like comparing Rust and Python, or Fiat and Cannondale: they have some similarities, but any comparison is gonna be stretched beyond use.

I've asked around a bit, and so far I've found no language or tool that can directly access C++ libraries without manually writing bindings. I hope that can change sometime in the near future.

pzo 5y ago
There is one -> Objective-C++ - interop is very seamless (just change file extension from .m to .mm). I do hope as well that will change and we will see some other languages speaking to c++ so easily.
gavinray 5y ago
I know of two languages: 1. D (https://dlang.org/spec/cpp_interface.html https://dlang.org/spec/cpp_interface.html) 2. Nim. Though this is a bit cheap because Nim is a frontend to C(++), so you're really writing C++ that calls other C++ when it boils down to it. See https://nim-lang.org/docs/manual.html#implementation-specific-pragmas-importcpp-pragma https://nim-lang.org/docs/manual.html#implementation-specifi...

torquemodwanted 5y ago

Not a working group, but a library does exist: https://cxx.rs/ https://cxx.rs/

dljsjr 5y ago
The difference is that cxx is doing codegen to create a C ABI compatible bridge. So the same thing most people already do when they want to interact w/ C++ over FFI. I believe that TFA is actually saying that the Swift compiler speaks C++ directly without doing any codegen and just handles everything at the compilation level. Same end result but a lot of subtle differences. Not having to do codegen is a big win, especially in Rust where compile times aren't terrific and binary sizes can already bloat up due to the statically linked nature.
rvz 5y ago
I hope one does not need to write the signatures manually and tweak the cxx generator, for detecting flags, types and the like just to get it properly working. If that's the case, then that would be tons of maintenance and more trouble than its worth for a more complex C++ codebase. Best to make that a first party feature built into the language compiler and have it do the majority of the work automatically rather than manually define the C++ types, functions, etc using a third party library.
dureuill 5y ago
Yes, cxx.rs is really good for what it is! There's also autocxx that aims at generating cxx bridges directly. What Rust lacks is, to my knowledge, a C++ interoperability working group. cxx.rs (which is useable but by no means finished) could be a topic of such a working group. Direct compiler support of C++ could be another. A better C++ rust interop story is a critical piece for Rust's success IMO

lowbloodsugar 5y ago

Funny, my cynical brain read the Swift/C++ announcement as two dead languages fighting for relevance, in the face of Rust, by banding together. Fuck Rust <-> C++. Let C++ die! ;-) (only half joking)

HNSucksAss 5y ago
pjmlp 5y ago
So when is Apple going to rewrite IO and Driver Kit, and re-base Metal Shading Language in Rust? If C++ dies Rust will have a hard time replacing its GCV/LLVM backends. Cranelift as it stands today won't do it.
- estebank 5y ago
  >> Let C++ die! > So when is Apple going to rewrite IO and Driver Kit, and re-base Metal Shading Language in Rust? Death of a language isn't a clear cut thing that really happens, so everyone has their own definition. Some consider a language dead when they fall from former glory, so for a popular language they don't need to disappear, they can even have multiple thriving niches and still be considered "dead" because they are a portion of the usage they used to have (see Python 2, still widely in use, but I can make argument to call it "dead"). Others consider a language dead when direct competitors are used instead of them for new projects (see Perl). Yet others consider a language dead when there's an active and thriving effort to migrate existing applications to other languages. All of these are varying interpretations of "dead language". I would call Delphi, Perl, Python 2 "dead", yet there are plenty of projects in use out there written in those languages, and in some cases even thriving communities. But even if their absolute numbers don't decrease, the rest of the world might continue to out grow them into "irrelevance" (whatever one might want to consider that to be). All that to say: C++ doesn't need to disappear to "die", it doesn't need to die for other langs to thrive, and it doesn't need to "die" even if other languages thrive. It is not a zero-sum game. > If C++ dies Rust will have a hard time replacing its GCV/LLVM backends. > Cranelift as it stands today won't do it. You're comparing a 20 year old project (LLVM) with a 4 year old project (cranelift) that have different goals. It's like comparing Rust and Python, or Fiat and Cannondale: they have some similarities, but any comparison is gonna be stretched beyond use.