16 ms·

Rust and C++ Interoperability

235 points by ogoffart 4y ago

armchairhacker 4y ago
Does anyone have experience using Slint do develop GUI in Rust? GUI in Rust is a hot topic, and to me it seems SlintUI may be the best general-purpose so far. The reason is rapid iteration and a flexible/intuitive layout system: Slint lets you write UI in a DSL with live preview and style/layout influenced by HTML and CSS, whereas competitors (egui, druid, iced) require you to write the GUI in Rust (which means you must rebuild and rerun to see changes) and have their own style/layout rules. Other competitors are GTK and Qt, but those have their own flaws and moreover, were designed way before Rust and seem to be less "idiomatic".
- dilawar 4y ago
  We are developing UI in slint-rs for our product. Our eventiual target is IoT devices (cyber defense) though we are starting with desktops. We are a young startup and our experience is very limited in UI space so please take all of it with a pinch of salt. One of our intern got the UI working with Slint in a few days and since then we didn't feel a strong need to move away from it. We found a few missing features: it was not possible to tell if a Windows is hidden or not. We ended up sending a few patches. So far our experience has been pretty good with slint-ui. We are not tested the UI on OSX and Linux yet, only windows. On AWS machines with Windows server, the UI fails to launch sometimes because of some missing GL libraries. Also note the licensing of Slint-UI https://github.com/slint-ui/slint/discussions/379 https://github.com/slint-ui/slint/discussions/379.
  - wizwit999 4y ago
    - ogoffart 4y ago
      Maintainer here :-). Would you like to elaborate?
      - wizwit999 4y ago
        Well the repeated obfuscation between 'product' and 'code' when someone asked you how an open source project with an Apache License can depend on your project. Realistically, there's no way a project with a fully permissive license like Apache/MIT can use your project. You say: > The GPL is a good fit for open source users As the thread tells you, it's clearly not for the many Apache/MIT licensed Rust projects that cannot use your GPL licensed code. Again you say: > With the GPL, we are happy to let open source users use the library for free. Commercial users still will be able to use the library because of the escape hatch of the dual license. You make this differentiation between commercial and open source users while conveniently ignoring that the most permissively open source projects (Apache/MIT) are practically prevented from using your software. At least with BSL, projects are honest about what they're doing. Don't play both sides.
        ogoffart 4y ago
        I stand by what I said Because Apache/MIT is compatible with the GPL, it is totally fine for people who like to license their code in Apache/MIT to do so. An example of that is KHTML, the web engine: KHTML was licensed under LGPL, despite it was based on Qt in very deep ways (usage of core feature such as QString, QList, all over the place). Qt was GPL at the time. Even then, Apple was able to take KHTML, and remove the Qt dependency, in order to create WebKit which is fully LGPL. One can totally make a "more permissive" product based on Slint. If someone wants to use the extra permissions that are not granted by the GPL, they still have the option to do so by purchasing a license, or using the free Slint license, or (worst case) porting away from Slint.
        pclmulqdq 4y ago
        I think the confusing part to the parent comment is that they don't understand that your GPL license infects their project, but not the code they write for that project (which can be MIT or Apache). Personally, I'm not a big fan of licenses like GPL and BSL, but you do you. I just won't use your product.
    - Xylakant 4y ago
      Why do you believe the maintainer is disingenuous? They are very open about their reasons to pick GPL as their license. We don’t have to like it but it’s their code and their right to choose. They’re not pulling some weird kind of bait and switch, they’re upfront about wanting to sell commercial licenses to commercial enterprises - a pretty common business model. The available licenses are prominently displayed in the readme. Looks all perfectly fine to me.
      - mk89 4y ago
        They are actually very clever about it. There is literally 0 alternative in the Rust world: this is what the "gpl competitive advantage" is about.
        tronical 4y ago
        We're not trying to be clever, TBH. There are many excellent alternatives out there in the Rust world. Our choice of Rust is primarily a technical choice, and later we found out that it's also a fantastic community to be part of. Most of us have our roots in the open source world, many (most?) of us learned coding because we were able to look at open source code, make changes to it, recompile and play with it. We're trying to give back to the open source community and at the same time earn a living by asking the people who use Slint for proprietary apps (i.e. not giving back) to support us by purchasing a license.
        OkayPhysicist 4y ago
        Frankly, that's a fantastic use of the GPL. The idea that open source developers should bend over backwards to support the use case of people who can't be assed to give back to the open source community is ridiculous. If a company wants to make proprietary software off the back of open source developers, they can pay for a commercial license. Everyone else is free to use the GPL. All other so-called "free" licenses are just a way for corporations to co-opt the open source software community.
  - Herbstluft 4y ago
    Wow that linked request is really something. Requesting/Suggesting the change of license is one thing. But this is just another example of a blatant lack of respect towards open source devs and maintainers. The misinformed GPL hatred displayed there is also ridiculous.
    - pie_flavor 4y ago
      Could you name, specifically, the true things they do not know or the false things that they think they know? Or is 'misinformed' here simply a way of saying that you disagree, and have no such preference for people not requiring you to license your own code a certain way?
      - bsder 4y ago
        It's not about whether it is true or not. Requesting a license change from a project that you are not a primary maintainer is more than a little rude. However, continuing to request a license change even after the owners have explained why they chose the license is an astonishing level of entitlement. If you don't like the license, don't use the project. That's the deal--take it or leave it.
        pie_flavor 4y ago
        "Misinformed" is, in fact, about whether something is true.
- gattr 4y ago
  I use GTK3 with Rust for my video acquisition tool [1] and it's been quite pleasant so far. However, from my testing GTK3 & 4 don't play nice with OpenGL drawing areas, so the next project I'm writing (also in Rust) using Dear ImGUI. [1] https://github.com/GreatAttractor/vidoxide https://github.com/GreatAttractor/vidoxide
not2b 4y ago
"The situation on the C++ side isn't too different: The ABI is compiler defined. This is why you can not mix libraries generated with MSVC and GCC." There is a multi-vendor C++ ABI, honored by clang, GCC, Intel's proprietary compiler, and others. It doesn't solve all problems, but provides interoperability.
- dataflow 4y ago
  I never got why ABI incompatibility is such a big problem. Why does every non-Windows compiler insist on bringing a non-Windows ABI to Windows? Why can't people just respect whatever the convention on each platform is and move on? It's not like you need ABIs to be cross-compatible across platforms.
  - fsloth 4y ago
    I suppose the key reason is ABI is not defined by the language standard? Nor is it is something (AFAIK) that would be standardized on Windows. This is not the same thing as binary compatibility on windows but rather about the internals of virtual function tables and so on. There are other problems as well from the "hands off" quality of the standard. Endemic of how bad the situation is regarding C++ DLL:s is that you can't free memory in a different C++ DLL than where it was allocated. Well, you _can_ but most of the time you shouldn't.
    - dataflow 4y ago
      > I suppose the key reason is ABI is not defined by the language standard? Nor is it is something (AFAIK) that would be standardized on Windows. This is not the same thing as binary compatibility on windows but rather about the internals of virtual function tables and so on. Not really. Windows already has specific ABIs that it follows (in NTDLL, MSVCRT, COM DLLs), etc., and that includes virtual functions and exception tables and unwinding and all that. MSVC follows them fine. There's no reason other compilers shouldn't be able to. They just don't seem to want to. > There are other problems as well from the "hands off" quality of the standard. Sure, but none of them imply "it's better to defy the convention by default". You still lessen the friction by following the convention. > Endemic of how bad the situation is regarding C++ DLL:s is that you can't free memory in a different C++ DLL than where it was allocated. Well, you _can_ but most of the time you shouldn't. That's an orthogonal problem, it's not like you're somehow making that problem any easier by switching to a different ABI than what you know is already conventional on the platform.
sahidoona 4y ago
[flagged]
zozbot234 4y ago
This blogpost should really mention the autocxx and crubit crates. There's a lot more to Rust/C++ interop than what they cover, and work on it is very much ongoing.
- kolbe 4y ago
  I think the link time optimization work is amazing as well. Calling out to different languages can really suck without whole program optimization, even if both the rust and the c++ sides are fully optimized, but taking the LLVM bit code of each and then running optimizations those bridges that gap.
eco 4y ago
Great article. Answered a lot of questions I've had as I toy with the idea of making part of a C++ project in Rust. Regarding Slint and all the other new GUI toolkits, one thing I don't understand is why they all seem to completely ignore any controls more complicated than the basics (buttons, checkboxes, drop downs, spin controls, sliders, radio buttons, and a basic list control). A To-Do app is a proof of concept, not an endgame. Beyond those basics I need combo boxes, date time pickers, color pickers, font pickers (fonts are hard, I get it, but my users expect access to system fonts), dockable windows, splits, tabs, modal dialogs, tooltips, masked text input, auto completion text input, context menus, calendar controls, file and directory pickers. Some of the new toolkits offer an assortment of these, including Slint but they rarely get all of them but the biggest thing missing from pretty much all of them are sophisticated data grids (both list and tree varieties). They need support for custom cell rendering, custom cell edit controls, and variable row heights. They also need to be fast even with tens of thousands of rows. Oh, and think about your printing story. You don't print a UI obviously but if I'm rendering diagrams and stuff using your rendering facilities I at least need a way to hook them up to the platform's system without just duplicating all of the drawing to a completely different rendering API to make printing work. This isn't a dig on Slint. I'm eagerly watching it, along with egui, as I desperately look for a cross platform alternative to all the legacy stuff I'm neck deep in. I just can't consider anything that has no good support for data dense applications.
- antihero 4y ago
  I think one of the issues with going beyond the basics is that once you start to tackle more advanced controls you not only have to be more opinionated, as there’s many ways to achieve these things, but also they become for more specific use cases and thus creating a general solution has exponential complexity.
  - zarzavat 4y ago
    What people want from a UI library is to be able to use system components. For example, there should be a way to open the system color picker, to display a system data grid, system date picker, etc. It doesn’t need to be more than that.
harryjadon 4y ago
[dead]
harryjadon 4y ago
Great article. Answered a lot of questions I've had as I toy with the idea of making part of a C++ project in Rust.
- booleandilemma 4y ago
  Your comment is worded exactly the same way as this person's comment: https://news.ycombinator.com/item?id=33591111 https://news.ycombinator.com/item?id=33591111 Are you the same person? I'm just curious. It's a funny coincidence :)
  - harryjadon 4y ago
    [dead]
virtualritz 4y ago
This seems to miss `cppmm` (C++--)[1]. This crate is currently mainly aimed at helping people from the Rust group of the Academy Software Foundation (ASWF) to make wrappers for the visual effects ecosystem of libs.[2] It is nevertheless very useful for all types of other cases. [1] https://github.com/vfx-rs/cppmm https://github.com/vfx-rs/cppmm [2] The above just means effort is prioritized regarding the blockers these libs present due to the resp. C++ features they use.
- zozbot234 4y ago
  Great, so now we have cxx, autocxx, crubit and cppmm. The Rust folks should convene an actual Working Group on this issue, there's clearly a lot of demand for a solution.
  - tobias12345 4y ago
    The problem is that the different crates typically address certain sub-eco-systems and produce better results for that one dialekt spoken there. It is hard to generalize all that.
- tobias12345 4y ago
  I missed more: There are a lot of tools out there addressing special cases. Those typically address certain C++ sub-eco-systems that follow certain rules that make the mapping in some special cases better. Most of these are either built on top of cxx or are similar in spirit. So I did not list all of them. The original presentation was only 30 min and there is only so much you can ask a person to read in a blog post:-) I did try to make it clear that my list is in no way exhaustive.
mkoubaa 4y ago
The carbon project for c++ defines some fixed ABI types in the standard library to enable things like this. I hope that c++ can learn from that - I tried to propose fixed ABI types in the standard a few years back but didn't get very far
rajman187 4y ago
I have used CXX in a project where I had to use a library available only in C++. There were Python bindings but somehow they were very slow. I could have rolled out my own pybind11 but wanted some of the Rust guarantees. It was probably more convoluted than necessary since I also then exposed the Rust lib to Python, so C++ <=> Rust <=> Python , but it was indeed fun to implement it all. https://github.com/dtolnay/cxx https://github.com/dtolnay/cxx
- htfy96 4y ago
  There's also a more blasphemy-ish approach of interop between C++ and Rust if the C++ code already have good Python bindings: C++ <=> Python <=> Rust. It's not bad as you may think. My company uses it to adapt C++ to Rust without rewriting the 40K LOC Pybind11 boilerplate. Going through the Python interpreter is definitely slower than a native call but perhaps <3x since we only rely on Python being a hosted + GC environment, plus it's much easier to express lifetime in Rust given that everything is managed on Python heap.
hda2 4y ago
I really hope one of these approaches gets bundled with the official (or gcc) toolchain one day. C++ is widespread enough that it should be supported directly like C and not require downloading yet another deptree from crates.io.

235 points by ogoffart 4y ago

Does anyone have experience using Slint do develop GUI in Rust? GUI in Rust is a hot topic, and to me it seems SlintUI may be the best general-purpose so far. The reason is rapid iteration and a flexible/intuitive layout system: Slint lets you write UI in a DSL with live preview and style/layout influenced by HTML and CSS, whereas competitors (egui, druid, iced) require you to write the GUI in Rust (which means you must rebuild and rerun to see changes) and have their own style/layout rules. Other competitors are GTK and Qt, but those have their own flaws and moreover, were designed way before Rust and seem to be less "idiomatic".

dilawar 4y ago
We are developing UI in slint-rs for our product. Our eventiual target is IoT devices (cyber defense) though we are starting with desktops. We are a young startup and our experience is very limited in UI space so please take all of it with a pinch of salt. One of our intern got the UI working with Slint in a few days and since then we didn't feel a strong need to move away from it. We found a few missing features: it was not possible to tell if a Windows is hidden or not. We ended up sending a few patches. So far our experience has been pretty good with slint-ui. We are not tested the UI on OSX and Linux yet, only windows. On AWS machines with Windows server, the UI fails to launch sometimes because of some missing GL libraries. Also note the licensing of Slint-UI https://github.com/slint-ui/slint/discussions/379 https://github.com/slint-ui/slint/discussions/379.
- wizwit999 4y ago
  - ogoffart 4y ago
    Maintainer here :-). Would you like to elaborate?
    - wizwit999 4y ago
      Well the repeated obfuscation between 'product' and 'code' when someone asked you how an open source project with an Apache License can depend on your project. Realistically, there's no way a project with a fully permissive license like Apache/MIT can use your project. You say: > The GPL is a good fit for open source users As the thread tells you, it's clearly not for the many Apache/MIT licensed Rust projects that cannot use your GPL licensed code. Again you say: > With the GPL, we are happy to let open source users use the library for free. Commercial users still will be able to use the library because of the escape hatch of the dual license. You make this differentiation between commercial and open source users while conveniently ignoring that the most permissively open source projects (Apache/MIT) are practically prevented from using your software. At least with BSL, projects are honest about what they're doing. Don't play both sides.
      - ogoffart 4y ago
        I stand by what I said Because Apache/MIT is compatible with the GPL, it is totally fine for people who like to license their code in Apache/MIT to do so. An example of that is KHTML, the web engine: KHTML was licensed under LGPL, despite it was based on Qt in very deep ways (usage of core feature such as QString, QList, all over the place). Qt was GPL at the time. Even then, Apple was able to take KHTML, and remove the Qt dependency, in order to create WebKit which is fully LGPL. One can totally make a "more permissive" product based on Slint. If someone wants to use the extra permissions that are not granted by the GPL, they still have the option to do so by purchasing a license, or using the free Slint license, or (worst case) porting away from Slint.
        pclmulqdq 4y ago
        I think the confusing part to the parent comment is that they don't understand that your GPL license infects their project, but not the code they write for that project (which can be MIT or Apache). Personally, I'm not a big fan of licenses like GPL and BSL, but you do you. I just won't use your product.
  - Xylakant 4y ago
    Why do you believe the maintainer is disingenuous? They are very open about their reasons to pick GPL as their license. We don’t have to like it but it’s their code and their right to choose. They’re not pulling some weird kind of bait and switch, they’re upfront about wanting to sell commercial licenses to commercial enterprises - a pretty common business model. The available licenses are prominently displayed in the readme. Looks all perfectly fine to me.
    - mk89 4y ago
      They are actually very clever about it. There is literally 0 alternative in the Rust world: this is what the "gpl competitive advantage" is about.
      - tronical 4y ago
        We're not trying to be clever, TBH. There are many excellent alternatives out there in the Rust world. Our choice of Rust is primarily a technical choice, and later we found out that it's also a fantastic community to be part of. Most of us have our roots in the open source world, many (most?) of us learned coding because we were able to look at open source code, make changes to it, recompile and play with it. We're trying to give back to the open source community and at the same time earn a living by asking the people who use Slint for proprietary apps (i.e. not giving back) to support us by purchasing a license.
        OkayPhysicist 4y ago
        Frankly, that's a fantastic use of the GPL. The idea that open source developers should bend over backwards to support the use case of people who can't be assed to give back to the open source community is ridiculous. If a company wants to make proprietary software off the back of open source developers, they can pay for a commercial license. Everyone else is free to use the GPL. All other so-called "free" licenses are just a way for corporations to co-opt the open source software community.
- Herbstluft 4y ago
  Wow that linked request is really something. Requesting/Suggesting the change of license is one thing. But this is just another example of a blatant lack of respect towards open source devs and maintainers. The misinformed GPL hatred displayed there is also ridiculous.
  - pie_flavor 4y ago
    Could you name, specifically, the true things they do not know or the false things that they think they know? Or is 'misinformed' here simply a way of saying that you disagree, and have no such preference for people not requiring you to license your own code a certain way?
    - bsder 4y ago
      It's not about whether it is true or not. Requesting a license change from a project that you are not a primary maintainer is more than a little rude. However, continuing to request a license change even after the owners have explained why they chose the license is an astonishing level of entitlement. If you don't like the license, don't use the project. That's the deal--take it or leave it.
      - pie_flavor 4y ago
        "Misinformed" is, in fact, about whether something is true.
gattr 4y ago
I use GTK3 with Rust for my video acquisition tool [1] and it's been quite pleasant so far. However, from my testing GTK3 & 4 don't play nice with OpenGL drawing areas, so the next project I'm writing (also in Rust) using Dear ImGUI. [1] https://github.com/GreatAttractor/vidoxide https://github.com/GreatAttractor/vidoxide

not2b 4y ago

"The situation on the C++ side isn't too different: The ABI is compiler defined. This is why you can not mix libraries generated with MSVC and GCC." There is a multi-vendor C++ ABI, honored by clang, GCC, Intel's proprietary compiler, and others. It doesn't solve all problems, but provides interoperability.

dataflow 4y ago
I never got why ABI incompatibility is such a big problem. Why does every non-Windows compiler insist on bringing a non-Windows ABI to Windows? Why can't people just respect whatever the convention on each platform is and move on? It's not like you need ABIs to be cross-compatible across platforms.
- fsloth 4y ago
  I suppose the key reason is ABI is not defined by the language standard? Nor is it is something (AFAIK) that would be standardized on Windows. This is not the same thing as binary compatibility on windows but rather about the internals of virtual function tables and so on. There are other problems as well from the "hands off" quality of the standard. Endemic of how bad the situation is regarding C++ DLL:s is that you can't free memory in a different C++ DLL than where it was allocated. Well, you _can_ but most of the time you shouldn't.
  - dataflow 4y ago
    > I suppose the key reason is ABI is not defined by the language standard? Nor is it is something (AFAIK) that would be standardized on Windows. This is not the same thing as binary compatibility on windows but rather about the internals of virtual function tables and so on. Not really. Windows already has specific ABIs that it follows (in NTDLL, MSVCRT, COM DLLs), etc., and that includes virtual functions and exception tables and unwinding and all that. MSVC follows them fine. There's no reason other compilers shouldn't be able to. They just don't seem to want to. > There are other problems as well from the "hands off" quality of the standard. Sure, but none of them imply "it's better to defy the convention by default". You still lessen the friction by following the convention. > Endemic of how bad the situation is regarding C++ DLL:s is that you can't free memory in a different C++ DLL than where it was allocated. Well, you _can_ but most of the time you shouldn't. That's an orthogonal problem, it's not like you're somehow making that problem any easier by switching to a different ABI than what you know is already conventional on the platform.

sahidoona 4y ago

[flagged]

zozbot234 4y ago

This blogpost should really mention the autocxx and crubit crates. There's a lot more to Rust/C++ interop than what they cover, and work on it is very much ongoing.

kolbe 4y ago
I think the link time optimization work is amazing as well. Calling out to different languages can really suck without whole program optimization, even if both the rust and the c++ sides are fully optimized, but taking the LLVM bit code of each and then running optimizations those bridges that gap.

eco 4y ago

Great article. Answered a lot of questions I've had as I toy with the idea of making part of a C++ project in Rust. Regarding Slint and all the other new GUI toolkits, one thing I don't understand is why they all seem to completely ignore any controls more complicated than the basics (buttons, checkboxes, drop downs, spin controls, sliders, radio buttons, and a basic list control). A To-Do app is a proof of concept, not an endgame. Beyond those basics I need combo boxes, date time pickers, color pickers, font pickers (fonts are hard, I get it, but my users expect access to system fonts), dockable windows, splits, tabs, modal dialogs, tooltips, masked text input, auto completion text input, context menus, calendar controls, file and directory pickers. Some of the new toolkits offer an assortment of these, including Slint but they rarely get all of them but the biggest thing missing from pretty much all of them are sophisticated data grids (both list and tree varieties). They need support for custom cell rendering, custom cell edit controls, and variable row heights. They also need to be fast even with tens of thousands of rows. Oh, and think about your printing story. You don't print a UI obviously but if I'm rendering diagrams and stuff using your rendering facilities I at least need a way to hook them up to the platform's system without just duplicating all of the drawing to a completely different rendering API to make printing work. This isn't a dig on Slint. I'm eagerly watching it, along with egui, as I desperately look for a cross platform alternative to all the legacy stuff I'm neck deep in. I just can't consider anything that has no good support for data dense applications.

antihero 4y ago
I think one of the issues with going beyond the basics is that once you start to tackle more advanced controls you not only have to be more opinionated, as there’s many ways to achieve these things, but also they become for more specific use cases and thus creating a general solution has exponential complexity.
- zarzavat 4y ago
  What people want from a UI library is to be able to use system components. For example, there should be a way to open the system color picker, to display a system data grid, system date picker, etc. It doesn’t need to be more than that.

harryjadon 4y ago

[dead]

harryjadon 4y ago

Great article. Answered a lot of questions I've had as I toy with the idea of making part of a C++ project in Rust.

booleandilemma 4y ago
Your comment is worded exactly the same way as this person's comment: https://news.ycombinator.com/item?id=33591111 https://news.ycombinator.com/item?id=33591111 Are you the same person? I'm just curious. It's a funny coincidence :)
- harryjadon 4y ago
  [dead]

virtualritz 4y ago

This seems to miss `cppmm` (C++--)[1]. This crate is currently mainly aimed at helping people from the Rust group of the Academy Software Foundation (ASWF) to make wrappers for the visual effects ecosystem of libs.[2] It is nevertheless very useful for all types of other cases. [1] https://github.com/vfx-rs/cppmm https://github.com/vfx-rs/cppmm [2] The above just means effort is prioritized regarding the blockers these libs present due to the resp. C++ features they use.

zozbot234 4y ago
Great, so now we have cxx, autocxx, crubit and cppmm. The Rust folks should convene an actual Working Group on this issue, there's clearly a lot of demand for a solution.
- tobias12345 4y ago
  The problem is that the different crates typically address certain sub-eco-systems and produce better results for that one dialekt spoken there. It is hard to generalize all that.
tobias12345 4y ago
I missed more: There are a lot of tools out there addressing special cases. Those typically address certain C++ sub-eco-systems that follow certain rules that make the mapping in some special cases better. Most of these are either built on top of cxx or are similar in spirit. So I did not list all of them. The original presentation was only 30 min and there is only so much you can ask a person to read in a blog post:-) I did try to make it clear that my list is in no way exhaustive.

mkoubaa 4y ago

The carbon project for c++ defines some fixed ABI types in the standard library to enable things like this. I hope that c++ can learn from that - I tried to propose fixed ABI types in the standard a few years back but didn't get very far

rajman187 4y ago

I have used CXX in a project where I had to use a library available only in C++. There were Python bindings but somehow they were very slow. I could have rolled out my own pybind11 but wanted some of the Rust guarantees. It was probably more convoluted than necessary since I also then exposed the Rust lib to Python, so C++ <=> Rust <=> Python , but it was indeed fun to implement it all. https://github.com/dtolnay/cxx https://github.com/dtolnay/cxx

htfy96 4y ago
There's also a more blasphemy-ish approach of interop between C++ and Rust if the C++ code already have good Python bindings: C++ <=> Python <=> Rust. It's not bad as you may think. My company uses it to adapt C++ to Rust without rewriting the 40K LOC Pybind11 boilerplate. Going through the Python interpreter is definitely slower than a native call but perhaps <3x since we only rely on Python being a hosted + GC environment, plus it's much easier to express lifetime in Rust given that everything is managed on Python heap.

hda2 4y ago

I really hope one of these approaches gets bundled with the official (or gcc) toolchain one day. C++ is widespread enough that it should be supported directly like C and not require downloading yet another deptree from crates.io.