[HN Gopher] Zngur: A C++/Rust interop tool
___________________________________________________________________
Zngur: A C++/Rust interop tool
Author : hkalbasi
Score : 144 points
Date : 2024-08-16 23:27 UTC (23 hours ago)
(HTM) web link (hkalbasi.github.io)
(TXT) w3m dump (hkalbasi.github.io)
| jdright wrote:
| This is insane.
|
| Is this being used in some codebase? How stable is it? What are
| the plans for it?
|
| I have so many questions, but will stick with these for now.
| boguscoder wrote:
| Interesting. Any clue how this compares to https://cxx.rs/
| boguscoder wrote:
| Maybe I should learn to read!
| https://hkalbasi.github.io/zngur/how_it_compares.html
| uneekname wrote:
| 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 how mature Zngur/CXX/etc. are for
| a project like mine? Would it be reasonable to invest effort in
| creating those bindings? Thanks.
|
| [0] https://www.cgal.org/
| npalli wrote:
| 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.
| dkersten wrote:
| It seems to do both:
|
| https://hkalbasi.github.io/zngur/tutorial.html#calling-c-
| fro...
|
| It sound like your quoted text is just saying that it's not
| as ergonomic, you cannot use arbitrary C++ types directly in
| Rust, but you can use arbitrary Rust types in C++.
| ogoffart wrote:
| For calling C++ libraries from Rust, there is also
| https://crates.io/crates/cpp
| tialaramex wrote:
| 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.
| throwup238 wrote:
| 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.
| slimsag wrote:
| Do you have some specific usage of Claude to help? Or how do
| you use Claude/Gpt for this more precisely?
| oneshtein wrote:
| IMHO, he created RAG from documentation to provide more
| context for Claude, so he then can call Claude with a task
| like "Generate bindings in Rust language for C++ class Foo
| from the Bar library.".
| nestorD wrote:
| 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).
| heavyset_go wrote:
| 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.
| _flux wrote:
| 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..).
| heavyset_go wrote:
| I've checked it out and it's on my list of things to
| revisit in the future, but I've been burned in the past
| by using less-proven GUI frameworks, which is why I'm
| trying to stick with something like QML.
|
| It's definitely something that looks promising, though.
| Hope to replace Qt with it in the future if it works out.
| adamnemecek wrote:
| Can you talk more any you Claude use?
| stavros wrote:
| Not the GP, but I use Claude with aider
| (https://aider.chat/) to write much of my chore code. At
| one point I even used it to write a whole mobile app, even
| though I have no experience with mobile.
| bschwindHN wrote:
| I've used cxx.rs to bind to the OpenCascade CAD kernel. It was
| a lot of work but the bindings seem to work well.
| hkalbasi wrote:
| Zngur allows you to write functions operating over Rust types,
| adding methods to Rust types and implementing Rust traits for
| C++ and Rust types inside C++. So you can write a rusty wrapper
| for the C++ library inside C++.
|
| If you want to immediately use a C++ library in Rust with
| minimal manual effort, check out autocxx [0]. Its generated api
| isn't very idiomatic Rust, and it uses Pin, moveit, ... but it
| covers a good percent of C++ apis and you can also make an
| idiomatic wrapper for it in Rust.
|
| [0] https://docs.rs/autocxx/latest/autocxx/
| mastax wrote:
| Wow! Amazing how reframing the problem to exclude C++ types in
| rust makes it all so much more elegant.
| pjmlp wrote:
| This kind of tools are great, as C++ isn't going away any time
| soon, and Rust is decades away to be relevant in some domains,
| specially those where C++ only recently took over C.
| benreesman wrote:
| 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 extraordinary
| claim that exceeds extraordinary evidence, there is still an
| ocean of C++ that we just can't rewrite in even a decade, maybe
| not in a century.
|
| There are use cases where Rust is just strictly a better choice:
| anything with an attack surface like a shell or an SSH daemon, or
| probably even a browser is an obvious candidate for a language
| with better reasoning about common attack vectors. I trust my
| Rust user land a lot more than my C userland.
|
| But the "rewrite everything in Rust and push that via bad
| interop" is limiting the adoption of a cool language.
|
| I'm a big fan of efforts to be more incremental.
| tialaramex wrote:
| > 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.
| codetrotter wrote:
| 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.
| cgio wrote:
| 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.
| wavemode wrote:
| Then you would agree that it is more "will not" than
| "cannot"
| gumby wrote:
| 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.
| wavemode wrote:
| 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.
| saghm wrote:
| > 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.
| hi-v-rocknroll wrote:
| Isn't Google offering funding for this exact topic?
___________________________________________________________________
(page generated 2024-08-17 23:01 UTC)