Zngur: A C++/Rust interop tool • Hacker News Board

Re: Zngur: A C++/Rust interop tool

#21

Post by tialaramex » Sat, Aug 17, 2024, 10:58 AM UTC

benreesman wrote: post #19

Having only glanced at the code I can’t offer much insight beyond “looks plausible”. A far more important point is to address is that any FFI story with C++ that’s well executed is going to be great for the Rust ecosystem, and historically the community’s commitment to C++ interop has seemed tepid at best. Even if one admits that Rust is strictly better than C++ for problems in the relevant domains, which seems an ex…

> we just can’t rewrite in even a decade, maybe not in a century.

The former claim seems unlikely as stated ("cannot") but is at least plausible in practice ("will not"). The latter makes no sense. C++ didn't exist fifty years ago, so you're asking that we believe somehow C++ was so well suited to some unspecified problems that rewriting software in a better language will take more than twice as long.

Re: Zngur: A C++/Rust interop tool

#22

Post by codetrotter » Sat, Aug 17, 2024, 12:55 PM UTC

tialaramex wrote: post #21

benreesman wrote: post #19

Having only glanced at the code I can’t offer much insight beyond “looks plausible”. A far more important point is to address is that any FFI story with C++ that’s well executed is going to be great for the Rust ecosystem, and historically the community’s commitment to C++ interop has seemed tepid at best. Even if one admits that Rust is strictly better than C++ for problems in the relevant domains, which seems an ex…

> we just can’t rewrite in even a decade, maybe not in a century. The former claim seems unlikely as stated ("cannot") but is at least plausible in practice ("will not"). The latter makes no sense. C++ didn't exist fifty years ago, so you're asking that we believe somehow C++ was so well suited to some unspecified problems that rewriting software in a better language will take more than twice as long.

I mean, there’s a lot of systems out there now that are so relied upon by other systems and people that you literally have to probably be bug for bug compatible with the existing system if you’re gonna have any chance of doing a rewrite of it in another language.

That kind of thing takes time. And all of that time spent is also time that you continuously will have to justify to the executives why exactly we are doing this rewrite again and why there have been 0 new features added to the system because everyone has been busy with the rewrite. Or you assign just part of the people to the rewrite and the rest of the teams continue adding features to the existing system, and now you have to constantly play catch-up. Or everyone is responsible for both rewriting and for adding features, and new features are added into the legacy code and then also written in the new language.

It’s possible. I’ve been on teams that successfully rewrote legacy software in Rust. But until it literally becomes something that directly impacts revenue in an indisputable way – say through fines imposed for security incidents and those incidents being due to memory safety – there’s still a lot of organizations that will completely refuse these kinds of rewrites no matter how good the evidence is that they should be doing so for many reasons.

Re: Zngur: A C++/Rust interop tool

#23

Post by cgio » Sat, Aug 17, 2024, 12:57 PM UTC

tialaramex wrote: post #21

benreesman wrote: post #19

Having only glanced at the code I can’t offer much insight beyond “looks plausible”. A far more important point is to address is that any FFI story with C++ that’s well executed is going to be great for the Rust ecosystem, and historically the community’s commitment to C++ interop has seemed tepid at best. Even if one admits that Rust is strictly better than C++ for problems in the relevant domains, which seems an ex…

> we just can’t rewrite in even a decade, maybe not in a century. The former claim seems unlikely as stated ("cannot") but is at least plausible in practice ("will not"). The latter makes no sense. C++ didn't exist fifty years ago, so you're asking that we believe somehow C++ was so well suited to some unspecified problems that rewriting software in a better language will take more than twice as long.

Rebuilding existing features tends to be deprioritised against building new. In that sense, the process for rebuilding might indeed take longer, even if the new approach is faster to deliver (which in the case discussed probably is not) as it does not happen in vacuum but in parallel with other developments.

Re: Zngur: A C++/Rust interop tool

#24

Post by tialaramex » Sat, Aug 17, 2024, 2:24 PM UTC

npalli wrote: post #6

uneekname wrote: post #5

I've been learning Rust and really enjoying it, but the primary downside (compared to C++) is the lack of access to the large, well-tested libraries that exist in C++. For example, my work would benefit from using the CGAL library [0], something that be nontrivial to rewrite in Rust. As much as I like Rust, at some point it's a better idea to use C++ to tap into libraries like that. Does anyone have thoughts about ho…

So, Zngur allows you to use arbitrary Rust types in C++, store them by value in the C++ stack, and call arbitrary Rust methods and functions on them. But it doesn't bridge any C++ type into Rust, since it is not possible with the same ergonomic You want to use C++ libraries from Rust. This only does interop the other way.

Zngur does allow you to execute arbitrary C++ from Rust.

Unfortunately it chooses to just assume your C++ is sound, it does explicitly warn you that you're signing up for this, but realistically this just doubles down on the known bad assumption in C++ that programmers are infallible.

Rather than (like Rust's native C FFI) marking the arbitrary C++ as unsafe, Zngur chooses to have you explicitly opt in if you want your code marked unsafe. We know from years of practical experience that C++ programmers rely heavily on unstated assumptions for the correctness of code, a practice which does not scale. A very large proportion of the C++ stdlib itself has a narrow contract, yet few practitioners memorise these contracts and they're unchecked - disaster looms.

Re: Zngur: A C++/Rust interop tool

#25

Post by _flux » Sat, Aug 17, 2024, 2:30 PM UTC

heavyset_go wrote: post #12

throwup238 wrote: post #7

Earlier quoted context omitted.

I’m using cxx/cxx-qt in a Rust QT app with substantial interop with Qt/QML and lots of C++ code (because Gpt/Claude make implementing some stuff easier in C++). It’s definitely mature enough because Qt’s libs are no joke. At this point I have a Claude project set up with Cxx documentation and it autogenerates most of my bindings.

How was your experience using Qt with Rust? Is it awkward writing models and QObjects in Rust? I'm a fan of QML and would love to use Rust with it if pleasant Qt bindings are finally there.

Do you know Slint?

I haven't really used it, but it seems to use the same idea, except it's native to Rust but comes with its own C++ and JavaScript bindings. I believe the project was started by some folks that left Qt (or some company that held the IPR at some point..).

Re: Zngur: A C++/Rust interop tool

#26

Post by wavemode » Sat, Aug 17, 2024, 3:41 PM UTC

cgio wrote: post #23

tialaramex wrote: post #21

Earlier quoted context omitted.

> we just can’t rewrite in even a decade, maybe not in a century. The former claim seems unlikely as stated ("cannot") but is at least plausible in practice ("will not"). The latter makes no sense. C++ didn't exist fifty years ago, so you're asking that we believe somehow C++ was so well suited to some unspecified problems that rewriting software in a better language will take more than twice as long.

Rebuilding existing features tends to be deprioritised against building new. In that sense, the process for rebuilding might indeed take longer, even if the new approach is faster to deliver (which in the case discussed probably is not) as it does not happen in vacuum but in parallel with other developments.

Then you would agree that it is more "will not" than "cannot"

Re: Zngur: A C++/Rust interop tool

#27

Post by nestorD » Sat, Aug 17, 2024, 4:59 PM UTC

slimsag wrote: post #10

throwup238 wrote: post #7

Earlier quoted context omitted.

I’m using cxx/cxx-qt in a Rust QT app with substantial interop with Qt/QML and lots of C++ code (because Gpt/Claude make implementing some stuff easier in C++). It’s definitely mature enough because Qt’s libs are no joke. At this point I have a Claude project set up with Cxx documentation and it autogenerates most of my bindings.

Do you have some specific usage of Claude to help? Or how do you use Claude/Gpt for this more precisely?

Not the OP but I have done similar things. Claude has a workspace option that let's you preset a set of documents (here the documentation of the library used) and a system prompt to be included when starting a new chat in the given workspace. Those will be in its, fairly large, context window (overall, independently of its intelligence, I have found Claude current UI to have an edge when dealing with files).

Re: Zngur: A C++/Rust interop tool

#28

Post by gumby » Sat, Aug 17, 2024, 6:30 PM UTC

wavemode wrote: post #26

cgio wrote: post #23

Earlier quoted context omitted.

Rebuilding existing features tends to be deprioritised against building new. In that sense, the process for rebuilding might indeed take longer, even if the new approach is faster to deliver (which in the case discussed probably is not) as it does not happen in vacuum but in parallel with other developments.

Then you would agree that it is more "will not" than "cannot"

You are arguing a distinction without a difference. If socially one could not muster the will to do something then it will never happen -- it cannot be done.

We certainly could reduce the use of fossil fuels by over 90% in a few months -- global nuclear war would probably work -- but I hope nobody has the will to make that happen. Conversely we could reduce them by that much over a 30 year span, but currently lack the will. So in that case the distinction would make sense.

But few are willing to "replace this working thing for a small gain" (and you can argue about rust but when something works and the downside is a statistical risk demonstrably of low probability* ) it will be hard to find many people willing to invest in it.

Eventually these old programs will be replaced but they won't be replaced with functional equivalents, any more than, say, wired home phones were replaced with fibre optic connections. They will be replaced with something de novo instead.

* nerds like us may say the risk is significant but the level of uproar in security breaches is negligible in practice and the actual incidence of bugs due to things like use-after-free is likewise tiny.

Re: Zngur: A C++/Rust interop tool

#29

Post by saghm » Sat, Aug 17, 2024, 6:50 PM UTC

benreesman wrote: post #19

Having only glanced at the code I can’t offer much insight beyond “looks plausible”. A far more important point is to address is that any FFI story with C++ that’s well executed is going to be great for the Rust ecosystem, and historically the community’s commitment to C++ interop has seemed tepid at best. Even if one admits that Rust is strictly better than C++ for problems in the relevant domains, which seems an ex…

> But the “rewrite everything in Rust and push that via bad interop” is limiting the adoption of a cool language.

For what it's worth, I've rarely heard "rewrite it in Rust" pushed by the most influential and productive members of the Rust ecosystem. I think the disparity here is that the people pushing the more extreme agenda aren't the same ones making major projects that people use, so it turns out that most of the stuff being made is for writing new software since that's what the people making it are interested in.

Re: Zngur: A C++/Rust interop tool

#30

Post by wavemode » Sat, Aug 17, 2024, 8:32 PM UTC

gumby wrote: post #28

wavemode wrote: post #26

Earlier quoted context omitted.

Then you would agree that it is more "will not" than "cannot"

You are arguing a distinction without a difference. If socially one could not muster the will to do something then it will never happen -- it cannot be done. We certainly could reduce the use of fossil fuels by over 90% in a few months -- global nuclear war would probably work -- but I hope nobody has the will to make that happen. Conversely we could reduce them by that much over a 30 year span, but currently lack th…

But... there is a difference. The difference is that it will not be done, rather than cannot be done. (Sort of self-explanatory, really.) They're different words, with different meanings, and different real-world consequences.

For example, if government regulations change, or the languages change, or engineering culture changes, or developers' desires and preferences change, suddenly "will not" becomes "will". But "cannot" is not so malleable.